apdu-rtoac
NF03/002
RTTPapdu ::=
--
priority
-- NF04/002
[2] ANY OPTIONAL
NF04/001
NF05/002
SessionConnectionIdentifier ::=
NF05/002
[0] ANY,
NF05/001
NF05/002
CHOICE{
NF05/002
OCTET STRING
NF05/002
Formules
TEXTE
8.1.1.1.3.1 Disk. 256 NF01/007 (OPM: 01) NF01/010 (OPM: 01) NF01/010 (OPM: 01) Disk. 257 NF01/025 (OPM: 02) (cs,1 NF02/016) - (cs,2 NF02/018)
(1BT) (BT..)
(85.TE.12.S)
(A1.23s) / [26s]
FOLIOS: 409 - 449
(DO PRC.COSY.2)
MEP {TPS.NON.PHOTO "[PA1]"} : OK= [1]
Saisie 89.03.02 SD
ID + LASER 15.03.89 CW
MAJ diskette 15.03.89 CW
Corr. LASER (1re épreuve) = 3eme ........ ..
AJOUTER (PA1) (CL1,0,0,0) pour MEP
MEP + LASER 6.04.89 CJ
Corr. MEP ........ ..
Insertion des tableaux (tabulateurs...) ........ ..
Corr. BAT 17.04.89 PM
MAJ DISKETTE ........ ..
8 Relación de correspondencia con los servicios
utilizados
En este punto se define cómo una MPTF transfiere las UDPA por medio de:
a)los servicios ESCA; o
b)el servicio de presentación.
En el 8.1 se define la relación de correspondencia con los servicios ESCA y en el 8.2 la relación de correspondencia con el servicio de presentación.
Se supone la identificación de la sintaxis abstracta denominada en uso para todos los servicios del ESTF y tiene una relación de correspondencia con los servicios utilizados; sin embargo este es un asunto de carácter local y está fuera del alcance de esta Recomendación.
8.1
Relación de correspondencia con los servicios ESCA
En este punto se define cómo las primitivas de servicio ESCA descritas en la Recomendación X.217 son utilizadas por la MPTF. En el cuadro 8»X.228 se define la relación de correspondencia de las primitivas de servicio y de las UDPA de ESTF con las primitivas de servicio ESCA.
Cuadro 8/X.228 [T8.228], p.
En el
8.1.1
se define la relación de correspondencia con ESCA en
modo normal. En el
8.1.2
se define la relación de correspondencia
con ESCA en el modo X.410-1984.
8.1.1
Relación de correspondencia con los servicios ESCA
en modo normal
8.1.1.1
Procedimiento de establecimiento de la
asociación
El procedimiento de establecimiento de la asociación se produce simultáneamente con el establecimiento de asociación de ESCA subyacente.
8.1.1.1.1
Parámetros directamente relacionados
Los siguientes parámetros de las primtivas de servicio TF-APERTURA tienen una correspondencia directa con los parámetros correspondientes de las primitivas de servicio A-ASOCIACIóN:
a)modo
b)nombre de contexto de aplicación
c)título PA llamante
d)identificador de invocación PA llamante
e)calificador EA llamante
f)identificador de invocación EA llamante
g)título PA llamado
h)identificador de invocación PA llamado
i)calificador EA llamado
j)identificador de invocación EA llamado
k)título PA respondedor
l)identificador de invocación PA respondedor
m)calificador EA respondedor
n)identificador de invocación EA respondedor
o)fuente de resultado
p)diagnóstico
q)dirección de presentación llamante
r)dirección de presentación llamada
s)dirección de presentación respondedora
t)lista de definiciones del contexto de presentación
u)lista de resultados de definición del contexto de presentación
v)nombre del contexto de presentación por defecto
w)resultado del contexto de presentación por defecto.
8.1.1.1.2
Parámetros no utilizados
No se utilizan los siguientes parámetros de las primitivas de servicio A-ASOCIACIóN:
a)requisito de presentación
b)número de serie del punto de sincronización inicial.
8.1.1.1.3
Utilización de otros parámetros de primitivas
Petición e Indicación A-ASOCIACIóN
8.1.1.1.3.1
Información de usuario
Para las primitivas Petición e Indicación A-ASOCIACIóN, el parámetro información de usuario se utiliza para transportar la UDPA TFAPT
8.1.1.1.3.2
Calidad de servicio
Los parámetros
`Control ampliado'
y
`Transferencia de diálogo
optimizada'
se ponen a
`no requeridos'
. Los parámetros restantes se
ponen de modo que se utilicen valores por defecto.
8.1.1.1.3.3
Requisitos de sesión
Este parámetro es fijado por la MPTF iniciadora de asociación para seleccionar las siguientes unidades funcionales:
a)unidad funcional semiduplex
b)unidad funcional de excepciones
c)unidad funcional de sincronización menor
d)unidad funcional de gestión de actividad.
8.1.1.1.3.4
Asignación inicial de testigos
La MPTF iniciadora de asociación solicitará siempre que el testigo de datos esté disponible para las interacciones monólogo o bidireccional alternada.
La MPTF iniciadora de asociación especificará cuál MPTF retendrá inicialmente el testigo de datos (testigo de sincronización menor y testigo mayor/actividad) después de la terminación satisfactoria de la fase de conexión de sesión, de acuerdo con el parámetro de turno inicial de la primitiva Petición TF-APERTURA.
La MPTF iniciadora de asociación asignará todos los testigos a la misma MPTF. La asociación de aplicación puede ser rechazada si se viola esta regla. En cualquier momento determinado, la MPTF poseedora de los testigos se denomina MPTF emisora, y la otra MPTF receptora.
8.1.1.1.3.5
Identificador de conexión de sesión
La MPTF iniciadora de asociación suministrará un identificador de conexión de sesión, que se utilizará para identificar inequívocamente la conexión de sesión. Este identificador está formado por los siguientes componentes: referencia de usuario-SS, referencia común y, facultativamente, información de referencia adicional. La referencia de usuario-SS es transportada como la referencia de usuario-SS llamante por la MPTF iniciadora de asociación. La referencia común y la información de referencia transicional son transportadas en parámetros denominados similarmente de la primitiva P-CONEXIóN.
Cada componente, cuando está presente, contendrá un elemento de datos del tipo apropiado de acuerdo con las siguientes definiciones.
CallingSSuserReference :: =
CHOICE{
T61String
--
sólo en el modo
X.410-1984
--,
OCTET STRING
--
sólo en modo normal
-- }
CommonReference :: = UTCTime
AdditionalReferenceInformation :: = T61String
8.1.1.1.4
Utilización de los otros parámetros de las
primitivas Respuesta y Confirmación A-ASOCIACIóN
8.1.1.1.4.1
Información de usuario
Nota
- Este parámetro sólo es pertinente si la
asociación de aplicación es aceptada por el proveedor de servicio ESCA.
Para las primitivas Respuesta y Confirmación A-ASOCIACIóN el parámetro información de usuario se utiliza para transportar la UDPA TFAAC, si la asociación de aplicación es aceptada; o la UDPA TFARCH si la asociación de aplicación es rechazada por la MPTF respondedora de asociación, o por el respondedor de asociación.
8.1.1.1.4.2
Resultado
Para la primitiva Respuesta A-ASOCIACIóN el parámetro resultado es fijado por la MPTF respondedora de asociación como sigue:
a)Si la MPTF respondedora de asociación rechaza la asociación de aplicación,
el valor de este parámetro se pone a
`rechazado (transitorio)'
o
`rechazado (permanente)'
.
b)Si la MPTF respondedora de asociación acepta la petición, el valor de este parámetro se deriva del parámetro resultado de la primitiva Respuesta TF-APERTURA.
8.1.1.1.4.3
Calidad de servicio
Este parámetro tiene el mismo valor que en las primitivas Petición e Indicación A-ASOCIACIóN.
8.1.1.1.4.4
Requisito de sesión
Este parámetro tiene el mismo valor que en las primitivas Petición e Indicación A-ASOCIACIóN.
8.1.1.1.4.5
Asignación inicial de testigos
Este parámetro no se utiliza.
8.1.1.1.4.6
Identificador de conexión de sesión
Este parámetro tiene el mismo valor que en la primitiva Indicación A-ASOCIACIóN. El valor de referencia de usuario-SS llamante de la primitiva Indicación A-ASOCIACIóN es devuelto como referencia de usuario-SS llamado por la MPTF respondedora de asociación.
8.1.1.2
Procedimiento de liberación de asociación
El procedimiento de liberación de asociación se produce simultáneamente con la liberación de asociación ESCA subyacente.
8.1.1.2.1
Parámetros directamente correspondientes
Los siguientes parámetros de las primitivas de servicio TF-CIERRE corresponden directamente con los parámetros correspondientes de las primitivas de servicio A-LIBERACIóN:
a)motivo
b)datos de usuario (e información de usuario).
8.1.1.2.2
Utilización de otros parámetros de las
primitivas Respuesta y Confirmación A-LIBERACIóN
8.1.1.2.2.1
Resultado
El valor de este parámetro es
`afirmativo'
.
8.1.1.3
Aborto de proveedor de asociación
8.1.1.3.1
Utilización de los parámetros de la primitiva
Indicación A-P-ABORTO
La utilización de los parámetros de la primitiva Indicación A-P-ABORTO se define en la Recomendación X.217.
8.1.1.4
Procedimiento de recuperación de asociación
El procedimiento de recuperación de asociación se produce simultáneamente con el establecimiento de la asociación de ESCA subyacente.
8.1.1.4.1
Parámetros del servicio TF-APERTURA
Los siguientes parámetros de las primitivas de servicio TF-APERTURA son almacenadas por las MPTF, y corresponden directamente con los parámetros correspondientes de las primitivas de servicio A-ASOCIACIóN:
a)modo
b)nombre del contexto de aplicación
c)título PA llamante
d)identificador de invocación PA llamante
e)calificador EA llamante
f)identificador de invocación EA llamante
g)título PA llamado
h)identificador de invocación PA llamado
i)calificador EA llamado
j)identificador de invocación EA llamado
k)título PA respondedor
l)identificador de invocación PA respondedor
m)calificador EA respondedor
n)identificador de invocación EA respondedor
o)dirección de presentación llamante
p)dirección de presentación llamada
q)dirección de presentación respondedora
r)lista de definiciones del contexto de presentación
s)lista de resultados de definición del contexto de presentación
t)nombre del contexto de presentación por defecto
u)resultado del contexto de presentación por defecto.
8.1.1.4.2
Parámetros no utilizados
No se utilizan los siguientes parámetros de las primitivas de servicio A-ASOCIACIóN:
a)requisitos de presentación
b)número de serie del punto de sincronización inicial.
8.1.1.4.3
Parámetros utilizados como en el procedimiento
de establecimiento de asociación
Los siguientes parámetros de las primitivas de servicio A-ASOCIACIóN se utilizan de la misma manera descrita para el procedimiento de establecimiento de asociación (véase el 8.1.1.1 ):
a)información de usuario
b)calidad de servicio
c)requisito de sesión
d)identificador de conexión de sesión.
8.1.1.4.4
Utilización de otros parámetros de las
primitivas Petición e Indicación A-ASOCIACIóN
8.1.1.4.4.1
Asignación inicial de testigos
Se aplican las siguientes reglas:
a)Si la MPTF iniciadora de asociación tiene el turno, especifica el valor
`lado solicitante'
.
b)Si la MPTF iniciadora de asociación no tiene el turno, pero ha emitido una
primitiva Petición P-CESIóN-CONTROL sin confirmación de que se hayan recibido
los testigos, especifica el valor
`lado aceptador'
. (La recepción de
datos sirve como confirmación de que se recibieron los testigos.)
c)Si la MPTF iniciadora de asociación no tiene los testigos y no tiene
pendiente una primitiva Petición P-CESIóN-CONTROL, especifica el valor
`aceptador elige'
.
8.1.1.4.5
Utilización de otros parámetros de las
primitivas Respuesta y Confirmación A-ASOCIACIóN
8.1.1.4.5.1
Asignación inicial de testigos
Si el valor de este parámetro en la primitiva Indicación A-ASOCIACIóN fue
`aceptador elige'
, la MPTF respondedora de asociación mantendrá (valor
`lado aceptador'
) o devolverá (valor
`lado solicitante'
) los
testigos según si los ha tenido antes de que se abortase la conexión de sesión.
8.1.1.4.5.2
Resultado
Si la MPTF respondedora de asociación rechaza la asociación de aplicación,
el valor de este parámetro se pone a
`rechazado (transitorio)'
o
`rechazado (permanente)'
, en los demás casos se pone a
`aceptado'
.
8.1.1.5
Procedimientos de aborto de asociación, de aborto
de proveedor y de asociación, de aborto de proveedor y de
aborto de usuario
8.1.1.5.1
Utilización de los parámetros de las primitivas
Petición e Indicación A-ABORTO
8.1.1.5.1.1
Fuente de aborto
Este valor de parámetro es
`solicitante'
.
8.1.1.5.1.2
Información de usuario
Este valor de parámetro es la UDPA TFAB.
8.1.2
Relación de correspondencia con los servicios ESCA en
el modo X.410-1984
8.1.2.1
Procedimiento de establecimiento de asociación
El procedimiento de establecimiento de asociación se produce simultáneamente con el establecimiento de asociación ESCA subyacente.
8.1.2.1.1
Parámetros directamente correspondientes
Los siguientes parámetros de las primitivas de servicio TF-APERTURA corresponden directamente con los parámetros correspondientes de las primitivas de servicio A-ASOCIACIóN:
a)modo
b)fuente de resultado
c)diagnóstico
d)dirección de presentación llamante
e)dirección de presentación llamada
f)dirección de presentación respondedora.
8.1.2.1.2
Parámetros no utilizados
No se utilizan los siguientes parámetros de las primitivas de servicio A-ASOCIACIóN:
a)nombre del contexto de aplicación
b)título PA llamante
c)identificador de invocación PA llamante
d)calificador EA llamante
e)identificador de invocación EA llamante
f)título PA llamado
g)identificador de invocación PA llamado
h)calificador EA llamado
i)identificador de invocación EA llamado
j)título PA respondedor
k)identificador de invocación PA respondedor
l)calificador EA respondedor
m)identificador de invocación EA respondedor
n)lista de definiciones del contexto de presentación
o)lista de resultados de definición del contexto de presentación
p)nombre del contexto de presentación por defecto
q)resultado del contexto de presentación por defecto.
8.1.2.1.3
Parámetros utilizados como en el modo normal
Los siguientes parámetros de las primitivas de servicio A-ASOCIACIóN se utilizan igual que en el modo normal (véase el 8.1.1 ):
a)información de usuario
b)resultado
c)calidad de servicio
d)requisitos de sesión
e)asignación inicial de testigos
f)identificador de conexión de sesión.
8.1.2.2
Procedimiento de liberación de asociación
El procedimiento de liberación de asociación se produce simultáneamente con la liberación de asociación ESCA subyacente.
8.1.2.2.1
Parámetros no utilizados
No se utilizan los siguientes parámetros de las primitivas de servicio A-LIBERACIóN:
a)motivo
b)información de usuario.
8.1.2.3
Procedimiento de aborto de proveedor de
asociación
8.1.2.3.1
Utilización de los parámetros de la primitiva
Indicación A-P-ABORTO
La utilización de los parámetros de la primitiva Indicación A-P-ABORTO se define en la Recomendación X.217.
8.1.2.4
Procedimiento de recuperación de asociación
El procedimiento de recuperación de asociación se produce simultáneamente con el establecimiento de asociación de ESCA subyacente.
8.1.2.4.1
Parámetros del servicio TF-APERTURA
Los siguientes parámetros de las primitivas de servicio TF-APERTURA son almacenados por las MPTF, y corresponden directamente con los parámetros correspondientes de las primitivas de servicio A-ASOCIACIóN:
a)modo
b)dirección de presentación llamante
c)dirección de presentación llamada
d)dirección de presentación respondedora.
8.1.2.4.2
Parámetros no utilizados
No se utilizan los siguientes parámetros de las primitivas de servicio A-ASOCIACIóN:
a)nombre del contexto de aplicación
b)título PA llamante
c)identificador de invocación PA llamante
d)calificador EA llamante
e)identificador de invocación EA llamante
f)título PA llamado
g)identificador de invocación PA llamado
h)calificador EA llamado
i)identificador de invocación EA llamado
j)título PA respondedor
k)identificador de invocación PA respondedor
l)calificador EA respondedor
m)identificador de invocación EA respondedor
n)lista de definiciones del contexto de presentación
o)lista de resultados de definición del contexto de presentación
p)nombre del contexto de presentación por defecto
q)resultado del contexto de presentación por defecto
r)requisitos de presentación
s)número de serie del punto de sincronización inicial.
8.1.2.4.3
Parámetros utilizados como en el modo normal
Los siguientes parámetros de las primitivas de servicio A-ASOCIACIóN se utilizan igual que en el modo normal (véase el 8.1.1 ):
a)información de usuario
b)resultado
c)calidad de servicio
d)requisitos de sesión
e)asignación inicial de testigos
f)identificador de conexión de sesión.
8.1.2.5
Procedimientos de aborto de asociación, de aborto
de proveedor y de aborto de usuario
8.1.2.5.1
Parámetros no utilizados
No se utiliza el siguiente parámetro de las primitivas de servicio A-ABORTO:
a)Origen del aborto.
8.1.2.5.2
Parámetros utilizados como en el modo normal
El siguiente parámetro de las primitivas de servicio A-ASOCIACIóN se utiliza igual que en el modo normal (véase el 8.1.1 ):
a)Información de usuario.
8.2
Relación de correspondencia con los servicios de
presentación
En este punto se define cómo las primitivas de servicios de presentación descritas en la Recomendación X.216 son utilizadas por la MPTF. En el cuadro 9/X.228 se define la relación de correspondencia de las primitivas y las UDPA del servicio ESTF con las primitivas de los servicios de presentación.
En este punto se define la relación de correspondencia con los servicios de presentación en el modo normal y en el modo X.410-1984
8.2.1
Procedimiento de transferencia
8.2.1.1
Utilización de los parámetros de las primitivas
Petición e Indicación P-COMIENZO DE ACTIVIDAD
8.2.1.1.1
Identificador de actividad
El identificador de actividad identifica la actividad por medio de un número de serie. A la primera actividad comenzada en una conexión de sesión se le asigna el número 1. A cada actividad sucesiva para ese sentido de transferencia se le asigna el número siguiente. De este modo, la numeración es distinta para cada sentido de transferencia.
La propiedad requerida de los identificadores de actividad es que deben identificar inequívocamente una actividad durante un intervalo de tiempo razonable dentro de una conexión de sesión determinada, de modo que puedan detectarse duplicados en caso de situaciones de error. Estos identificadores se atribuyen numerando las actividades durante una sesión, comenzando con uno para la primera y aumentando para cada actividad sucesiva, y para representar el número mediante un elemento de datos, de tipo INTERGER codificados de acuerdo con la Recomendación X.209. Es innecesario que la MPTF receptora haga hipótesis sobre el método de atribución, solamente para poder comparar dos identificadores en cuanto a la igualdad, octeto por octeto.
Tableau 9/X.228 [T9.228] p.
8.2.1.1.2
Datos de usuario
Este parámetro no se utiliza.
8.2.1.2
Utilización de los parámetros de las primitivas
Petición e Indicación P-DATOS
8.2.1.2.1
Datos de usuario
El tamaño máximo de datos de usuario (número de octetos del valor de la UDPA TFTR) habrá sido negociado durante el procedimiento de establecimiento de asociación. La MPTF emisora someterá datos de usuario conformes a dicho acuerdo.
8.2.1.3
Utilización de los parámetros de servicio
P-SINCRONIZACIóN MENOR
8.2.1.3.1
Tipo
La MTFP utiliza solamente el tipo
`confirmación explícita prevista'
de sincronización menor.
8.2.1.3.2
Número de serie del punto de sincronización
El proveedor del servicio de sesión atribuye números de serie de punto de comprobación y los pasa a las MPTF emisora y receptora para asociarlos con los datos transmitidos.
8.2.1.3.3
Datos de usuario
Este parámetro no se utiliza.
8.2.1.4
Utilización de los parámetros del servicio
P-FIN DE ACTIVIDAD
8.2.1.4.1
Número de serie del punto de sincronización
El número de serie del punto de sincronización mayor implicado es atribuido por el proveedor del servicio de sesión y pasado a ambas MPTF.
8.2.1.4.2
Datos de usuario
Este parámetro no se utiliza.
8.2.2
Procedimiento solicitud turno
8.2.2.1
Utilización de los parámetros de las primitivas
Petición e Indicación P-SOLICITUD TESTIGO
8.2.2.1.1
Testigos
La MPTF receptora pedirá solamente el testigo de datos. Como los testigos no pueden separarse, la MPTF emisora rendirá también todos los otros testigos disponibles cuando emite la primitiva Petición P-CESIóN CONTROL.
8.2.2.1.2
Datos de usuario
Esta es la UDPA TFTPF.
8.2.3
Procedimiento cesión-turno
8.2.3.1
Utilización de los parámetros del servicio P-CESIóN
CONTROL
Las primitivas del servicio P-CESIóN CONTROL no tienen parámetros. Los testigos datos, sincronización menor y mayor»actividad son transferidos automáticamente a la otra MPTF.
8.2.4
Procedimiento de informe de excepción de usuario
8.2.4.1
Utilización de los parámetros del servicio
P-U-INFORME DE EXCEPCIóN
8.2.4.1.1
Motivo
Este parámetro puede especificar uno de los siguientes motivos:
a)capacidad receptora comprometida
b)error de usuario-SS local
c)error de secuencia
d)error de procedimiento irrecuperable
e)error no específico.
8.2.4.1.2
Datos de usuario
Este parámetro no se utiliza.
8.2.5
Procedimiento de informe de excepción de
proveedor
8.2.5.1
Utilización de los parámetros del servicio
P-P-INFORME DE EXCEPCIóN
8.2.5.1.1
Motivo
Se suministrará uno de los siguientes códigos de motivo:
a)error de protocolo
b)error no específico.
8.2.6
Procedimiento de interrupción de transferencia
8.2.6.1
Utilización de los parámetros del servicio
P-INTERRUPCIóN DE ACTIVIDAD
8.2.6.1.1
Motivo
Este parámetro puede especificar uno de los siguientes errores:
a)error de usuario-SS local
b)error no específico.
8.2.7
Procedimiento de descarte de transferencia
8.2.7.1
Utilización de los parámetros del servicio
P-DESCARTE DE ACTIVIDAD
8.2.7.1.1
Motivo
Este parámetro puede especificar uno de los siguientes errores:
a)error de usuario-SS local
b)error de procedimiento irrecuperable
c)error no específico.
8.2.8
Procedimiento de reanudación de transferencia
8.2.8.1
Utilización de los parámetros del servicio
P-REANUDACIóN DE ACTIVIDAD
8.1.8.1.1
Identificador de actividad
La MPTF emisora atribuirá y suministrará el número siguiente de identificador de actividad para la sesión vigente.
8.2.8.1.2
Identificador de actividad antiguo
La MPTF emisora suministrará el identificador de actividad original que fue asignado a la actividad interrumpida previamente en la primitiva Petición P-COMIENZO DE ACTIVIDAD.
8.2.8.1.3
Número de serie del punto de sincronización
La MPTF emisora especificará el número de serie del último punto de comprobación confirmado en la actividad interrumpida. El proveedor de servicio de sesión fijará también el número de serie de sesión vigente a este valor. Si no hay punto de comprobación confirmado previamente, la actividad no puede continuarse. La MPTF emisora enviará entonces una primitiva Petición P-REANUDACIóN DE ACTIVIDAD (con el número de serie del punto de sincronización puesto a cero), seguida de una primitiva Petición P-DESCARTE DE ACTIVIDAD.
8.2.8.1.4
Identificador de conexión de sesión antigua
La MPTF emisora puede suministrar el identificador de conexión de sesión de la conexión de sesión durante la cual se comenzó la actividad; lo suministrará si esa conexión de sesión no es la vigente. Este identificador de conexión de sesión se transporta en los componentes referencia de usuario-SS llamante, referencia común y, facultativamente, información de referencia adicional, de este parámetro. El componente referencia de usuario-SS llamado no se utiliza.
8.2.8.1.5
Datos de usuario
Este parámetro no se utiliza.
9
Definición de la sintaxis
abstracta de las UDPA
En este punto se especifica la sintaxis abstracta de cada UDPA de ESTF utilizando la notación de sintaxis abstracta de la Recomendación X.208, y se muestra en la figura 1/X.228.
Figura 1/X.228 (Parte 1 de 3) [T10.228], p. (à traiter comme
tableau MEP)
Figura 1/X.228 (Parte 2 de 3) [T11.228], p. (à traiter comme
tableau MEP)
Figura 1/X.228 (Parte 3 de 3) [T12.228], p. (à traiter comme
tableau MEP)
10
Conformidad
Toda realización que pretenda ser conforme a esta Recomendación cumplirá los requisitos indicados en los 10.1 a 10.3.
10.1
Requisitos de declaración
El realizador declarará lo siguente:
a)el contexto de aplicación para el cual se pretende la conformidad, incluyendo si el sistema admite el modo normal, el modo X.410-1984, o ambos.
10.2
Requisitos estáticos
El sistema:
a)se ajustará a la definición de sintaxis abstracta de las UPDA definidas en el 9 .
10.3
Requisitos dinámicos
El sistema:
a)se ajustará a los elementos de procedimiento definidos en el 7 ;
b)cumplirá las relaciones de correspondencia con los servicios utilizados, para los cuales se pretende la conformidad, según se define en el 8 .
ANEXO A (a la Recomendación X.228)
Tablas de estados de
la MPTF
A.1
Generalidades
Este anexo define una sola máquina de protocolo de transferencia fiable (MPTF) en términos de una tabla de estados. La tabla de estados muestra la interrelación entre el estado de una asociación de aplicación, los sucesos entrantes que se producen en el protocolo, las acciones realizadas y, finalmente, el estado resultante de la asociación de aplicación.
La tabla de estados de la MPTF no constituye una definición formal de la MPTF. Se incluye para proporcionar una especificación más precisa de los elementos de procedimiento definidos en el 7 .
Este anexo contiene los siguientes cuadros:
a)El cuadro A-1»X.228 especifica el nombre abreviado, la fuente y el nombre»descripción de cada suceso entrante. Las fuentes son:
1)Usuario-ESTF (usuario-ESTF);
2)MPTF par (MPTF-par);
3)Elemento de servicio de control de asociación (ESCA);
4)Proveedor de servicio de presentación (proveedor-SP); y
5)MPTF (MPTF).
b)El cuadro A-2/X.228 especifica el nombre abreviado de cada estado de la MPTF.
c)El cuadro A-3/X.228 especifica el nombre abreviado, el objetivo y el nombre/descripción de cada suceso saliente. Los objetivos son:
1)Usuario ESTF (usuario-ESTF);
2)MPTF par (MPTF-par);
3)Elemento de servicio de control asociación (ESCA);
4)Proveedor de servicio de presentación (proveedor-SP); y
5)MPTF (MPTF).
d)El cuadro A-4»X.228 especifica los predicados.
e)El cuadro A-5/X.228 indica las acciones específicas.
f)Los cuadros A-6/X.228 a A-16/X.228 inclusive especifican la tabla de los estados de la MPTF utilizando las abreviaturas de los cuadros anteriores.
Para algunos sucesos la fuente y el objetivo es la MPTF (suceso interno). Si la MPTF emite un suceso interno como parte de una acción realizada, la MPTF espera ese suceso en el estado resultante.
A.2
Convenios
La intersección de un suceso entrante (fila) y un estado (columna) forman una casilla.
En la tabla de estados, una casilla en blanco representa la combinación de un suceso entrante y un estado que no está definido para la MPTF (véase el Î A.3.1). Algunos estados esperan únicamente algunos sucesos entrantes de la MPTF fuente (sucesos internos). Estos estados están marcados por * y no se considera ningún otro suceso entrante.
Una casilla que no está en blanco representa un suceso entrante y un estado que está definido para la MPTF. Esta casilla contiene una o más listas de acciones. Una lista de acciones puede ser obligatoria o condicional. Si una casilla contiene una lista de acciones obligatorias, es la única lista de acciones en la casilla.
Una lista de acciones obligatorias contiene:
a)facultativamente uno o más sucesos salientes,
b)facultativamente una o más acciones específicas, y
c)un estado resultante.
Una lista de acciones condicionales contiene:
a)una expresión predicativa que comprende predicados y operadores booleanos ( representa el booleano NOT, & representa el booleano AND), y
b)una lista de acciones obligatorias (esta lista de acciones obligatorias se utiliza solamente si la expresión de predicado es verdadera).
Una colisión local entre un suceso entrante del usuario ESTF y el procedimiento de recuperación de asociación se modela aplazando ese suceso hasta que se complete el procedimiento de recuperación de asociación.
A.3
Acciones que ha de realizar la MPTF
La tabla de estados de la MPTF define las acciones que ha de realizar la MPTF en términos de un suceso saliente facultativo, acciones específicas facultativas y el estado resultante de la asociación de aplicación.
A.3.1
Intersecciones inválidas
Las casillas en blanco indican una intersección inválida de un suceso entrante y un estado. Si se produce esta intersección, se realiza una de las acciones siguientes:
a)si el suceso entrante viene del usuario-ESTF, o es un suceso interno, cualquier acción realizada por la MPTF es un asunto local;
b)si el suceso entrante se relaciona con una UDPA recibida, el proveedor-SP, o el ESCA, la MPTF emite un suceso interno apropiado, o la MPTF emite un suceso saliente TF-PAind (a su usuario-ESTF) y un suceso saliente TFAB (a su MTF par).
A.3.2
Intersecciones válidas
Si la intersección del estado y el suceso entrante es válida, se ejecuta una de las acciones siguientes:
a)si la casilla contiene una lista de acciones obligatorias, la MPTF realiza las acciones especificadas;
b)si la casilla contiene una o más listas de acciones condicionales, para cada expresión de predicado que es verdadera, la MPTF realiza la acción especificada. Si ninguna de las expresiones de predicado es verdadera, la MPTF realiza una de las acciones definidas en el Î A.3.1.
A.4
Definición de variables y temporizadores
Se especifican las variables y los temporizadores siguientes.
A.4.1
MPTF iniciadora de asociación
Esta variable booleana se pone a VERDADERO si la MPTF es la MPTF iniciadora de asociación (acción específica [a1]), en los demás casos se pone a FALSO (acción específica [a2]).
Esta variable booleana se prueba en el predicado p11.
A.4.2
Punto de comprobación confirmado
Esta variable booleana es VERDADERA, si por lo menos se confirmó un punto de comprobación durante el procedimiento de transferencia. Se pone a FALSO al principio del procedimiento de transferencia (acción específica [a30]). Se pone a VERDADERO, si se emite una primitiva Confirmación P-SINCRONIZACIóN MENOR a la MPTF emisora (acción específica [a32]).
A.4.3
Sincronizaciones menores pendientes
Esta variable entera indica el número de confirmaciones de punto de comprobación pendientes durante el procedimiento de transferencia. Se pone a cero al principio del procedimiento de transferencia (acción específica [a30] y [a33]). Se incrementa en 1, si una primitiva Petición P-SINCRONIZACIóN MENOR es emitida por la MPTF emisora (acción específica [a31]). Se disminuye en 1, si se emite una primitiva Confirmación P-SINCRONIZACIóN MENOR a la MPTF emisora (acción específica [a32]).
El valor de esta variable se compara con el valor del campo de tamaño de ventana de la UDPA TFAAC en el predicado p32. El valor de esta variable se compara con el valor cero en el predicado p33.
A.4.4
Temporizador de transferencia Tr
Este temporizador se utiliza para controlar el tiempo de transferencia. Se pone al valor del parámetro tiempo de transferencia de la primitiva Petición TF-TRANSFERENCIA (acción específica [a30]). Se reinicia si una primitiva Respuesta TF-TRANSFERENCIA es emitida por la MPTF (acción específica [a35]).
En el caso de temporización, se produce la temporización-tr de suceso interno.
A.4.5
Temporizador de recuperación Rec
Este temporizador se utiliza para controlar el tiempo de recuperación. Se pone a un valor especificado localmente en el caso de recuperación (acción específica [a38]). Se reinicia después de la recuperación satisfactoria (especificación [a39]).
En el caso de temporización, se produce la temporización-rec de suceso interno.
Cuadro A-1/X.228 (Parte 1 de 3), [T13.228] p.
Cuadro A-1/X.228 (Parte 2 de 3), [T14.228] p.
Cuadro A-1/X.228 (Parte 3 de 3), [T15.228] p.
Cuadro A-2/X.228 (Parte 1 de 2), [T16.228] p.
Cuadro A-2/X.228 (Parte 2 de 2), [T17.228] p.
Cuadro A-3/X.228 (Parte 1 de 3), [T18.228] p.
Cuadro A-3/X.228 (Parte 2 de 3), [T19.228] p.
Cuadro A-3/X.228 (Parte 3 de 3), [T20.228] p.
Cuadro A-4/X.228, [T21.228] p.
Cuadro A-5/X.228 [T22.228] p.
Cuadro A-6/X.228, [T23.228] p.
Cuadro A-7/X.228, [T24.228] p.
Cuadro A-8/X.228 (Parte 1 de 3), [T25.228] p.
Cuadro A-8/X.228 (Parte 2 de 3), [T26.228] p.
Cuadro A-8/X.228 (Parte 3 de 3), [T27.228] p.
Cuadro A-9/X.228, [T28.228] p.
Cuadro A-10/X.228, [T29.228] p.
Cuadro A-11/X.228, [T30.228] p.
Cuadro A-12/X.228, [T31.228] p.
Cuadro A-13/X.228 (Parte 1 de 2), [T32.228] p.
Cuadro A-13/X.228 (Parte 2 de 2), [T33.228] p.
Cuadro A-14/X.228 (Parte 1 de 2), T34.228] p.
Cuadro A-14/X.228 (Parte 2 de 2), [T35.228] p.
Cuadro A-15/X.228, [T36.228] p.
Cuadro A-16/X.228, [T37.228] p.
ANEXO B (a la Recomendación X.228)
Diferencias entre esta
Recomendación y la Recomendación X.410-1984 del CCITT
Este anexo no forma parte de esta Recomendación.
En este anexo se describen las diferencias técnicas entre el protocolo para transferencia fiable de esta Recomendación y el protocolo correspondiente de la Recomendación X.410-1984 del CCITT.
En el modo X.410-1984, esta Recomendación y su utilización del ESCA y del servicio de presentación es compatible a nivel de bits con la Recomendación X.410-1984 teniendo en cuenta las aclaraciones y erratas de la Guía de realizadores V.5 de las Recomendaciones de la serie X.400.
B.1
Unidades de datos de protocolo de aplicación
B.1.1
PConnect (PConexión)
1)El tipo SET y sus dos elementos (DataTransferSyntax y pUserData) son ahora información de control de protocolo de presentación (ICPP). Los elementos de la udpaTFAPT son los elementos de pUserData de SET.
2)El elemento de protocolo de aplicación es ahora OPTIONAL y se utiliza únicamente en el modo X.410-1984.
3)Rotulado implícito de SET en modo normal.
B.1.2
PAccept (PAceptación)
1)El tipo SET y sus dos elementos (DataTransfertSyntax y pUserData) son ahora la información de control de protocolo de presentación. Los elementos de la udpaTFAAC son los elementos de pUserData de SET.
2)Rotulado implícito de SET en modo normal.
B.1.3
PRefuse (PRechazo)
1)El tipo SET es ahora información de control de protocolo de presentación. Los elementos de la udpaTFARCH son los elementos de SET PRefuse.
2)Rotulado implícito de SET en modo normal.
3)Campo de datos de usuario facultativo adicional en modo normal.
B.1.4
DataTransferSyntax
Esta información es ahora información de control de protocolo de presentación.
B.1.5
AbortInformation (InformaciónAborto)
1)El tipo SET es ahora información de control de protocolo de presentación. Los elementos de la udpaTFAB son los elementos de SETAbortInformation.
2)Rotulado implícito de SET en modo normal.
3)Campo de datos de usuario facultativo adicional en modo normal.
B.1.6
AbortReason (MotivoAborto)
Añadir:
Los valores (5) a (6) inclusive. El valor (7)
fue añadido mediante el Addéndum a la Guía de realizadores, versión 5 de las
Recomendaciones de la serie X.400.
B.2
Procedimientos y relación de correspondencia
Relación de correspondencia general con los servicios utilizados.
Modificación:
De: Relación de correspondencia con los
servicios de sesión
A: Relación de correspondencia con el ESCA y los servicios de presentación.
ANEXO C (a la Recomendación X.228)
Resumen de valores
asignados de identificador de objeto
Este anexo no forma parte de esta
Recomendación.
En este anexo se resumen los valores de identificador de objeto asignados en las Recomendaciones X.218 y X.228.
{ joint-iso-ccitt reliable-transfer (3) apdus (0) }
--
Módulo de ASN.1
--
definido en la
Recomendación X.228
{ joint-iso-ccitt reliable-transfer (3) aseID (1) }
--
Identificador de ESTF
--
definido en la
Recomendación X.228
{ joint-iso-ccitt reliable-transfert (3) abstract-syntax (2)
}
--
Nombre de sintaxis abstracta
--
definido en la Recomendación X.228
Formules TEXTE
Anexo A
Disk. 258 NF01/008 (OPM: 01)
- NF01/008 (OPM: 01)
Recomendación X.200 - NF01/011 (OPM: 01)
RO (o ROS) NF01/019 (OPM: 01)
NF01/048 (OPM: 01)
Cambiar
^: de: NF01/074 (OPM: 01)
{
NF01/074 (OPM: 01)
(cs,) - (cs,)
(1BT) (BT..)
(85.TE.13.S)
(A1.23s) / [26s]
FOLIOS: 450 - 478
(DO PRC.COSY.2)
MEP {TPS.NON.PHOTO "[PA1]"} : OK= [1]
Saisie 09.03.89 IR
ID + LASER + diskette MAJ 16.03.89 CW
Corr. LASER (1re épreuve) = 3eme 28.03.89 GG
Espaces réservés + transf. + impr. 89.04.04 DD
AJOUTER (PA1) (CL1,0,0,0) pour MEP
MEP + Impr. 06.04.89 GH/ZR
Corr. MEP ........ ..
Insertion des tableaux (tabulateurs...) ........ ..
BAT 18.04.89 PM
Changement de MEP (sup. AS) 24.04.89 ZR
MAJ DISKETTE ........ ..
Recomendación X.229
OPERACIONES A DISTANCIA: ESPECIFICACIóN DE
PROTOCOLO
(Melbourne, 1988)
El CCITT,
considerando
(a)que la Recomendación X.200 define el modelo de referencia básico de interconexión de sistemas abiertos (ISA) para aplicaciones del CCITT;
(b)que la Recomendación X.210 define los convenios de servicio para describir los servicios del modelo de referencia de ISA;
(c)que la Recomendación X.216 define el servicio de capa de presentación;
(d)que la Recomendación X.217 define el servicio de control de asociación;
(e)que la Recomendación X.218 define el servicio de transferencia fiable;
(f)que la Recomendación X.219 define el servicio y la notación de operaciones a distancia;
(g)que se necesita una base común de operaciones a distancia para diversas aplicaciones,
recomienda por unanimidad
que el protocolo de operaciones a distancia de interconexión de sistemas
abiertos para aplicaciones del CCITT sea el definido en la presente
Recomendación, como se indica en
`Objeto y campo de aplicación'
.
íNDICE
0
Introducción
1
Objeto y campo de aplicación
2
Referencias
3
Definiciones
4
Abreviaturas
5
Convenios
6
Visión general del protocolo
7
Elementos de procedimiento
8
Relación de correspondencia con los servicios
utilizados
9
Definición de la sintaxis abstracta de las unidades de
datos de protocolo de aplicación (UDPA)
10
Conformidad
Anexo A-Tablas de estados de la MPOD
Anexo B-Diferencias entre esta Recomendación y la Recomendación X.410-1984
Anexo C-Resumen de valores asignados de identificador de objeto
0 Introducción
Esta Recomendación especifica el protocolo para los servicios proporcionados por un elemento de servicio de aplicación, el elemento de servicio de operaciones a distancia (ESOD), para permitir aplicaciones interactivas en un entorno de sistemas abiertos distribuidos. Esta Recomendación forma parte de un conjunto de Recomendaciones que definen conjuntos de elementos de servicio de aplicación utilizados en común por varias aplicaciones.
Las interacciones entre entidades de una aplicación distribuida se modelan como operaciones a distancia, y se definen utilizando una notación de operaciones a distancia. Una operación a distancia es solicitada por una entidad; la otra entidad trata de efectuar la operación a distancia e informa después el resultado de la tentativa. Las operaciones a distancia son apoyadas por el ESOD.
Esta Recomendación está armonizada técnicamente con la Norma ISO 9072-2.
1 Objeto y campo de aplicación
Esta Recomendación especifica el protocolo (sintaxis abstracta) y procedimientos para el elemento de servicio de operaciones a distancia (Recomendación X.219). Los servicios de ESOD son proporcionados junto con los servicios del elemento de servicio de control de asociación (ESCA) (Recomendación X.217) y el protocolo ESCA (Recomendación X.227), facultativamente los servicios del elemento de servicio de transferencia fiable (ESTF) (Recomendación X.218) y el protocolo ESTF (Recomendación X.228) y el servicio de presentación (Recomendación X.216).
Los procedimientos ESOD se definen en términos de:
a)las interacciones entre máquinas de protocolo ESOD pares mediante la utilización de servicios de ESTF o del servicio de presentación;
b)las interacciones entre la máquina de protocolo ESOD y su usuario de servicio.
Esta Recomendación especifica los requisitos de conformidad para los sistemas que aplican estos procedimientos.
2
Referencias
Recomendación X.200 -Modelo de referencia de interconexión de sistemas abiertos para aplicaciones del CCITT (véase también la Norma ISO 7498).
Recomendación X.208 -Especificación de la notación de sintaxis abstracta uno (NSA.1) (véase también la Norma ISO 8824).
Recomendación X.209 -Especificación de reglas básicas de codificación de la notación de sintaxis abstracta uno (NSA.1) (véase también la Norma ISO 8825).
Recomendación X.210 -Convenios relativos a la definición del servicio de capa en la interconexión de sistemas abiertos (véase también la Norma ISO/TR 8509).
Recomendación X.216 -Definición del servicio de presentación para la interconexión de sistemas abiertos para aplicaciones del CCITT (véase también la Norma ISO 8822).
Recomendación X.217 -Definición del servicio de control de asociación para la interconexión de sistemas abiertos para aplicaciones del CCITT (véase también la Norma ISO 8649).
Recomendación X.218 -Transferencia fiable: Modelo y definición del servicio (véase también la Norma ISO 9066-1).
Recomendación X.219 -Operaciones a distancia: Modelo, notación y definición del servicio (véase también la Norma ISO 9072-1).
Recomendación X.227 -Especificación del protocolo de control de asociación para la interconexión de sistemas abiertos para aplicaciones del CCITT (véase también la Norma ISO 8650).
Recomendación^X.228 -Transferencia fiable: Especificación del protocolo (véase también la Norma ISO 9066-2).
3
Definiciones
3.1
Definiciones del modelo de referencia
Esta Recomendación se basa en los conceptos desarrollados en la Recomendación X.200 y utiliza los siguientes términos definidos en ella:
a)capa de aplicación;
b)proceso de aplicación;
c)entidad de aplicación;
d)elemento de servicio de aplicación;
e)unidad de datos de protocolo de aplicación;
f)información de control del protocolo de aplicación;
g)servicio de presentación;
h)conexión de presentación;
i)servicio de sesión;
j)conexión de sesión;
k)sintaxis de transferencia; y
l)elemento de usuario.
3.2
Definiciones de convenios de servicios
Esta Recomendación utiliza los siguientes términos definidos en la Recomendación X.210:
a)proveedor de servicio;
b)usuario de servicio;
c)servicio confirmado;
d)servicio no confirmado;
e)servicio iniciado por el proveedor;
f)primitiva;
g)petición (primitiva);
h)indicación (primitiva);
i)respuesta (primitiva);
j)confirmación (primitiva).
3.3
Definiciones del servicio de presentación
Esta Recomendación utiliza los siguientes términos definidos en la Recomendación X.216:
a)sintaxis abstracta;
b)nombre de sintaxis abstracta;
c)contexto de presentación.
3.4
Definiciones de control de asociación
Esta Recomendación utiliza los siguientes términos definidos en la Recomendación X.217:
a)asociación de aplicación; asociación;
b)contexto de aplicación;
c)elemento de servicio de control de asociación.
3.5
Definiciones de transferencia fiable
Esta Recomendación utiliza los siguientes términos definidos en la Recomendación X.218:
a)elemento de servicio de transferencia fiable.
3.6
Definiciones de servicios de ESOD
Esta Recomendación utiliza los siguientes términos definidos en la Recomendación X.219:
a)entidad de aplicación iniciadora de asociación; iniciador de asociación;
b)entidad de aplicación respondedora de asociación; respondedor de asociación;
c)entidad de aplicación invocadora; invocador;
d)entidad de aplicación realizadora; realizador;
e)solicitante;
f)aceptador;
g)operaciones enlazadas;
h)operación progenitora;
i)operación vástago;
j)notación OD;
k)elemento de servicio de operaciones a distancia;
l)proveedor ESOD;
m)usuario ESOD;
n)usuario ESTF;
o)operaciones a distancia.
3.7
Definiciones de especificación de protocolo de
operaciones a distancia
A los efectos de esta Recomendación, se aplican las siguientes definiciones:
3.7.1@
máquina de protocolo de operaciones a distancia
@
\Máquina de protocolo para el elemento de servicio de operaciones a distancia especificado en esta Recomendación.\
3.7.2@
máquina de protocolo de operaciones a distancia
solicitante
@
\Máquina de protocolo de operaciones a distancia cuyo usuario de servicio es el solicitante de un servicio determinado del elemento de servicio de operaciones a distancia.\
3.7.3@
máquina de protocolo de operaciones a distancia
aceptadora
@
\Máquina de protocolo de operaciones a distancia cuyo usuario de servicio es el aceptador de un servicio determinado del elemento de servicio de operaciones a distancia.\
4
Abreviaturas
4.1
Niveles de datos
@UDPAUnidad de datos de protocolo de aplicación.\
4.2
Tipos de unidades de datos de protocolo de
aplicación
Se han adaptado las siguientes abreviaturas para las unidades de datos de protocolo de aplicación definidas en esta Recomendación:
@ODIVunidad de datos de protocolo de aplicación OD-INVOCACIóN\
@ODRSunidad de datos de protocolo de aplicación OD-RESULTADO\
@ODERunidad de datos de protocolo de aplicación OD-ERROR\
@ODRCHunidad de datos de protocolo de aplicación OD-RECHAZO\
4.3
Otras abreviaturas
En esta Recomendación se utilizan las siguientes abreviaturas:
@EAentidad de aplicación\
@ESCAelemento de servicio del control de aplicación\
@ESAelemento de servicio de aplicación\
@OD (o SOD)operaciones a distancia\
@MPODmáquina de protocolo de operaciones a distancia\
@ESODelemento de servicio de operaciones a distancia\
@TFtransferencia fiable\
@ESTFelemento de servicio de transferencia fiable\
5
Convenios
Esta Recomendación emplea una presentación tabular de los campos de sus UDPA. En el 7 se presentan tablas para cada UDPA de ESOD. Cada campo se resume utilizando la siguiente notación:
Ola presencia es obligatoria;
Ula presencia es una opción del usuario ESOD;
petla fuente es una primitiva de petición conexa;
indel sumidero es una primitiva de indicación conexa;
respla fuente es una primitiva de respuesta conexa;
confel sumidero es una primitiva de confirmación conexa;
spla fuente o sumidero es la MPOD.
La estructura de cada UDPA de ESOD se especifica en el 9 utilizando la notación de sintaxis abstracta de la Recomendación X.208.
6 Visión general del protocolo
6.1
Provisión de servicios
El protocolo especificado en esta Recomendación proporciona los servicios ESOD definidos en la Recomendación X.219. Estos servicios se indican en el cuadro 1/X.229.
Cuadro 1/X.229, [T1.229] p.
6.2
Utilización de los servicios
El protocolo ESOD especificado en esta Recomendación necesita un servicio de transferencia para pasar información en forma de UDPA de ESOD entre entidades de aplicación pares (EA).
Pueden utilizarse alternativamente dos servicios de transferencia:
a)los servicios ESTF, si el ESTF está incluido en el contexto de aplicación, o
b)el servicio de presentación, si el ESTF no está incluido en el contexto de aplicación.
En ambos casos se supone una asociación de aplicación existente, establecida y liberada por medio de los servicios ESCA.
6.2.1
Utilización de los servicios ESTF
Si el ESTF está incluido en el contexto de aplicación, esta Recomendación supone que la máquina de protocolo de operaciones a distancia (MPOD) es el único usuario del servicio TF-TRANSFERENCIA y del servicio TF-CESIóN TURNO.
La EA iniciadora puede solamente pedir la liberación de la asociación de aplicación por medio del servicio TF-CIERRE si posee el turno. Por tanto, el usuario ESTF y la MPOD son los usuarios del servicio TF-SOLICITUD TURNO.
La MPOD es el usuario de los servicios TF-U-ABORTO y TF-P-ABORTO.
6.2.2
Utilización del servicio de presentación
Si el ESTF no está incluido en el contexto de aplicación, la MPOD es un usuario del servicio P-DATOS.
6.3
Modelo
La máquina de protocolo de operaciones a distancia (MPOD) comunica con su usuario de servicio por medio de primitivas definidas en la Recomendación X.219. Cada invocación de la MPOD controla una sola asociación de aplicación.
La MPOD es activada por primitivas Petición del servicio ESOD de su usuario de servicio y por primitivas Indicación y Confirmación de los servicios ESTF, o del servicio de presentación. La MPOD emite a su vez primitivas Indicación a su usuario de servicio y primitivas Petición en los servicios ESTF o el servicio de presentación utilizados. Si el ESTF está incluido en el contexto de aplicación, se utilizan las primitivas Indicación TF-TRANSFERENCIA, Petición TF-TRANSFERENCIA y Confirmación TF-TRANSFERENCIA. En el caso de un contexto de aplicación que excluye el ESTF, se utilizan las primitivas Petición P-DATOS e Indicación P-DATOS del servicio de presentación. En este caso la transferencia no es confirmada.
La recepción de una primitiva de servicio ESOD, o de una primitiva de servicio ESTF o de una primitiva de servicio de presentación y la generación de las acciones dependientes se consideran indivisibles.
Durante el intercambio de las UDPA, se supone la existencia de la EA iniciadora de asociación y de la EA respondedora de iniciación. La forma en que se crean estas EA está fuera del objeto de esta Recomendación.
Durante la ejecución de operaciones, se supone la existencia de una asociación de aplicación entre las EA pares. La forma en que se establece y libera esta asociación de aplicación está fuera del objeto de esta Recomendación (véanse las Recomendaciones X.219, X.217, X.227, X.218 y X.228).
Nota
- Cada asociación de aplicación puede ser
identificada en un sistema final por un mecanismo interno, que depende de la
realización, de modo que el usuario del servicio ESOD y la MPOD pueden
referirse a ella.
7 Elementos de procedimiento
El protocolo ESOD consta de los siguientes elementos de procedimiento:
a)invocación;
b)retorno de resultados;
c)retorno de error;
d)rechazo de usuario;
e)rechazo de proveedor.
A continuación se presenta un resumen de cada uno de estos elementos de procedimiento, que consiste en un resumen de las UDPA pertinentes, y una visión general de alto nivel de la relación entre las primitivas de servicio ESOD, las UDPA participantes y el servicio de transferencia que se utiliza.
Los términos genéricos servicio de transferencia, proveedor de servicio de transferencia, petición de transferencia e indicación de transferencia se utilizan en el contexto del 7 . En el 8 se describe la relación de correspondencia de estas primitivas de servicio genéricas con los servicios ESTF o con el servicio de presentación.
En el 9 figura una especificación detallada de las UDPA de ESOD mediante la notación definida en la Recomendación X.208.
7.1
Invocación
7.1.1
Finalidad
El procedimiento de invocación es utilizado por una EA (la invocadora) para solicitar una operación que ha de ser efectuada por la otra EA (la realizadora).
7.1.2
UDPA utilizadas
El procedimiento de invocación utiliza la UDPA OD-INVOCACIóN (ODIV).
Los campos de la UDPA o de ODIV se indican en el cuadro 2/X.229.
Cuadro 2/X.229, [T2.229] p.
7.1.3
Procedimiento de invocación
Este procedimiento es activado por los siguientes sucesos:
a)una primitiva Petición OD-INVOCACIóN del solicitante;
b)una UDPA ODIV como datos de usuario de una primitiva de indicación de transferencia.
7.1.3.1
Primitiva Petición OD-INVOCACIóN
La MPOD solicitante forma una UDPA ODIV a partir de los valores del parámetro de la primitiva Peticion OD-INVOCACIóN. Emite una primitiva de petición de transferencia. El parámetro datos de usuario de la primitiva de petición de transferencia contiene la UDPA ODIV.
La MPOD solicitante espera una primitiva de indicación de transferencia del proveedor del servicio de transferencia o cualquier otra primitiva del solicitante.
7.1.3.2
UDPA ODIV
La MPOD aceptadora recibe una UDPA ODIV de su par como datos de usuario en una primitiva de indicación de transferencia. Si cualquiera de los campos de UDPA ODIV son inaceptables a esta MPOD, se efectúa el procedimiento de rechazo por el proveedor, y la MPOD no emite ninguna primitiva Indicación OD-INVOCACIóN.
Si la UDPA ODIV es aceptable a la MPOD aceptadora, emite una primitiva Indicación OD-INVOCACIóN al aceptador. Los parámetros de la primitiva Indicación OD-INVOCACIóN se derivan de la UDPA ODIV.
La MPOD aceptadora espera una primitiva de indicación de transferencia del proveedor del servicio de transferencia o de cualquier otra primitiva del aceptador.
7.1.4
Utilización de los campos de la UDPA ODIV
Los campos ODIV se utilizan como sigue.
7.1.4.1
ID-invocación
Es el valor del parámetro ID-invocación de la primitiva Petición OD-INVOCACIóN. Aparece como el valor del parámetro ID-invocación de la primitiva Indicación OD-INVOCACIóN.
El valor de este campo es transparente a la MPOD; sin embargo, el valor puede ser utilizado en el procedimiento de rechazo del proveedor.
7.1.4.2
ID-enlazados
Es el valor del parámetro ID-enlazados de la primitiva Petición OD-INVOCACIóN. Aparece como el valor del parámetro ID-enlazados de la primitiva Indicación OD-INVOCACIóN.
El valor de este campo es transparente a la MPOD.
7.1.4.3
Valor de operación
Es el valor del parámetro valor de operación de la primitiva Petición OD-INVOCACIóN. Aparece como el valor del parámetro valor de operación de la primitiva Indicación OD-INVOCACIóN.
El valor de este campo es transparente a la MPOD.
7.1.4.4
Argumento
Es el valor del parámetro argumento de la primitiva Petición OD-INVOCACIóN. Aparece como el valor del parámetro argumento de la primitiva Indicación OD-INVOCACIóN.
El valor de este campo es transparente a la MPOD.
7.2
Retorno de resultado
7.2.1
Finalidad
El procedimiento retorno de resultado es utilizado por una EA (la realizadora) para pedir a la otra EA (la invocadora) la transferencia del resultado de una operación efectuada satisfactoriamente.
7.2.2
UDPA utilizadas
El procedimiento retorno de resultado utiliza la UDPA OD-RESULTADO (ODRS)
Los campos de la UDPA ODRS se indican en el cuadro 3/X.229.
Cuadro 3/X.229, [T3.229] p.
7.2.3
Procedimientos retorno de resultado
Este procedimiento es activado por los siguientes sucesos:
a)una primitiva Petición OD-RESULTADO del solicitante;
b)una UDPA ODRS como datos de usuario de una primitiva de indicación de transferencia.
7.2.3.1
Primitiva Petición OD-RESULTADO
La MPOD solicitante forma una UDPA ODRS a partir de los valores del parámetro de la primitiva Petición OD-RESULTADO. Emite una primitiva de petición de transferencia. El parámetro datos de usuario de la primitiva de petición de transferencia contiene la UDPA ODRS.
La MPOD solicitante espera una primitiva de indicación de transferencia del proveedor del servicio de transferencia o cualquier otra primitiva del solicitante.
7.2.3.2
UDPA ODRS
La MPOD aceptadora recibe una UDPA ODRS de su par como datos de usuario en una primitiva de indicación de transferencia. Si cualquiera de los campos de la UDPA o de ODRS son inaceptables a esta MPOD, se efectúa el procedimiento de rechazo del proveedor y la MPOD no emite ninguna primitiva Indicación OD-RESULTADO.
Si la UDPA ODRS es aceptable a la MPOD aceptadora, emite una primitiva Indicación OD-RESULTADO al aceptador. Los parámetros de la primitiva Indicación OD-RESULTADO se derivan de la UDPA ODRS.
La MPOD aceptadora espera una primitiva de transferencia del proveedor de servicio de transferencia o cualquier otra primitiva del aceptador.
7.2.4
Utilización de los campos de la UDPA ODRS
Los campos de la ODRS se utilizan como sigue.
7.2.4.1
ID-invocación
Es el valor del parámetro ID-invocación de la primitiva Petición OD-RESULTADO. Aparece como el valor del parámetro ID-invocación de la primitiva Indicación OD-RESULTADO.
El valor de este campo es transparente a MPOD, sin embargo, el valor puede utilizarse en el procedimiento de rechazo del proveedor.
7.2.4.2
Valor de operación
Es el valor del parámetro valor de operación de la primitiva Petición OD-RESULTADO. Aparece como el parámetro valor de operación de la primitiva Indicación OD-RESULTADO.
El valor de este campo es transparente a la MPOD.
Este campo estará presente solamente si el campo resultado está presente.
7.2.4.3
Resultado
Es el valor del parámetro resultado de la primitiva Petición OD-RESULTADO. Aparece como el valor del parámetro resultado de la primitiva Indicación OD-RESULTADO.
El valor de este campo es transparente a la MPOD.
7.3
Retorno de error
7.3.1
Finalidad
El procedimiento retorno de error es utilizado por una EA (la realizadora) para solicitar a la otra EA (la invocadora) la transferencia de la información de error en el caso de una operación efectuada infructuosamente.
7.3.2
UDPA utilizadas
El procedimiento retorno de error utiliza la UDPA OD-ERROR (ODER).
Los campos de la UDPA ODER se indican en el cuadro 4/X.229.
Cuadro 4/X.229, [T4.229] p.
7.3.3
Procedimiento retorno de error
Este procedimiento es activado por los siguientes sucesos:
a)una primitiva de petición OD-ERROR del solicitante;
b)una UDPA ODER como datos de usuario de una primitiva de indicación de transferencia.
7.3.3.1
Primitiva Petición OD-ERROR
La MPOD solicitante forma una UDPA ODER a partir de los valores del parámetro de la primitiva Petición OD-ERROR. Emite una primitiva de petición de transferencia. El parámetro datos de usuario de la primitiva de petición de transferencia contiene la UDPA ODER.
La MPOD solicitante espera una primitiva de transferencia del proveedor del servicio de transferencia o cualquier otra primitiva del solicitante.
7.3.3.2
UDPA ODER
La MPOD aceptadora recibe una UDPA ODER de su par como datos de usuario en una primitiva de indicación de transferencia. Si cualquiera de los campos de la UDPA ODER son inaceptables a esta MPOD, se efectúa el procedimiento de rechazo del proveedor y la MPOD no emite ninguna primitiva Indicación OD ERROR.
Si la UDPA ODER es aceptable a la MPOD aceptadora, emite una primitiva Indicación OD-ERROR al aceptador. Los parámetros de la primitiva Indicación OD-ERROR se derivan de la UDPA ODER.
La MPOD aceptadora espera una primitiva de indicación de transferencia del proveedor de servicio de transferencia o cualquier otra primitiva del aceptador.
7.3.4
Utilización de los campos de la UDPA ODER
Los campos de la UDPA ODER se utilizan como sigue.
7.3.4.1
ID-invocación
Es el valor del parámetro ID-invocación de la primitiva Petición OD-ERROR. Aparece como el valor del parámetro ID-invocación de la primitiva Indicación OD-ERROR.
El valor de este campo es transparente a la MPOD; sin embargo el valor puede utilizarse en el procedimiento de rechazo del proveedor.
7.3.4.2
Valor de error
Es el valor del parámetro valor de error de la primitiva Petición OD-ERROR. Aparece como el valor del parámetro valor de error de la primitiva Indicación OD-ERROR.
El valor de este campo es transparente a la MPOD.
7.3.4.3
Parámetro de error
Es el valor del parámetro parámetro de error de la primitiva Petición OD-ERROR. Aparece como el valor del parámetro parámetro de error de la primitiva Indicación OD-ERROR.
El valor de este campo es transparente a la MPOD.
7.4
Rechazo de usuario
7.4.1
Finalidad
El procedimiento de rechazo de usuario es utilizado por una EA para rechazar la petición (invocación) o respuesta (resultado o error) de la otra EA.
7.4.2
UDPA utilizadas
El procedimiento de rechazo de usuario utiliza la UDPA OD-RECHAZO (ODRCH). Esta UDPA ODRCH es utilizada además por el procedimiento de rechazo por el proveedor.
Los campos de la UDPA ODRCH utilizados para el procedimiento de rechazo por el usuario se indican en el cuadro 5/X.229.
Cuadro 5/X.229, [T5.229] p.
7.4.3
Procedimiento de rechazo de usuario
Este procedimiento es activado por los siguientes sucesos:
a)una primitiva Petición OD-RECHAZO-U del solicitante;
b)una UDPA ODRCH como datos de usuario de una primitiva de indicación de transferencia.
7.4.3.1
Primitiva Petición OD-RECHAZO-U
La MPOD solicitante forma una UDPA ODRCH a partir de los valores del parámetro de la primitiva Petición OD-RECHAZO-U. Emite una primitiva de petición de transferencia. El parámetro datos de usuario de la primitiva de petición de transferencia contiene la UDPA-ODRCH.
La MPOD solicitante espera una primitiva de indicación de transferencia del proveedor del servicio de transferencia o cualquier otra primitiva del solicitante.
7.4.3.2
UDPA ODRCH
La MPOD aceptadora recibe una UDPA ODRCH de su par como datos de usuario en una primitiva de indicación de transferencia. Si cualquiera de los campos de la UDPA ODRCH son inaceptables a esta MPOD, la MPOD no emite ninguna primitiva Indicación OD-RECHAZO-U.
Si la UDPA ODRCH es aceptable a la MPOD aceptadora y los campos de la UDPA ODRCH indican un rechazo de usuario (es decir problema de invocación, problema de retorno de resultado, o problema de retorno de error), emite al aceptador una primitiva Indicación OD-RECHAZO-U. Los parámetros de la primitiva Indicación OD-RECHAZO-U (ID-invocación y motivo-rechazo) se derivan de la UDPA ODRCH.
La MPOD aceptadora espera una primitiva de indicación de transferencia del proveedor de servicio de transferencia o cualquier otra primitiva del aceptador.
7.4.4
Utilización de los campos de la UDPA ODRCH
Los campos de la UDPA ODRCH se utilizan como sigue.
7.4.4.1
ID-invocación
Es el valor del parámetro ID-invocación de la primitiva Petición OD-RECHAZO-U. Aparece como el valor del parámetro ID-invocación de la primitiva Indicación OD-RECHAZO-U.
El valor de este campo es transparente a la MPOD.
7.4.4.2
Problema
Es el valor del parámetro problema de la primitiva Petición OD-RECHAZO-U. Aparece como el valor del parámetro problema de la primitiva Indicación OD-RECHAZO-U.
Los valores utilizados por el procedimiento de rechazo por el usuario son:
a)
Problema de invocación
: Rechazo del usuario de una
primitiva Indicación OD-INVOCACIóN con valores:
-Invocación duplicada: significa que el parámetro ID-invocación viola las reglas de asignación de la Recomendación X.219.
-Operación no reconocida: significa que la operación no es una de las acordadas entre los usuarios ESOD.
-Argumento con tipo erróneo: significa que el tipo del argumento de operación suministrado no es el acordado entre los usuarios ESOD.
-Limitación de rescursos: el usuario ESOD realizador no puede efectuar la operación invocada debido a limitación de recursos.
-Liberación por el iniciador: el iniciador de la asociación no está dispuesto a efectuar la operación invocada porque está a punto de tratar de liberar la asociación de aplicación.
-ID-enlazado no reconocido: significa que no hay operación en curso con un ID-invocación igual al ID-enlazado especificado.
-Respuesta enlazada no esperada: significa que la operación invocada a que hace referencia el ID-enlazado no es una operación progenitora.
-Operación vástago no esperada: significa que la operación vástago invocada no es una que permite la operación progenitora invocada a que hace referencia el ID-enlazado.
b)
Problema retorno de resultado
: Rechazo del usuario de
una primitiva Indicación OD-RESULTADO con valores:
-Invocación no reconocida: significa que no está en curso ninguna operación con el ID-invocación especificado.
-Respuesta de resultado no esperada: significa que la operación invocada no informa un resultado.
-Resultado con tipo erróneo: significa que el tipo de parámetro resultado suministrado no es el acordado entre los usuarios ESOD.
c)
Problema de retorno de error
: Rechazo del usuario de
una primitiva Indicación OD-ERROR con valores:
-Invocación no reconocida: significa que no está en curso ninguna operación con el ID-invocación especificado.
-Respuesta de no esperada: significa que la operación invocada no informa fallo.
-Error no reconocido: significa que el error informado no es uno de los acordados entre los usuarios ESOD.
-Error no esperado: significa que el error informado no es uno de los que la operación invocada pueda informar.
-Parámetro con tipo erróneo: significa que el tipo del parámetro de error suministrado no es el acordado entre los usuarios ESOD.
7.5
Rechazo por el proveedor
7.5.1
Finalidad
El procedimiento de rechazo por el proveedor es utilizado para informar al usuario ESOD y a la MPOD par, si la MPOD detecta un problema.
7.5.2
UDPA utilizadas
El procedimiento de rechazo por el proveedor utiliza la UDPA OD-RECHAZO (ODRCH). Esta UDPA ODRCH es utilizada además por el procedimiento de rechazo de usuario.
Los campos de la UDPA ODRCH utilizados para el procedimiento de rechazo por el proveedor se indican en el cuadro 6/X.229.
Cuadro 6/X.229, [T6.229] p.
7.5.3
Procedimiento de rechazo por el proveedor
Este procedimiento es activado por los siguientes sucesos:
a)una UDPA inaceptable como datos de usuario de una primitiva Indicación de transferencia;
b)una UDPA ODRCH con la elección problema general del parámetro problema como datos de usuario de una primitiva de indicación de transferencia;
c)transferencia de UDPA infructuosa (por ejemplo, aborto de asociación).
7.5.3.1
UDPA inaceptable
La MPOD receptora recibe una UDPA de su par como datos de usuario en una primitiva de indicación de transferencia. Si cualquiera de los campos de la UDPA (excepto UDPA ODRCH) son inaceptables a esta MPOD, forma una UDPA ODRCH con la elección problema general del campo problema y la ID-invocación de la UDPA rechazada. La MPOD receptora emite una primitiva de petición de transferencia. El parámetro datos de usuario de la primitiva de petición de transferencia contiene la UDPA ODRCH.
Si la UDPA inaceptable recibida es una UDPA ODRCH, no se forma ni se transfiere ninguna nueva UDPA ODRCH. En este caso, o después del rechazo de un número de UDPA especificado localmente, la asociación de aplicación se libera de manera anómala.
Si la asociación de aplicación no es liberada anómalamente, la MPOD receptora espera una primitiva de indicación de transferencia del proveedor del servicio de transferencia o cualquier otra primitiva del solicitante.
7.5.3.2
UDPA ODRCH
La MPOD receptora recibe una UDPA ODRCH de su par como datos de usuario en una primitiva de indicación de transferencia. Si cualquiera de los campos de la UDPA ODRCH son inaceptables a esta MPOD, se aplica el procedimiento de rechazo por el proveedor para una UDPA inaceptable.
Si la UDPA ODRCH es aceptable a la MPOD aceptadora y el campo problema de la UDPA ODRCH indica problema general, emite una primitiva Indicación OD-RECHAZO-P al aceptador. Los parámetros de la primitiva Indicación OD-RECHAZO-P (ID-invocación y motivo-rechazo) se derivan de la UDPA ODRCH.
La MPOD receptora espera una primitiva de indicación de transferencia del proveedor de servicio de transferencia o cualquier otra primitiva del aceptador.
7.5.3.3
Transferencia de UDPA infructuosa
Si una MPOD emisora no puede transferir una UDPA por medio de la primitiva de petición de transferencia (por ejemplo, en el caso de liberación de asociación anómala), la MPOD emisora emite una primitiva Indicación OD-RECHAZO-P al solicitante para cada UDPA no transferida aún.
El parámetro parámetros devueltos de la primitiva Indicación OD-RECHAZO-P contiene los parámetros de las primitivas Petición OD-INVOCACIóN, Petición OD-RESULTADO, Petición OD-ERROR o Petición OD-RECHAZO-U.
Después que han sido emitidos al solicitante todos los parámetros devueltos de las UDPA no transferidas, la asociación de aplicación, si existe aún, es liberada anómalamente.
7.5.4
Utilización de los campos de la UDPA ODRCH
Los campos de la UDPA ODRCH se utilizan como sigue.
7.5.4.1
ID-invocación
Este es el campo ID-invocación de una UDPA rechazada y el parámetro ID-invocación de la primitiva de servicio Indicación OD-RECHAZO-P. El tipo y el valor de este campo pueden ser NULL, si el campo ID-invocación la la UDPA rechazada no es detectable. En este caso, se omite el parámetro ID-invocación de la primitiva Indicación OD-RECHAZO-P.
7.5.4.2
Problema: problema general
Es el valor del parámetro problema de la primitiva Indicación OD-RECHAZO-P. Los valores utilizados por el procedimiento de rechazo por el proveedor son:
d)
Problema general
: Rechazo por el proveedor de una
UDPA con valores:
-UDPA no reconocida: significa que el tipo de la UDPA, evidenciado por su identificador de tipo, no es uno de los cuatro definidos por esta Recomendación.
-UDPA con tipo erróneo: significa que la estructura de la UDPA no se ajusta a esta Recomendación.
-UDPA mal estructurada: significa que la estructura de la UDPA no se ajusta a la notación y codificación normalizadas definidas en las Recomendaciones X.208 y X.209.
8 Relación de correspondencia con los
servicios utilizados
Esta cláusula define cómo una MPOD transfiere las UDPA por medio de:
a)los servicios ESTF, o
b)el servicio de presentación.
En el 8.1 se define la relación de correspondencia con los servicios ESTF, y en el 8.2 la relación de correspondencia con el servicio de presentación.
Se supone la identificación de la sintaxis abstracta denominada en uso para todos los servicios ESOD y se establece su correspondencia con los servicios utilizados; sin embargo, éste es un asunto local y está fuera del objeto de esta Recomendación.
8.1
Relación de correspondencia con los servicios ESTF
En este apartado se define cómo las primitivas de servicio ESTF descritas en la Recomendación X.218 son utilizadas por la MPOD. En el cuadro 7/X.229 se indica la relación de correspondencia de las primitivas del servicio ESOD y sus UDPA con las primitivas de servicio ESTF.
Cuadro 7/X.229, [T7.229] p.
8.1.1
Gestión del turno
Una MPOD poseerá el turno antes de que pueda utilizar el servicio TF-TRANSFERENCIA. La MPOD sin el turno puede emitir una primitiva Petición TF-SOLICITUD TURNO, cuyo parámetro prioridad refleja la UDPA de máxima prioridad que espera transferencia.
La MPOD que tiene el turno puede emitir una primitiva Petición TF-CESIóN TURNO cuando no tiene otras UDPA para transferir. Emitirá una primitiva Petición TF-CESIóN TURNO en respuesta a una Indicación TF-SOLICITUD TURNO cuando no tiene otras UDPA para transferir de prioridad igual o mayor a la indicada en la primitiva Indicación TF-SOLICITUD TURNO. Si tiene UDPA de prioridad menor aún por transferir, puede emitir una Petición TF-SOLICITUD TURNO cuya prioridad refleje la UDPA de máxima prioridad que queda por transferir.
8.1.1.1
Utilización del servicio TF-SOLICITUD TURNO
La MPOD emite la primitiva Petición TF-SOLICITUD TURNO para pedir el turno. Puede hacerlo así solamente si no posee ya el turno. El servicio TF-SOLICITUD TURNO es un servicio no confirmado.
La utilización de los parámetros de servicio TF-SOLICITUD TURNO es la siguiente:
Prioridad: refleja la UDPA de máxima prioridad que espera transferencia.
8.1.1.2
Utilización del servicio TF-CESIóN TURNO
La MPOD emite la primitiva Petición TF-CESIóN TURNO para ceder el turno a su par. Puede hacerlo así solamente si posee el turno. El servicio TF-CESIóN TURNO es un servicio no confirmado que no tiene parámetros.
8.1.2
Transferencia de UDPA
Cada UDPA es transferida como datos de usuario del servicio TF-TRANSFERENCIA. La MPOD sólo emite una primitiva Petición TF-TRANSFERENCIA si la MPOD posee el turno y si no hay primitiva Confirmación TF-TRANSFERENCIA pendiente.
8.1.2.1
Utilización del servicio TF-TRANSFERENCIA
El servicio TF-TRANSFERENCIA es un servicio confirmado.
Los parámetros de la primitiva Petición TF-TRANSFERENCIA se utilizan como sigue:
UDPA La UDPA que ha de transferirse. Su tamaño máximo no está limitado en esta correspondencia.
Tiempo de transferencia Es especificado por una regla local de la MPOD emisora. Puede relacionarse con la prioridad de la UDPA.
Los parámetros de la primitiva Indicación TF-TRANSFERENCIA se utilizan como sigue:
UDPA La UDPA transferida. Su tamaño máximo no está limitado en esta correspondencia.
Los parámetros de la primitiva Confirmación TF-TRANSFERENCIA se utilizan como sigue:
UDPA
La UDPA no transferida dentro del tiempo de transferencia. Este parámetro se
proporciona solamente si el valor del parámetro resultado es
`UDPA no
transferida'
. En este caso, la MPOD emite una primitiva Indicación
OD-RECHAZO-P con el parámetro parámetros devueltos.
Resultado
El valor de parámetro
`UDPA transferida'
indica una confirmación
positiva, el valor de parámetro
`UDPA no transferida'
indica una
confirmación negativa.
8.2
Relación de correspondencia con el servicio de
presentación
A continuación se define cómo las primitivas del servicio de presentación descritas en la Recomendación X.216 son utilizadas por la MPOD. En el cuadro 8/X.229 se define la relación de correspondencia de las primitivas y de las UDPA del servicio ESOD con las primitivas del servicio de presentación.
Cuadro 8/X.229, [T8.229] p.
8.2.1
Transferencia de UDPA
Cada UDPA es transferida como datos de usuario del servicio P-DATOS.
8.2.1.1
Utilización del servicio P-DATOS
El servicio P-DATOS es un servicio no confirmado.
Los parámetros de las primitivas Petición P-DATOS e Indicación P-DATOS se utilizan como sigue:
Datos de Usuario La UDPA que ha de transferirse. Su tamaño máximo no está limitado en esta correspondencia.
9 Definición de la sintaxis abstracta de
las UDPA
A continuación se especifica la sintaxis abstracta de cada UDPA del ESOD utilizando la notación de sintaxis abstracta de la Recomendación X.208 que se muestra en la figura 1/X.229.
Figure 1/X.229 [T9.229], p.9 (à traiter comme tableau
MEP)
Figure 1/X.229 [T10.229], p.10 (à traiter comme tableau
MEP)
Figure 1/X.229 [T11.229], p.11 (à traiter comme tableau
MEP)
10
Conformidad
Una realización que se manifieste conforme con esta Recomendación cumplirá los requisitos indicados en los 10.1 a 10.3.
10.1
Requisitos de declaración
El realizador declarará lo siguiente:
a)el contexto de aplicación para el cual se pretende la conformidad, incluido si el sistema admite la correspondencia de ESOD con ESTF, con el servicio de presentación, o con ambos.
10.2
Requisitos estáticos
El sistema:
a)se ajustará a la definición de sintaxis abstracta de las UDPA definida en el 9 .
10.3
Requisitos dinámicos
El sistema:
a)se ajustará a los elementos de procedimiento definidos en el 7 ;
b)se ajustará a las correspondencias con los servicios usados, para los cuales se pretende la conformidad, según se define en el 8 .
ANEXO A (a la Recomendación X.229)
Tablas de estados de la
MPOD
Este anexo forma parte integrante de esta Recomendación.
A.1
Generalidades
Este anexo define una sola máquina de protocolo de operaciones a distancia (MPOD) en términos de una tabla de estados. Esta tabla de estados muestra la interrelación entre el estado de una asociación de aplicación, los sucesos entrantes que se producen en el protocolo, las acciones realizadas y, por último, el estado resultante de la asociación de aplicación.
La tabla de estados de la MPOD no constituye una definición formal de la MPOD. Se incluye para proporcionar una especificación más precisa de los elementos de procedimiento definidos en los 7 y 8.
Este anexo contiene los siguientes cuadros:
a)cuadro A-1/X.229, que especifica el nombre abreviado, fuente y nombre»descripción de cada suceso entrante. Las fuentes son:
1)usuario-ESOD (usuario-ESOD);
2)MPOD par (MPOD-par);
3)MPOD que excluye la parte de transferencia (MPOD);
4)parte transferencia de la MPOD (MPOD-TR);
5)proveedor del servicio de presentación (proveedor-SP) y el elemento de servicio del control de asociación (ESCA), o el elemento de servicio de transferencia fiable (ESTF);
b)cuadro A-2/X.229, que especifica el nombre abreviado de cada estado de la MPOD;
c)cuadro A-3/X.229, que especifica el nombre abreviado de cada estado de la MPOD-PR;
d)cuadro A-4/X.229 especifica el nombre abreviado, objetivo y nombre»descripción de cada suceso saliente. Los objetivos son:
1)usuario-ESOD (usuario-ESOD);
2)MPOD par (MPOD-par);
3)MPOD que excluye la parte de transferencia (MPOD);
4)parte transferencia de la MPOD (MPOD-TR); y
5)proveedor del servicio de presentación (proveedor-SP) y el elemento de servicio del control de asociación (ESCA), o el elemento de servicio de transferencia fiable (ESTF);
e)cuadro A-5/X.229, que especifica los predicados;
f)cuadro A-6/X.229, que especifica la tabla de estados de la MPOD utilizando las abreviaturas de las tablas anteriores;
g)cuadro A-7/X.229, que especifica la tabla de estados de la MPOD-TR utilizando las abreviaturas de las tablas anteriores, si el ESTF está incluido en el contexto de aplicación;
h)cuadro A-8/X.229, que especifica la tabla de estados de la MPOD-TR utilizando las abreviaturas de las tablas anteriores, si el ESTF no está incluido en el contexto de aplicación.
A.2
Convenios
La intersección de un suceso entrante (fila) y un estado (columna) forman una casilla.
En la tabla de estados, una casilla en blanco representa la combinación de un suceso entrante y un estado que no está definido para la MPOD (véase el Î A.3.1).
Una casilla que no está en blanco representa un suceso entrante y un estado que está definido para la MPOD. Esta casilla contiene una o más listas de acciones. Una lista de acciones puede ser obligatoria o condicional. Si una casilla contiene una lista de acciones obligatorias, ésta es la única lista de acciones en la casilla.
Una lista de acciones obligatorias contiene:
a)facultativamente uno o más sucesos salientes, y
b)un estado resultante.
Una lista de acciones condicionales contiene:
a)una expresión de predicado que comprende predicados y operadores booleanos ( representa el booleano NOT), y
b)una lista de acciones obligatorias (esta lista de acciones obligatorias se utiliza solamente si la expresión de predicado es verdadera).
A.3
Acciones que ha de realizar la MPOD
La tabla de estados de la MPOD define la acción que ha de realizar la MPOD en términos de un suceso saliente facultativo y el estado resultante de la asociación de aplicación.
A.3.1
Intersecciones inválidas
Las casillas en blanco indican una intersección inválida de un suceso entrante y un estado. Si se produce esta intersección, se ejecuta una de las acciones siguientes:
a)Si el suceso entrante proviene del usuario ESOD, cualquier acción realizada por la MPOD es un asunto local.
b)Si el suceso entrante se relaciona con una UDPA recibida, el proveedor-SP, ESCA o ESTF, la MPOD emite un suceso AA-ABpet a la MPOD-TR, o la MPOD-TR emite una ABORTpet al ESTF o al ESCA y una AA-ABind a la MPOD.
A.3.2
Intersecciones válidas
Si la intersección del estado y del suceso entrante es válida, se realiza una de las acciones siguientes:
a)Si la casilla contiene una lista de acciones obligatorias, la MPOD realiza las acciones especificadas.
b)Si la casilla contiene una o más listas de acciones condicionales, para cada expresión de predicado que es verdadera, la MPOD realiza la acción especificada. Si ninguna de las expresiones de predicado es verdadera, la MPOD realiza una de las acciones definidas en el Î A.3.1.
Tableau A-1/X.229 [T12.229], p.12
Tableau A-2/X.229 [T14.229], p.13
Tableau A-3/X.229 [T15.229], p.14
Tableau A-4/X.229 [T16.229], p.15
Tableau A-5/X.229 [T17.229], p.16
Tableau A-6/X.229 [T18.229], p.17
Tableau A-7/X.229 [T19.229], p.18
Tableau A-8/X.229 [T20.229], p.19
ANEXO B (a la Recomendación X.229)
Diferencias entre esta
Recomendación y la Recomendación X.410-1984
Este
anexo no forma parte integrante de esta Recomendación.
En este anexo se describen las diferencias técnicas entre la notación y el protocolo para operaciones a distancia de esta Recomendación y la notación y el protocolo correspondientes de la Recomendación X.410-1984.
B.1
Macros
B.1.1
Nuevas macros
1)
Añadir
^:macro BIND y macro UNBIND
B.1.2
Macro OPERATION
1)Notación de valor
Cambiar
^: De:INTEGER A:CHOICE{INTEGEROBJECT IDENTIFIER}
2)Tipo denominado en producción de resultados
Cambiar
^: De:obligatorio A:facultativo
3)
Añadir
^:Producciones para operaciones enlazadas.
B.1.3
Macro ERROR
1)Notación de valor (Véase el apartado 1) del Î B.1.2.
B.2
Unidades de datos de protocolo de aplicación
B.2.1
UDPA
1)Alternativa de elección
Cambiar
^: De:rotulado
explícito A:rotulado implícito
B.2.2
Invocación
1)
Añadir
:elemento ID-enlazado facultativo a SEQUENCE
2)Elemento de argumento
Cambiar
^: De:obligatorio
A:facultativo
B.2.3
Retorno de resultado
1)
Añadir
:Valor de operación de campo y SEQUENCE
2)Elemento de resultado
Cambiar
^: De:obligatorio
A:facultativo
B.2.4
Rechazo
1)Invocación problema
Añadir
:valores (3) a (7) inclusive
B.3
Procedimientos y relación de correspondencia
B.3.1
Relación de correspondencia con los servicios
utilizados
1)
Añadir:
Relación de correspondencia con el servicio de
presentación si el ESTF está ausente en el contexto de aplicación.
2)
Añadir:
Relación de correspondencia para BIND y
UNBIND.
B.4
Interfuncionamiento entre las realizaciones de 1984 y de
1988
Debido al apartado 1) del Î B.2.1 y al apartado 1) del Î B.2.3, el interfuncionamiento entre las realizaciones de 1984 y de 1988 no es posible. Sin embargo, el primer cambio se indicó en la versión 5 de la Guía de realizadores de las Recomendaciones de la serie X.400.
ANEXO C (a la Recomendación X.229)
Resumen de valores
asignados de identificador de objeto
Este anexo no forma parte
integrante de esta Recomendación.
En este anexo se resumen los valores de identificador de objeto asignados en las Recomendaciones X.219 y X.229.
{ joint-iso-ccitt remote-operations (4) notation (0)
}
--
módulo NSA.1 definido en la Recomendación X.219
{ joint-iso-ccitt remote-operations (4) apdus (1) }
--
módulo NSA.1 definido en la Recomendación X.229
{ joint-iso-ccitt remote-operations (4) notation-extensions
(2) }
--
módulo NSA.1 definido en la Recomendación
X.219
{ joint-iso-ccitt remote-operations (4) aseID (3) }
--
identificador ESA definido en la Recomendación X.229
{ joint-iso-ccitt remote-operations (4) aseID-ACSE (4)
}
--
identificador ESA definido en la Recomendación
X.219
PROCEDIMIENTO PARA EL
INTERCAMBIO DE
IDENTIFICACIONES DE PROTOCOLO DURANTE EL ESTABLECIMIENTO DE
LLAMADAS VIRTUALES
EN LAS REDES
PúBLICAS DE DATOS CON CONMUTACIóN DE PAQUETES
(Málaga-Torremolinos, 1984)
El CCITT,
considerando
(a) que la Recomendación X.25 define el interfaz entre el equipo terminal de datos (ETD) y el equipo de terminación del circuito de datos (ETCD) para terminales que funcionan en el modo paquetes y están conectados con una red pública de datos por un circuito especializado;
(c) que la Recomendación X.29 define los procedimientos para el intercambio de información de control y datos de usuario entre una facilidad de desensamblado/ensamblado de paquetes (DEP) y un ETD de paquetes u otra DEP;
(d) que la Recomendación X.224 define el protocolo de la capa de transporte para la interconexión de sistemas abiertos en aplicaciones del CCITT, que incluye disposiciones relativas a la identificación del protocolo de transporte;
(e) que para el establecimiento de una llamada virtual es necesario identificar y/o negociar el protocolo que se utilizará por encima del nivel paquetes,
recomienda por unanimidad
que para equipos terminales de datos que funcionen en el modo paquetes el mecanismo para la identificación y/o negociación del protocolo que se utilizará por encima del nivel paquetes deberá ajustarse a la siguiente especificación.
1 Introducción
Esta Recomendación define los procedimientos de intercambio de identificación de protocolo durante el establecimiento de una llamada virtual en una red pública de datos con conmutación de paquetes. Este procedimiento actúa sobre el nivel paquetes de la Recomendación X.25. Este procedimiento utiliza los bits 8 y 7 del primer octeto del campo de datos de usuario en los paquetes de establecimiento de la llamada definidos en la Recomendación X.25.
2
Campo de datos
de usuario llamante
El siguiente procedimiento se aplica al
campo de datos de
usuario llamante
de los paquetes de petición de
llamada y de llamada entrante.
Si el campo de datos de usuario llamante está presente, la utilización y el formato de este campo vienen determinados por los bits 8 y 7 de su primer octeto (véase la nota más abajo).
Si los bits 8 y 7 del primer octeto del campo de datos de usuario llamante son 01, una parte del campo de datos de usuario de la llamada puede utilizarse para identificación de protocolo de conformidad con especificaciones establecidas por las Administraciones.
Si los bits 8 y 7 del primer octeto del campo de datos de usuario llamante son 10, una parte del campo de datos de usuario de la llamada puede utilizarse para identificación de protocolo de acuerdo con especificaciones establecidas por organismos internacionales de usuario.
Si los bits 8 y 7 del primer octeto del campo de datos de usuario llamante son 11, la utilización, por el ETD, de la parte restante del campo de datos de usuario de la llamada no está sujeta a ninguna restricción.
Se previene a los usuarios de que si los bits 8 y 7 del primer octeto del campo de datos de usuario llamante tienen un valor cualquiera distinto de 11, se podrá identificar un protocolo de aplicación dentro de las redes públicas de datos.
Nota
- Cuando se está estableciendo una llamada
virtual entre dos ETD de paquetes, la red no actúa sobre ninguna parte del
campo de datos de usuario llamante.
3
Campo de datos
de usuario llamado
El siguiente procedimiento se aplica al campo de datos de usuario llamado
de los paquetes de
llamada aceptada
y de
llamada establecida
utilizados en combinación con la
facilidad de selección rápida.
Si el campo de datos de usuario llamado está presente, la utilización y el formato de este campo vienen determinados por los bits 8 y 7 de su primer octeto (véase la nota más abajo).
Si los bits 8 y 7 del primer octeto del campo de datos de usuario llamado son 00, una parte del campo de datos de usuario llamado se utiliza para identificación de protocolo de conformidad con otras Recomendaciones.
Si los bits 8 y 7 del primer octeto del campo de datos de usuario llamado son 10, una parte del campo de datos de usuario llamado puede utilizarse para identificación de protocolo de acuerdo con especificaciones establecidas por organismos internacionales de usuarios.
Si los bits 8 y 7 del primer octeto del campo de datos de usuario llamado son 11, la utilización, por el ETD, de la parte restante del campo de datos de usuario llamado no está sujeta a ninguna restricción.
Se previene a los usuarios de que si los bits 8 y 7 del primer octeto del campo de datos de usuario llamado tienen un valor cualquiera distinto de 11, se podrá identificar un protocolo de aplicación dentro de las redes públicas de datos.
Nota
- Cuando se está estableciendo una llamada virtual
entre dos ETD de paquetes, la red no actúa sobre ninguna parte del campo de
datos de usuario llamado.
SECCIóN 2 - Disk 259 NF01/007 (OPM = 01)
Anexo D
NF01/010 (OPM = 01)
- NF01/010 (OPM = 01)
Apéndice III
NF01/010 (OPM = 01)
- NF01/010 (OPM = 01)
Recomendación X.200 - NF01/020 (OPM = 01)
Recomendación* Disk 260 NF01/028 (OPM = 02)
Recomendación X.290/1 - Disk 262 NF01/005 (OPM = 04)
TTCN NF01/007 (OPM = 04)
D.1.1 Disk 263 NF01/012 (OPM = 06)
D.1.1.1 NF01/012 (OPM = 06)
(cs,1) Disk ... NF../... (OPM = ..)
(BT..) Disk ... NF../... (OPM = ..)
(85.TE.14.S)
(A1.23s) / [26s]
FOLIOS: 479 - 529
(DO PRC.COSY.2)
MEP {TPS.NON.PHOTO "[PA1]"} : OK= [1]
Saisie diskettes 259 à 263 08.03.89 YB/PR/YB/PR/IR
ID + Vérif. + diskette MAJ + laser 20.03.89 PV
Corr. LASER (1re épreuve) = 3eme 03.04.89 RM
Vérif. corr. + transfert + imprimantes 05.04.89 ZR
Espaces réservés 05.04.89 GH/ZR
AJOUTER (PA1) (CL1,0,0,0) pour MEP
MEP + LASER 07.04.89 GH/ZR
Corr. MEP ........ ..
Insertion des tableaux (tabulateurs ..) ........ ..
BAT du 19.04.89 24.04.89 PV
Ultimes 01.05.89 PV
MAJ DISKETTE ........ ..
SECCIóN 4
METODOLOGíA DE LAS PRUEBAS DE CONFORMIDAD
Recomendación X.290
METODOLOGíA DE LAS PRUEBAS DE CONFORMIDAD CON ISA Y MARCO PARA
LAS RECOMENDACIONES SOBRE LOS PROTOCOLOS PARA APLICACIONES
DEL CCITT
La Recomendación X.290 ha sido elaborada en estrecha colaboración
con las actividades ISO/CEI sobre el marco y la metodología de las pruebas de
conformidad ISA. Para su publicación, la Recomendación X.290 estaba alineada
con los textos de DP 9646/1 y DP 9646/2. Dado que este trabajo se encontraba en
una etapa inicial de su elaboración, cabe esperar cambios en él. En
consecuencia, los usuarios deberían ser prudentes al aplicar esta
Recomendación.
(Melbourne, 1988)
El CCITT,
considerando
(a) que la Recomendación X.200 define el modelo de referencia para la interconexión de sistemas abiertos (ISA) para aplicaciones del CCITT;
(b) que el objetivo de la ISA sólo se alcanzará completamente cuando los sistemas dedicados a aplicaciones especificadas por el CCITT puedan ser probados para determinar si son o no conformes a las Recomendaciones pertinentes sobre los protocolos para la ISA;
(c) que para cada una de las Recomendaciones sobre los protocolos ISA deben elaborarse series de pruebas normalizadas como un medio para:
-obtener una aceptación y una confianza generalizadas en los resultados de las pruebas de conformidad obtenidos por diferentes probadores;
-crear la confianza en que los equipos que superan las pruebas de conformidad normalizadas puedan funcionar combinadamente;
(d) la necesidad de establecer una Recomendación internacional para definir el marco y los principios generales para la especificación de series de pruebas de conformidad y la prueba de realizaciones de protocolos,
recomienda por unanimidad
(1) que los principios generales, las definiciones de términos y los conceptos relativos a las pruebas de conformidad de protocolos ISA se ajusten a la parte 1 de esta Recomendación;
(2) que los métodos de prueba, las series de pruebas y las notaciones de prueba se ajusten a la parte 2 de esta Recomendación.
íNDICE
Parte 1
-
Conceptos generales
0Introducción
1Objeto y campo de aplicación
2Referencias
SECCIóN 1 -
Terminología
3Definiciones
4Abreviaturas
SECCIóN 2 -
Visión de conjunto
5El significado de conformidad en la ISA*
6Conformidad y comprobación
7Métodos de prueba
8Series de pruebas
9Relaciones entre conceptos y roles
10Cumplimiento
Parte 2
-
Especificación de series de
pruebas abstractas
0Introducción
1Objeto y campo de aplicación
2Referencias
3Definiciones
4Abreviaturas
5Conformidad
SECCIóN 1 -
Requisitos que deben cumplir los especificadores
de protocolos
6Requisitos de conformidad en las Recomendaciones* ISA*
7Proformas ECRP
SECCIóN 2 -
Requisitos que deben cumplir los especificadores
de series de pruebas abstractas
8Proceso de elaboración de series de pruebas
9Determinación de los requisitos de conformidad y del ECRP
10Estructura de las series de pruebas
11Especificación de caso de prueba genérica
12Métodos de pruebas abstractas
13Especificación de series de pruebas abstractas
14Utilización de una especificación de serie de pruebas abstractas
15Mantenimiento de series de pruebas
Anexo A
-Opciones
Anexo B
-Guía para la redacción de Recomendaciones*
sobre protocolos
Anexo C
-Requisitos de conformidad estática incompletos
Anexo D
-Notación combinada tabular y de árbol
Apéndice I
-Aplicabilidad de los métodos de prueba a
protocolos ISA*
Apéndice II
-índice de las definiciones de términos
Apéndice III
-Ejemplos de orientación para los
especificadores de proformas de ECRP
Apéndice IV
-Ejemplo de elección de métodos de pruebas
abstractas
Parte 1 - Conceptos generales
0 Introducción
El objetivo de la interconexión de sistemas abiertos (ISA) sólo se
alcanzará completamente cuando sea posible probar los sistemas para determinar
si son o no conformes con las Normas o Recomendaciones relativas a la ISA o a
las correspondientes Recomendaciones de las series X y T del CCITT. (En lo
sucesivo, las Recomendaciones de las series X y T del CCITT sobre la ISA o
relativas a ella se designarán abreviadamente por
`ISA*'
y las Normas o
Recomendaciones se designarán abreviadamente por
`Recomendaciones*'
.)
Para cada Recomendación sobre protocolo ISA* deberán elaborarse series de pruebas normalizadas para que sean utilizadas por los suministradores, o por los realizadores en pruebas efectuadas por su cuenta, por los usuarios de productos ISA, por las Administraciones* o por terceras entidades dedicadas a realización de pruebas (verificadores). Esto debe conducir a la compatibilidad y una amplia aceptación de los resultados de pruebas realizadas por diferentes verificadores, y traducirse en una reducción de las repeticiones de pruebas de conformidad del mismo sistema.
La normalización de las series de pruebas require la definición y aceptación internacional de una metodología común de pruebas y de métodos y procedimientos de prueba apropiados. Esta Recomendación tiene por finalidad definir la metodología, proporcionar un marco para especificar series de pruebas de conformidad, y definir los procedimientos que han de seguirse durante las pruebas.
La prueba de conformidad comprende la verificación de las capacidades y del comportamiento de una realización y la comprobación de que lo que se está observando se ajusta a los requisitos de conformidad establecidos en las Recomendaciones* pertinentes así como a las capacidades de la realización tal como éstas han sido enunciadas por el realizador.
Las pruebas de conformidad no comprenden una evaluación de la calidad ni de robustez o la fiabilidad de una realización. Tampoco proporcionan juicios sobre la realización física de las primitivas de servicio abstractas, sobre el modo en que se ha realizado un sistema, o la manera de proporcionar un servicio solicitado, ni tampoco sobre el entorno de la realización de los protocolos. No pueden proporcionar, al menos en forma indirecta, prueba alguna sobre el diseño lógico del protocolo propiamente dicho.
Las pruebas de conformidad tienen por objeto aumentar la probabilidad de que puedan interfuncionar realizaciones diferentes. Esto se consigue verificándolas por medio de una serie de pruebas de protocolos, con lo cual se aumenta la confianza en que cada realización sea conforme a la especificación del protocolo. La confianza en la conformidad con una especificación de protocolo es particularmente importante cuando deban interfuncionar equipos suministrados por proveedores diferentes.
No obstante, debe tenerse presente que la complejidad de la mayor parte de los protocolos hace prácticamente imposible realizar pruebas exhaustivas sobre una base técnica y económica. Además, las pruebas no pueden garantizar la conformidad con una especificación, pues en ellas se detectan errores, y no la ausencia de éstos. En consecuencia, la conformidad obtenida mediante una serie de pruebas no puede garantizar el interfuncionamiento. Lo que sí se obtiene es cierto grado de confianza en que una realización tiene las aptitudes requeridas y que su comportamiento se ajusta a situaciones representativas de comunicaciones.
Debe señalarse que en el modelo de referencia de ISA para aplicaciones del CCITT (Recomendación X.200) se expresa (en el 4.3 ):
`Como pauta del comportamiento de los sistemas reales abiertos, sólo se
considera el comportamiento externo de los sistemas abiertos.'
Esto significa que, aunque en las Recomendaciones* sobre la ISA* se describen aspectos de los comportamientos interno y externo, los sistemas abiertos reales sólo tienen que satisfacer los requisitos del comportamiento externo. Aunque algunos de los métodos definidos en esta Recomendación imponen, en efecto, ciertas restricciones al realizador, por ejemplo que deba haber algún medio para realizar el control y la observación en uno o más puntos de acceso al servicio, debe señalarse que otros métodos definidos en las misma no imponen esas limitaciones.
Sin embargo, en el caso de sistemas finales ISA* parciales, que proporcionan protocolos ISA* hasta una determinada frontera de capa, es conveniente probar tanto el comportamiento externo de las entidades de protocolo realizadas como las posibilidades de esas entidades para permitir un comportamiento externo correcto en capas superiores.
En diversas partes de esta Recomendación se realiza una investigación detallada de las ventajas relativas, la eficacia y las limitaciones de todos los métodos. No obstante, toda organización que contemple la utilización de los métodos de prueba definidos en esta Recomendación en un contexto tal como la certificación deberá estudiar detenidamente las limitaciones de aplicabilidad y las ventajas de los diferentes métodos de prueba posibles.
La prueba es voluntaria en lo que respecta a la ISO/CCITT. Los requisitos que deben cumplirse para las pruebas en las adquisiciones y otros contratos externos no constituyen materia de normalización.
1 Objeto y campo de aplicación
1.1 Esta Recomendación especifica una metodología general para verificar la conformidad, con las Recomendaciones* sobre protocolos ISA*, de productos con relación a los cuales se declara que se han construido de conformidad con las Recomendaciones*. La metodología es también aplicable a la prueba de la conformidad con las Recomendaciones* sobre la sintaxis de transferencia, en la medida en que pueda determinarse probando cada producto en combinación con un protocolo ISA* específico.
1.2 Esta Recomendación está estructurada en dos partes distintas:
En la parte 1 se identifican las diferentes fases del proceso de prueba de conformidad; estas fases se caracterizan por cuatro papeles principales. Estos papeles, o roles, son:
a)la especificación de series de pruebas abstractas para determinados protocolos ISA*;
b)la elaboración de series de pruebas ejecutables e instrumentos de prueba asociados;
c)el rol del cliente de un laboratorio de prueba que somete a prueba una realización de protocolos ISA*;
d)la ejecución de las pruebas de conformidad, como resultado de las cuales se establece un informe de prueba de conformidad en el cual se indican los resultados obtenidos sobre la base de las Recomendaciones* y las series de pruebas utilizadas.
Además, esta parte contiene material didáctico, así como las definiciones de conceptos y términos.
La parte 2 define los requisitos y proporciona orientaciones para la especificación de series de pruebas abstractas para los protocolos ISA*.
1.3 En ambas partes de esta Recomendación, el objeto se ha limitado de modo que incluya solamente las informaciones necesarias para alcanzar los siguientes objetivos:
a)lograr un nivel de confianza adecuado en las pruebas como orientación para la conformidad;
b)lograr la comparabilidad entre los resultados de las pruebas correspondientes realizadas en tiempos y lugares diferentes;
c)facilitar la comunicación entre las entidades responsables de los roles descritos anteriormente.
1.4 Uno de estos aspectos concierne al marco para la elaboración de series de pruebas ISA*. Por ejemplo:
a)su relación con los diversos tipos de requisitos de conformidad;
b)los tipos de prueba que deben normalizarse y los tipos que no necesitan normalización;
c)los criterios para seleccionar las pruebas que habrán de incluirse en una serie de pruebas de conformidad;
d)la notación que ha de utilizarse para definir pruebas;
e)la estructura de una serie de pruebas.
1.5 La certificación, que es un procedimiento administrativo que puede seguir a una prueba de conformidad, está fuera del ámbito de esta Recomendación. Los requisitos de las adquisiciones y los contratos tampoco están comprendidos en el ámbito de esta Recomendación.
1.6 Los protocolos de la capa física y de control de acceso a los medios, están fuera del campo de aplicación de esta Recomendación.
2
Referencias
Recomendación X.200 -
Modelo de referencia de interconexión
de sistemas abiertos para aplicaciones del CCITT
(véase también la Norma ISO 7498).
Recomendación X.210 -
Convenios relativos a la definición
del servicio de capa en la interconexión de sistemas
abiertos (ISA)
(véase también la Norma ISO TR 8509).
Recomendación X.209 -
Especificación de reglas básicas
de codificación para la notación de sintaxis abstracta uno
(NSA.1)
(véase también la Norma ISO 8825).
SECCIóN 1 -
Terminología
3
Definiciones
3.1
Definiciones relativas al modelo de referencia
Esta Recomendación se basa en los conceptos desarrollados en el modelo de referencia de interconexión de sistemas abiertos para aplicaciones del CCITT (Recomendación X.200) y utiliza los siguientes términos definidos en dicha Recomendación:
a)entidad (N)
b)servicio (N)
c)capa (N)
d)protocolo (N)
e)punto de acceso al servicio (N)
f)relevo (N)
g)unidad de datos de protocolo (N)
h)información de control de protocolo (N)
i)datos de usuario (N)
j)sistema abierto real
k)subred
l)entidad de aplicación
m)elemento de servicio de aplicación
n)sintaxis de referencia
o)capa física
p)capa de enlace de datos
q)capa de red
r)capa de transporte
s)capa de sesión
t)capa de presentación
u)capa de aplicación
v)gestión de sistemas
w)gestión de aplicación
x)gestión de capa
3.2
Términos definidos en otras Recomendaciones
En esta Recomendación se utilizan los siguientes términos definidos en convenios del servicio ISA (Recomendación X.210):
a)usuario del servicio
b)proveedor del servicio.
En esta Recomendación se utilizan los siguientes términos definidos en la Recomendación sobre las reglas básicas de codificación - NSA.1 (Recomendación X.209):
c)codificación.
3.3
Definiciones relativas a las pruebas de conformidad
Para los fines de esta Recomendación son aplicables las definiciones indicadas en los 3.4 a 3.8.
3.4
Términos básicos
3.4.1@
realización sometida a prueba (RSP)
@
\Parte de un sistema abierto real que ha de estudiarse mediante una prueba y que debe ser la realización de uno o más protocolos ISA* en una relación usuario/proveedor adyacente.\
3.4.2@
sistema sometido a prueba (SSP)
@
\Sistema abierto real en que reside la RSP.\
3.4.3@
requisitos de conformidad dinámica
@
\Todos los requisitos (y opciones) que determinan el comportamiento observable que está permitido por las Recomendaciones* ISA* pertinentes en situaciones de comunicación.\
3.4.4@
requisitos de conformidad estática
@
\Limitaciones impuestas en Recomendaciones* ISA* para facilitar el interfuncionamiento definiendo los requisitos que deben cumplir las capacidades de una realización.
Nota
- Los requisitos de conformidad estática pueden
establecerse a un nivel generalizado, como por ejemplo la agrupación de
unidades funcionales y opciones en clases de protocolo, o a un nivel detallado,
como por ejemplo las gamas de valores que deberán ser admitidos para parámetros
o temporizadores específicos.\
3.4.5@
capacidades de una RSP
@
\Conjunto de funciones y opciones en el protocolo o protocolos pertinentes y, si procede, conjunto de facilidades y opciones de la definición de servicio correspondiente, que son admitidos por la RSP.\
3.4.6@
enunciado de conformidad de realización de protocolo
(ECRP)
@
\Enunciado elaborado por el suministrador de una realización o sistema ISA* en el cual se indican las capacidades y opciones que han sido establecidas, y toda prestación o característica que haya sido omitida.\
3.4.7@
proforma del ECRP
@
\Documento, en forma de cuestionario preparado por el especificador de un protocolo, o por el especificador de una serie de pruebas de conformidad, el cual, tras haberse establecido para una realización o sistema ISA*, se convierte en el ECRP.\
3.4.8@
información suplementaria sobre realización de
protocolo para pruebas (ISRPP)
@
\Enunciado elaborado por el suministrador o el realizador de una RSP que contiene toda la información (además de la contenida en el ECRP) relacionada con la RSP y su entorno de pruebas, o hace referencia a la misma, y que permitirá al laboratorio de pruebas aplicar la serie apropiada de pruebas a la RSP.\
3.4.9@
proforma de la ISRPP
@
\Documento, en forma de cuestionario, proporcionado por el laboratorio de pruebas, el cual, una vez establecido durante la preparación de una prueba, se convierte en una ISRPP.\
3.4.10@
realización conforme
@
\RSP que, se ha demostrado, satisface los requisitos de conformidad estática y dinámica para las capacidades enunciadas en el ECRP.\
3.4.11@
enunciado de conformidad de sistema
@
\Documento que indica en forma concisa las Recomendaciones* ISA* que han sido aplicadas, y con relación a las cuales se ha enunciado la conformidad.\
3.4.12@
cliente
@
\Organización que somete un sistema o realización a una prueba de conformidad.\
3.4.13@
laboratorio de pruebas
@
\Organización que realiza pruebas de conformidad. Puede ser un tercero, una organización de usuarios, una Administración*, o una parte identificable de la organización del proveedor.\
3.5
Tipos de pruebas
3.5.1@
prueba activa
@
\Aplicación de una serie de pruebas a un SSP en condiciones controladas, con la intención de observar las acciones consiguientes de la RSP.\
3.5.2@
prueba pasiva
@
\Observación de actividad de las UDP en un enlace, y comprobación de si el comportamiento observado está o no permitido por las Recomendaciones* pertinentes.\
3.5.3@
prueba multicapa
@
\Prueba del comportamiento de una RSP multicapa, en conjunto, por oposición a su prueba capa por capa.\
3.5.4@
prueba insertada
@
\Prueba del comportamiento de una sola capa dentro de una RSP multicapa sin acceder a las fronteras que tiene esa capa dentro de la RSP.\
3.5.5@
prueba de interconexión básica
@
\Prueba limitada de una RSP para determinar si la conformidad con las características principales de los protocolos pertinentes es o no suficiente para que sea posible una interconexión, sin tratar de realizar una prueba exhaustiva.\
3.5.6@
pruebas de aptitud
@
\Pruebas para determinar las aptitudes de una RSP.
Nota
- Implica la verificación de todas las aptitudes
obligatorias y de las aptitudes facultativas que se indican en el ECRP como
admitidas, pero no de las aptitudes facultativas que se indican en el ECRP como
admitidas por el RSP.\
3.5.7@
examen de conformidad estática
@
\Examen del grado en que la RSP cumple los requisitos de conformidad estática, mediante la comparación de los requisitos de conformidad estática expresados en las Recomendaciones* pertinentes con el ECRP con los resultados de cualquier prueba de aptitudes asociada.\
3.5.8@
prueba de comportamiento
@
\Verificación del grado en que la RSP cumple los requisitos de conformidad dinámica.\
3.5.9@
prueba de conformidad
@
\Verificación del grado en que una RSP es una realización conforme.\
3.5.10@
proceso de evaluación de conformidad
@
\Proceso completo de realización de todas las actividades de pruebas de conformidad necesarias para poder evaluar la conformidad de una realización o de un sistema con una o más Recomendaciones* ISA*. Comprende el establecimiento de los documentos ECRP e ISRPP, la preparación del probador y del SSP reales, la ejecución de una o más series de pruebas, el análisis de los resultados y el establecimiento de los informes de prueba de conformidad apropiados del sistema y del protocolo.\
3.6
Terminología relativa a las series de pruebas
3.6.1@
método de prueba abstracta
@
\Descripción de la manera de probar una RSP, a un nivel de abstracción apropiado, para conseguir que la descripción sea independiente de toda realización particular de instrumentos de prueba, pero lo suficientemente detallada para poder especificar pruebas para este método.\
3.6.2@
metodología de comprobación abstracta
@
\Modo de describir y categorizar métodos de pruebas abstractas.\
3.6.3@
caso de prueba abstracta
@
\Especificación completa e independiente de las acciones requeridas para
alcanzar un objetivo de prueba específico, definido al nivel de abstracción de
un determinado método de prueba abstracta. Comprende un preámbulo y un epílogo
para asegurar que se comienza y se termina en un estado estable (es decir, un
estado que pueda mantenerse casi indefinidamente, como son los estados
`reposo'
o
`transferencia de datos'
), e incluye una o más
conexiones consecutivas o concurrentes.
Nota 1
- La especificación debe ser completa en el
sentido de ser suficiente para poder asociar inequívocamente un veredicto a
cada resultado potencialmente observable (es decir, una secuencia de sucesos de
prueba).
Nota 2
- La especificación ha de ser independiente en
el sentido de que debe ser posible ejecutar el caso de prueba ejecutable
derivado, aislado de cualquier otro caso de prueba (es decir, la especificación
debe incluir siempre la posibilidad de comenzar y terminar en el estado
`reposo'
- o sea, sin ninguna conexión existente, excepto las
permanentes). Con relación a algunos casos de prueba, puede haber requisitos
previos en el sentido de que la ejecución pudiera requerir algunas capacidades
específicas de la RSP, que deberían haber sido confirmadas por resultados de
casos de prueba ejecutados anteriormente.\
3.6.4@
caso de prueba ejecutable
@
\Realización de un caso de prueba abstracta.
Nota
- En general, la palabra
`prueba'
se
utiliza con el significado que usualmente tiene en el lenguaje ordinario.
Algunas veces puede utilizarse como abreviatura de caso de prueba abstracta o
caso de prueba ejecutable. El significado debe poderse determinar por el
contexto.\
3.6.5@
finalidad de la prueba
@
\Descripción del objetivo que debería alcanzar un caso de prueba abstracta.\
3.6.6@
caso de prueba genérica
@
\Especificación de las acciones que deben realizarse para alcanzar una finalidad de prueba específica, definida por un cuerpo de prueba junto con una descripción del estado inicial, en el cual deberá comenzar el cuerpo de prueba.\
3.6.7@
prólogo
@
\Fases de la prueba necesarias para definir el trayecto desde el estado estable de comienzo del caso de prueba hasta el estado inicial en que comenzará el cuerpo de prueba.\
3.6.8@
cuerpo de prueba
@
\Conjunto de fases de la prueba que son esenciales para alcanzar la finalidad de la prueba y asignar valoraciones a los posibles resultados.\
3.6.9@
epílogo
@
\Fases de la prueba necesarias para definir los trayectos desde el final del cuerpo de prueba hasta el estado estable de finalización del caso de prueba.\
3.6.10@
fase de prueba
@
\Subdivisión denominada de un caso de prueba, construida a partir de sucesos de prueba y/u otras fases de prueba, y que se utiliza para modularizar casos de prueba abstracta.\
3.6.11@
suceso de prueba
@
\Unidad indivisible de especificación de prueba en el nivel de abstracción de la especificación (por ejemplo envío o recepción de una UDP simple).\
3.6.12@
serie de pruebas
@
\Conjunto completo de casos de prueba, posiblemente combinados para formar los grupos de pruebas anidados, y que es necesario para realizar pruebas de conformidad o pruebas de interconexión básica para una RSP o un protocolo dentro de una RSP.\
3.6.13@
caso de prueba
@
\Caso de prueba genérico, abstracto o ejecutable.\
3.6.14@
grupo de pruebas
@
\Conjunto denominado de fases de prueba conexas.\
3.6.15@
serie de pruebas genéricas
@
\Serie de pruebas compuesta de casos de pruebas genéricas, que tiene la misma cobertura que el conjunto completo de finalidades de prueba para el protocolo en cuestión, siendo éste el conjunto o un superconjunto de las finalidades de prueba de una serie cualquiera de pruebas abstractas para el mismo protocolo.\
3.6.16@
serie de pruebas abstractas
@
\Serie de pruebas compuesta de casos de prueba abstracta.\
3.6.17@
serie de pruebas ejecutables
@
\Serie de pruebas compuesta de casos de prueba ejecutables.\
3.6.18@
serie de pruebas de conformidad
@
\Serie de pruebas para la verificación de la conformidad de uno o más protocolos ISA*.
Nota
- Debe comprender las pruebas de capacidad y las
pruebas de comportamiento. Puede ser calificada por los adjetivos abstracta,
genérica, o ejecutable, según proceda. Si no se especifica otra cosa, se supone
que se trata de una
`serie de pruebas abstractas'
.\
3.6.19@
serie de pruebas de interconexión básica
@
\Serie de pruebas para verificar la interconexión básica de uno o más protocolos ISA*.\
3.6.20@
serie de pruebas abstractas seleccionadas
@
\Subconjunto de una serie de pruebas abstractas seleccionadas utilizando un ECRP específico.\
3.6.21@
serie de pruebas ejecutables seleccionadas
@
\Subconjunto de una serie de pruebas ejecutables seleccionadas utilizando un ECRP específico y que corresponde a una serie seleccionada de pruebas abstractas.\
3.6.22@
caso de prueba abstracta parametrizada
@
\Caso de prueba abstracta en el cual todos los parámetros apropiados tienen asignados valores de acuerdo con un ECRP y una ISRPP específicos.\
3.6.23@
caso de prueba ejecutable parametrizada
@
\Caso de prueba ejecutable en el cual todos los parámetros apropiados tienen asignados valores de acuerdo con un ECRP y una ISRPP específicos.\
3.6.24@
serie de pruebas abstractas parametrizadas
@
\Serie seleccionada de pruebas abstractas en la cual todos los casos de prueba se han transformado en casos de prueba abstracta parametrizada para el ECRP y la ISRPP apropiados.\
3.6.25@
serie de pruebas ejecutables parametrizadas
@
\Serie seleccionada de pruebas ejecutables en la cual todos los casos de prueba se han transformado en casos de prueba ejecutable parametrizada para el ECRP y la ISRPP apropiados, y que corresponde a una serie de pruebas abstractas parametrizadas.\
3.7
Terminología relativa a los resultados
3.7.1@
repetibilidad (de resultados)
@
\Característica de un caso de prueba según la cual las ejecuciones repetidas sobre la misma RSP conducen al mismo veredicto, siendo por extensión una característica de una serie de pruebas.\
3.7.2@
comparabilidad (de resultados)
@
\Característica de los procesos de evaluación de conformidad según la cual su ejecución sobre la misma RSP, en diferentes entornos de prueba, conduce al mismo resumen global.\
3.7.3@
resultado
@
\Secuencia de sucesos de prueba junto con la entrada/salida asociadas, identificada por un especificador de caso de prueba abstracta, u observada durante la ejecución de una prueba.\
3.7.4@
resultado previsto
@
\Resultado identificado o categorizado en la especificación de un caso de prueba abstracta.\
3.7.5@
resultado imprevisto
@
\Resultado no identificado o categorizado en la especificación de un caso de prueba abstracta.\
3.7.6@
veredicto
@
\Enunciado de
`favorable'
,
`desfavorable'
o
`dudosa'
,
en lo que respecta a la conformidad de una RSP con un caso de prueba que ha
sido ejecutado, y que está especificado en la serie de pruebas abstractas.\
3.7.7@
informe de prueba de conformidad de sistema
(IPCS)
@
\Documento escrito después de terminado un proceso de evaluación de conformidad, que da el resumen global de la conformidad del sistema con el conjunto de protocolos con relación al cual se efectuaron las pruebas de conformidad.\
3.7.8@
informe de prueba de conformidad de protocolo
(IPCP)
@
\Documento escrito después de terminado el proceso de evaluación de conformidad, que da los detalles de las pruebas efectuadas sobre un determinado protocolo, incluida la identificación de los casos de prueba abstracta para los cuales se aplicaron los casos de prueba ejecutable correspondientes, indicándose para cada caso de prueba la finalidad de la prueba y el veredicto.\
3.7.9@
suceso de prueba válido
@
\Suceso de prueba admitido por la Recomendación* sobre protocolo, y que cumple la doble condición de ser sintácticamente correcto y de ocurrir, o llegar, en un contexto autorizado en un resultado observado.\
3.7.10@
suceso de prueba sintácticamente inválido
@
\Suceso de prueba que, sintácticamente, no está admitido por la Recomendación* sobre protocolo.
Nota
- La utilización del término
`suceso de prueba
inválido (o no válido)'
está desaconsejada.\
3.7.11@
suceso de prueba inoportuno
@
\Suceso de prueba que, aunque es sintácticamente correcto, ocurre o llega en un punto de un resultado observado, en el cual la Recomendación* sobre protocolo no permite que esto suceda.\
3.7.12@
veredicto de
`favorable'
@
\Veredicto dado cuando el resultado observado satisface la finalidad de la prueba y es válido con respecto a las Recomendaciones* pertinentes, así como con respecto al ECRP.\
3.7.13@
veredicto de
`desfavorable'
@
\Veredicto dado cuando el resultado observado es sintácticamente inválido o inoportuno con respecto a las Recomendaciones* pertinentes o al ECRP.\
3.7.14@
veredicto de
`dudoso'
@
\Veredicto dado cuando el resultado observado es válido con respecto a las Recomendaciones* pertinentes, pero impide que se alcance la finalidad de la prueba.\
3.7.15@
registro de conformidad
@
\Registro que contiene información suficiente, necesaria para verificar asignaciones de veredictos como resultado de pruebas de conformidad.\
3.8
Terminología relativa a los métodos de prueba
3.8.1@
punto de control y observación (PCO)
@
\Punto en el que se especifica el control y la observación en un caso de prueba.\
3.8.2@
probador inferior
@
\Abstracción del medio de proporcionar, durante la ejecución de una prueba, el control y la observación en el PCO apropiado, sea por debajo de la RSP o distante con respecto a la RSP, según se haya definido en el método de prueba abstracta elegido.\
3.8.3@
probador superior
@
\Abstracción del medio de proporcionar, durante la ejecución de la prueba, el control y la observación de la frontera de servicio superior de la RSP, así como el control y la observación de toda primitiva local abstracta pertinente.\
3.8.4@
primitiva de servicio (N) abstracta [PSA(N)]
@
\Descripción independiente de la realización de la interacción entre un usuario de servicio y un proveedor del servicio en una frontera de servicio (N), definida en una Recomendación* sobre la definición del servicio ISA*.\
3.8.5@
primitiva local abstracta (PLA)
@
\Abreviatura de una descripción de control y/u observación que ha de efectuar el probador superior, que no puede describirse en términos de PSA, pero que está relacionada con sucesos o estados definidos en Recomendaciones* sobre protocolo aplicables a la RSP.
Nota
- La ISRPP indicará si una PLA determinada puede
o no realizarse dentro del SSP. La idoneidad del SSP para admitir ciertas PLA,
especificadas en la ISRPP, se utilizará como criterio en el proceso de
selección de las pruebas.\
3.8.6@
procedimientos de coordinación de pruebas
@
\Reglas para la cooperación entre los probadores superior e inferior durante la prueba.\
3.8.7@
protocolo de gestión de pruebas
@
\Protocolo utilizado como realización de los procedimientos de coordinación de pruebas para una determinada serie de pruebas.\
3.8.8@
métodos de prueba local
@
\Métodos de prueba abstracta en los cuales los PCO se encuentran situados exactamente en las fronteras de capa de la RSP.\
3.8.9@
métodos de prueba externa
@
\Métodos de prueba abstracta en los cuales el probador inferior está separado del SSP y comunica con éste a través de un proveedor de servicio de capa inferior apropiado.
Nota
- El proveedor de servicio está inmediatamente
debajo del protocolo (de la capa más baja) que es el foco de las pruebas y
puede comprender varias capas de ISA.\
3.8.10@
método de prueba distribuida
@
\Método de prueba externa en el cual hay un PCO en la frontera de capa en la parte superior de la RSP.\
3.8.11@
método de prueba coordinada
@
\Método de prueba externa para el cual un protocolo de gestión de prueba normalizada está definido como la realización de los procedimientos de coordinación de pruebas, y que permite especificar el control y la observación solamente en términos de la actividad del probador inferior, incluido el control y la observación de las UDP de gestión de prueba.\
3.8.12@
método de prueba (a distancia)
@
\Método de prueba externa en el cual no existen ni un PCO por encima de la RSP, ni un protocolo normalizado de gestión de pruebas; algunos requisitos de los procedimientos de coordinación de pruebas pueden estar implícitos, o expresados informalmente en la serie de pruebas abstractas, pero no se efectúa ninguna hipótesis en cuanto a su viabilidad o realización.\
3.8.13@
probador real
@
\Realización del probador inferior, más la definición o la realización del probador superior, más la definición de los procedimientos de coordinación de pruebas, según convenga para un método de prueba dado.\
3.8.14@
realizador de la prueba
@
\Organización que asume la responsabilidad de proporcionar, en una forma independiente del cliente y la RSP, los medios para probar las RSP de acuerdo con la serie de pruebas abstractas.\
4
Abreviaturas
En la presente Recomendación se utilizan las siguientes abreviaturas.
@PLAPrimitiva local abstracta\
@PSAPrimitiva de servicio abstracta\
@ETDEquipo terminal de datos\
@RSPRealización sometida a prueba\
@ISAInterconexión de sistemas abiertos\
@ISA*Recomendaciones del CCITT de las series X o T sobre la ISA o relacionadas con ella\
@PCOPunto de control y observación\
@IPCPInforme de prueba de conformidad de protocolo\
@UDPUnidad de datos de protocolo\
@ECRPEnunciado de conformidad de realización de protocolo\
@ISRPPInformación suplementaria de realización de protocolo para pruebas\
@PASPunto de acceso al servicio\
@IPCSInforme de prueba de conformidad de sistema\
@
@SSPSistema sometido a prueba\
@UDP-GPUDP gestión de pruebas\
SECCIóN 2 -
Visión de conjunto
5 El significado de conformidad en la ISA*
5.1
Introducción
En el contexto de la ISA*, se dice que un sistema real es conforme, o muestra conformidad, si cumple los requisitos de las Recomendaciones* ISA* aplicables en su comunicación con otros sistemas reales.
Las Recomendaciones* ISA* aplicables incluyen Recomendaciones* sobre protocolos, y Recomendaciones* sobre sintaxis de transferencia, en la medida en que éstas se aplican junto con protocolos.
Las Recomendaciones* ISA* forman un conjunto de Recomendaciones* relacionadas entre sí que, juntas, definen el comportamiento de sistemas abiertos en su comunicación. La conformidad de un sistema real se expresará por tanto en dos niveles: conformidad con cada una de las Recomendaciones*, y conformidad con el conjunto de Recomendaciones*.
Nota
- Si la realización se basa en un conjunto
predefinido de Recomendaciones*, al que suele denominarse perfil o norma
funcional, el perfil o el concepto de conformidad puede ampliarse a requisitos
específicos expresados en la norma funcional, siempre que los mismos no estén
en contradicción con los requisitos de las Recomendaciones* de base.
5.2
Requisitos de conformidad
5.2.1 Los requisitos de conformidad en una Recomendación* pueden ser:
a)requisitos obligatorios: deben cumplirse en todos los casos;
b)requisitos condicionales: sólo deben cumplirse si se dan las condiciones establecidas en la Recomendación*;
c)requisitos falcultativos (opciones): pueden seleccionarse de modo que se ajusten a la realización, siempre que se cumplan todos los requisitos aplicables a la opción. En el anexo A se da más información sobre las opciones.
Por ejemplo, las facilidades CCITT esenciales son requisitos obligatorios; las facilidades adicionales pueden ser requisitos condicionales o facultativos.
Nota
- Los términos utilizados por el CCITT
`facilidades esenciales'
y
`facilidades adicionales'
deben
considerarse en el contexto del ámbito de la Recomendación del CCITT de que se
trate; en muchos casos, las facilidades esenciales son obligatorias para las
redes, pero no para los ETD.
5.2.2 Además, los requisitos de conformidad en una Recomendación* pueden formularse:
a)de modo positivo: cuando se indica lo que hay que hacer;
b)de modo negativo (prohibición): cuando se indica lo que no se debe hacer.
5.2.3 Por último, los requisitos de conformidad pueden clasificarse en los dos grupos siguientes:
a)requisitos de conformidad estática;
b)requisitos de conformidad dinámica.
Estos dos grupos se discuten en los 5.3 y 5.5, respectivamente.
5.3
Requisitos de conformidad estática
Los requisitos de conformidad estática son los que definen las capacidades mínimas permitidas de una realización, a fin de facilitar el interfuncionamiento. Estos requisitos pueden presentarse a un nivel generalizado, por ejemplo la agrupación de unidades funcionales y opciones en clases de protocolo, o a un nivel detallado, por ejemplo una gama de valores que tendrán que ser permitidas por determinados parámetros o temporizadores.
Los requisitos de conformidad estática y las opciones en las Recomendaciones* sobre la ISA*, presentan dos modalidades:
a)las que determinan las capacidades que han de incluirse en la realización del protocolo en cuestión;
b)las que determinan relaciones de dependencia entre diversas capas, por ejemplo, las que imponen limitaciones a las capacidades de las capas subyacentes del sistema en el cual reside la realización del protocolo. Estos requisitos probablemente se encuentren en las Recomendaciones* sobre las capas superiores.
Todas las capacidades no enunciadas explícitamente como requisitos de conformidad estática deberán considerarse facultativas.
5.4
Enunciado de conformidad de realización de
protocolo (ECRP)
Para evaluar la conformidad de una determinada realización, es necesario disponer de un enunciado de las capacidades y opciones que han sido establecidas, así como de las características que han sido omitidas, de modo que pueda probarse la conformidad de la realización con respecto a los requisitos pertinentes y solamente con respecto a ellos. Este enunciado se denomina enunciado de conformidad de realización de protocolo (ECRP).
Debe distinguirse entre las siguientes categorías de informaciones contenidas en un ECRP:
a)información relativa a los requisitos de conformidad estática obligatorios, facultativos y condicionales, del protocolo propiamente dicho;
b)información relacionada con los requisitos de conformidad estática obligatorios, facultativos y condicionales de las relaciones de dependencia entre las diversas capas.
Si un conjunto de Recomendaciones* sobre protocolos ISA*, relacionadas unas con otras, ha sido aplicado en un sistema, se necesita un ECRP para cada protocolo. Se necesitará también un enunciado de conformidad del sistema que recapitule todos los protocolos del sistema para cada uno de los cuales se haya proporcionado un ECRP distinto.
5.5
Requisitos de conformidad dinámica
Los requisitos de conformidad dinámica son los requisitos (y las opciones) que determinan qué comportamiento observable es permitido por las Recomendaciones* ISA* pertinentes en situaciones de comunicación. Forman el grueso de cada Recomendación* sobre protocolos ISA*. Definen el conjunto de comportamientos admisibles de una realización o sistema reales. Este conjunto define la capacidad máxima que puede tener una realización o un sistema real en base a la Recomendación* sobre protocolos ISA*.
Un sistema muestra conformidad dinámica en una situación de comunicación si su comportamiento está comprendido en el conjunto de comportamientos permitidos por las Recomendaciones* pertinentes sobre protocolos ISA* de una manera que sea coherente con el ECRP.
5.6
Sistema conforme
Un sistema o una realización es conforme si puede demostrarse que satisface los requisitos de conformidad estática y dinámica, de acuerdo con las capacidades enunciadas en el ECRP, para cada protocolo declarado en el enunciado de conformidad del sistema.
5.7
Interfuncionamiento y conformidad
5.7.1 Las pruebas de conformidad tienen esencialmente por finalidad aumentar la probabilidad de que realizaciones diferentes puedan interfuncionar.
El interfuncionamiento correcto de dos o más sistemas abiertos reales puede lograrse con una probabilidad mayor si todos estos sistemas son conformes al mismo subconjunto de una Recomendación* ISA*, o a la misma selección de Recomendaciones* ISA*, que si no lo son.
Para preparar dos o más sistemas de modo que interfuncionen correctamente, se recomienda hacer una comparación de los enunciados de conformidad del sistema y los ECRP de estos sistemas.
Si hay más de una versión de la Recomendación* ISA* pertinente indicada en los ECRP, será necesario identificar las diferencias entre las versiones y sus implicaciones, incluyendo su uso en combinación con otras Recomendaciones*.
5.7.2 La conformidad es una condición necesaria, pero no suficiente para garantizar la capacidad de interfuncionamiento. Aunque dos realizaciones sean conformes con la misma Recomendación* sobre el protocolo ISA*, es posible que, debido a factores fuera del ámbito de esa Recomendación, las dos realizaciones no interfuncionen.
Se recomienda hacer ensayos de interfuncionamiento para detectar estos factores. Se puede obtener más información que facilite el interfuncionamiento entre dos sistemas ampliando la comparación de ECRP a otras informaciones pertinentes, incluidos los informes de prueba y las ISRPP (véase el 6.2 ). La comparación puede basarse en:
a)mecanismos adicionales con los cuales se pretende salvar ciertas ambigüedades o deficiencias conocidas, aún no corregidas en las Recomendaciones* o en sistemas reales de identidades pares, por ejemplo para resolver problemas en que intervienen varias capas;
b)selección de opciones libres que no se tienen en cuenta en los requisitos de conformidad estática establecidos en las Recomendaciones*;
c)existencia de temporizadores no especificados en la Recomendación* y los valores asociados a los mismos.
Nota
- La comparación puede hacerse entre dos sistemas
individuales, entre dos o más tipos de productos, o cuando sólo se comparan los
ECRP, entre dos o más especificaciones para adquisición, permisos para
conectar, etc.
6 Conformidad y comprobación
6.1
Objetivos de las pruebas de conformidad
6.1.1
Introducción
Las pruebas de conformidad descritas en esta Recomendación son esencialmente pruebas de conformidad con las Recomendaciones* sobre protocolos ISA*. No obstante, se aplican también a las pruebas de conformidad con las Recomendaciones* sobre las sintaxis de transferencia ISA*, en la medida en que esto pueda realizarse probando la sintaxis de transferencia en combinación con un protocolo ISA*.
En principio, las pruebas de conformidad tienen por objeto determinar si la realización que se prueba es o no conforme con la especificación en la Recomendación* pertinente. Limitaciones prácticas hacen imposible que estas pruebas sean exhaustivas. Pueden estar también limitadas por consideraciones de orden económico.
En consecuencia, en esta Recomendación se distinguen cuatro tipos de pruebas, según la medida en que proporcionen una indicación de conformidad:
a)pruebas de interconexión básica que permiten afirmar
prima
facie
^ que una RRP es conforme;
b)pruebas de capacidad, que verifican que las capacidades observables de la RSP cumplen los requisitos de conformidad estática y las capacidades anunciadas en el ECRP;
c)pruebas de comportamiento, que tratan de proporcionar una prueba lo más amplia posible de la gama completa de requisitos de conformidad dinámica especificados en la Recomendación*, dentro de las capacidades de la RSP;
d)pruebas de resolución de conformidad, que examinan en profundidad la conformidad de una RSP con determinados requisitos, a fin de proporcionar una respuesta definitiva de tipo sí/no e información de diagnóstico en relación con asuntos específicos de conformidad; este tipo de pruebas no está normalizado.
6.1.2
Pruebas de interconexión básica
6.1.2.1 Las pruebas de interconexión básica son pruebas limitadas de una RSP en relación con las características principales especificadas en una Recomendación*, a fin de determinar que el grado de conformidad es suficiente para que sea posible la interconexión, sin tratar de efectuar una prueba completa.
6.1.2.2 Las pruebas de interconexión básicas son apropiadas:
a)para detectar casos difíciles de no conformidad;
b)como un filtro previo, antes de efectuar pruebas más costosas;
c)para dar una indicación
prima facie
^ de que una
realización que ha superado todas las pruebas de conformidad en un entorno es
también conforme en un nuevo entorno [por ejemplo, antes de probar una
realización (N), comprobar que una realización (N - 1) ya probada no ha sufrido
un cambio profundo por estar vinculada a la realización (N)];
d)para ser utilizadas por usuarios de realizaciones con el fin de determinar si las realizaciones parecen poder utilizarse para comunicación con otras realizaciones conformes, por ejemplo en forma preliminar a un intercambio de datos.
6.1.2.3 Las pruebas de interconexión básicas no son apropiadas:
a)para ser utilizadas por el suministrador de una realización como base para declarar su conformidad;
b)como un criterio para determinar causas de fallo de comunicaciones.
6.1.2.4 Las pruebas de interconexión básica deben normalizarse como una serie muy pequeña de pruebas o como un subconjunto de una serie de pruebas de conformidad (incluidas las pruebas de capacidad y de comportamiento). Pueden utilizarse por sí mismas o combinadas con una serie de pruebas de conformidad. La existencia y la ejecución de pruebas de interconexión básica son facultativas.
6.1.3
Pruebas de capacidad
6.1.3.1 Las pruebas de capacidad proporcionan una verificación limitada de cada uno de los requisitos de conformidad estática en una Recomendación*, con el fin de determinar qué capacidades de la RSP pueden observarse, y comprobar que esas capacidades observables son válidas con respecto a los requisitos de conformidad estática y al ECRP.
6.1.3.2 Las pruebas de capacidad son apropiadas:
a)para verificar hasta el punto que sea posible la coherencia del ECRP con la RSP;
b)como un filtro previo antes de efectuar pruebas más completas y costosas;
c)para comprobar que las capacidades de la RSP son coherentes con los requisitos de conformidad estática;
d)para hacer posible una selección eficaz de pruebas de comportamiento para una determinada RSP;
e)para servir de base a anuncios de conformidad, cuando se realizan en combinación con pruebas de comportamiento.
6.1.3.3 Las pruebas de capacidad son inadecuadas:
a)por sí mismas, para ser utilizadas por el suministrador de una realización como base para declarar la conformidad;
b)para probar detalladamente el comportamiento asociado con cada capacidad que ha sido realizada o no realizada;
c)para la resolución de problemas que surgen durante el uso activo o cuando otras pruebas indican posibles no conformidades, aunque hayan sido satisfechas las pruebas de capacidad.
6.1.3.4 Las pruebas de capacidad están normalizadas dentro de una serie de pruebas de conformidad. Pueden existir separadamente formando su propio grupo o grupos de prueba, o estar mezcladas con las pruebas de comportamiento.
6.1.4
Pruebas de comportamiento
6.1.4.1 Las pruebas de comportamiento se utilizan para comprobar una realización en una forma tan completa como sea posible en la práctica, en toda la gama de requisitos de conformidad dinámica especificados en una Recomendación*. Como el número de combinaciones posibles de sucesos y la temporización de los sucesos son infinitos estas pruebas no pueden ser exhaustivas. Existe aún otra limitación: estas pruebas están destinadas a efectuarse colectivamente en un solo entorno de prueba, por lo cual un fallo cualquiera que sea difícil o imposible de detectar en ese entorno probablemente no sea advertido. En consecuencia, es posible que una realización no conforme supere la serie de pruebas de conformidad; un objetivo del diseño de las series de pruebas de conformidad es que esto ocurra el menor número de veces posible.
6.1.4.2 Las pruebas de comportamiento, cuando se realizan asociadas a pruebas de capacidad, sirven de base para el proceso de evaluación de la conformidad.
6.1.4.3 Las pruebas de comportamiento son inadecuadas para la resolución de problemas que surgen durante el uso activo, o cuando otras pruebas indican posibles no conformidades, aunque hayan sido satisfechas las pruebas de comportamiento.
6.1.4.4 Las pruebas de comportamiento están normalizadas como el grueso de una serie de pruebas de conformidad.
Nota
- Las pruebas de comportamiento incluyen pruebas
del comportamiento válido de la RSP en respuesta a un comportamiento de
protocolo válido, inoportuno y sintácticamente inválido del probador real. Esto
incluye la prueba del rechazo por la RSP de tentativas de uso de
características (capacidades) que están indicadas en el ECRP como no
realizadas. Así, las pruebas de capacidad no necesitan incluir pruebas de
capacidades que no figuren en el ECRP.
6.1.5
Pruebas de resolución de
conformidad
6.1.5.1 Las pruebas de resolución de conformidad proporcionan respuestas diagnóstico lo más cercanas posible a respuestas definitivas para resolver si una realización satisface o no determinados requisitos. Debido a los problemas de exhaustividad señalados en 6.1.4.1 , las respuestas definitivas se obtienen a expensas de circunscribir las pruebas a un estrecho campo.
6.1.5.2 Normalmente, la arquitectura de prueba y el método de prueba se eligirán teniendo en cuenta específicamente los requisitos que van a probarse, y no tienen necesariamente que ser los que son útiles, en general, para el cumplimiento de otros requisitos. Pueden ser incluso los que se consideran inaceptables para series de pruebas de conformidad abstracta (normalizadas), por ejemplo pruebas que impliquen métodos específicos de realización en los cuales se utiliza, por ejemplo, facilidades de diagnóstico y de depuración del sistema operativo específico.
6.1.5.3 La distinción entre pruebas de comportamiento y pruebas de resolución de conformidad puede ilustrarse mediante el caso de un suceso tal como una reiniciación. Las pruebas de comportamiento pueden incluir solamente una selección representativa de condiciones en las cuales podría producirse una reiniciación, y pudiera fracasar al tratar de detectar un comportamiento incorrecto en otras circunstancias. Las pruebas de resolución de conformidad estarían circunscritas a condiciones en las cuales se sospecha que ocurre un funcionamiento incorrecto, y confirmarían si esa sospecha era o no correcta.
6.1.5.4 Las pruebas de resolución de conformidad son apropiadas:
a)para proporcionar una respuesta de tipo sí/no en una situación estrictamente limitada y previamente identificada (por ejemplo, durante el desarrollo de una realización, para verificar si una determinada característica ha sido correctamente establecida, o durante el uso operacional, para investigar la causa de problemas);
b)como un medio para identificar y ofrecer resoluciones relativas a deficiencias en una serie de pruebas de conformidad que se están efectuando.
6.1.5.5 Las pruebas de resolución de conformidad son inadecuadas como base para determinar si una realización muestra o no una conformidad global.
6.1.5.6 Las pruebas de resolución de conformidad no están normalizadas.
Nota al
6.1
- Como subproducto de las
pruebas de conformidad, pueden identificarse errores y deficiencias en las
Recomendaciones* sobre protocolos.
6.2
Información suplementaria de realización de
protocolo para las pruebas
(ISRPP)
A fin de probar una realización de protocolo, el laboratorio de prueba
necesitará información relativa a la RSP, así como a su entorno de prueba,
además de la proporcionada por el ECRP. Esta
`información suplementaria de
realización de protocolo para las pruebas'
(ISRPP) la proporcionará el
cliente que somete a prueba una realización, como resultado de consultas con el
laboratorio de prueba.
La ISRPP puede contener las siguientes informaciones:
a)la información que necesita el laboratorio de pruebas para poder aplicar la serie de pruebas adecuada al sistema específico (por ejemplo, información relacionada con el método de prueba que ha de utilizarse para aplicar los casos de prueba, información de direccionamiento);
b)información ya mencionada en el ECRP y que debe precisarse (por ejemplo, una gama de valores de temporizador que se declara como parámetro en el ECRP debe especificarse en la ISRPP);
c)información para facilitar la determinación de las capacidades, entre las enunciadas en el ECRP como admitidas, que pueden probarse y las que no pueden probarse;
d)otras cuestiones administrativas (por ejemplo, el identificador de RSP, la referencia al ECRP correspondiente).
La ISRPP no debe estar en contradicción con el ECRP correspondiente.
El especificador de la serie de pruebas abstractas, el realizador de la prueba y el laboratorio de pruebas contribuirán al desarrollo de la proforma de la ISRPP.
6.3
Descripción del proceso de evaluación de
conformidad
6.3.1 La característica principal del proceso de evaluación de conformidad es una configuración de equipo que permita intercambios de información entre la RSP y un probador real. Estos intercambios son controlados y observados por el probador real.
6.3.2 En un bosquejo conceptual, las pruebas de conformidad deben incluir varios pasos, constituidos por fases de examen de la conformidad estática y fases de prueba activa, todo lo cual culmina en la elaboración de un informe de prueba que será tan completo como sea posible en la práctica.
6.3.3 Estos pasos son:
a)análisis del ECRP;
b)selección y parametrización de la prueba;
c)prueba de interconexión básica (facultativa);
d)pruebas de capacidad;
e)pruebas de comportamiento;
f)examen y análisis de los resultados;
g)síntesis, conclusiones y elaboración del informe de la prueba de conformidad.
Estos pasos se ilustran en la figura 1/X.290, parte 1.
Antes de ejecutar cualquiera de las pruebas, el ECRP y la ISRPP de la RSP se introducen en los procesos de selección de caso de prueba y de parametrización.
Figure 1/X.290, partie 1, (N), p.
6.4
Análisis de resultados
6.4.1
Generalidades
6.4.1.1
Resultados y veredictos
El resultado observado (de la ejecución de la prueba) es la serie de sucesos que ocurrieron durante la ejecución de un caso de prueba; incluye todas las entradas y salidas de la RSP en los puntos de control y observación.
Los resultados previstos se identifican y definen por la especificación de caso de prueba abstracta en combinación con la Recomendación* sobre protocolo. Para cada caso de prueba puede haber uno o más resultados previstos. Los resultados previstos se definen esencialmente en términos abstractos.
Un veredicto es una declaración de
`favorable'
,
`desfavorable'
o
`dudoso'
, que ha de asociarse a cada uno de los
resultados previstos en la especificación de la serie de pruebas abstractas.
El análisis de los resultados se efectúa comparando los resultados obtenidos con los resultados previstos.
El veredicto asignado a un resultado observado es el asociado con el resultado previsto con el cual concuerda. Si el resultado observado es imprevisto, la especificación de la serie de pruebas abstractas indicará el veredicto por defecto que deba asignársele.
El medio utilizado para la comparación de los resultados observados con los resultados previstos está fuera del ámbito de esta Recomendación.
Nota
- Existen las siguientes posibilidades:
a)comparación manual o automatizada (o una combinación de ambas);
b)comparación durante o después de la ejecución;
c)traducción de los resultados observados a una forma abstracta para la comparación con los resultados previstos, o traducción de los resultados previstos a la forma utilizada para registrar los resultados observados.
El veredicto será
favorable
,
desfavorable
^ o
dudoso
:
a)
favorable
^ significa que el resultado observado
satisface la finalidad de la prueba y es válido con respecto a las
Recomendaciones* pertinentes y al ECRP;
b)
desfavorable
^ significa que el resultado observado es
sintácticamente inválido o inoportuno con respecto a las Recomendaciones*
pertinentes o al ECRP;
c)
dudoso
^ significa que el resultado observado es
válido con respecto a las Recomendaciones* pertinentes, pero impide que se
alcance la finalidad de la prueba.
El veredicto que se asignará a un determinado resultado dependerá de la finalidad de la prueba y de la validez del comportamiento del protocolo observado.
Los veredictos formulados con respecto a casos de pruebas individuales serán sintetizados para formar un resumen global para la RSP, basado en los casos de prueba ejecutados.
6.4.1.2
Informes de prueba de conformidad
Los resultados de las pruebas de conformidad se documentarán en un conjunto de informes de prueba de conformidad. Estos informes serán de dos tipos: informe de prueba de conformidad de sistema (IPCS) e informe de prueba de conformidad de protocolo (IPCP).
El IPCS, que se proporcionará siempre, ofrece un resumen general sobre la situación de conformidad del SSP, con respecto a su RSP monocapa, o multicapa. Deberá estudiarse ulteriormente la presentación de una proforma normalizada para el IPCS.
El IPCP, que se elabora para cada protocolo probado en el SSP, documenta todos los resultados de los casos de prueba haciendo referencia a los registros de conformidad que contienen los resultados observados. El IPCP hace también referencia a todos los documentos necesarios relativos a la ejecución del proceso de evaluación de conformidad para ese protocolo.
Deberá estudiarse ulteriormente una proforma normalizada para el IPCP. La lista ordenada de casos de prueba para uso en el IPCP se especificará de acuerdo con la Recomendación* sobre series de pruebas.
6.4.2
Repetibilidad de los resultados
Para alcanzar el objetivo de credibilidad de las pruebas de conformidad, es evidente que el resultado de la ejecución de un caso de prueba sobre una RSP debe ser el mismo cualquiera que sea el momento en que se realiza. Estadísticamente, puede que no sea posible realizar una serie completa de pruebas de conformidad y observar resultados que sean absolutamente idénticos a los obtenidos en otra ocasión: en efecto, se producen resultados imprevistos, y esta es una característica de los entornos existentes. No obstante, a nivel de caso de prueba es muy importante que los especificadores de las pruebas y los laboratorios de pruebas reduzcan al mínimo la posibilidad de que un caso de prueba produzca resultados diferentes en distintas ocasiones.
6.4.3
Comparabilidad de los resultados
A fin de alcanzar los objetivos finales de las pruebas de conformidad, el resumen global sobre la conformidad de una RSP tiene que ser independiente del entorno de prueba en el cual ésta se efectúa. En otros términos, la normalización de todos los procedimientos relativos a las pruebas de conformidad debe culminar en la asignación a las RSP de un resumen global comparable, independientemente de que las pruebas hayan sido efectuadas por el suministrador, por un usuario o por una tercera entidad encargada de la prueba. Para conseguir esto hay que estudiar un gran número de factores, dentro de los cuales los más importantes son:
a)diseño cuidadoso de la especificación del caso de prueba abstracta para asegurar la flexibilidad cuando sea conveniente, al mismo tiempo que se expresen los requisitos que han de cumplirse (que es el objeto de esta Recomendación);
b)especificación cuidadosa del probador real que debe utilizarse para aplicar la serie de pruebas; también en este caso la especificación debe proporcionar flexibilidad donde sea conveniente, al mismo tiempo que indica los requisitos que han de cumplirse, incluidos todos los procedimientos de coordinación de pruebas (si existen);
c)especificación cuidadosa del procedimiento a seguir para determinar cómo
debe utilizarse el contenido del ECRP en el análisis de resultados de casos de
prueba; no debe haber margen para una interpretación
`optimista'
;
d)especificación cuidadosa de los procedimientos que han de seguir los laboratorios de prueba para la repetición de un caso de prueba antes de establecer un veredicto para esa finalidad de prueba;
e)proforma para un informe de prueba de conformidad;
f)especificación cuidadosa de los procedimientos necesarios cuando se sintetiza un resumen global.
6.4.4
Verificabilidad de los resultados
Por razones de índole legal, entre otras, puede ser necesario examinar los resultados observados durante la ejecución de una serie de pruebas de conformidad a fin de asegurarse de que todos los procedimientos han sido correctamente aplicados. Independientemente de que el análisis se haya efectuado manual o automáticamente, es esencial que todas las entradas, salidas y otros sucesos de prueba hayan sido debidamente anotados, y los resultados registrados. En algunos casos esto puede ser responsabilidad del realizador de la prueba, quien puede optar por incluir los criterios de prueba en el registro de conformidad, así como todos los resultados. En otros casos, la responsabilidad recaería sobre el laboratorio de pruebas, que tendría que seguir todos los procedimientos normalizados para el registro de los resultados.
Nota
- En cuanto a la verificabilidad, serían
preferibles algunos procedimientos automáticos, pero en tal caso habría que
tener en cuenta que, desde el punto de vista legal, los propios procedimientos
automáticos tendrían que estar acreditados, si se desea que gocen de
credibilidad.
7 Métodos de prueba
7.1
Introducción
La prueba de un determinado protocolo ISA* puede exigir el uso de varios métodos de prueba, pues los sistemas sometidos a prueba pueden presentarse en varias configuraciones, y varían en cuanto a las posibilidades que ofrecen para producir efectos aplicables a una frontera de capa.
En este apartado se comienza por describir las características del sistema sometido a prueba que deben tomarse en consideración, se definen después los posibles métodos de prueba en forma abstracta, y por último se dan orientaciones sobre sus posibilidades de aplicación a sistemas reales.
7.2
Clasificación de sistemas abiertos reales y RSP para
pruebas de conformidad
7.2.1
Clasificación de sistemas sometidos a prueba
7.2.1.1 Hay una relación entre los métodos de prueba y las configuraciones de los sistemas abiertos reales que han de probarse. Los métodos de prueba apropiados varían con arreglo a lo siguiente:
a)la función principal del sistema (sistema final o sistema relevador);
b)las capas que utilizan protocolos ISA*;
c)la posibilidad de emplear también protocolos no-ISA*.
7.2.1.2 Para fines de pruebas de conformidad se han identificado las siguientes configuraciones de sistemas que se ilustran en las figuras 2/X.290 a 4/X.290. Las configuraciones 1 a 3 son las configuraciones básicas de los sistemas sometidos a prueba (SSP).
a)Configuración 1: sistema abierto de siete capas (sistema final).
Estos sistemas utilizan protocolos de la Recomendación* sobre ISA* en las siete capas.
b)Configuración 2: sistema abierto parcial (N) (sistema final).
Estos sistemas utilizan protocolos de la Recomendación* sobre ISA* en las capas 1 a N.
c)Configuración 3: sistemas abiertos de relevo.
Estos sistemas utilizan protocolos ISA* en las capas 1 a 3 (sistemas de relevo de red) o en las capas 1 a 7 (sistemas de relevo de aplicación).
Figuras 2/X.290, parte 1 a 4/X.290, parte 1, (N), p.
7.2.1.3 Pueden derivarse otras configuraciones de las configuraciones básicas.
Un SSP puede ser una combinación de las configuraciones básicas 1 y 2, que ofrece la alternativa de utilizar procedimientos ISA* y no-ISA* por encima de la capa N (véase la figura 5/X.290, parte 1).
Figura 5/X.290, parte 1, (N), p.
7.2.2
Identificación de la realización sometida a prueba
(RSP)
Una realización sometida a prueba (RSP) es la parte de un sistema abieto real que ha de estudiarse mediante pruebas de conformidad. Debe ser la realización de uno o más protocolos de capas ISA* adyacentes.
Las RSP pueden definirse para configuraciones 1 y 2 de los SSP como RSP monocapa (se prueba una sola capa del SSP), o como RSP multicapa (se prueba un conjunto constituido por cualquier número de capas adyacentes del SSP, combinadamente).
Una RSP definida en un sistema abierto de relevo incluirá al menos la capa que proporciona la función de relevo.
Cuando en un sistema existen protocolos ISA* y no-ISA*, la(s) RSP se definirá(n) para el modo (o los modos) de funcionamiento ISA*. La prueba de protocolos no-ISA* está fuera del ámbito de esta Recomendación.
Los clientes y los laboratorios de prueba se pondrán de acuerdo sobre la parte del SSP que se considerará como la RSP.
7.3
Metodología de las pruebas abstractas -
Generalidades
Los métodos de prueba tienen que hacer referencia a una metodología de pruebas abstractas, basada en el modelo de referencia de ISA. Considerando primeramente los sistemas finales [sistemas abiertos de siete capas y sistemas abiertos parciales (N)] y las RSP monocapa dentro de estos sistemas, se describen métodos de prueba abstracta en base a las salidas de la RSP que se observan y las entradas a la misma que se pueden controlar. Más específicamente se describe un método de prueba abstracta identificando los puntos más cercanos a la RSP en los cuales puede efectuarse una observación.
Las Recomendaciones* sobre protocolos ISA* definen el comportamiento permitido de una entidad de protocolo (es decir los requisitos de conformidad dinámica) sobre la base de unidades de datos de protocolo (UDP) y primitivas de servicio abstractas (PSA), por encima y por debajo de esa entidad. Así, el comportamiento de una entidad (N) se define mediante las PSA(N) y las PAS(N - 1) [incluyendo estas últimas las UDP-(N)].
Si una RSP comprende más de una entidad de protocolo, el comportamiento requerido puede definirse según las PSA por encima y por debajo de la RSP, incluidas las UDP de los protocolos en la RSP.
El punto de partida para elaborar métodos de prueba es la arquitectura de
prueba conceptual, ilustrada en la figura 6/X.290, parte 1. Esta es una
arquitectura de prueba activa de tipo
`caja negra'
, basada en la
definición del comportamiento requerido de la RSP.
La acción del probador, indicada en la figura 6/X.290, parte 1, puede aplicarse bien localmente, en cuyo caso hay un acoplamiento directo con el sistema sometido a prueba, bien externamente a través de un enlace o red. Los dos conjuntos de interacciones, por encima y por debajo de la RSP, pueden, en la práctica, observarse y controlarse en varios puntos diferentes, local o externamente.
En la identificación de los posibles puntos de control y observación (PCO) intervienen tres factores:
a)que el objeto del control y la observación sean primitivas PSA o unidades UDP;
b)la identidad de las PSA o las UDP en cuestión, en cuanto a la capa;
c)si son o no controladas y observadas dentro del sistema sometido a prueba o en un sistema distante del sistema sometido a prueba; en este último caso, las PSA se señalan por la adición de un carácter de comillas (^Ñ^).
Figura 6/X.290, parte 1, (N), p.
En la figura 7a)/X.290, parte 1, se presentan posibles PCO dentro del SSP. En
la figura 7b)/X.290, parte 1 se presentan posibles PCO en el caso de que la
actividad por debajo de la RSP sea controlada y observada externamente. Estas
figuras muestran que hay una multiplicidad de posibles PCO en diferentes capas,
lo que ofrece diferentes grados de control y observación del comportamiento de
la RSP. En esta Recomendación se hace una selección, a partir de este conjunto
de posibles PCO, definiendo un número limitado de métodos de prueba abstracta.
Figura 7a/X.290, parte 1, (N), p.
Figura 7b/X.290, parte 1, (N), p.
Si el control y la observación por encima de la RSP, o fuera de ella, se
especifican en términos de PSA, ello incluirá el control y la observación de
las UDP transportadas por esas PSA; en cambio, si se especifican en términos de
UDP (en la capa N), no se considera que las PSA (en la capa N - 1) están
controladas u observadas.
Se supone que la actividad de las PSA por debajo de la RSP puede observarse y controlarse por lo menos a través de la actividad de la entidad par en un sistema de prueba distante, por ejemplo las PSAÑ correspondientes. Así, cuando las PSA por debajo de la RSP no pueden ser controladas u observadas localmente, la prueba de conformidad puede efectuarse externamente, a condición de que el servicio subyacente ofrecido sea suficientemente fiable para efectuar el control y la observación a distancia.
Es posible que la actividad de PSA por encima de la RSP no pueda ser controlada u observada, en cuyo caso se dice que esta actividad está oculta.
No se necesita que los SSP proporcionen acceso a fronteras de capa. Sin embargo, la posible provisión de tal acceso y las posibles posiciones de esas fronteras con respecto a las capas de las RSP son factores que habrá que tomar en consideración para la definición de los métodos de prueba, donde se puede aprovechar la ventaja de este acceso para definir series de prueba en base a las PSA correspondientes. El hecho de que se gane acceso a las fronteras accesibles a través de puntos de acceso al servicio (PAS), o a través de otros PCO, no tiene importancia alguna.
La figura 8/X.290, parte 1, presenta ejemplos de RSP con respecto a la accesibilidad de las fronteras de capa.
Nota
- Además, una Recomendación* sobre series de
pruebas de conformidad puede definir
`primitivas locales abstractas'
.
Estas se utilizan para especificar el control y la observación de sucesos o
estados a los cuales se hace referencia en la Recomendación* sobre protocolos,
pero que son internos a la RSP y no pueden expresarse en base a PSA. Son
abreviaturas de descripciones de texto de control y observaciones que ha de
realizar el probador superior.
Cabe hacer consideraciones similares sobre los sistemas de relevo. (Para más detalles, véase la parte 2 de la Recomendación.)
Figura 8/X.290, parte 1, (N), p.
7.4
Funciones de comprobación abstracta
La definición de métodos de prueba abstracta exige que los PCO estén distribuidos en dos funciones de comprobación abstracta: el probador inferior y el probador superior.
El probador inferior es el concepto abstracto del medio de proporcionar, durante la ejecución de la prueba, el control y la observación en el PCO apropiado, bien por debajo de la RSP, o a distancia de la RSP, según esté definido por el método de prueba abstracta elegido. En consecuencia, es la función de prueba relacionada con el control y la observación de la frontera inferior de la RSP. Si la acción del probador es local al SSP, el probador inferior ocupará el lugar de la parte inferior del SSP. Si la acción del probador es externa al SSP, el probador inferior confiará en el servicio (N - 1), proporcionado conjuntamente por el propio probador inferior, un enlace y el SSP.
El probador superior es el concepto abstracto del medio de proporcionar, durante la ejecución de la prueba, el control y la observación de la frontera de servicio superior de la RSP y de cualquier primitiva local abstracta pertinente.
Es necesaria una cooperación entre el probador superior y el probador inferior; las reglas para tal cooperación se denominan procedimientos de coordinación de las pruebas.
Los métodos de prueba varían según la manera de especificar los procedimientos de coordinación de las pruebas. En algunos casos es posible definir un protocolo de gestión de pruebas para proporcionar la coordinación entre los probadores superior e inferior. En otros casos sólo es posible describir los requisitos que deben cumplir los procedimientos de coordinación de las pruebas, sin especificar el mecanismo que pudiera utilizarse para realizarlos.
7.5
Visión de conjunto de los métodos de prueba
abstracta
7.5.1
RSP de sistemas finales
Para las RSP definidas dentro de SSP que son sistemas finales (configuraciones 1 y 2 en las figuras 2/X.290, parte 1 y 3/X.290, parte 1) se definen cuatro categorías de métodos de prueba abstracta, uno local y tres externos, suponiéndose que el probador inferior está situado a distancia del SSP y conectado a éste por un enlace o red.
7.5.2
Métodos de prueba local
Los métodos de prueba abstracta local definen los PCO como las fronteras de servicio por encima y por debajo de la RSP. Los sucesos de prueba se especifican en base a las PSA por encima de la RSP y a las UDP por debajo de la RSP, como se ilustra en la figura 9a)/X.290, parte 1. En un orden abstracto, se considera que un probador inferior conserva y controla las PSA y las UDP por debajo de la RSP, mientras que un probador superior observa y controla las PSA por encima de la RSP. Los requisitos que deben cumplir los procedimientos de coordinación utilizados para coordinar las realizaciones de los probadores superior e inferior se definen en las series de pruebas de conformidad abstractas, aunque los procedimientos de coordinación de las pruebas, en sí, no están definidos.
7.5.3
Métodos de prueba externa
Los métodos de prueba externa emplean el control y la observación de las PSA por debajo de la RSP por medio de un probador inferior distinto del SSP, junto con el control y la observación de las PSA, por encima de la RSP. Se definen tres categorías diferentes de métodos de prueba abstracta externa, designados como métodos de prueba distribuida, coordinada, y a distancia. Varían según el nivel de exigencia o normalización establecido para los procedimientos de coordinación de la pruebas, el acceso a la frontera de capa por encima de la RSP, y los requisitos de un probador superior. Se ilustran en las figuras 9b), c) y d)/X.290, parte 1.
El método de prueba coordinada requiere que los procedimientos de coordinación de las pruebas utilizados para coordinar la realización de los probadores superior e inferior se efectúen mediante protocolos de gestión de las pruebas. Los otros dos métodos no parten de ningún supuesto en cuanto a la realización de los procedimientos de coordinación de las pruebas.
Los métodos de prueba distribuida y de prueba coordinada requieren funciones específicas del probador superior por encima de la RSP. El método de prueba a distancia no las requiere.
El método distribuido requiere el acceso a la frontera superior de la RSP. Los otros dos métodos no lo requieren.
Figura 9/X.290, parte 1, (N), p.
7.5.4
Variantes de los métodos de prueba del sistema
final
Cada categoría de métodos de prueba tiene variantes que pueden aplicarse a RSP monocapa o multicapa. Para las RSP multicapa en las cuales los protocolos habrán de probarse capa por capa, pueden utilizarse variantes de prueba insertadas.
Todos los métodos de prueba abstracta para sistemas finales están especificados íntegramente en el 8 de la parte 2 de esta Recomendación, incluidas las variantes monocapa, multicapa e insertada, cuando proceda.
7.5.5
RSP de sistemas de relevo
Para los sistemas abiertos de relevo se definen dos métodos de prueba: el método de prueba en bucle y el método de prueba transversal, que se especifican íntegramente en el 8 de la parte 2 de esta Recomendación.
7.6
Aplicabilidad de métodos de prueba a sistemas abiertos
reales
La arquitectura y el estado de desarrollo de un sistema abierto real determinan la aplicabilidad de métodos de prueba al mismo.
Los métodos de prueba local son adecuados para sistemas en desarrollo, en los cuales su arquitectura permite aislar una RSP, ya sea ésta monocapa o multicapa.
Los métodos de prueba externa son adecuados para probar sistemas finales completos o parciales que pueden conectarse a las redes de telecomunicaciones.
Los métodos de prueba coordinada son aplicables cuando es posible realizar un protocolo normalizado de gestión de pruebas en un probador superior en el SSP, por encima de la RSP.
Los métodos de prueba a distancia se aplican cuando es posible utilizar algunas funciones del SSP para controlar la RSP durante la prueba, en vez de utilizar un probador superior específico.
Los métodos de prueba distribuida se aplican cuando es necesario dar libertad total para la realización de los procedimientos de coordinación de las pruebas entre el SSP y el probador inferior, pero se necesita también especificar detalladamente los requisitos de control y de observación en ambos extremos.
Los métodos de prueba monocapa son los más apropiados para la prueba de la mayoría de los requisitos de conformidad de protocolo.
Los métodos de prueba multicapa se utilizarán cuando hay que probar que se cumplan requisitos de conformidad dinámica en varias capas.
Los métodos de prueba insertada permiten la aplicabilidad de pruebas monocapa a todas las capas de una RSP multicapa.
Para los sistemas abiertos de 7 capas se prefiere la utilización incremental de métodos de prueba insertada monocapa externa con los siguientes PCO:
a)interfaz superior de la capa de aplicación, proporcionado por el sistema abierto de 7 capas, cuando sea aplicable;
b)sucesivamente, cada PAS (o PCO correspondiente, si no hay PAS como tales) por debajo del protocolo que constituye el foco de la prueba, controlado y observado en el probador inferior externo, comenzando por el protocolo de nivel más bajo de la RSP y progresando hacia arriba.
7.7
Aplicabilidad de los métodos de prueba a los protocolos
y capas ISA*
Los métodos de prueba definidos en esta Recomendación son aplicables a todas las capas, con excepción de la capa física y los protocolos de control de acceso a los medios, que están fuera del ámbito de esta Recomendación. El apéndice I de esta Recomendación da orientación sobre la aplicabilidad de métodos de prueba a las demás capas.
8 Series de pruebas
8.1
Estructura
Las series de pruebas tienen una estructura jerárquica (véase la figura 10/X.290, parte 1) en la cual un nivel importante es el caso de prueba. (Cada caso de prueba tiene una finalidad estrictamente definida, como es la de verificar que la RSP tiene cierta capacidad requerida (por ejemplo, poca capacidad para admitir ciertos tamaños de paquetes) o presenta cierto comportamiento requerido (por ejemplo, se comporta de la manera requerida cuando ocurre un determinado suceso en un determinado estado).
Dentro de una serie de pruebas, se utilizan grupos de pruebas anidados para proporcionar un ordenamiento lógico de los casos de prueba. Los grupos de prueba pueden ser anidados a una profundidad arbitraria. Pueden utilizarse para ayudar a la planificación, el desarrollo, la comprensión o la ejecución de series de pruebas.
Los casos de prueba se modularizan utilizando subdivisiones denominadas que
se conocen por pasos de prueba. Cada caso de prueba comprende por lo menos un
paso de prueba: el ordenamiento de los sucesos abarcados por la finalidad de la
prueba (
`cuerpo de prueba'
). Puede incluir más pasos de prueba para
llevar la RSP al estado requerido, de modo que el cuerpo de prueba comience por
un estado estable (el
`preámbulo'
), o retorne a un estado estable (el
`epílogo'
) después de que el cuerpo de prueba ha terminado.
Por razones prácticas, los pasos de prueba comunes se pueden agrupar en bibliotecas de pasos de prueba. Las bibliotecas de pasos de prueba pueden estructurarse en conjuntos de pasos de prueba anidados a una profundidad arbitraria. Las bibliotecas de pasos de prueba pueden asociarse a la totalidad de la serie de pruebas, a un determinado grupo de pruebas, o a un caso de prueba.
Además, todos los pasos de prueba consisten en un ordenamiento de otros pasos de prueba y/o sucesos de prueba (es decir, la transferencia de una sola UDP o PSA hacia o desde la RSP). En consecuencia, todos los pasos de prueba son equivalentes a una ordenación de sucesos de prueba (después de la ampliación de los pasos de prueba internos).
Figura 10/X.290, parte 1, (N), p.
8.2
Casos de prueba genérica, abstracta y ejecutable
8.2.1 Un caso de prueba genérica es aquel que:
a)proporciona un perfeccionamiento de la finalidad de la prueba;
b)especifica todas las secuencias de sucesos de prueba (trayectos) en el
cuerpo de prueba que corresponden a veredictos de
`favorable'
,
`desfavorable'
y
`dudoso'
, utilizando una notación especializada;
c)se utiliza como raíz común de casos de prueba abstracta correspondientes para diferentes series de pruebas abstractas para el mismo protocolo;
d)incluye una descripción del estado inicial en el que debe comenzar el cuerpo de prueba, en lugar de un preámbulo;
e)no necesita describir el epílogo;
f)se especifica utilizando el estilo del método de prueba monocapa a distancia o distribuida.
8.2.2 Un caso de prueba abstracta se deriva de un caso genérico y de la correspondiente especificación de protocolo, y:
a)especifica el caso de prueba en base a un determinado método de prueba;
b)añade una especificación más precisa para las secuencias de sucesos, que sólo se describen informalmente en el caso de prueba genérica;
c)añade las secuencias de sucesos de prueba requeridas para alcanzar los objetivos del preámbulo y del epílogo del caso de prueba genérica, utilizando una notación especializada.
8.2.3 Un caso de prueba ejecutable se deriva de un caso de prueba abstracta, y tiene una forma que permite su ejercicio en un probador real para probar una realización real.
8.2.4 Los términos genérico, abstracto y ejecutable se utilizan para describir series de pruebas que comprenden casos de prueba genérica, abstracta y ejecutable, respectivamente.
8.2.5 Una serie de pruebas genérica abarca el conjunto o superconjunto de todas las posibles series de pruebas abstractas para un determinado protocolo.
9 Relaciones entre conceptos y roles
La figura 11/X.290, parte 1 es una representación gráfica de la relación entre las diversas Recomendaciones* y los procesos que producen series de pruebas genéricas, abstractas y ejecutables, e informes de prueba.
La parte 2 trata de la elaboración de Recomendaciones* sobre protocolos comprobables y Recomendaciones* sobre series de pruebas abstractas. La parte 1 contiene conceptos generales y definiciones.
Nota
- Deberán estudiarse ulteriormente otros aspectos
del proceso de evaluación de conformidad, tales como la derivación de prueba
ejecutable, la preparación de la RSP, el ECRP y la ISRPP por el cliente y el
rol del laboratorio de prueba.
10
Cumplimiento
En esta Recomendación el término
`cumplimiento'
se utiliza en el
sentido de cumplimiento de requisitos especificados en la misma. Dicha palabra
se utiliza con el fin de eliminar la confusión entre
cumplimiento
de esta Recomendación y la
conformidad
de una realización de protocolo con
Recomendaciones* sobre protocolos.
Esta parte de la Recomendación no contiene requisitos de cumplimiento.
Figure 11/X.290, partie 1, (N), p. 10
Parte 2 -
Especificación de series de
pruebas abstractas
0 Introducción
Esta parte de la Recomendación presenta una descripción general de la
especificación de las series de pruebas de conformidad, relacionadas con las
Recomendaciones del CCITT de las series X y T referentes a la ISA (a las cuales
se hará referencia en lo sucesivo como
`ISA*'
) a un nivel que es
independiente del medio empleado para ejecutar dichas series de pruebas (que en
lo sucesivo se denominarán
`series de pruebas abstractas'
). Este nivel
de abstracción es adecuado para la normalización y facilita la comparación de
resultados obtenidos por diferentes organizaciones que realizan las
correspondientes series de pruebas ejecutables.
En la sección 1, se recuerda que existen requisitos establecidos para los especificadores de protocolo ISA* que deben cumplirse antes de que puedan tomarse como base objetiva para el proceso de desarrollo de una serie de pruebas abstractas. Se señala la necesidad de secciones de conformidad y de proformas de ECRP y de ISRPP coherentes en las Recomendaciones* sobre protocolo ISA*.
En la sección 2, se describe el proceso de desarrollo de una serie de pruebas abstractas incluyendo los criterios de diseño que han de utilizarse y las orientaciones sobre su estructura y cobertura. Se definen los posibles métodos de pruebas abstractas y se dan orientaciones para ayudar al especificador de series de pruebas a decidir qué método(s) debe(n) utilizarse para crear una determinada serie de pruebas. La relación entre las series de pruebas abstractas para diferentes métodos se presenta para una serie de pruebas genéricas que es independiente del método de prueba. Se define una notación de las pruebas y se indican los requisitos, ofreciéndose información de orientación sobre su utilización, para especificar casos de pruebas genéricas y abstractas. Estos incluyen la subdivisión de los casos de prueba en pasos de prueba y la asignación de veredictos, a los resultados.
El especificador de series de pruebas debe también proporcionar información a los realizadores de las pruebas, en particular sobre las limitaciones que deben respetarse en la selección de los casos de prueba y en su ordenación.
Finalmente, se presenta información de orientación y se indican los requisitos para el mantenimiento de las series de pruebas.
1 Objeto y campo de aplicación
Esta parte de la Recomendación especifica los requisitos y presenta información de orientación para la elaboración de series de pruebas de conformidad independientes del sistema para una o más Recomendaciones* ISA*. En particular, se aplica a la preparación de todas las Recomendaciones* sobre series de pruebas de conformidad para protocolos ISA*.
Se trata la preparación de casos de pruebas de conformidad que verifican el cumplimiento, por una realización, de los requisitos de conformidad estáticos y/o dinámicos, controlando y observando el comportamiento con respecto a los protocolos. Los métodos de prueba abstracta incluidos en esta Recomendación pueden, de hecho, ser utilizados para especificar cualquier caso de prueba que puede expresarse abstractamente en términos de control y observación de unidades de datos de protocolo, primitivas de servicio abstractas y primitivas locales abstractas. Sin embargo, para algunos protocolos podrían necesitarse casos de prueba que no pueden expresarse en estos términos. La especificación de tales casos de prueba está fuera del ámbito de esta Recomendación, aunque esos casos de prueba pueden necesitar ser incluidos en una Recomendación* para una serie de pruebas de conformidad.
Nota
- Por ejemplo, algunos requisitos de conformidad
estática relacionados con un servicio de aplicación pueden necesitar técnicas
de prueba que son específicas de esa aplicación particular.
La elaboración de series de pruebas de conformidad para protocolos de múltiples entidades pares o de la capa física está fuera del ámbito de esta Recomendación.
La relación entre las técnicas de especificación de pruebas abstractas y las técnicas de descripción formal está también fuera del ámbito de esta Recomendación.
2
Referencias
Recomendación X.200
Modelo de referencia de interconexión
de sistemas abiertos para aplicaciones del CCITT.
^
(Véase también la Norma ISO 7498.)
Recomendación X.214
Definición del servicio de transporte
para la interconexión de sistemas abiertos para
aplicaciones del CCITT.
^ (Véase también la Norma ISO 8072.)
Recomendación X.224
Especificación del protocolo de
transporte para la interconexión de sistemas abiertos para
aplicaciones del CCITT.
^ (Véase también la Norma ISO 8073.)
Recomendación X.210
Convenios relativos a la definición del
servicio de capa en la interconexión de sistemas
abiertos.
^ (Véase también la Norma ISO TR 8509.)
Recomendación X.208
Especificación de la notación de
sintaxis abstracta uno (NSA.1).
^ (Véase también la
Norma ISO 8824.)
Recomendación X.209
Especificación de las reglas de
codificación básicas para la notación de sintaxis
abstracta uno (NSA.1).
^ (Véase también la Norma ISO 8825.)
Recomendación X.290/1
Metodología de las pruebas de
conformidad con ISA y marco para las Recomendaciones sobre
los protocolos destinados a aplicaciones del CCITT - Parte
1: Conceptos generales.
Norma ISO 8571-4
Information Processing Systems - Open
Systems
Interconnection - File Protocol
Specification.
3
Definiciones
A los efectos de esta parte de la Recomendación, son aplicables todas las definiciones que figuran en la parte 1.
4
Abreviaturas
A los efectos de esta Recomendación, son aplicables las abreviaturas indicadas en el 4 de la parte 1 de la Recomendación. También son aplicables las abreviaturas que se indican a continuación.
PSAÑprimitiva de servicio abstracta en el lado del proveedor de servicio distante de la RSP
CMU(método de prueba) coordinada multicapa
CMO(método de prueba) coordinada monocapa
CMOI(método de prueba) coordinada monocapa insertada
DMU(método de prueba) distribuida multicapa
DMO(método de prueba) distribuida monocapa
DMOI(método de prueba) distribuida monocapa insertada
TDFtécnica de descripción formal
LMU(método de prueba) local multicapa
LMO(método de prueba) local monocapa
LMOI(método de prueba) local monocapa insertada
RMU(método de prueba) distante multicapa
RMO(método de prueba) distante monocapa
RMOI(método de prueba) distante monocapa insertada
NCTAnotación combinada tabular y de árbol
YL(método de prueba) en bucle
YT(método de prueba) transversal
5
Conformidad
5.1 Una Recomendación* de protocolo que cumple con esta parte de esta Recomendación deberá satisfacer todos los requisitos indicados en la sección 1.
Nota
- Tal cumplimiento es un requisito para que una
Recomendación* de protocolo constituya una base eficaz para las pruebas de
conformidad de las realizaciones.
5.2 Una especificación de series de pruebas abstractas que cumpla esta parte de la presente Recomendación deberá:
a)constituir una serie de pruebas de conformidad;
b)ser especificada en una notación de prueba normalizada por la ISO o el CCITT;
c)satisfacer todos los requisitos indicados en la sección 2.
5.3 Se recomienda utilizar la notación de prueba denominada Notación combinada tabular y de árbol (NCTA). Si se utiliza NCTA, la serie de pruebas abstractas cumplirá todos los requisitos indicados en el anexo D.
SECCIóN 1 -
Requisitos que deben cumplir los especificadores
de protocolos
6 Requisitos de conformidad en Recomendaciones*
ISA*
6.1
Introducción
El significado de conformidad en ISA* se examinó en la parte 1 de esta Recomendación. Es necesario que haya una comprensión inequívoca y objetiva de los requisitos de conformidad de un protocolo ISA* o una Recomendación* sobre la sintaxis de transferencia, como condición previa a la elaboración de una serie de pruebas abstractas para esa Recomendación*. Esta sección indica los requisitos que deben cumplir los especificadores de protocolos para asegurar que exista esa comprensión de los requisitos de conformidad.
6.2
Requisitos generales
6.2.1 Debe establecerse una clara distinción entre requisitos de conformidad estática y dinámica. A fin de evitar ambigüedades, deben expresarse separadamente unos de otros.
6.2.2 Debe entenderse claramente lo que significa conformidad con una Recomendación*, en el sentido de lo que debe hacerse, lo que está permitido pero no es obligatorio, y lo que no debe realizarse para ajustarse a la Recomendación*.
6.2.3 Será siempre posible decidir si una situación de comunicación es o no dinámicamente conforme.
Por ejemplo, se debe poder examinar un registro de actividad de las UDP y decidir si es o no válido.
6.2.4 Los requisitos relativos a la necesidad de elaborar un ECRP y al contenido del mismo deberán enunciarse separadamente de los requisitos de la realización del protocolo propiamente dicho.
6.3
Secciones sobre conformidad
6.3.1 Cada protocolo ISA* y Recomendación* sobre la sintaxis de transferencia deberá incluir una sección sobre conformidad, redactada de una manera clara e inequívoca.
6.3.2En las secciones sobre conformidad se distinguirá claramente entre las siguientes categorías de información:
a)referencias a secciones que indican requisitos de conformidad dinámica;
b)requisitos de conformidad estática sobre realización de protocolos;
c)requisitos de conformidad estática sobre las relaciones de dependencias entre varias capas;
d)lo que debe de indicarse en el ECRP con relación al apartado b);
e)lo que debe indicarse en el ECRP en relación al apartado c);
f)cualquier otra información que deba proporcionarse (por ejemplo, para facilitar las pruebas) y si ésta debe estar contenida en el ECRP o en otro lugar.
6.3.3 En Recomendaciones* sobre protocolos orientados a la conexión, la sección de conformidad deberá incluir:
a)la opción de permitir la iniciación de una conexión, la aceptación de una conexión, o ambas;
b)el requisito de poder aceptar todas las secuencias correctas de UDP recibidas de entidades pares, y responder con secuencias correctas de UDP, apropiadas al estado definido de la conexión;
c)el requisito de poder responder correctamente a todas las secuencias incorrectas de UDP recibidas, siendo la respuesta adecuada al estado definido de la conexión.
6.4
Orientación adicional para las nuevas Recomendaciones*
sobre protocolos
Se reconoce que aunque las actuales Recomendaciones* sobre protocolos pueden mejorarse mediante un addéndum para agregar una proforma de ECRP y la armonización de la sección sobre conformidad con los requisitos antes expresados, es poco realista esperar mejoras mayores. Sin embargo, deben elaborarse nuevas Recomendaciones* sobre protocolos sobre la base de las orientaciones adicionales ofrecidas en el anexo B para que los requisitos de conformidad sean más fácilmente comprensibles y menos propensos a la ambigüedad.
7
Proformas de ECRP
7.1
Requisitos de las proformas de ECRP
7.1.1 Los requisitos específicos que deberán satisfacer los suministradores con respecto a cada ECRP que proporcionan, deberán normalmente indicarse en la Recomendación* pertinente sobre protocolos. La especificación de estos requisitos incluirá una proforma de ECRP. En circunstancias excepcionales, la proforma de ECRP puede encontrarse en la Recomendación* sobre series de pruebas abstractas, más bien que en la Recomendación* sobre protocolos: en particular, esto se aplica cuando la proforma de ECRP deba abarcar versiones diferentes del mismo protocolo provenientes de la ISO y del CCITT. En circunstancias normales, la proforma de ECRP debe encontrarse en un anexo a la Recomendación* sobre protocolos y se debe hacer referencia a la misma en la sección sobre conformidad, y, si es necesario, se hará seguir como un addéndum más bien que como parte de la Recomendación* original.
Nota
- Un ECRP para una realización de protocolo
específica deberá ir acompañado de una información administrativa y documental
relativa al suministrador, el sistema y el entorno deseado.
7.1.2 La proforma del ECRP deberá tener el formato de un cuestionario o lista de control que completará el suministrador o el realizador de una realización del protocolo ISA* correspondiente.
7.1.3 La proforma del ECRP deberá abarcar todas las funciones, elementos de procedimiento, parámetros, opciones, UDP, temporizadores, dependencias multicapa y otras capacidades identificadas en la Recomendación* sobre protocolos, incluidas las capacidades facultativas y condicionales. Conviene, cuando ello sea posible en la práctica, incluir todas las características obligatorias. Debe haber una relación de correspondencia bien definida, así como la debida coherencia, entre los requisitos de conformidad estática y la proforma del ECRP.
7.1.4 La proforma del ECRP irá precedida de una sección que indicará:
`El suministrador de una realización de protocolo que declare la
conformidad con esta Recomendación deberá completar la siguiente proforma del
enunciado de conformidad de realización de protocolo (ECRP) y facilitar la
información necesaria para identificar unívocamente el suministrador y la
realización.'
7.1.5 En cada página de la proforma del ECRP se indicará el nombre, la versión y la fecha de la Recomendación* pertinente sobre protocolos.
7.1.6 La proforma del ECRP para un protocolo específico contendrá:
a)explicaciones de símbolos especiales, abreviaturas y términos especiales, así como referencias apropiadas;
b)instrucciones explícitas para completar e interpretar el ECRP;
c)una indicación de toda característica obligatoria que no haya sido realizada, y de los motivos de ello;
d)uno o más cuadros (u otras clases de formularios, si es necesario) que deberán ser rellenados para indicar detalladamente las capacidades de la realización, incluyendo:
;1)nombre de la característica, tipo de UDP, temporizador, parámetro, y otras capacidades;
2)una columna que indicará si la característica es obligatoria, facultativa, negociable o condicional;
3)cuando sea posible, una columna con referencias a las secciones aplicables de la Recomendación;
4)una columna que indique la gama o los valores permitidos, en su caso;
5)una columna para rellenar, que indicará los valores o gamas de valores admitidos, en su caso;
6)una columna para rellenar, que indicará si cada capacidad ha sido establecida;
e)la proforma dará una indicación clara de los tipos de datos preferidos (por ejemplo, bases de numeración, tipos de cadena, octetos, bits, segundos, minutos, etc.) para las respuestas.
7.1.7 En la proforma del ECRP se utilizarán las siguientes abreviaturas, a menos que planteen problemas con abreviaturas utilizadas en la Recomendación* específica sobre protocolos:
mobligatorio
oopcional
ccondicional
nnegociable (utilizando el protocolo)
xexclusión de capacidad
-no es aplicable
scapacidad para transmitir
rcapacidad para recibir.
7.2
Orientación sobre las proformas del ECRP
El apéndice III presenta algunos ejemplos de carácter general para dar orientaciones sobre la construcción de las proformas del ECRP.
SECCIóN 2 -
Requisitos que deben cumplir los especificadores de
series de pruebas abstractas
8 Proceso de elaboración de series de
pruebas
A fin de presentar los requisitos y las orientaciones generales para la especificación de series de pruebas abstractas es conveniente suponer una forma normal del proceso de elaboración de series de pruebas. Esta sección describe el proceso pero solamente en dicha forma normal. Los especificadores de series de pruebas abstractas no están obligados a seguir exactamente esta forma normal, aunque se recomienda que utilicen un proceso similar que comprenda los mismos pasos, quizás en un orden diferente.
A los efectos de esta Recomendación, se supone que el proceso de elaboración de series de pruebas abstractas comprende lo siguiente:
a)estudiar la Recomendación* o Recomendaciones* pertinentes para determinar los requisitos de conformidad (incluidas las opciones) que deben probarse, y las necesidades que deben indicarse en el ECRP (véase el 9 );
b)decidir qué grupos de pruebas serán necesarios para obtener la cobertura apropiada de los requisitos de conformidad y formar, con estos grupos de pruebas, conjuntos de finalidades de prueba (véase el 10 );
c)especificar casos de pruebas genéricas para cada finalidad de prueba, utilizando alguna notación de prueba apropiada (véase el 11 );
d)elegir el método o los métodos de prueba para los cuales deberán ser especificados los casos completos de pruebas abstractas y decidir qué limitaciones deben imponerse a las capacidades del probador inferior y (si ello corresponde al método o los métodos de prueba elegidos) al probador superior y a los procedimientos de coordinación de pruebas (véase el 12 );
e)elegir la notación de prueba para la especificación de los casos completos de pruebas abstractas, y especificar los casos completos de pruebas abstractas, incluyendo la estructura de pasos de prueba que ha de utilizarse (véase el 13 );
f)especificar las relaciones entre los casos de prueba, y entre éstos y el ECRP, así como, en la medida de lo posible, la ISRPP, a fin de determinar las limitaciones a la selección y parametrización de los casos de prueba para ejecución, y el orden en que pueden ejecutarse (véase el 14 );
g)considerar los procedimientos para mantener la serie de pruebas abstractas (véase el 15 ).
En el resto de esta sección se indican los requisitos que deben cumplirse y se dan orientaciones en relación con cada paso del proceso antes mencionado.
9 Determinación de los requisitos de
conformidad y del ECRP
9.1
Introducción
Antes de poder especificar una serie de pruebas abstractas, el especificador de la serie de pruebas determinará primeramente qué requisitos de conformidad se indican en la Recomendación* o Recomendaciones* pertinentes y qué otros se indican en la proforma de ECRP relativa a la realización de esas Recomendaciones*.
9.2
Requisitos de conformidad
La sección 1 de esta Recomendación especifica los requisitos que deben satisfacer los especificadores de protocolo con anterioridad a la elaboración de una serie de pruebas abstractas para un determinado protocolo.
En la práctica, las Recomendaciones* ISA* iniciales podrían no contener una especificación clara de todos los requisitos de conformidad aplicables. En particular, los requisitos de conformidad estática podrían estar mal especificados, o incluso no figurar en las mismas. En tales casos, el especificador de la serie de pruebas contribuirá a la preparación de una enmienda o addéndum a la Recomendación* o Recomendaciones* pertinentes para aclarar los requisitos de conformidad. Si, no obstante, debe elaborarse una serie de pruebas abstractas antes de que se aclaren los requisitos de conformidad en las Recomendaciones* pertinentes, el especificador de la serie de pruebas adoptará la solución a corto plazo indicada en el anexo C y expresará claramente en la Recomendación* sobre series de pruebas qué implicaciones tiene esto (es decir, lo que deba suponerse obligatorio, lo que deba suponerse condicional, indicándose las condiciones, y lo que deba suponerse opcional).
9.3
Proforma del ECRP
Si en una Recomendación* pertinente sobre protocolo no se incluye una proforma de ECRP, el especificador de la serie de pruebas proporcionará una proforma de ECRP que se tratará como addéndum a esa Recomendación* o, en circunstancias excepcionales (examinadas en el 7.1.1 ), en forma de anexo a la Recomendación* sobre serie de pruebas abstractas.
Nota
- La progresión de un addéndum hasta convertirse
en una Recomendación* existente sobre protocolo puede ser más rápida que la
progresión de la Recomendación* sobre serie de pruebas abstractas, porque la
proforma del ECRP probablemente sea menos controvertible que la serie de
pruebas y, por eso, probablemente requiera menos modificaciones para poder ser
adoptada como texto final.
10 Estructura de las series de pruebas
10.1
Requisitos básicos
Una serie de pruebas abstractas comprenderá cierto número de casos de prueba. Los casos de prueba se agruparán en grupos de prueba, los cuales, si es necesario, estarán anidados. La estructura será jerárquica en el sentido de que un elemento de nivel inferior estará completamente contenido en un elemento de nivel superior. No es necesario, sin embargo, que la estructura sea estrictamente jerárquica en el sentido de que todo caso de prueba pueda producirse en más de una serie de pruebas o en más de un grupo de pruebas. Pueden darse grupos de pruebas similares en más de un grupo de pruebas de nivel superior o de serie de pruebas.
El especificador de una serie de pruebas abstractas deberá asegurar que un subconjunto de las finalidades de prueba de cada serie de pruebas abstractas afecte a la prueba de capacidad y que otro subconjunto afecte a la prueba de comportamiento. Esto no tiene necesariamente que conducir a casos de prueba distintos para cada prueba de comportamiento y de capacidad, porque puede ser posible utilizar los mismos pasos de prueba para una finalidad de prueba de comportamiento y para una finalidad de prueba de capacidad. El especificador de una serie de pruebas presentará una explicación de la forma en que las finalidades de prueba se derivan o están relacionadas con la Recomendación* sobre protocolo. El especificador de una serie de pruebas proporcionará también un resumen de la cobertura alcanzada por la serie de pruebas.
10.2
Estructura de grupo de pruebas
A fin de asegurar que la serie de pruebas abstractas resultante proporciona una cobertura adecuada de los requisitos de conformidad, se aconseja al especificador de una serie de pruebas que diseñe la estructura de la serie de pruebas en forma de grupos de pruebas anidados de una manera descendente (véase la figura 1/X.290, parte 2).
Hay muchas formas de estructurar la misma serie de pruebas en grupos de pruebas; ninguna de esas maneras es necesariamente correcta, y puede darse el caso de que el mejor método para una serie de pruebas no sea apropiado para otra serie de pruebas. No obstante, el especificador de una serie de pruebas asegurará que la serie de pruebas incluya casos de prueba para cualesquiera de las siguientes categorías pertinentes:
a)pruebas de capacidad (para requisitos de conformidad estática);
b)pruebas de comportamiento en que se verifica el comportamiento válido;
c)pruebas de comportamiento en que se verifica el comportamiento sintácticamente inválido;
d)pruebas de comportamiento en que se verifica el comportamiento inoportuno;
e)pruebas relacionadas con las UDP enviadas a la RSP;
f)pruebas relacionadas con las UDP recibidas de la RSP;
g)pruebas relacionadas con interacciones entre lo que se envía y lo que se recibe;
h)pruebas relacionadas con cada característica de protocolo obligatoria;
i)pruebas relacionadas con cada característica facultativa establecida;
j)pruebas relacionadas con cada fase del protocolo;
k)variaciones del suceso de prueba que ocurren en un estado determinado;
l)variaciones de la temporización y de los temporizadores;
m)variaciones de la codificación de las UDP;
n)variaciones de los valores de parámetros individuales;
o)variaciones de las combinaciones de valores de parámetros.
Esta lista no es exhaustiva; podría ser necesario prever categorías adicionales para asegurar una cobertura de los requisitos de conformidad pertinentes para una serie de pruebas específica. Además, estas categorías se superponen unas a otras, e incumbe al especificador de la serie de pruebas situarlas en una estructura jerárquica apropiada. La siguiente estructura es un ejemplo de una serie de pruebas monocapa, presentada como orientación:
APruebas de capacidad
A.1Características obligatorias
A.2Características facultativas indicadas en el ECRP como admisibles
BPruebas de comportamiento - Respuesta a un comportamiento válido por una realización par
B.1Fase de establecimiento de la conexión (en su caso)
B.1.1Atendiendo a lo que se envía a la RSP
B.1.1.1Variación del suceso de prueba en cada estado B.1.1.2Variación de la temporización/temporizador B.1.1.3Variación de la codificación B.1.1.4Variación del valor del parámetro individual B.1.1.5Combinación de valores de parámetros
B.1.2Atendiendo a lo que se recibe de la RSP
- subestructurado como en B.1.1
B.1.3Atendiendo a interacciones
- subestructurado como en B.1.1
B.2Fase de transferencia de datos
- subestructurado como en B.1
B.3Fase de liberación de la conexión (en su caso)
- subestructurado como en B.1
CPruebas de comportamiento - Respuesta a un comportamiento sintácticamente inválido por una realización par
C.1Fase de establecimiento de la conexión (en su caso)
C.1.1Atendiendo a lo que se envía a la RSP
C.1.1.1Variación del suceso de prueba en cada estado C.1.1.2Variación de la codificación del suceso inválido C.1.1.3Variación de valor inválido del parámetro individual C.1.1.4Variación de la combinación inválida de valores de parámetro
C.1.2Atendiendo a lo que se pide a la RSP que envíe
C.1.2.1Valores inválidos de los parámetros individuales C.1.2.2Combinaciones inválidas de valores de parámetro
C.2Fase de transferencia de datos
- subestructurado como en C.1
C.3Fase de liberación de la conexión (en su caso)
- subestructurado como en C.1
DPruebas de comportamiento - Respuesta a sucesos inoportunos por una realización par
D.1Fase de establecimiento de la conexión (en su caso)
D.1.1Atendiendo a lo que se envía a la RSP
D.1.1.1Variación del suceso de prueba en cada estado D.1.1.2Variación de la temporización/temporizador D.1.1.3Variaciones de las codificaciones especiales D.1.1.4Variaciones importantes de los valores de parámetro individuales D.1.1.5Variación en combinación importante de los valores de parámetro
D.1.2Atendiendo a lo que se pide a la RSP que envíe
- subestructurado como en D.1.1
D.2Fase de transferencia de datos
- subestructurado como en D.1
D.3Fase de liberación de la conexión (en su caso)
- subestructurado como en D.1.
Si la serie de pruebas debe abarcar más de una capa, podría replicarse para cada capa en cuestión una estructura de serie de pruebas monocapa como ésta. Además, podría elaborarse una estructura detallada correspondientemente para probar las capacidades y el comportamiento de múltiples capas tomadas en conjunto, incluyendo la interacción entre las actividades en capas adyacentes.
10.3
Finalidades de prueba
El especificador de una serie de pruebas asegurará que, para cada caso de prueba en una serie de pruebas abstractas, haya un enunciado claro de la finalidad de la prueba. Se sugiere que estas finalidades de prueba se preparen como el perfeccionamiento siguiente de la serie de pruebas, después de haberse definido su estructura en forma de grupos de pruebas. Las finalidades de prueba podrían prepararse directamente partiendo de las secciones de la Recomendación* o Recomendaciones* pertinentes apropiadas para el grupo de pruebas en cuestión. Para algunos grupos de pruebas, las finalidades de prueba podrían deducirse directamente de la tabla de estados del protocolo; para otros, podrían deducirse de las definiciones de codificación de las UDP o de las descripciones de parámetros particulares, o del texto que especifica los requisitos de conformidad correspondientes. Como otra posibilidad, el especificador de serie de pruebas podría emplear una descripción formal del protocolo (o protocolos) en cuestión y derivar de ésta las finalidades de prueba por medio de algún método automatizado.
Cualquiera que sea el método utilizado para deducir las finalidades de prueba, el especificador de una serie de pruebas asegurará que estas finalidades proporcionen una cobertura adecuada de los requisitos de conformidad de las Recomendaciones* consideradas. Deberá haber por lo menos una finalidad de prueba relacionada con cada uno de los distintos requisitos de conformidad.
Además, será posible dar alguna orientación sobre el significado de
`cobertura adecuada'
con referencia al ejemplo anterior. A fin de
expresar esto se utilizará una notación abreviada: la letra
`x'
representará todos los valores apropiados para la primera cifra del
identificador del grupo de pruebas, y de manera similar
`y'
para la
segunda cifra, de modo que B.x.y.1 represente B.1.1.1, B.1.2.1, B.1.3.1,
B.2.1.1, B.2.2.1, B.2.3.1, B.3.1.1, B.3.2.1 y B.3.3.1. Con esta notación, una
`cobertura adecuada'
mínima para el ejemplo anteriormente mencionado
sería la siguiente:
a)para grupos de prueba de capacidad (A.1, A.2):
1)al menos una finalidad de prueba para cada prestación, clase o subconjunto aplicable;
2)al menos una finalidad de prueba para cada tipo de UDP y para cada
variación importante de cada tipo, utilizando valores
`normales'
o por
defecto para cada parámetro;
b)para los grupos de pruebas en que se produce una variación del suceso de prueba en cada estado (B.x.y.1, C.x.1.1, D.x.y.1):
-al menos una finalidad de prueba por cada combinación de estado/suceso aplicable;
c)para grupos de pruebas relacionados con temporizadores y temporizaciones (B.x.y.2, D.x.y.2):
1)al menos una finalidad de prueba relacionada con la expiración de cada temporizador definido;
2)al menos una finalidad de prueba relacionada con una respuesta rápida para cada tipo aplicable de UDP;
3)al menos una finalidad de prueba relacionada con una respuesta muy lenta para cada tipo aplicable de UDP;
d)para grupos de pruebas relacionados con variaciones de la codificación (B.x.y.3, C.x.1.2, D.x.y.3):
-al menos una finalidad de prueba para cada clase aplicable de variación de la codificación por cada tipo aplicable de UDP;
e)para grupos de pruebas relacionados con valores válidos de parámetros individuales (B.x.y.4, D.x.y.4):
1)para cada parámetro entero aplicable, finalidades de prueba relacionadas con los valores límite y un valor de mitad de gama seleccionado al azar;
2)para cada parámetro binario aplicable, finalidades de prueba para tantos
valores como sea posible en la práctica; su número no será menor que el de
todos los valores
`normales'
o comunes;
3)para otros parámetros aplicables, por lo menos una finalidad de prueba
relacionada con un valor diferente de los que se consideran
`normales'
o
por defecto en otros grupos de pruebas;
f)para grupos de pruebas relacionados con valores inválidos de parámetro individuales (C.x.1.3, C.x.2.1):
1)para cada parámetro binario aplicable, finalidades de prueba relacionadas con valores inválidos adyacentes a los valores límite autorizados, y otro valor inválido seleccionado al azar;
2)para cada parámetro binario aplicable, finalidades de prueba para tantos valores inválidos como sea posible en la práctica;
3)para todos los otros tipos aplicables de parámetro, por lo menos una finalidad de prueba por parámetro;
g)para grupos de pruebas relacionados con combinaciones de valores de parámetros (B.x.y.5, C.x.1.4, C.x.2.2, D.x.y.5):
1)al menos una finalidad de prueba para par de valores
`crítico'
;
2)al menos una finalidad de prueba por cada par de parámetros interrelacionados, para probar una combinación aleatoria de valores aplicables.
11 Especificación de caso de prueba
genérica
11.1
Introducción
Se aconseja al especificador de una serie de pruebas que especifique una serie de pruebas genéricas, en especial si tiene la intención de elaborar más de una serie de pruebas abstractas.
Una serie de pruebas genéricas consistirá en un caso de prueba genérica para cada finalidad de prueba. Cada caso de prueba genérica será un perfeccionamiento de su finalidad de prueba, la cual puede utilizarse como raíz común de casos de prueba abstracta correspondientes para diferentes métodos de prueba.
La preparación de una serie de pruebas genéricas con antelación a series de pruebas abstractas será un paso útil en el proceso de diseño. Si una serie de pruebas genéricas se elaborara después de haberse preparado por lo menos una serie de pruebas abstractas, dicha serie proporcionará un medio para relacionar entre sí diferentes series de pruebas y para analizar la posible existencia de sectores que han quedado fuera de su cobertura.
11.2
Descripción de casos de prueba genérica
Un caso de prueba genérica consiste en una descripción textual de un
`estado inicial'
(del cuerpo de prueba) y una especificación del cuerpo
de prueba con una notación de prueba normalizada. El
`estado inicial'
comprende no solamente el estado del protocolo, sino también toda información
necesaria sobre el estado del SSP y del entorno de pruebas.
El cuerpo de prueba es la parte de un caso de prueba en la cual se asignan a resultados previstos, veredictos relacionados con la finalidad de prueba. El cuerpo de prueba:
a)Se definirá en el estilo, del método de prueba distante del método de prueba distribuida.
Nota
- Los casos de prueba genérica pueden aprovechar
toda la potencia de expresión de estos métodos (para detalles, véase el
12.3.3
), incluyendo el uso de primitivas locales abstractas;
b)asignará veredictos a todos los resultados posibles; todos los resultados
que reciban un veredicto de
`favorable'
serán identificados
explícitamente, y todos los resultados que reciban un veredicto de
`desfavorable'
o
`dudoso'
serán identificados o categorizados (lo
que puede incluir la categorización de veredictos por defecto);
c)se describirán utilizando una notación de prueba normalizada; se recomienda emplear la notación combinada tabular de árbol (NCTA) (definida en el anexo D).
11.3
Relación entre un caso de prueba genérica y un caso de
prueba abstracta
Para un determinado método de prueba abstracta será posible derivar muchos casos de prueba abstracta de un solo caso de prueba genérica. Una diferencia fundamental entre un caso de prueba abstracta y un caso de prueba genérica es que el caso de prueba abstracta incluye especificaciones de un preámbulo y un epílogo. El preámbulo comienza en un estado estable elegido y conduce al estado inicial requerido del cuerpo de prueba. El epílogo comienza al final del cuerpo de prueba y retorna a un estado estable elegido.
El preámbulo y el epílogo pueden realizarse de diferentes maneras, que dependerán del grado de control y observación proporcionados por el método de prueba utilizado, y de la diversidad de los diferentes estados estables posibles, en los cuales podrá comenzar o terminar, respectivamente, el caso de prueba abstracta derivado. Estos casos de prueba abstracta son, simplemente, maneras diferentes de obtener una misma finalidad de prueba.
Además, el cuerpo de prueba de un caso de prueba abstracta puede ser diferente del correspondiente caso de prueba genérica, si el método de prueba utilizado para el caso de prueba abstracta es diferente del utilizado para el caso de prueba genérica.
Si se produce una serie de pruebas genéricas, deberá utilizarse como medio de relacionar series de pruebas abstractas correspondientes para diferentes métodos de prueba abstracta.
12 Métodos de pruebas abstractas
12.1
Introducción
Cada serie de pruebas abstractas se especificará mediante el control y la observación de sucesos de acuerdo con uno de los métodos de prueba abstracta definidos en esta sección. El método de prueba elegido determina los puntos en que deberá especificarse el control y la observación, así como las categorías de sucesos que habrán de utilizarse [por ejemplo, PAS(N - 1), UDP(N)].
12.2
Especificación general de los métodos de prueba
abstracta
12.2.1
RSP de sistema final
Para las RSP que forman parte de los SSP de sistemas finales hay cuatro
categorías de métodos de prueba abstracta, una
local
y
tres
externas
que suponen que el probador exterior se
encuentra situado en un lugar diferente del SSP y está conectado a éste por un
enlace o una red.
Por razones de generalidad de la exposición, los métodos de prueba se
describen con referencia a una RSP en la cual la capa más elevada lleva el
número
`Ns'
(donde s, significa
`superior'
) y el protocolo de
capa inferior lleva el número
`Ni'
(donde i, significa
`inferior'
). La RSP puede realizar protocolos en capas más bajas que
`Ni'
, pero éstas no ofrecen interés para las descripciones de los
métodos de prueba. La descripción se aplica a RSP monocapa haciendo que Ns sea
igual a Ni.
12.2.2
Primitivas locales abstractas
Los especificadores de series de pruebas abstractas pueden, si es necesario, definir un conjunto de primitivas locales abstractas (PLA) que se utilizan en la especificación de la serie de prueba. Una PLA es una forma abreviada de la descripción de control y/u observación que ha de efectuar el probador superior, y que no puede describirse en términos de PSA, pero que inicia sucesos o cambios de estado definidos en las Recomendaciones* pertinentes sobre protocolos. Las PLA pueden utilizarse con cualquier método de prueba abstracta para SSP de sistemas finales pero, por razones de simplicidad, no se indicarán en ninguna de las figuras que ilustran estos métodos.
Todo método de prueba que utiliza una PLA será facultativo en la serie de pruebas abstractas.
12.2.3
Métodos de prueba local
Abreviatura: L
En este método:
a)la serie de pruebas abstractas se especifica mediante el control y la observación de las PSA(Ni - 1) y de las UDP(Ni) a (Ns);
b)la serie de pruebas abstractas se especifica también mediante el control y la observación de las PSA(Ns);
c)la serie de pruebas abstractas puede también especificarse mediante el control y la observación por el probador superior de las primitivas locales abstractas (PLA);
d)el método requiere el acceso a las fronteras inferior y superior de la RSP y una relación de correspondencia entre las PSA especificadas y su realización dentro del SSP;
e)los requisitos que deben cumplir los procedimientos de coordinación de pruebas se especifican en la serie de pruebas abstractas, pero no se adopta ninguna hipótesis en cuanto a su realización;
f)los probadores superior e inferior deberán efectuar el control y la observación de las PSA especificadas y los procedimientos requeridos de coordinación de pruebas. Se supone que están integrados en el SSP.
Este método se ilustra en la figura 1/X.290, parte 2.
12.2.4
Métodos de prueba externa
12.2.4.1
Método de prueba distribuida
Abreviatura: D
En este método:
a)la serie de pruebas abstractas se especifica mediante el control y la observación de las PSAÑ(Ni - 1) y de las UDP(Ni) a (Ns);
b)la serie de pruebas abstractas se especifica también mediante el control y la observación de las PSA(Ns); el método requiere el acceso a la frontera superior de la RSP y una relación de correspondencia entre las PSA(Ns) y su realización dentro del SSP;
c)la serie de pruebas abstractas puede también especificarse mediante el control y la observación de las PLA por el probador superior;
d)los requisitos para los procedimientos de coordinación de pruebas se especifican en la serie de pruebas abstractas, pero no se adopta ninguna hipótesis en cuanto a su realización;
e)el probador superior deberá efectuar el control y la observación de las PSA(Ns) especificadas y producir los efectos de los procedimientos requeridos de coordinación de pruebas; no se adopta ninguna otra hipótesis;
f)el probador inferior deberá efectuar el control y la observación de las PSAÑ(Ni) especificadas y de las UDP especificadas y seguir los procedimientos requeridos de coordinación de pruebas.
Este método se ilustra en la figura 2/X.290, parte 2.
12.2.4.2
Método de prueba coordinada
Abreviatura: C
En este método:
a)la serie de pruebas abstractas se especifica mediante el control y la observación de las PSAÑ(Ni - 1), UDP(Ni) a (Ns) y las UDP de gestión de prueba (UDP-GP);
b)las PSA(Ns) no tienen que utilizarse en la especificación de la serie de pruebas abstractas; no se adopta ningúna hipótesis en cuanto a la existencia de una frontera superior de la RSP;
c)los requisitos de los procedimientos de coordinación se especifican en la serie de pruebas abstractas por medio de un protocolo normalizado de gestión de pruebas;
d)pueden definirse las UDP-GP que correspondan a PLA;
e)el probador superior deberá establecer el protocolo de gestión de prueba y obtener los efectos apropiados en la RSP;
f)el probador inferior deberá efectuar el control y la observación de las PSAÑ(Ni) especificadas y las UDP especificadas (incluidas las UDP-GP).
Este método se ilustra en la figura 3/X.290, parte 2.
12.2.4.3
Método de prueba distante
Abreviatura: R
En este método, se prevé el caso en que no es posible observar y controlar la frontera superior de la RSP. También, en este método:
a)la serie de pruebas abstractas se especifica mediante el control y la observación de las PSAÑ(Ni - 1) y de las UDP(Ni) a (Ns);
b)no se utilizan las PSA(Ns) en la especificación de la serie de pruebas abstractas; no se adopta ningúna hipótesis en cuanto a la existencia de una frontera superior de la RSP;
c)la serie de pruebas abstractas puede también describirse mediante el control y la observación de PLA dentro del SSP;
d)algunos requisitos de los procedimientos de coordinación de pruebas pueden indicarse implícitamente o expresarse informalmente en la serie de pruebas abstractas, pero no se adopta ningúna hipótesis en cuanto a su viabilidad o realización;
e)en un orden abstracto, el SSP debe realizar algunas funciones de probador superior para obtener cualquier efecto de los procedimientos de coordinación y todo control y»u observación de la RSP que haya sido indicado implícitamente, expresado informalmente o descrito por las PLA en la serie de pruebas abstractas para un protocolo dado; estas funciones no se especifican; ni se adopta ninguna hipótesis en cuanto a su viabilidad o realización;
f)el probador inferior deberá efectuar el control y la observación de las PSAÑ(Ni) especificadas y de UDP especificadas y debe tratar de efectuar los procedimientos de coordinación de pruebas implícitos o expresados informalmente, de acuerdo con la información correspondiente en la ISRPP.
Este método se ilustra en la figura 4/X.290, parte 2.
Figuras 1, 2, 3 et 4/X.290, parte 2, (N), p.
12.2.5
Variantes monocapa, multicapa e insertadas
Cada categoría de métodos de prueba tiene una variante que puede aplicarse a las RSP monocapa (abreviatura: MO); y otra que puede aplicarse a las RSP multicapa (abreviatura: MU), cuando deba probarse el conjunto de capas adyacentes en combinación (como un todo).
Para una RSP multicapa en la cual los protocolos van a probarse capa por capa se ha definido una variante insertada de los métodos de prueba (abreviatura: I).
Si se aplican el control y la observación como medio de acceso a la frontera superior de las entidades sometidas a prueba dentro del SSP, los métodos de prueba son normales (y no se agrega I al nombre abreviado). Si, en cambio, el control y la observación se aplican a través de una o más entidades de capa ISA* por encima de las entidades sometidas a prueba, los métodos de prueba se denominan insertados (y se agrega I al nombre abreviado).
Los nombres de las variantes particulares de los métodos de prueba se forman como sigue:
| L | R | C | D | MO | MU [ I ] Por ejemplo DMOI es la abreviatura
del método de prueba
`distribuida monocapa insertada'
.
12.2.6
Sistemas abiertos de relevo
Para los sistemas abiertos de relevo se definen los métodos de prueba en bucle y transversal. Sus abreviaturas son YL e YT, respectivamente.
12.3
Métodos de prueba monocapa para RSP monocapa en
sistemas finales
Para los métodos de prueba monocapa, el modelo abstracto de la RSP se denomina entidad (N) sometida a prueba.
12.3.1
Método de prueba local monocapa
El método de prueba abstracta local monocapa (LMO) define los puntos de control y de observación como los situados en las fronteras del servicio por encima y por debajo de la entidad (N) sometida a prueba. Los sucesos de prueba se especifican mediante las PSA (N) por encima de la RSP y las PSA(N - 1) y las UDP(N) por debajo de la RSP, como se indica en la figura 5/X.290, parte 2. Además, pueden utilizarse PLA como sucesos de prueba. En un orden abstracto, se considera que un probador inferior observa y controla las PSA(N - 1) y las UDP(N), en tanto que un probador superior observa y controla las PSA (N) y las PLA. Los requisitos que deben satisfacer los procedimientos de coordinación de pruebas utilizados para coordinar las realizaciones de los probadores superior e inferior se definen en las series de pruebas abstractas, si bien los procedimientos de coordinación de pruebas propiamente dichos no se definen.
12.3.2
Método de prueba distribuida monocapa
El método de prueba abstracta distribuida monocapa (DMO) define los puntos de control y observación como los situados en las fronteras del servicio por encima de la entidad sometida a prueba (N) y por encima del proveedor de servicio (N - 1) en el PAS distante de la entidad (N) sometida a prueba. Los sucesos de prueba se especifican mediante las PSA (N) por encima de la RSP y las PSAÑ(N - 1) y las UDP(N), distantes, como se indica en la figura 6/X.290, parte 2. Además, pueden utilizarse las PLA como sucesos de prueba. En un orden abstracto, se considera aquí también que los probadores inferior y superior observan y controlan el comportamiento en los puntos respectivos. Los requisitos que deben cumplir los procedimientos de coordinación de prueba se definen entonces en las series de pruebas abstractas, si bien los procedimientos propiamente dichos no se definen.
Para las capas inferiores (1-3), en las que puede ser irreal especificar la observación y el control de las PSAÑ(N - 1), la observación y el control por el probador inferior se especificarán en términos de las UDP(N) y, cuando sea necesario, los cambios de estado de la conexión subyacente.
Nota
- Por ejemplo, el estado de la conexión
subyacente podría cambiar al establecerse una nueva conexión, o reiniciarse o
cerrarse una conexión existente.
La observación y el control que debe efectuar el probador inferior pueden especificarse facultativamente en forma de las PSAÑ(N), cuando esto reduzca el volumen de la especificación del caso de prueba sin pérdida de la precisión requerida.
Figuras 5 y 6/X.290, parte 2, (N), p.
12.3.3
Método de prueba coordinada monocapa
El método de prueba abstracta coordinada monocapa (CMO) es una versión mejorada del método DMO que utiliza un probador superior normalizado y la definición de un protocolo de gestión de pruebas para la realización de los procedimientos de coordinación entre los probadores superior e inferior. El mismo probador superior normalizado y el mismo protocolo de gestión de pruebas no tienen necesariamente que ser aplicables a todas las series de pruebas que emplean el método de prueba coordinada.
Los probadores superiores y protocolos de gestión de pruebas normalizados son aplicables a una determinada serie de pruebas abstractas normalizada para el método de prueba coordinada y pueden no ser aplicables a otras series de pruebas abstractas para el método de prueba coordinada.
Sólo hay un punto de control y de observación, por encima del proveedor de servicio (N - 1) en el PAS distante de la entidad (N) sometida a prueba. Los sucesos de prueba se especifican en forma de las PSAÑ(N - 1), las UDP(N) y las UDP-GP, como se indica en la figura 7/X.290, parte 2.
Para las capas inferiores (1-3) en que puede no ser realista especificar la observación y el control de PSAÑ(N - 1), la observación y el control deberán especificarse en términos de las UDP-GP, las UDP(N), y cuando sea necesario, los cambios en el estado de la conexión subyacente.
En cuanto al protocolo de gestión de prueba:
a)este protocolo se aplicará dentro del SSP directamente encima de la frontera del servicio abstracto en la parte superior de la RSP;
b)no será necesario que la RSP interprete las UDP-GP, bastando con que las transfiera hacia y desde el probador superior;
c)un protocolo de gestión de pruebas sólo está definido para la prueba de un determinado protocolo, por lo que no necesita ser independiente del protocolo subyacente;
d)los veredictos sobre casos de prueba no tienen que basarse en la aptitud del SSP para presentar cualquier PSA o parámetro de una PSA en la frontera de servicio superior de la RSP, pues esto contravendría la definición del método de prueba coordinada en cuanto a que la frontera de servicio superior de la RSP no es un punto de control y observación en este método. Sin embargo, se recomienda que el protocolo de gestión de pruebas se defina separadamente de las series de pruebas abstractas, a fin de facilitar la tarea del realizador de un probador superior. Esta definición (al igual que ocurre con la definición de todo protocolo ISA* definido por la ISO o el CCITT) puede hacer referencia a las PSA de su servicio subyacente (es decir, las PSA en la frontera de servicio superior de la RSP);
e)las UDP-GP que corresponden a las PLA son facultativas y no se exige que sean admitidas por el probador superior.
12.3.4
Método de prueba distante monocapa
El método de prueba abstracta distante monocapa (RMO) define el punto de control y observación como el situado encima del proveedor de servicio (N - 1) en el PAS distante de la entidad (N) sometida a prueba. Los sucesos de prueba se especifican en base a las PSAÑ(N - 1) y las UDP(N), a distancia, como se indica en la figura 8/X.290, parte 2. Además, pueden utilizarse PLA como sucesos de prueba. Algunos requisitos de los procedimientos de prueba pueden venir implícitos o estar expresados informalmente en las series de pruebas abstractas, pero no se adoptan hipótesis con respecto a su viabilidad o realización.
Para las capas inferiores (1-3), donde no es realista especificar la observación y el control de las PSAÑ(N - 1), la observación y el control se especificarán mediante las UDP(N) y, cuando sea necesario, el estado de la conexión subyacente.
Además, a fin de superar la falta de especificación de comportamiento por
encima de la entidad (N) sometida a prueba, en caso necesario el comportamiento
requerido del sistema sometido a prueba se especificará en términos de las
PSAÑ(N - 1) o las UDP(N) que deben ser observadas por el probador inferior. Se
considerará que esta forma de especificación implícita significa
`hacer todo
lo necesario dentro del sistema sometido a prueba para provocar este
comportamiento requerido'
.
Nota
- Con este método de prueba, tal especificación
implícita es necesaria para cualquier caso de prueba que requiera un suceso
iniciado por la RSP y que no podría ser iniciado por una PLA. Dado que las PLA
sólo pueden definirse si el mismo efecto no puede obtenerse mediante las PSA,
entonces, toda UDP que pueda ser iniciada por una PSA necesita una
especificación implícita para permitir que pueda ser iniciada en este método de
prueba.
Sin embargo, es posible que no puedan ejecutarse algunos casos de prueba en la serie de pruebas abstractas (por ejemplo, la transmisión y mantenimiento de condiciones de ocupado, la transmisión de unidades UDP de datos consecutivas sin acuse de recibo, etc.). En tales situaciones se deja que sean el laboratorio y el cliente quienes negocien el método que habrá de emplearse para realizar estas pruebas.
Aun con tal especificación implícita de control de la RSP, en este método es posible especificar el control, pero no la observación por encima de la RSP, salvo si se utilizan las PLA. Esta es la principal diferencia entre este método de prueba y los métodos DMO y CMO.
Figuras 7 y 8/X.290, parte 2, (N), p.
12.4
Métodos de prueba multicapa para las RSP multicapa
(LMU, DMU, CMU, RMU)
Cuando se conoce el comportamiento autorizado combinado de la realización multicapa, la prueba multicapa implica la prueba de todas las capas de una RSP multicapa, como un todo, sin controlar ni observar ninguna de las fronteras entre capas dentro de la RSP.
En el método de prueba local multicapa (LMU), los puntos de observación y control son las fronteras del servicio directamente encima y debajo de la RSP. Los sucesos de prueba se especificarán mediante las PSA(Ns) y las PLA encima de la RSP y las PSA(N - 1) y UDP(N) a (Ns) debajo de la RSP.
En el método de prueba distribuida multicapa (DMU), los puntos de observación y control están en la frontera del servicio encima de la RSP y debajo del proveedor del servicio (N - 1) en el PAS distante de la RSP. Los sucesos de prueba se especificarán en términos de las PSA(Ns) y las PLA encima de la RSP y de las PSAÑ(N - 1) y las UDP(N) a (Ns), distantes.
En el método de prueba coordinada multicapa (CMU), el punto de observación y control está por encima del proveedor de servicio (N - 1) en el PAS distante de la RSP. Los sucesos de prueba se especificarán mediante las PSAÑ(N - 1), las UDP(N) a (Ns) y las UDP-GP. El protocolo de gestión de pruebas se diseñará de modo que funcione por encima del servicio (Ns), siendo (Ns) la capa más alta en la RSP.
En el método de prueba distante multicapa (RMU), el punto de observación y control está por encima del proveedor del servicio (N - 1) en el PAS distante de la RSP. Los sucesos de prueba se especificarán en términos de las PSAÑ(N - 1) y las UDP(N) a (Ns), las PLA y la especificación implícita del control del comportamiento del SSP cuando sea necesario. Algunos requisitos de los procedimientos de coordinación de las pruebas pueden estar implícitos o ser expresados informalmente, pero no se adoptan hipótesis en cuanto a su viabilidad o realización.
12.5
Prueba monocapa de las RSP o los SSP multicapa (métodos
de prueba insertada)
En los métodos de prueba monocapa insertada, la prueba se especifica para una sola capa dentro de una RSP multicapa, incluyendo la especificación de la actividad del protocolo en las capas por encima de la que se está probando, pero sin especificar control u observación en las fronteras del servicio dentro de la RSP multicapa. Por tanto, en una prueba abstracta de una RSP multicapa de la capa (N) a la (Ns), los casos de prueba abstracta para probar la capa (Nj) deberán incluir la especificación de las UDP en capas (Nj + 1) a (Ns) así como las de la capa (Nj).
El método de prueba local monocapa insertada (LMOI) utiliza los mismos puntos de control y observación que el método de prueba LMU para el mismo conjunto de capas. Los sucesos de prueba se especificarán también en los mismos términos que para el método de prueba LMU. La diferencia es que el método de prueba LMOI actúa sobre una sola capa en cada momento, en tanto que el método de prueba LMU prueba la RSP multicapa en su conjunto.
En el método de prueba distribuida monocapa insertada (DMOI) para la capa (Nj) dentro de una RSP multicapa de la capa (N) a la (Ns), los puntos de observación y control están en la frontera del servicio encima de la RSP y encima del proveedor de servicio (Nj - 1) en el PAS distante de la RSP, como se ilustra en la figura 9a)/X.290, parte 2. Los sucesos de prueba se especificarán en términos de PSA(Ns), y las PLA encima de la RSP y de las PSAÑ(Nj - 1) y UDP(Nj) a (Ns) distantes.
Nota
- Para la capa superior en la RSP multicapa,
(Ns), este método es el mismo que en el método de prueba DMO.
El método de prueba coordinada monocapa insertada (CMOI) utiliza características de los dos métodos de prueba CMO y DMOI. Los sucesos de prueba serán especificados en términos de las PSAÑ(Nj - 1), las UDP (Nj) a (Ns) y las UDP-GP, y el protocolo de gestión de pruebas se diseñará para que funcione encima del servicio (Ns). Esto se ilustra en la figura 9b)/X.290, parte 2.
El método de prueba distante monocapa insertada (RMOI) utiliza el mismo punto de control y observación que el método de prueba RMO para la misma capa, pero difiere de este último método en que deben especificarse las UDP(Nj + 1) a (Ns) en los casos de prueba para la capa (Nj).
La utilización sucesiva de un método de prueba monocapa insertada [de la capa (N) a (Ns)] se denomina prueba incremental de una RSP multicapa.
Los métodos de prueba DMOI/CMOI/RMOI se definen para una sola capa sometida a prueba en una RSP multicapa. Esto no significa que no puedan estar accesibles fronteras del servicio dentro de la RSP multicapa, sino simplemente que no se utilizan esas fronteras en los métodos de prueba. Así, deberá considerarse que todas las capas entre la capa sometida a prueba y la capa superior, para las cuales las UDP se expresen como sucesos de prueba en la serie de pruebas abstractas, forman parte de la RSP multicapa.
Nota
- Teóricamente, podrían definirse métodos de
prueba DMUI/CMUI/RMUI para probar cierto número de capas, en su conjunto,
dentro de una RSP formada por un número mayor de capas, pero a fin de evitar
una complejidad excesiva, no se tratan detalladamente en esta Recomendación.
Figura 9/X.290, parte 2, (N), p.
12.6
Métodos de prueba de relevo
Hay dos métodos de prueba abstracta para probar los sistemas de relevo:
a)El método de prueba en bucle (YL): utilizado para probar un sistema de relevo desde una subred.
Este método se ilustra en la figura 10/X.290, parte 2.
Para este método de prueba hay puntos de observación y control en una subred en puntos PAS distantes del relevo (N). En el caso de los protocolos con conexión, es necesario que las dos conexiones de prueba se conecten en bucle en el lado distante del relevo (N), pero se especifica si esta conexión en bucle se efectúa dentro del relevo (N) o en la segunda subred. Para los protocolos sin conexión, es necesario que las UDP sean devueltas en bucle dentro de la segunda subred y direccionadas para que regresen al segundo punto de control y observación.
b)El método de prueba transversal (YT): utilizado para probar un sistema de relevo desde dos subredes.
Este método de prueba se ilustra en la figura 11/X.290, parte 2.
En este método de prueba hay dos puntos de control y observación, uno en cada subred, en los puntos PAS distantes del relevo (N).
Figura 10/X.290, parte 2, (N), p.
Figura 11/X.290, parte 2, (N), p.
12.7
Elección del método de prueba
12.7.1
Introducción
Antes de definir una serie de pruebas abstractas es necesario estudiar todos los entornos probables de prueba del protocolo y establecer en consecuencia el(los) método(s) de prueba que han de utilizarse para la elaboración de una o más series de pruebas abstractas.
Los especificadores de series de pruebas abstractas se guiarán por la Recomendación* sobre series de pruebas abstractas que defina los métodos de prueba abstracta que deberán ser permitidos, como mínimo, por una organización que anuncie la prestación de un servicio de pruebas globales para los protocolos en cuestión.
12.7.2
Entornos de la RSP
Existe una relación entre los métodos de prueba y las configuraciones de los sistemas abiertos reales que han de probarse.
En el 7.2 de la parte 1 de esta Recomendación se presenta una exposición completa de la clasificación de los sistemas y las RSP.
Cuando se vaya a elegir un método de prueba, los especificadores de series de pruebas deben determinar, si no lo han hecho ya antes, si las series de pruebas que tienen el propósito de elaborar son para las RSP que:
a)comprenden una o varias capas;
b)pertenecen a sistemas finales o de relevo;
c)pertenecen a sistemas totales o parciales;
d)pertenecen a sistemas abiertos o mixtos;
e)tienen fronteras de servicio accesibles o inaccesibles;
f)son sistemas de propósito especial (es decir, una sola aplicación) o de propósito general (es decir, destinados a varias aplicaciones).
12.7.3
Posibilidades de aplicación de los métodos de prueba
abstracta
La posibilidad de elaborar una serie de pruebas abstractas para un determinado método de prueba dependerá de los protocolos que se consideren, así como de los resultados del estudio descrito en el 12.7.2 . Esto se aplica a la posibilidad de establecer series de pruebas para una determinada combinación de métodos (por ejemplo, métodos de prueba incremental) o una variante dada de un método (por ejemplo, una prueba insertada).
En el apéndice I a la parte 1 de esta Recomendación se hacen algunas consideraciones sobre las posibilidades de aplicación de los métodos a las diferentes capas.
Deberán seleccionarse uno o más métodos adecuados de prueba abstracta para el protocolo considerado.
Deben asignarse prioridades a los diversos métodos de prueba que se han identificado, de acuerdo con las configuraciones que se encuentren con mayor frecuencia en los sistemas reales.
12.7.4
Ejemplo ilustrativo
En el apéndice III se presenta un ejemplo ilustrativo de la elección de los métodos de prueba abstracta para determinados protocolos.
12.8
Procedimientos de coordinación de pruebas
Para una ejecución eficaz y fiable de las pruebas de conformidad es necesario establecer algún conjunto de normas para la coordinación del proceso de prueba entre el probador inferior y el probador superior. El objetivo general de estas normas es permitir que el probador inferior controle a distancia la operación del probador superior, o a la inversa, como sea necesario para aplicar la serie de pruebas seleccionadas para la RSP.
Estas normas conducen a la elaboración de procedimientos de coordinación de pruebas para asegurar la sincronización entre el probador inferior y el probador superior y la gestión de la información intercambiada durante el proceso de prueba. Los detalles y la manera de obtener estos efectos están estrechamente relacionados con las características del SSP, así como de los métodos de prueba externa.
Para cada serie de pruebas abstractas utilizando los métodos de prueba coordinada, distribuida o local, debe establecerse un conjunto de procedimientos de coordinación de pruebas. La razón para ello es que estos procedimientos dependen de la funcionalidad del probador superior y de las definiciones de los casos de prueba.
En el caso de métodos de pruebas coordinadas (CMO, CMOI, CMU), los procedimientos de coordinación de pruebas se realizan mediante la normalización de un protocolo de gestión de pruebas. El protocolo de gestión de pruebas deberá poder transportar peticiones a la RSP para obtener el efecto de una primitiva de servicio o PLA, y transportar en retorno, al probador inferior, el registro de observaciones de efectos equivalentes a la aparición de primitivas de servicio o PLA. El probador superior debe ser una realización del protocolo de gestión de pruebas. Será necesario añadir casos de prueba a la serie de pruebas abstractas con el fin de verificar que el probador superior cumple los requisitos de la especificación del protocolo de gestión de pruebas. Esos casos de prueba no contribuyen a la evaluación de conformidad de la RSP.
Cuando se definan casos de prueba para métodos de prueba local y de prueba distribuida, el especificador de series de pruebas deberá registrar todas las limitaciones del probador superior y/o a los procedimientos de coordinación de pruebas que sean necesarias.
13 Especificación de series de pruebas
abstractas
13.1
Casos de prueba
13.1.1El especificador de series de pruebas abstractas seleccionará una notación normalizada apropiada para su uso en los casos de prueba abstracta. Para esta finalidad se ha creado la notación combinada tabular y de árbol (NCTA), cuya definición figura en el anexo D.
13.1.2Una vez elegidos la notación de prueba y el método de prueba, los casos de prueba genérica podrán ampliarse a casos de prueba abstracta. Para convertir un caso de prueba genérica en un caso de prueba abstracta hay que hacer dos modificaciones principales. La primera consiste en expresar el cuerpo de prueba en términos del control y la observación requeridos por el método de prueba y, si procede, incluir una descripción de la sincronización que se necesita entre los probadores superior e inferior. La segunda consiste en especificar el preámbulo y el epílogo.
13.1.3La especificación de preámbulos y epílogos puede dar lugar a varios
pasos de prueba para cada una. El preámbulo comenzará en un estado estable y
progresará hacia el estado deseado. A la inversa, el epílogo se desplazará del
estado final del cuerpo de prueba al estado estable. Se definirá un pequeño
número de estados estables para el protocolo en cuestión entre los cuales
deberá existir, como mínimo, el estado
`reposo'
. Cada estado de prueba
abstracta deberá poder ser operado independientemente, por lo cual incluirá
pasos de prueba para comenzar el preámbulo a partir del estado
`reposo'
y terminar el epílogo en el estado
`reposo'
.
Sin embargo, otros estados estables iniciales y finales para un caso de prueba abstracta pueden ser útiles cuando se necesite una concatenación eficaz de los casos de prueba abstracta.
Además, al diseñar la estructura del paso de prueba en el contexto de los casos de prueba abstracta, el especificador de series de pruebas puede servirse del recurso que consiste en utilizar los mismos pasos de prueba en varios casos de prueba abstracta.
13.1.4En la conversión de casos de prueba genérica en casos de prueba abstracta, el especificador de series de pruebas deberá asegurar que se mantendrá el estado inicial para el cuerpo de prueba, que se mantendrán los trayectos a través del cuerpo de prueba y que se mantendrá la coherencia en la asignación de veredictos a resultados.
A fin de mantener la coherencia en la asignación de veredictos a resultados se cumplirán los siguientes requisitos condicionales:
a)si el comportamiento del preámbulo y el comportamiento del epílogo son válidos, el veredicto asignado a un resultado dado será el mismo que el asignado al resultado correspondiente en el caso de prueba genérica;
b)si como resultado del preámbulo no se alcanza el estado inicial del cuerpo
de prueba, aunque no haya un comportamiento inválido, el veredicto deberá ser
`dudoso'
;
c)si como resultado del preámbulo no se alcanza el estado inicial del cuerpo
de prueba, debido a un comportamiento inválido, el veredicto deberá ser
`desfavorable, pero propósito de prueba dudoso'
(
`desfavorable de
tipo 3'
);
d)si el epílogo presenta un comportamiento inválido y el veredicto de caso
de prueba genérica (o de cuerpo de prueba) es
`favorable'
o
`dudoso'
, el veredicto deberá ser
`desfavorable, pero propósito de
prueba alcanzado'
(
`desfavorable de tipo 2'
) o
`desfavorable pero
propósito de prueba dudoso'
(
`desfavorable de tipo 3'
),
respectivamente;
e)si el veredicto de caso de prueba genérica (o de cuerpo de prueba) es
`desfavorable'
, el comportamiento inválido en el preámbulo no cambiará
el veredicto (
`desfavorable de tipo 1'
).
13.1.5El especificador de series de pruebas asegurará también que cada caso
de prueba abstracta identifique explícitamente todos los resultados asignados
al veredicto
`favorable'
e identifique o categorice todos los demás
resultados previstos, asignando a cada uno de los resultados o categorías un
veredicto
`favorable'
o
`dudoso'
. A todos los resultados
imprevistos en la prueba se le asignará:
a)el veredicto
`desfavorable'
, o bien;
b)el veredicto
`dudoso'
.
El especificador de series de prueba asegurará que la aplicación de a) o b)
sea coherente en toda la serie de pruebas abstractas. Si se elige a), a todo
resultado imprevisto en el preámbulo se le asignará el veredicto
`desfavorable pero propósito de prueba dudoso'
(
`desfavorable de tipo
3'
), y todo resultado imprevisto en el epílogo se tratará como una
violación de protocolo, conducente al tipo apropiado de veredicto desfavorable.
Si se elige b), a todo resultado imprevisto en el preámbulo se le asignará
el veredicto
`desfavorable pero propósito de prueba dudoso'
(
`desfavorable de tipo 3'
), y a todo resultado imprevisto en el
preámbulo se le asignará el tipo apropiado de veredicto desfavorable.
13.2
Series de pruebas
Una especificación de serie de pruebas abstractas comprende un conjunto de casos de prueba y de pasos de prueba. Los casos de prueba deberán ir precedidos de la siguiente información:
a)nombre de la serie de pruebas abstractas, fecha de origen y número de versión;
b)nombres (y números de versión) de la Recomendación* o las Recomendaciones* sobre protocolo para las cuales se proporcionan casos de prueba;
c)nombre (y números de versión) de la Recomendación* o las Recomendaciones* de servicio cuyas primitivas son observadas según la especificación;
d)nombre (y número de versión) de la Recomendación* que define la notación de prueba, o una referencia a un anexo, para dicha notación, si no está normalizada en otra parte;
e)nombre del método de prueba deseado;
f)descripción de la cobertura de la serie de pruebas, por ejemplo, los subconjuntos funcionales de las Recomendaciones* de protocolo que se prueban;
g)descripción de la estructura de la serie de pruebas, mediante los grupos de prueba y su relación con Recomendaciones* de protocolo;
h)descripción de los procedimientos de coordinación de pruebas (si es aplicable en el método de prueba);
i)enunciado de los casos de prueba que son facultativos y los que son obligatorios para la conformidad con la Recomendación* sobre series de pruebas abstractas;
j)información para ayudar al realizador de las pruebas y al laboratorio de pruebas a aplicar la Recomendación* sobre series de pruebas abstractas (véase el 14 ).
14 Utilización de una especificación de
serie de pruebas abstractas
El especificador de series de pruebas abstractas proporcionará información en la Recomendación* sobre series de pruebas abstractas para ayudar al realizador de pruebas y al laboratorio de pruebas en la utilización de la serie de pruebas. Esta información incluirá, pero no estará limitada, a lo siguiente:
a)una correspondencia de los casos de prueba abstracta con los registros de la proforma del ECRP para determinar si el caso de prueba abstracta debe o no seleccionarse para una RSP dada; la correspondencia debe especificarse en una notación adecuada para expresiones booleanas;
b)una correspondencia de los casos de prueba abstracta con los registros de la proforma de ISRPP, en la medida en que son conocidos por el especificador de series de pruebas abstractas, a fin de parametrizar la serie de pruebas para la RSP en cuestión y determinar qué casos de prueba seleccionados no pueden funcionar con la RSP en cuestión;
El especificador de series de pruebas definirá una proforma de ISRPP parcial. Esta contendrá una lista de todas las PLA utilizadas en la serie de pruebas (o en el protocolo de gestión de pruebas) y una lista de todos los parámetros para los cuales la serie de pruebas requiere valores. Si cualquiera de los valores requeridos de los parámetros se encontrara en el ECRP, el registro de la proforma del ISRPP para cada uno de esos parámetros hará referencia al registro correspondiente en la proforma del ECRP;
Nota
- Deberán estudiarse ulteriormente otros aspectos
de la proforma del ISRPP;
c)una lista de los casos de prueba abstracta en el orden en que serán utilizados en el informe de prueba de conformidad de protocolo (IPCP), así como toda información que deba preservarse en el IPCP sobre el estado de cada caso de prueba; ésta es una contribución a la elaboración de una proforma del IPCP;
d)toda posible limitación del orden en que podrán ejecutarse los casos de prueba;
e)referencia a la descripción de los procedimientos de coordinación de pruebas (si son aplicables en el método de prueba elegido);
f)toda información necesaria sobre temporización.
15 Mantenimiento de series de pruebas
Una vez que está especificada y se está utilizando una serie de pruebas abstractas, cabe esperar que quienes la utilicen detecten errores y omisiones en la misma. El especificador de series de pruebas abstractas deberá, en tales circunstancias, avanzar en la actualización de la serie de pruebas utilizando para ello los procedimientos pertinentes para enmiendas rápidas.
Además, cada cierto tiempo se efectuarán cambios en las Recomendaciones* sobre protocolos con las cuales se relaciona la serie de pruebas. El especificador de series de pruebas abstractas asegurará que la serie de pruebas será actualizada lo más pronto posible después que se hayan ratificado los cambios de la Recomendación* pertinente sobre protocolos.
ANEXO A (a la Recomendación X.290, parte 2)
Opciones
A.1 Opciones son los puntos de una Recomendación* con relación a los cuales el
realizador puede elegir el que conviene a la realización.
A.2 Esta elección no es verdaderamente libre. Hay requisitos que especifican las condiciones en que se aplica la opción, y limitaciones de la elección.
A la inversa, en una Recomendación* puede haber requisitos obligatorios o condicionales, o prohibiciones, que dependen de la opción o combinación de opciones ya elegidas.
A.3 A continuación se presentan algunos ejemplos de opciones y requisitos asociados; la lista no es exhaustiva:
a)
Opciones
`booleanas'
:
^ la opción es
`hacer
o no hacer'
; el requisito es
`si se hace, entonces hacerlo como se
especifica'
.
b)
Opciones mutuamente exclusivas:
^ el requisito es
hacer solamente una de
n
acciones; la opción consiste en
determinar cuál de ellas se hace.
c)
Opciones seleccionables:
^ la opción consiste en hacer
cualesquiera
m
^ acciones de entre
n
^
acciones; el requisito es hacer por lo menos una acción (1
m n
y
n
2).
A.4 Las opciones pueden aplicarse a todo lo que se encuentre dentro del objeto de una Recomendación* (por ejemplo, aspectos estáticos o dinámicos, uso o prestación de un servicio, acciones a ejecutar, presencia»ausencia o forma de parámetros, etc.).
A.5 También se distingue entre opciones de usuario del servicio y opciones de proveedor del servicio.
A.6 En un contexto más amplio, la elección vendrá determinada por condiciones que se encuentran fuera del ámbito de la Recomendación* [por ejemplo otras Recomendaciones* que se aplican a la realización, los protocolos utilizados en las capas (N + 1) y (N - 1), la aplicación deseada, condiciones de suministro, precio deseado para la realización, etc.]. Sin embargo, estas condiciones no influyen en forma alguna en la conformidad con la Recomendación* en que aparece la opción.
NF01/009 = OPM: 01 A NF01/018 = OMP: 01 ?OTHERWISE[x=2] NF01/053 = OPM: 01 A NF01/053 = OPM: 01 => NF01/053 = OPM: 01 (cs,) - (cs,) NF01/022
(1BT) (BT..)
(85.TE.15.S)
(A1.23f) / [26f]
FOLIOS: 530 - 559
(DO PRC.COSY.2)
MEP {TPS.NON.PHOTO "[PA1]"} : OK= [1]
Saisie 10.03.89 CV
ID + LASER 16.03.89 SJ/CW
MAJ diskette 04.04.89 CW
Corr. LASER (1re épreuve) = 3eme 11.04.89 GG
AJOUTER (PA1) (CL1,0,0,0) pour MEP
Inséré ER 13.04.89 PM
MEP + LASER 17.04.89 GH/ZR
Corr. MEP ........ ..
Insertion des tableaux (tabulateurs...) ........ ..
BAT 2.05.89 PM
Ultimes 23.05.89 DD
MAJ DISKETTE ........ ..
ANEXO B (a la Recomendación X.290, Parte 2)
Guía para la
redacción de Recomendaciones* sobre protocolos con objeto de
facilitar las pruebas de conformidad
B.1
Introducción
Este anexo ofrece información de orientación, destinada esencialmente a los especificadores de nuevas Recomendaciones* sobre protocolos para facilitar las pruebas de conformidad, asegurando una clara comprensión de los requisitos de conformidad.
B.2
Orientación sobre el objeto y el campo de
aplicación
B.2.1 La precisión en los apartados relativos al objeto y al campo de aplicación es de importancia fundamental para la precisión del resto de la Recomendación*. Los requisitos expresados en la Recomendación* deben ser coherentes con el objeto y el campo de aplicación, y viceversa.
B.2.2 El objeto debe distinguir claramente entre los tres tipos siguientes de la información incluida en la Recomendación* sobre protocolos.
a)la definición de los procedimientos para comunicación, que han de seguirse cuado se efectúa una comunicación;
b)los requisitos que deben cumplir los suministradores de realizaciones de los procedimientos;
c)orientación sobre la manera de establecer los procedimientos.
La orientación sobre la manera de establecer los procedimientos no entraña requisitos adicionales ni produce efecto alguno sobre la conformidad. Si se incluye esa información de orientación, deberán precisarse en el objeto todos estos detalles, e indicarse cómo habrá que distinguir entre la orientación y los requisitos de la Recomendación*. Esta distinción será mucho más fácil si la orientación se presenta separadamente de los requisitos. El método recomendado para tal separación en las directrices de la ISO (ISO Directives) es el de presentar la información de orientación en notas y anexos.
B.2.3 Debe expresarse claramente a quiénes se aplica la Recomendación*.
B.2.4 Debe expresarse claramente en qué momento se aplica la Recomendación*.
Los procedimientos de protocolo se aplican entre pares de partes comunicantes en el curso de una comunicación. Si hubiese alguna ambigüedad en cuanto a cuáles son las partes comunicantes, dicha ambigüedad debe resolverse en el objeto.
Lo más adecuado es que las Recomendaciones* de protocolo se redacten de tal
manera que los requisitos deban ser cumplidos por una sola parte comunicante
(la
`primera'
parte comunicante para este propósito) en beneficio de una
o varias otras partes comunicantes (las
`segundas'
partes comunicantes).
De esta forma, cuando se prevea que dos (o más) partes comunicantes comuniquen
de conformidad con la Recomendación*, la Recomendación* se aplica primero a una
parte, que se tratará como la
`primera'
, y después se aplicará a la otra
u otras partes por su turno. Con esto se garantiza que si se produce una
violación de los procedimientos, se sabrá exactamente la parte que la provocó.
B.2.5 Si se da alguna orientación sobre factores que no están normalizados definitivamente, deberá indicarse claramente en el objeto que toda información referente a los mismos puede pasarse por alto sin que ello afecte a la conformidad.
B.2.6 Deben señalarse claramente los aspectos que no sean tratados en el objeto.
No todos los factores aplicables a los procedimientos o a los productos que los aplican tienen que estar normalizados; en realidad, a veces conviene dejar cierta libertad al realizador. Por ejemplo, puede ser conveniente omitir en una Recomendación* sobre protocolo todo requisito relativo a valores explícitos de temporizaciones, y dar en su lugar una orientación.
En el objeto se deben precisar los aspectos que son normalizados definitivamente, los aspectos que se tratan por medio de una información de orientación sin que esta entrañe requisitos, y los aspectos que no son absolutamente tratados por la Recomendación*. Todos los aspectos con relación a los cuales pudiera pensarse que estarían tratados, por estar estrechamente relacionados con aspectos que están normalizados, deberán indicarse explícitamente.
B.2.7 De ser posible, todas las opciones deberán identificarse claramente en el objeto.
Las opciones son uno de los puntos que más problemas plantean en las
Recomendaciones* sobre protocolos, pero desgraciadamente son necesarias. Se
sitúan en un campo intermedio entre lo normalizado y lo no normalizado. Se
tratarán con mayor profundidad más adelante. Con respecto a este punto, es
importante que las opciones no estén
`ocultas'
entre las numerosas
disposiciones de una Recomendación*, sino que estén diáfanamente declaradas al
principio. Si el número de las opciones, y su naturaleza detallada, impide
proceder de esta manera, será necesario plantearse seriamente la cuestión de si
es necesaria realmente tal complejidad. ³Es posible agrupar las opciones
detalladas de cierta manera (por ejemplo, en clases) para simplificar la
Recomendación*?
B.2.8 El objeto y el campo de aplicación deben revisarse después de considerar el resto de la Recomendación*
A menudo, no es posible dar cumplimiento a algunas de las sugerencias mencionadas antes de que se haya considerado el resto de la Recomendación*. Por eso, generalmente es necesario regresar al objeto y verificar que concuerda realmente con el contenido de la Recomendación*. Es corriente, al examinar este contenido, encontrarse excepciones que están evidentemente fuera del objeto de la Recomendación*.
B.3
Orientación sobre referencias
B.3.1 Las Recomendaciones* sobre protocolos ISA deben estar referidas al modelo de referencia ISA, a las Recomendaciones* pertinentes sobre los servicios, y a toda otra Recomendación* pertinente sobre convenios relativos a los protocolos, directrices o técnicas de descripción formal.
B.3.2 Debe precisarse con claridad si la conformidad con la Recomendación* sobre protocolos exige la conformidad con cualquier parte de cualquier otra Recomendación*.
B.3.3 Debe expresarse claramente con respecto a cada referencia si ésta se hace a una versión particular de la Recomendación* o a cada una de las versiones sucesivas.
Normalmente se requiere la versión más reciente, pero esto puede dar lugar a problemas, pues las modificaciones de la Recomendación* anterior podrían afectar a la conformidad con la Recomendación* m as reciente.
B.4
Orientaciones sobre requisitos y opciones
B.4.1 El status de cada requisito debe ser inequívoco.
Puesto que los requisitos facultativos y los condicionales son tan usuales, existe una tendencia a considerar facultativo todo lo que pueda interpretarse como facultativo.
B.4.2 Una situación de comunicación deberá poder ser conforme con todos los requisitos obligatorios de la conformidad dinámica.
B.4.3 Deberán indicarse con claridad las condiciones en las cuales son aplicables requisitos condicionales.
B.4.4 No debe ser imposible para el realizador o suministrador saber cuáles son estas condiciones.
B.4.5 No debe haber posibilidad de confusión entre lo que es dinámicamente opcional y lo que es estáticamente opcional.
Puede haber requisitos obligatorios de conformidad estática para proporcionar características cuyo uso es facultativo durante la comunicación. A la inversa, un mensaje cuyo uso es obligatorio en un contexto dado durante la comunicación puede formar parte de un mecanismo de protocolo cuyo soporte es estáticamente facultativo.
B.4.6 Si la Recomendación* contiene una
`lista de comprobación'
de
opciones, y están limitadas las combinaciones permitidas de esas opciones,
deberán especificarse claramente las limitaciones. éstas deberán contener la
identificación de toda exclusión mutua y de todo límite mínimo y máximo a la
gama autorizada de opciones.
B.4.7 Si la Recomendación* no contiene ninguna norma para la selección de opciones, deberán aclararse en el objeto que sólo están normalizadas la gama total y las opciones individuales, y no la selección.
B.4.8 Deben evitarse las opciones legitimantes. Por opciones legitimantes se entiende aquellas que permiten que versiones alternativas e incompatibles de una misma entidad anuncien conformidad con la misma Recomendación*. Si bien esas opciones no impiden, por si mismas, una comprensión objetiva de la conformidad, pueden no obstante entrañar el fracaso de los fines de la ISA.
B.4.9 No debe haber opciones que permitan al realizador ignorar requisitos importantes de la Recomendación*. Tales opciones van en detrimento de la Recomendación* y del significado de la conformidad con la misma.
B.4.10 Si en la Recomendación* hay prohibiciones, deberán ser lo suficientemente precisas para que tengan sentido.
Muchas Recomendaciones* tienen secciones que dicen, en efecto,
`hacer
todo esto y nada que no sea esto'
. Tales prohibiciones pueden no tener
sentido, pues todo protocolo contiene alguna información que no está
normalizada, los denominados
`datos de usuario'
y todo producto
normalizado tiene atributos que no están normalizados, por ejemplo, el peso.
Puede ser difícil establecer una línea divisoria objetiva y clara entre aquello
que la Recomendación* no puede prohibir y lo que los redactores de la
Recomendación* desean prohibir, a menos que las prohibiciones se indiquen
explícitamente.
B.5
Orientación sobre las unidades de datos de
protocolo
B.5.1 Debe expresarse claramente el conjunto permitido de tipos y codificaciones de parámetros de unidades de datos de protocolo (UDP).
B.5.2 Debe indicarse expresamente la gama permitida de valores para cada parámetro.
B.5.3 Deberá indicarse expresamente que no son inválidos todos los valores no comprendidos en la gama permitida.
Si no se hace esto, algunas personas sostendrán que esos valores no están definidos pero sí están autorizados, en tanto que otras considerarán que dichos valores no son válidos.
B.5.4 Deberá indicarse claramente si están autorizados los tipos de UDP no definidos.
Es más seguro que todos los tipos UDP no definidos estén declarados como no válidos.
B.5.5 En el objeto deben indicarse claramente los valores críticos no definidos como valores no definidos.
B.5.6 Debe existir un procedimiento definido que aplique la primera parte comunicante cada vez que reciba un paramétro de UDP no válido o no definido.
B.5.7 Deberá ser posible determinar si se ha seguido o no en tales casos el procedimiento definido. Si esto no es posible, deberá ser porque ello no tiene importancia.
Algunas veces, el procedimiento a seguir cuando se recibe una UDP inválida es, intencionalmente, el mismo que cuando se reciben algunas UDP válidas en las mismas circunstancias. Por ejemplo, el procedimiento podría ser no hacer nada hasta que se reciba un tipo específico de UDP, ignorándose todo lo demás. En tales casos, probablemente no importe que el error aparentemente haya pasado sin ser detectado. En otros casos, la intención puede ser que se dé un tratamiento especial a los casos de error, considerándose que el procedimiento no ha sido correcto elegido, con el resultado de que no puede distinguirse de la acción realizada en casos de inexistencia de error.
B.5.8 Si, en la codificación de las UDP, hay algunos campos declarados como reservados, debe haber una indicación clara de los valores (si existen) que están autorizados y de los que no están autorizados en estos campos.
B.5.9 Si, en UDP distintas pueden transportarse parámetros interrelacionados, el conjunto de relaciones permitidas entre los valores de estos parámetros debe definirse con precisión y claridad.
B.5.10 Si la codificación de parámetros permite especificar los parámetros en cualquier orden y el formato de las UDP impone restricciones a los órdenes permitidos, deberán indicarse claramente estas restricciones. Debe reconocerse que si se permiten muchos órdenes diferentes, deberá probarse una muestra representativa amplia de los diferentes órdenes. La mayor complejidad de la prueba de conformidad deberá por tanto quedar adecuadamente compensada por la cierta ventaja que representa el permitir esta libertad.
B.5.11 Deberá indicarse claramente el orden en que los bits, octetos, etc. deben ser transportados en el protocolo subyacente.
Por ejemplo, en el caso de un entero formado por dos octetos, ³cuál debe transmitirse primero, el más significativo o el menos significativo? Es sorprendente la frecuencia con que pasan inadvertidas estas simples causas de ambigüedad.
B.5.12 Deberá definirse claramente la relación entre las UDS y las UDP.
B.6
Orientación sobre los estados
B.6.1 Los procedimientos de protocolo suelen definirse utilizando un método, formalizado o no, basado en un número finito de estados. La especificación de estos estados está incompleta en muchas ocasiones.
B.6.2 Cada estado debe definirse con claridad.
B.6.3 Si existen sucesos que sólo pueden producirse en un subconjunto de posibles estados, debe distinguirse entre la posible ocurrencia de un suceso y su ocurrencia válida.
B.6.4 Deben definirse para cada posible par estado/suceso las acciones requeridas y las transiciones de estados. En particular, deben definirse en base pares estado/suceso posibles, aunque no válidos.
B.7
Orientación sobre las técnicas de descripción
formal
B.7.1 Los requisitos que siguen sólo son aplicables a las Recomendaciones* que incluyen una descripción formal. Es posible redactar Recomendaciones* precisas e inequívocas sin el auxilio de una técnica de descripción formal (TDF), pero en Recomendaciones* complejas, como son las relativas a protocolos, se recomienda encarecidamente la utilización de descripciones formales. No obstante, deberá tenerse en cuenta que las descripciones formales pueden, por sí mismas, plantear problemas en relación con la conformidad.
B.7.2 Deberá indicarse claramente si la descripción formal es una parte esencial de la Recomendación* o se presenta solamente como orientación.
Es sumamente importante tener una idea precisa del status de la descripción formal. Idealmente, no debe haber diferencias entre el texto y la descripción formal, pero, dado que esto es muy difícil de alcanzar en la práctica, es importante que el lector sepa cuál de las dos descripciones tiene prioridad. Si la descripción formal se ha proporcionado solamente para orientación, no puede definir requisitos de conformidad.
B.7.3 La TDF debe estar correctamente definida, y referenciada, y ser estable.
B.7.4 Si la descripción formal define varios, pero no todos los requisitos de la Recomendación*, deberá indicarse claramente, en tal situación, que el texto incluye requisitos que no están cubiertos por la descripción formal, y deberán identificarse claramente esos requisitos adicionales.
B.7.5 Si la descripción formal define requisitos, y define también un modo autorizado de realizar algunos aspectos del protocolo, pero existe la intención de dejar al realizador cierto grado de libertad para establecer esos aspectos de otra manera, tal situación constituye lo que se ha denominado un sobre-definición. Esto es relativamente corriente en las descripciones formales, y crea dificultades en relación con la conformidad. Si la descripción formal es una parte esencial de la Recomendación*, debe proporcionarse el texto, para calificarla, indicando dónde existe tal sobre-definición y cuáles son los requisitos reales.
El problema suele plantearse por el hecho de que la descripción formal describe el comportamiento interno de una realización idealizada, y no el comportamiento externo observable requerido. Sin embargo, el único comportamiento que puede probarse es el comportamiento observable externo y, por tanto, es el que hay que tener en cuenta a los fines de los requisitos de conformidad. Puede muy bien darse el caso de que para definir los requisitos se utilice una TDF diferente de la empleada para proporcionar orientación a los realizadores.
B.8
Orientaciones diversas
B.8.1Existen informaciones que, aunque parezcan evidentes, deben no obstante indicarse.
Si se omite algo que es
`obvio'
, algunos lectores supondrán que eso
se requiere porque es
`obvio'
, en tanto que otras supondrán que se ha
omitido para dar libertad a los realizadores. Por ejemplo, ³implica la
existencia de una suma de control que dicha suma deba ser verificada?
ANEXO C (a la Recomendación X.290, Parte 2)
Requisitos de
conformidad estática incompletos
C.1Como asunto de orden histórico, la
elaboración de Recomendaciones* sobre protocolos se ha emprendido en paralelo
con la determinación del significado de conformidad, y en particular con la
comprensión de la distinción entre conformidad estática y dinámica.
C.2En consecuencia, algunas Recomendaciones* iniciales sobre protocolos no dan una especificación completa de los requisitos de conformidad estática. Un ejemplo típico de tal situación es la exigencia de admitir una función particular sin indicar si esto se aplica a la emisión, la recepción o a ambas, o la ausencia de condiciones precisas de detección de errores de protocolo en mensajes entrantes recibidos.
C.3 Por consiguiente, puede haber diferentes interpretaciones de lo que es una realización conforme.
C.4 En futuras Recomendaciones* o cuando las Recomendaciones* existentes sean revisadas, será necesario proporcionar una especificación íntegra de los requisitos de conformidad estática. Esta incluiría la especificación de condiciones aplicables a la realización o no realización de todo aquello que no es, ni siempre obligatorio, ni siempre facultativo.
C.5 A corto plazo, es esencial que, como mínimo, los proyectos en curso se modifiquen para aclarar la presente situación; no se considera aceptable que deban redactarse Recomendaciones* en una forma en que los requisitos de realización sean ambiguos. También es necesario considerar lo que deberá hacerse cuando los protocolos hayan alcanzado ya el estado de norma internacional ISO o Recomendaciones del CCITT.
C.6 No se ve otra solución a corto plazo que aceptar y enunciar claramente que todas las capacidades no contempladas explícitamente por los requisitos de conformidad estática son facultativas, y minimizar los problemas potenciales que esto pueda causar especificando que:
a)sólo las realizaciones que
1)apliquen todo lo que esté explicítamente especificado como obligatorio; y
2)no omitan nada, a menos que explícitamente se indique que ello es
facultativo, aunque haya una causa general de tipo
`si no está especificado,
es facultativo'
;
deberán designarse como
`conformes'
sin calificación;
b)toda realización que
1)aplique todo lo que está explícitamente especificado como obligatorio; y
2)omita aspectos que no estén enunciados explícitamente como facultativos,
debido tal vez a una causa general de tipo
`si no está especificado, es
facultativo'
;
se describirá como conforme a un subconjunto.
C.7Las realizaciones que omitan cualquier aspecto que sea obligatorio no son conformes, en modo alguno.
Nota
- Un sistema conforme sin calificación no
interfuncionará necesariamente con otro sistema, ni funcionará necesariamente
mejor que un sitema conforme a un subconjunto. El sistema
`perfecto'
puede rechazar UDP recibidas, de otros sistemas por considerarlas incorrectas o
incompletas. Así podrá rechazar o abortar conexiones.
En consecuencia, debe considerarse especialmente la conformidad con respecto a la detección de errores de protocolo, especialmente cuando esta detección puede ser facultativa explícita o implícitamente.
ANEXO D (a la Recomendación X.290, Parte 2)
Notación combinada
tabular y de árbol
D.0
Introducción
En la preparación de una serie de pruebas abstractas se utiliza una notación de prueba para describir los casos de prueba abstracta. La notación de prueba puede ser una notación informal (sin una semántica definida de una manera precisa) o una @técnica de descripción formal (TDF)\. Este anexo describe una notación informal denominada @notación combinada tabular y de árbol (NCTA).\
La NCTA responde a las siguientes finalidades:
a)proporcionar una referencia común para evaluar otras notaciones de prueba y ayudar al examen de los problemas que plantea el diseño de casos de prueba y de series de pruebas;
b)proporcionar una base para la traducción de casos de prueba a otras notaciones de prueba;
c)facilitar, mediante descripciones de comportamientos con la NCTA, la especificación de casos de prueba y pasos de prueba.
Una serie de pruebas puede considerarse una jerarquía que va, en orden descendente, de la serie completa de pruebas a los sucesos de prueba (véase la parte 1, 8.1 ). La NCTA supone que los tipos básicos de suceso de prueba son primitivas de servicio abstractas (PSA), primitivas locales abstractas (PLA) y sucesos de temporizador.
Los casos de prueba abstracta pueden también expresarse en términos de UDPs (utilizando un mecanismo de abreviación descrito en el Î D.5.11).
D.1
Componentes de una serie de pruebas descrita en la
NCTA
Una serie de pruebas descrita en la NCTA tendrá las cuatro secciones siguientes, en el orden indicado a continuación:
a)Visión de conjunto de la serie de pruebas (Î D.4)
Información necesaria para la presentación general y la comprensión de la serie de pruebas, tal como las referencias de pruebas y una descripción de su finalidad global.
b)Declaraciones (Î D.5)
Se describe el alfabeto de los sucesos que han de utilizarse en la serie de pruebas (por ejemplo, PAS, temporizadores, PSA, UDP, PLA y sus parámetros). En esta sección se presenta la definición de las abreviaturas que se utilizarán en la serie de pruebas.
c)Parte dinámica (Î D.6)
Cuadros que contienen árboles de comportamiento expresados principalmente en términos de la aparición de PSA en puntos de control y observación. Un conjunto de descripciones de comportamiento va seguido de un conjunto de descripciones de comportamiento por defecto.
d)Parte de limitaciones (Î D.8)
Esa sección especifica valores para las PSA, UDP y sus parámetros utilizados en la parte dinámica.
D.2
Forma de sintaxis de la NCTA
La @NCTA se proporciona en una forma gráfica (NCTA-GR)\ que es adecuada para su lectura por una persona.
Nota
- @Una forma informatizada (NCTA-PM)\, adecuada
para la transmisión de descripciones NCTA entre máquinas, y que también podría
utilizarse para otros procesamientos automatizados, será objeto de ulterior
estudio.
D.3
Convenios
D.3.1
Proformas de cuadros
La notación NCTA-GR se define utilizando cierto número de tipos de cuadros diferentes. En la descripción de las plantillas de estos cuadros, se empleará el siguiente convenio:
a)los textos en negrita (
como éste
) deberán aparecer
literalmente en cada cuadro construido;
b)los textos en cursiva (
este tipo de letra
) ^no
aparecerán literalmente. Este tipo de escritura se utiliza para indicar que el
texto en cuestión debe ser reemplazado por el símbolo en cursiva.
Además, dentro de las proformas de cuadro pueden insertarse comentarios en campos no reservados para comentario, delimitándolos por los símbolos /* y */.
D.3.2
Tipos de corchetes
En la figura D-2/X.290, parte 2 se indican los términos que se utilizarán para designar los diversos tipos de corchetes.
Figura D-2/X.290, Parte 2 [T1.290], p. (traiter comme tableau
MEP)
D.3.3
Convenios de denominación
D.3.3.1
Referencias a grupos de pruebas y a casos de
prueba
a)La referencia (nombre) de un grupo de pruebas será de una de las formas indicadas en la figura D-3/X.290, parte 2 e ilustradas en el ejemplo D-2.
Figure D-3/X.290, Parte 2 [T2.290], p. (traiter comme tableau
MEP)
Ejemplo D-2
- Referencia a grupo de transporte.
Transporte/Clase0/Establ-conexión/ b)La referencia (nombre) de un caso de prueba será de una de las formas indicadas en la figura D-4/X.290, parte 2 e ilustradas en el ejemplo D-3.
Figure D-4/X.290, Parte 2 [T3.290], p. (traiter comme tableau
MEP)
Ejemplo D-3
- Referencias a caso de prueba de transporte.
Tansporte/Inic Transporte/Clase0/Establ-Conexión/Inic-PI
c)Las referencias a grupo de pruebas, junto con las referencias a casos de prueba, definen la estructura de la serie de pruebas.
D.3.3.2
Referencias a pasos de prueba
a)Los pasos de prueba se asocian a un punto dado en la estructura de la serie de pruebas, como se define por las referencias de grupo y de caso (véase el Î D.3.3.1).
b)Los pasos de prueba, en su punto de asociación, pueden agruparse en
`bibliotecas'
, organizadas de modo jerárquico.
c)Una referencia de paso tiene entonces la forma siguiente:
(PointOfAttachment)
:
(LibraryStructure)
donde:
1)
(PointOfAttachment)
^es o bien:
A)
(TestSuite)
^ o
B)
(TestGroupReference)
^ definido en el Î D.3.3.1 o
C)
(TestCaseReference)
^ definido en el Î D.3.3.1
2)y
(LibraryStructure)
^ es o bien:
A)
(TestStep)
^ o
B)
(Component
1
)/^.^.^./(Component
n
)/(TestStep)
Ejemplo D-4
- Referencias de pasos de prueba de
transporte.
Transporte:Paso-A Transporte/Clase0/Establ-Conexión/:Paso-B Transporte/Clase0/Establ-Conexión/Inic-PI:Paso-C Transporte:Biblio-Común/Preámbulos/Paso-C
Nota 1
- El símbolo dos puntos (:) en la referencia de
paso de prueba separa la primera parte, que se refiere a un punto en la
estructura de serie de pruebas ya definida, de la segunda parte, que define la
estructura de biblioteca.
Nota 2
- Los componentes permiten agrupar los pasos en
una jerarquía arbitraria dentro de bibliotecas, lo cual no influye sobre la
estructura de la serie de pruebas propiamente dicha.
D.4
Visión de conjunto de la serie de pruebas
Esta sección incluirá al menos la siguiente información:
a)referencia a las normas de base pertinentes;
b)una referencia al ECRP y a la ISRPP y la manera de utilizarlos;
c)una indicación del método o métodos de prueba relacionados con la serie de pruebas;
d)un índice completo de la serie de pruebas, constituido por la referencia de prueba, el identificador de prueba, el número de página y la finalidad de la prueba para cada caso de prueba y paso de prueba en la serie de pruebas. Las finalidades de prueba se organizarán de acuerdo con la estructura de la serie de pruebas.
Deberá incluirse también como comentario cualquier otra información que pueda facilitar la comprensión de la serie de pruebas, por ejemplo el modo en que ha sido derivada.
Esta información se proporcionará en el formato indicado en la figura D-5/X.290, parte 2.
D.5
Declaraciones
La sección sobre declaraciones tiene por finalidad describir el conjunto de sucesos de prueba y todos los demás atributos que se utilizarán en la serie de pruebas. Todos los objetos utilizados en la parte dinámica tendrán que estar declarados en la parte declaraciones. Hay dos clases de sucesos de prueba:
a)primitivas de servicio abstractas (PSA) que ocurren en los puntos de control y observación (PCO) utilizados por el probador (Î D.5.8);
b)sucesos de temporizador (Î D.5.10).
Se especifican también otros atributos:
a)tipos definidos por el usuario (Î D.5.1.3);
b)operadores definidos por el usuario (Î D.5.3);
c)parámetros de serie de pruebas (Î D.5.4);
d)constantes globales (Î D.5.5);
e)variables globales (Î D.5.6);
f)PCO (Î D.5.7);
g)parámetros de PSA (Î D.5.8);
h)tipos de datos (incluidas las UDP y sus parámetros) (Î D.5.9);
i)abreviaturas (Î D.5.11).
Figure D-5/X.290, partie 2 [T4.290],p.4 (traiter comme tableau
MEP)
D.5.1
Tipos generales en la NCTA
La NCTA admite cierto número de tipos y de mecanismos predefinidos que permiten la definición de tipos declarados por el usuario. Estos tipos pueden utilizarse en toda la serie de pruebas y ser referenciados cuando se definen variables, constantes, parámetros PSA, parámetros UDP, o parámetros de serie de pruebas.
D.5.1.1
Tipos predefinidos
Existe cierto número de tipos comúnmente utilizados, predefinidos para su uso en la NCTA. Estos tipos pueden ser referenciados aunque no aparezcan en una declaración de tipo en una serie de pruebas. Todos los demás tipos utilizados en una serie de pruebas tienen que ser designados en declaraciones de tipo por el usuario (de acuerdo con el Î D.5.1.2) y referenciados por un nombre.
a)
tipo predefinido integer (entero
): tipo con valores
distinguidos que son números enteros positivos y negativos, incluyendo el cero
(como valor distinguido simple).
b)
tipo predefinido bitstring (cadenadebits
): tipo cuyos
valores distinguidos son las secuencias ordenadas de cero, uno o más bits.
c)
tipo predefinido octetstring (cadenaoctetos
): tipo
cuyos valores distinguidos son las secuencias ordenadas de cero, uno o más
octetos, cada uno de los cuales es una secuencia ordenada de ocho bits.
d)
tipos predefinidos character string (cadena de
caracteres
): tipos cuyos valores distinguidos son cero, uno o más
caracteres de algún juego de caracteres. Pueden utilizarse los tipos de cadena
de caracteres enumerados en la figura D-6/X.290, parte 2. Se definen en la
sección 2 de la Recomendación X.208.
Figura D-6/X.290, Parte 2 [T5.290], p. (traiter comme tableau
MEP)
e)
tipo predefinido connection endpoint identifier
(identificador de punto extremo de conexión
) (IdEC): tipo
que consiste en un número ilimitado de valores distinguidos.
D.5.1.2
Tipos definidos por el usuario
El usuario de la NCTA puede introducir tipos específicos de una serie de pruebas. Para definir un nuevo tipo, deberá proporcionar la siguiente información:
a)un nombre para el tipo;
b)el tipo de base (en su caso);
c)una definición del tipo, proporcionada de una de las siguientes formas;
1)dando una referencia precisa a una o más cláusulas, de una norma que define el tipo;
2)asignando una referencia de tipo NSA-1 (Recomendación X.208) de la forma
(modulereference)
.
(typereference)
3)enumerando el conjunto de valores distinguidos denominados que comprenden el
tipo (véase la figura D-7/X.290, parte 2);
4)especificando el subconjunto de los valores distinguidos de otro tipo.
Esto puede hacerse de varias maneras:
A)especificando una subgama del tipo predefinido
Integer
;
B)especificando una subgama de un tipo enumerado;
C)limitando la longitud de una
BitString
,
OctetString
, o un tipo predefinido de cadena de
caracteres.
Esta información se proporcionará en el formato indicado en la figura D-8/X.290, parte 2.
Figura D-7/X.290, Parte 2 [T6.290], p. (traiter comme tableau
MEP)
Figura D-8/X.290, Parte 2 [T7.290], p. (traiter comme tableau
MEP)
D.5.2
Designación de valor
Los valores de los diferentes tipos deberán designarse de la manera siguiente:
D.5.2.1
Valores de tipos predefinidos
Los valores de tipos predefinidos deberán designarse como se indica a continuación:
a)
Valores Enteros
: los valores de tipo
Integer
^ deberán designarse por una o más cifras. La
primera cifra no será cero, a menos que el valor sea cero.
b)
Valores BitString y OctetString
: los valores del tipo
Bitstring
^y
OctetString
^se
designarán de una de las formas siguientes:
1)Por un lista de bits:
En este caso, el valor será designado por un número arbitrario (que puede ser cero) de ceros y unos, precedidos por un solo ' y seguidos por el par de caracteres 'B.
Ejemplo D-5
- '01101100'B
2)Una lista de semioctetos:
En este caso, el valor consistirá en un número arbitrario (que puede ser cero) de caracteres
0 1 2 3 4 5 6 7 8 9 A B C D E F precedidos de un solo ' y seguidos por el par de caracteres 'H. Cada carácter se utiliza para designar el valor de un semiocteto utilizando una representación hexadecimal.
Ejemplo D-6
- 'AB0196'H
c)
Valores de Character String
: los valores de tipos de
cadena de caracteres se designarán por un número arbitrario (que puede ser
cero) de caracteres tomados del juego de caracteres referenciados por el tipo
de cadena de caracteres, precedido y seguido de ". Si el tipo cadena de
caracteres incluye el carácter ", este carácter será representado por un par de
" en la designación de cualquier valor.
d)
Valores Connection Endpoint Identifier
: los valores del
tipo
IdEC
^ no tienen designación.
Nota
- La designación no es necesaria porque la única
operación definida sobre el tipo
IdEC
^ es la igualdad
(véase el Î D.5.8).
D.5.2.2
Valores de tipos definidos por el usuario
Los valores de los tipos definidos por el usuario se designarán como sigue:
a)La designación de los valores de los tipos introducidos por referencia a la sección o secciones, de una Recomendación*, especificarán como los valores distinguidos de ese tipo deberán ser designados en la serie de pruebas, en los comentarios asociados con el tipo de definición.
b)Un valor de un tipo NSA-1 referenciado se designará utilizando NSA-1 bien por:
1)una referencia de la forma:
(modulereference)
.
(valuereference)
o
2)especificando un valor NSA-1 del tipo dado.
Nota
- El método modular NSA-1 tiene ampliaciones que
permiten especificar parcialmente el valor (Î D.8.3).
c)Un valor de un tipo enumerado deberá designarse por su nombre.
d)Un valor de un tipo obtenido a través de un subconjunto de otro tipo tendrá la misma designación que los valores del tipo sobre el cual se estableció el subconjunto.
D.5.3
Operadores
El usuario de la NCTA puede introducir operadores específicos para una serie de pruebas. Para definir una nueva operación deberá proporcionarse la siguiente información:
a)un nombre para la operación;
b)la signatura de la operación, constituida por:
1)una lista de los tipos de entradas;
2)un nombre para cada componente de entrada;
3)el tipo del resultado;
c)una descripción de la operación.
Se proporcionará en el formato indicado en la figura D-9/X.290, parte 2.
Figura D-9/X.290, Parte 2 [T8.290], p. (traiter comme tableau
MEP)
Las definiciones de dos operaciones de cadena se indican en las figuras
D-10/X.290, parte 2 y D-11/X.290, parte 2.
Figure D-10/X.290, partie 2 [T9.290], p.9 (traiter comme tabl.
MEP)
Figure D-11/X.290, partie 2 [T10.290], p.10 (traiter comme tabl.
MEP)
Nota
- Una operación puede compararse con una función en
un lenguaje de programación ordinario. Sin embargo, los argumentos de la
operación no se alteran como resultado de la invocación de la operación (no hay
efectos marginales).
D.5.4
Parámetros de series de pruebas
Esta sección tiene por objeto declarar constantes derivadas del ECRP o de la ISRPP que parametrizan globalmente la serie de pruebas. Estas constantes se conocen como parámetros de series de pruebas.
Nota
- En la mayor parte de los casos de pruebas, los
parámetros de las series de pruebas estarán ligados a un valor cuando tiene
lugar el procesamiento de ECRP»ISRPP.
En esta sección se proporciona la siguiente información sobre cada parámetro de serie de pruebas:
a)su nombre;
b)su tipo.
Esta información se proporcionará en el formato indicado en la figura D-12/X.290, parte 2.
Figura D-12/X.290, Parte 2 [T11.290], p. (traiter comme tableau
MEP)
D.5.5
Constantes globales
Esta sección tiene por objeto declarar un conjunto de nombres para valores no derivados del ECRP o de la ISRPP y que se mantendrán constantes en toda la serie de pruebas.
En esta sección se proporcionará la siguiente información relativa a cada constante global.
a)su nombre;
b)su tipo;
c)su valor.
Esta información se suministrará en el formato indicado en la figura D-13/X.290, parte 2.
D.5.6
Variables globales
Una serie de pruebas puede utilizar un conjunto de variables que son globales al ser aplicables conjuntamente a la parte dinámica y a la parte de las limitaciones. Usualmente, estas variables se utilizarán para valores de referencia de los campos de limitaciones de la UDP o las PSA, o componentes procedentes de la parte dinámica. Las variables son similares a las utilizadas en un lenguaje de programación convencional (por ejemplo, contadores).
Deberán declararse todas las variables globales que se utilizarán en una serie de pruebas. Para cada declaración de variable, se proporcionará la siguiente información:
a)su nombre;
b)su tipo.
Esta información se propondrá en el formato de la figura D-14/X.290, parte 2.
Figure D-13/X.290, partie 2 [T12.290], p.12 (traiter comme
tableau MEP)
Figure D-14/X.290, partie 2 [T13.290], p.13 (traiter comme
tableau Inicialmente, todas las variables no están acotadas.
Las variables pueden estar acotadas (o reacotadas) en los contextos
siguientes:
a)cuando la variable aparece a la izquierda de un enunciado de asignación (Î
D.6.7.1);
b)cuando la variable no acotada aparece en una expresión booleana (Î
D.6.7.1);
c)cuando la variable aparece en una referencia a limitaciones (Î D.8).
D.5.7
Declaraciones de PCO
En esta sección se indica el conjunto de @puntos de control y observación (PCO)\ y se expresa en qué lugar, dentro del entorno de las pruebas, existen estos PCO.
Nota
- El método de prueba elegido determina los PCO necesarios para
definir la serie de pruebas.
Para cada PCO utilizado en la serie de pruebas deberá suministrarse la siguiente información:
a)su nombre;
el nombre se utilizará en la sección comportamiento para especificar dónde ocurren sucesos particulares;
b)una explicación del tipo de probador situado en el PCO y del rol que desempeña el probador.
Esta información se proporcionará en el formato indicado en la figura D-15/X.290, parte 2.
Figure D-15/X.290, partie 2 [T14.290], p. (traiter comme tableau
MEP)
Ejemplo D-7
- Una muestra de una declaración de PCO se
presenta en el ejemplo D-8.
Ejemplo D-8
- Declaraciones de PCO.
Exemple D-8 [T15.290], p.15 (traiter comme tableau MEP)
Usualmente, los puntos de control y observación son simples PAS, pero en
general pueden ser cualquier punto apropiado en que puedan controlarse y
observarse los sucesos de prueba. Sin embargo, es posible definir un PCO que
corresponda a un conjunto de PAS, a condición de que todos los PAS que
constituyan el mencionado PCO sean:
a)en el mismo lugar (es decir, en el probador inferior o en el probador superior);
b)PAS del mismo servicio.
Cuando un PCO corresponde a varios PAS, se utilizan la dirección llamante (cuando inicia) o la dirección llamada (cuando recibe) para identificar el PAS en cuestión.
Ejemplo D-9
- Un ejemplo típico en que un PCO
corresponde a varios PAS podría ser un probador inferior interred que utiliza
un PCO el cual representa todos los puntos de asociación de su red para enviar
varias UDP interred a través de diferentes rutas. Otra posibilidad sería
presentar el mismo ejemplo con varios PCO.
También es posible considerar que un solo PAS se haga corresponder con varios PCO. En este caso habría un PCO por cada conexión.
Nota
- De esta manera es más fácil relacionar cada
suceso de prueba con la conexión apropiada.
Finalmente, debe señalarse la posibilidad de que un PCO no esté relacionado, en forma alguna, con un PAS. Por ejemplo, esto podría ocurrir cuando una capa está compuesta de subcapas (por ejemplo, en la capa de aplicación, o en las capas inferiores, donde un punto de asociación de subred no es un PAS).
D.5.8
Declaraciones de PSA
Esta sección enumera el conjunto de PSA que pueden aparecer en los PCO indicados en el Î D.5.7.
Normalmente, la información declarada puede encontrarse en la definición de servicio apropiada. Sin embargo, el declararla explícitamente permite la inserción de comentarios específicos a las pruebas y a una determinada serie de pruebas, así como tener en cuenta casos en que no existe una definición de servicio ISA* explícita (por ejemplo, X.25).
La siguiente información se suministrará para cada PSA:
a)su nombre;
si se utiliza un nombre abreviado, el nombre completo (tal como aparezca en cualquier especificación de servicio apropiado) deberá seguir entre paréntesis;
b)el PCO o los PCO en que pueda tener lugar;
todos estos PCO deberán haber sido declarados en la sección de declaraciones de PCO de la serie de pruebas;
c)si se utiliza o no un identificador de punto extremo de conexión para distinguir diferentes situaciones de la PSA;
si se expresa que se utiliza un identificador de punto extremo de conexión
(véase c), más arriba) estará disponible un parámetro denominado idec de tipo
IdEC
^ sin una ulterior declaración;
al recibirse una PSA que utiliza este parámetro, el valor de idec pasará a ser situado al punto extremo de conexión en el cual se recibió la PSA. Este valor estará entonces disponible para uso en el caso de prueba.
Ejemplo D-10
- Uso de un IdEC:
PCO? AN-PSA [idec=3]
d)una lista de los parámetros asociados con la PSA;
deberá suministrarse la siguiente información para cada parámetro:
1)su nombre;
si se utiliza un nombre abreviado, deberá seguir entre paréntesis el nombre completo (como se indique en cualquier especificación de servicio apropiada);
2)su tipo.
Las declaraciones de PAS tienen solamente un nivel de parámetro. Sin embargo, estos parámetros pueden ser de un tipo arbitrariamente complejo (por ejemplo, un tipo NSA-1 complejo).
Esta información se proporcionará en el formato indicado en la figura D-16/X.290, parte 2.
Ejemplo D-11
- La figura D-17/X.290, parte 2 presenta
un ejemplo tomado del servicio de transporte (Recomendación X.214). Podría
tratarse de una parte del alfabeto de las PSA utilizadas para describir el
comportamiento de un probador superior abstracto en una serie de pruebas DMO
para el transporte de clase 0. DLLA, DLLE y CDS son tipos definidos por el
usuario. (Véase Recomendación X.224 sobre protocolos.)
Figure D-16/X.290, partie 2 [T16.290], p.16 (traiter comme
tableau MEP)
Figure D-17/X.290, partie 2 [T17.290], p.17 (traiter comme
tableau MEP)
D.5.8.1
Declaraciones de PLA
Las PLA se declaran utilizando una proforma similar a la proforma para las PSA. Para cada PLA deberá suministrarse la siguiente información:
a)su nombre;
b)el PCO o los PCO en los cuales puede aparecer;
c)una descripción funcional de la PLA;
d)una lista de los parámetros asociados con la PLA.
Para cada parámetro deberá suministrarse la siguiente información:
1)su nombre;
si se utiliza un nombre abreviado, deberá seguir entre paréntesis el nombre completo (como se indique en cualquier especificación de servicio apropiada);
2)su tipo.
Esta información deberá proporcionarse en el formato indicado en la figura D-18/X.290, parte 2.
Figure D-18/X.290, partie 2 [T18.290], p.18 (traiter comme
tableau MEP)
D.5.9
Declaraciones de tipos de datos
Esta sección tiene por finalidad declarar los tipos de datos que se utilizan en la serie de pruebas. Estos tipos de datos se utilizarán principalmente en declaraciones de parámetros de las PSA.
Las declaraciones de tipos de datos más comunes son las declaraciones de UDP. Otras declaraciones de tipos de datos pueden incluir declaraciones de tipo NSA-1, si procede.
D.5.9.1
Declaraciones de UDP
La declaración de UDP es similar a la declaración de PSA. La siguiente información se suministrará para cada UDP:
a)su nombre;
si se utiliza un nombre abreviado deberá ir seguido de su nombre completo escrito entre paréntesis (como se indique en cualquier especificación de protocolo apropiada);
b)una lista de parámetros o, de una manera más general, de campos asociados con la UDP.
Nota
- Para poder describir pruebas en que se emplea la
codificación de las UDP puede ser necesario incluir campos (por ejemplo,
indicadores de longitud) en la descripción de la UDP, aunque es posible que
dichos campos no se consideren parámetros de UDP en la especificación del
protocolo.
Para cada parámetro se suministrará la siguiente información:
1)su nombre;
si se utiliza un nombre abreviado, deberá ir seguido del nombre completo entre paréntesis (como se indica en cualquier especificación de protocolo apropiada);
2)su tipo.
Esta información se proporcionará en el formato indicado en la figura D-19/X.290, parte 2.
Figura D-19/X.290, Parte 2 [T19.290], p. (traiter comme tableau
MEP)
Donde sea más conveniente, podrá utilizarse una referencia precisa a una
descripción de tipo NSA-1 de una UDP, en lugar de suministrar toda la
información antes indicada. En este caso, la información se proporcionará en el
formato indicado en la figura D-20/X290, parte 2.
Figura D-20/X.290, Parte 2 [T20.290], p. (traiter comme tableau
MEP)
Ejemplo D-12
- La figura D.21/X.290, parte 2 presenta un
ejemplo de definición de tipo de UDP, basada en la FTAM (ISO 8571).
Figura D-21/X.290, Parte 2 [T21.290], p. (traiter comme tableau
MEP)
D.5.10
Temporizadores
En una serie de pruebas pueden utilizarse varios tipos de temporizadores. Estos tipos se establecen atendiendo a la duración de los periodos de temporización. En una serie de pruebas puede utilizarse un número cualquiera de casos del mismo tipo de temporizador.
Para cada tipo de temporizador se suministrará la siguiente información:
a)el nombre del tipo de temporizador;
b)la duración del temporizador, que podrá especificarse mediante un valor o una gama de valores.
Esta información se suministrará en el formato presentado en la figura D-22/X.290, parte 2.
Figura D-22/X.290, Parte 2 [T22.290], p. (traiter comme tableau
MEP)
Ejemplo D-13
- La figura D-23/X.290, parte 2 muestra un
ejemplo de declaración de temporizador.
Figura D-23/X.290, Parte 2 [T23.290], p. (traiter comme tableau
MEP)
D.5.11
Abreviaturas
En este apartado se definen las abreviaturas que deben utilizarse en el resto de la serie de pruebas. Las abreviaturas se utilizan como facilidad macro, empleando para ello operaciones simples de sustitución de textos. Pueden emplearse en toda una serie de pruebas.
Una abreviatura, puede reemplazar a cualquier parte de texto dentro de una casilla sola cualquiera de un cuadro. El redactor del caso de prueba se cerciorará de que la ampliación resultante sigue la sintaxis de la NCTA.
Una definición de abreviatura proporcionará la siguiente información:
a)un identificador de abreviatura, o testigo;
b)su ampliación, para reemplazar a toda aparición del identificador a lo largo de la serie de pruebas.
Esta información se suministrará según el formato indicado en la figura D-24/X.290, parte 2.
Figura D-24/X.290, Parte 2 [T24.290], p. (traiter comme tableau
MEP)
Ejemplo D-14
- La figura D-25/X.290, parte 2 muestra un
ejemplo de declaración de abreviatura tomado de una serie de pruebas para
transporte (Recomendación X.224).
Nota
- El operador ~ se define en Î D.6.8.
Figura D-25/X.290, Parte 2 [T25.290], p. (traiter comme tableau
MEP)
D.6
Parte dinámica
La parte dinámica contiene el cuerpo principal de la serie de pruebas: las descripciones de comportamiento del caso de prueba y»o paso de prueba.
D.6.1
Descripción del comportamiento dinámico
Para la descripción del comportamiento de cada caso de prueba, paso de prueba o conjunto de pasos de prueba conexos deberá suministrarse la siguiente información:
a)una referencia: la referencia da un nombre a la descripción del comportamiento del caso de prueba o paso de prueba. Una referencia de caso de prueba cumplirá los requisitos del Î D.3.3.1. Una referencia de paso de prueba cumplirá los requisitos del Î D.3.3.2;
b)un identificador: una referencia refleja la estructura de la serie de pruebas y la finalidad del caso de prueba o del paso de prueba, por lo cual puede ser bastante larga. A veces conviene que un caso de prueba o un paso de prueba tengan un nombre corto. El identificador cumple esta finalidad y puede utilizarse de manera intercambiable con una referencia. El identificador de prueba será único dentro de una serie de pruebas dada;
c)un enunciado de finalidad: deberá ser un enunciado informal de finalidad del caso de prueba o del paso o los pasos de prueba;
d)referencia por defecto: hará referencia a una descripción de comportamiento por defecto, si existe, que se aplica a esta especificación de comportamiento (Î D.6.17);
e)una descripción de comportamiento: esta sección describirá el comportamiento del probador o los probadores en forma de sucesos de prueba (y sus parámetros) en la notación de árbol descrita en el Î D.6.2.
Esta información se proporcionará en el formato indicado en la figura D-26/X.290, parte 2.
Figure D-26/X.290, partie 2 [T26.290], p. (traiter comme tableau
MEP)
D.6.2
Notación de árbol
La notación de árbol se utiliza para construir las descripciones de comportamiento para una serie de pruebas. Las descripciones de comportamiento son enumeraciones de posibles secuencias observables de sucesos de prueba.
Ejemplo D-15
- Supóngase que las siguientes secuencias
de sucesos ocurren durante una prueba que tiene por finalidad, simplemente,
establecer una conexión, intercambiar algunos datos y liberar la conexión:
a)petCON, cnfCON, petDAT, indDAT, petDES
b)petCON, cnfCON, petDAT, indDAT, indDES
c)petCON, cnfCON, petDAT, indDES
d)petCON, cnfCON, indDES
e)petCON, indDES
La progresión puede ser detenida en cualquier momento por el proveedor de servicio subyacente. La notación de árbol extrae simplemente, como factores, secuencias iniciales comunes, del conjunto completo. Utilizando la notación de árbol, esto podría escribirse de la forma siguiente:
AProgresión del tiempo
l
EJEMPLO DE áRBOL
tpetCON
eCcnfCON
rCCpetDAT
nCCDindDAT
aCCDDpetDES
tCCDDindDES
iCCDindDES
vCCindDES
aCindDES
s
Los sucesos que aparecen al mismo nivel de sangrado representan los posibles sucesos alternativos que pueden ocurrir en cada instante. Los sucesos alternativos se darán en el orden en que el probador tratará de efectuarlos.
D.6.3
Sucesos de prueba
Los nombres de sucesos a iniciar por el probador serán prefijados por un signo final de admiración (!). De manera similar, los que podrán ser aceptados por el probador irán prefijados por un signo final de interrogación (?).
Ejemplo D-16
- Utilizando este convenio, el ejemplo de
árbol podría representarse como sigue:
EJEMPLO DE áRBOL
!petCON
!C?cnfCON
!CC!petDAT
!CCD?indDAT
!CCD?!petDES
!CCD??indDES
!CCD?indDES
!CC?indDES
!C?indDES
Tales nombres (compuestos de ! o ? seguido de un nombre de suceso) serán prefijados por uno de los nombres de PCO que aparecen en la lista de PCO del árbol en que aparece el suceso, a menos que en la serie de pruebas sólo se utilice un PCO, en cuyo caso puede omitirse el prefijo PCO. El nombre del PCO se utiliza para indicar el PCO en el cual puede ocurrir el suceso de prueba.
En casos en que el comportamiento no pueda especificarse en forma de sucesos con la notación NCTA (por ejemplo, debido al método de prueba que se está utilizando), las descripciones de comportamiento se presentarán en lenguaje ordinario.
Ejemplo D-17
- Paso de prueba de una serie de pruebas
genéricas.
áRBOL PARCIAL
?indN-DATOS[DatosusuarioûDR]
?!petN-DATOS[DatosusuarioûDC]
?!N+EPíLOGO
EPíLOGO
/*cerrar todas las conexiones de red abiertas*/
D.6.3.1
Enunciado ?OTHERWISE (?ENOTROCASO)
El seudosuceso predefinido
(PCO) ?OTHERWISE
puede utilizarse para
designar cualquier PSA o PLA que el probador puede recibir en ese PCO.
Ejemplo D-18
- Se supone que los sucesos A, B y C
pueden recibirse en un PCO dado:
?A[X=1] ?B ?OTHERWISE
algún comportamiento .^.^.^ ?TIMEOUT
es lo mismo que
?A ?B ?A
algún comportamiento .^.^.^ ?B
algún comportamiento .^.^.^ ?C
algún comportamiento .^.^.^ ?TIMEOUT
Cuando se utiliza ?OTHERWISE deben tenerse en cuenta los puntos siguientes:
a)?OTHERWISE está siempre ampliado con todos los posibles sucesos que pueden recibirse en el PCO ya que, incluso si un suceso está presente en el mismo nivel, una expresión booleana o un requisito de sincronización pueden impedir que este suceso ocurra;
b)Si se utilizan múltiples PCO, deberá enunciarse un PCO en el enunciado, ?OTHERWISE;
c)?OTHERWISE no tiene necesariamente que ser la última de un conjunto de alternativas;
d)?OTHERWISE puede tener una expresión booleana y»o una asignación asociada al mismo;
Ejemplo D-19
- ilustración de un ?OTHERWISE
calificado.
áRBOL-PRINCIPAL (X)
?Afavorable
?B[X=2]desfavorable1
?OTHERWISE[X=2]desfavorable1
?Cdesfavorable1
?OTHERWISEfavorable
si se invoca el árbol con X = 2, entonces
:
A=>favorable
B=>desfavorable1
para todo otro suceso => desfavorable1
si se invoca el árbol con X 2 entonces
:
A=>favorable
C=>desfavorable1
para todo otro suceso => favorable
e)?OTHERWISE no impide la utilización de valores por defecto. Los valores por defecto están agregados al conjunto de alternativas y serán examinados por su orden. Esto significa que ?OTHERWISE invalidará algunos valores por defecto, pero no necesariamente todos.
Ejemplo D-20
- Utilización de ?OTHERWISE en el árbol
principal y en el árbol por defecto.
áRBOL-PRINCIPAL
PCO1? A
PCO2? B
PCO1? OTHERWISE
áRBOL-POR-DEFECTO
PCO2
?OTHERWISEdesfavorable1 PCO1? Cdesfavorable PCO1?TIMEOUTfavorable
Los sucesos primero y tercero de la situación por defecto no son invalidados por ?OTHERWISE en el árbol principal.
D.6.4
Nombres de árbol
Una descripción de comportamiento contendrá por lo menos un árbol de comportamiento. Cada árbol de comportamiento irá prefijado por un nombre de árbol que es único dentro de una descripción de comportamiento (véase Î D.6.5).
Nota
- Muchos de los ejemplos muestran nombres de
árbol en texto escrito en negrita. Esto tiene por finalidad, solamente una
mayor claridad tipográfica, y no conlleva ningún otro significado.
D.6.4.1
PCO formales
Donde una serie de pruebas comprenda la prescripción de comportamiento en más de un PCO, el nombre de árbol irá seguido de una lista de los nombres de PCO (formales) utilizados en el árbol encerrado entre corchetes. Donde una serie de pruebas sólo prescriba comportamiento en un PCO, esta lista de PCO podrá omitirse.
Ejemplo D-21
- Un árbol que comprende los PCO L y U
podría denominarse:
NOMBRE-áRBOL[L,U]
D.6.4.2
Parámetros formales
Si en un paso de pruebas se utilizan parámetros de entrada, entonces, después de la lista de PCO (si existe), aparecerá una lista de parámetros formales del árbol. Estos parámetros irán encerrados entre paréntesis. La NCTA no admite parámetros de salida.
Ejemplo D-22
-
NOMBRE-áRBOL[L,U](X,Y)
D.6.5
Asociación de árbol
Se pueden asociar árboles a otros árboles reemplazando un nombre de suceso por el nombre del árbol que ha de asociarse, prefijado por un +. El nombre del árbol asociado adoptará la forma:
a)
&lab;TreeReference>
,^ o
b)
&lab;TreeReference>
[
&lab;ActualPCOs>
],^ o
c)
&lab;TreeReference>
(
&lab;ActualParameters>
),^ o
d)
&lab;TreeReference>
[
&lab;ActualPCOs>
](
&lab;ActualParameters>
)
Cuando un árbol se asocia a otro árbol, todos los actuales son sustituidos por los formales mediante un simple reemplazo textual. Así, un árbol asociado es análogo a un macro.
D.6.5.1
Alcance de asociación
Las descripciones de comportamiento pueden contener más de un árbol. Sin embargo, sólo el primer árbol de la descripción de comportamiento es accesible desde el exterior de la descripción de comportamiento. Todos los árboles ulteriores se consideran pasos de prueba locales con respecto a la descripción de comportamiento, y, por tanto no accesibles externamente. Los casos de prueba, desde luego, no son asociables.
Así, el
&lab;TreeReference>
^ será de una de las
formas siguientes:
a)
&lab;TreeName>
En este caso
&lab;TreeName>
^ será el nombre de uno de
los árboles en la descripción habitual de comportamiento.
b)
&lab;TestStepReference>
/
&lab;TreeName>
En este caso,
&lab;TreeName>
^ será el nombre del
primer árbol en la descripción de comportamiento del paso de prueba señalado
por la referencia de paso de prueba.
Como es usual, el
&lab;Test step reference>
^ puede
ser reemplazado por el
&lab;TestStepIdentifier>
^
equivalente.
Ejemplo D-23
- El siguiente par de árboles:
áRBOL-PRINCIPAL[L,U]
y
SUB-áRBOL[X]
L!PetCON X?IndCON
L!CON+SUB-ARBOL[U]
es equivalente a
:
áRBOL-COMPUESTO[L,U]
L!PetCON
L!CONU?IndCON
Puesto que la asociación de árbol constituye realmente una forma abreviada, las variables se utilizan en los árboles asociados con el valor que tienen en el punto en que el árbol es asociado, y pueden después ser utilizadas en asignaciones y/o expresiones booleanas en el árbol asociado.
Los árboles asociados pueden tener parámetros. Los actuales son sustituidos por formales cuando el árbol es asociado.
Ejemplo D-24
- El siguiente par de árboles:
áRBOL-PRINCIPAL SUB-áRBOL(X,Y)
(M:=1) (X:=Y)
+SubArbol(M,2)
(M:=3)
es equivalente a
áRBOL-COMPUESTO
(M:=1)
(M:=2)
(M:=3)
D.6.6
Etiquetas y GOTO
Un conjunto de sucesos alternativos puede etiquetarse colocando una etiqueta en la columna de etiqueta del primer suceso de las alternativas.
Si un conjunto de alternativas está etiquetado se permite pasar a ese conjunto desde cualquier punto del árbol. Esto se efectúa colocando o la palabra clave GOTO seguida del nombre de una etiqueta que está definida en el mismo árbol, inmediatamente después de un suceso. Si ocurre el suceso, la prueba continúa con el conjunto de alternativas señaladas por la etiqueta.
Ejemplo D-25
- La figura D-27/X.290, parte 2 ilustra
el uso del GOTO.
Sucesos, que no son necesariamente el primero de un conjunto de sucesos alternativos, pueden tener también una etiqueta para la especificación de requisitos de sincronización (Î D.6.11). Estas etiquetas no se utilizarán como objeto de un GOTO.
En el caso de que un primer suceso debiera etiquetarse para GOTO y para un requisito de sincronización deberá utilizarse una etiqueta común.
D.6.7
Expresiones
Los términos de una expresión pueden ser:
a)constantes (incluidos parámetros de serie de pruebas);
b)variables acotadas;
c)valores de parámetro del suceso asociado (si existen) referenciados por el nombre del parámetro dado en la declaración de suceso;
d)referencias a valores de campo de UDP en parámetros PSA. Estas referencias adoptan la forma:
&lab;ASPParameter>
.
&lab;FieldName>
Figure D-27/X.290, partie 2 [T27.290], p.27 (traiter comme
tableau MEP)
D.6.7.1
Cláusulas de asignación
Todo suceso puede ir seguido de una serie de asignaciones. La cláusula de asignación tiene por efecto acotar la variable global de la expresión únicamente si ocurre el suceso.
Las asignaciones se producen en el orden en que aparecen en la cláusula de asignación. La expresión no contendrá variables no acotadas.
D.6.7.2
Expresiones booleanas
Un suceso puede ser calificado. Esta calificación se obtiene colocando una expresión booleana entre corchetes después del suceso. Se entenderá que esta calificación significa la combinación de que ocurra el suceso y se satisfaga la expresión booleana.
Si hay una expresión booleana y una cláusula de asignación asociadas al mismo suceso, la expresión booleana aparecerá primero.
Los términos utilizados en la expresión booleana pueden ser cualquiera de los siguientes:
a)constantes (incluyendo parámetros de serie de pruebas);
b)variables:
Si en una expresión booleana aparecen variables no acotadas, el suceso ocurre únicamente si existen valores para las variables no acotadas que satisfacen la expresión booleana. Si el suceso ocurre efectivamente, todas la variables no acotadas pasarán a ser variables acotadas a los valores correspondientes a su tipo y que satisfacen la expresión booleana;
c)valores de parámetro de la PSA asociada (si existen) referenciados por el nombre del parámetro dado en la declaración de PSA;
d)referencias a una codificación de UDP en la parte restricciones (Î D.8). Esta codificación puede calificarse escribiendo:
&lab;PDUReference>
[
&lab;Boolean
Expression>
]
donde los términos de la expresión booleana pueden ser referencias a campos de la UDP referenciada;
e)referencias a valores de campo de UDP codificados en parámetros PSA en la parte restricciones. Estas referencias adoptan la forma:
&lab;ASPParameter>
.
&lab;FieldName>
D.6.7.3
Cláusulas de asignación y expresiones booleanas
sin sucesos
Se permite asociar un suceso con una asignación, o con una expresión booleana, o con ambos. Sin embargo, sólo pueden utilizarse las siguientes combinaciones:
a)
&lab;Suceso>
^ El suceso no está calificado.
b)
&lab;Suceso>
(
&lab;Asignación>
) La asignación sólo se ejecuta si
ocurre el suceso.
c)
&lab;Suceso>
[
&lab;Expresión
booleana>
] El suceso sólo puede ocurrir si se cumple la expresión
booleana.
d)
&lab;Suceso>
[
&lab;Expresión
booleana>
](
&lab;Asignación>
) La asignación se
ejecuta únicamente si se cumplen las dos condiciones:
1)ocurre el suceso; y
2)se cumple la expresión booleana.
Dado que todas las variables que aparecen en la expresión booleana pasan a estar acotadas, podrán utilizarse en las expresiones que forman parte de la asignación.
Las expresiones booleanas pueden dividirse en un conjunto ininterrupido de expresiones booleanas. Esta posibilidad puede ser útil cuando se utiliza junto con abreviaturas (Î D.5.11). De manera similar, las asignaciones pueden descomponerse en un conjunto ininterrumpido de asignaciones.
Ejemplo D-26 - PCO? CR [X = 1][Y < 3]
es equivalente
a
^ PCO? CR [(X = 1) AND (Y < 3)].
D.6.7.4
Cláusulas de asignación y expresiones booleanas
sin sucesos
Se permite utilizar cláusulas de asignación y expresiones booleanas solas, sin ningún suceso asociado.
Sólo se permiten las siguientes composiciones:
a)(
&lab;Asignación>
) La asignación sólo se ejecuta si
se produce el suceso.
b)[
&lab;Expresión booleana>
] El suceso puede ocurrir
solamente si se cumple la expresión booleana.
c)[
&lab;Expresión booleana>
] La asignación se ejecuta
solamente si se cumple la expresión booleana.
MONTAGE:
Î D.6.8 sur le reste de cette page
D Disk. 266 NF01/005 (OPM: 01) ii) NF01/030 (OPM: 01) - NF01/039 (OPM: 01) NF01/054 (OPM: 01) NF01/054 (OPM: 01) NF01/060 (OPM: 01) (cs,1) - (cs,1) NF01/088
(1BT) (BT..)
(85.TE.16.S)
(A1.23s) / [26s]
FOLIOS: 559 - 592
(BL) (DO PRC.COSY.2)
MEP {TPS.NON.PHOTO "[PA1]"} : OK= [1]
Saisie 13.03.89 PR
ID + LASER 23.03.89 CW
MAJ diskette 30.03.89 CW
Corr. LASER (1re épreuve) = 3eme 13.04.89 UT
Espaces réservés + imprimantes 14.04.89 DD
AJOUTER (PA1) (CL1,0,0,0) pour MEP
MEP + LASER 18.04.89 GH/ZR
Corr. MEP ........ ..
Insertion des tableaux (tabulateurs...) ........ ..
BAT 9.05.89 PM
Ultimes corrections 17.05.89 PM
MAJ DISKETTE ........ ..
MONTAGE:
Fin du ÎD.6.7.4. en tête de cette page
D.6.8
Operador codificar/decodificar
El operador codificar/decodificar permite la especificación de la
codificación de campos de UDP. La sintaxis para este operador se define en el
D.6.8.2. El operador ~ debe leerse como
`es la codificación de'
.
Ejemplo D-27
- Considérese el suceso:
N-PAS? IndN-DATOS[DatosUsuario ~ UDPT-CR] CR1
significa que el suceso concuerda únicamente si se recibe en un PAS-N una IndN-DATOS cuyo campo de datos de usuario es la codificación correcta de una UDPT-CR de acuerdo con la limitación CR1 (véase el Î D.6.13).
Supóngase que F1 es un campo de la limitación CR1. Si ocurre este suceso, F1 puede ser referenciado escribiendo UserData.F1.
Nota
- Si el contenido de F1 es una variable libre (el
Î D.8.2) o una variable global (el Î D.5.6), el suceso que ocurra acotará esta
variable (véase el Î D.6.7.2).
De manera similar:
N-PAS! PetN-DATOS[UserData ~ UDPT-CC] CC1
significa que el probador envía una PetN-DATOS cuyo campo UserData es la codificación de una UDPT-CC conforme a la limitación CC1.
D.6.8.1
Utilización de alias
Se proporciona un método sencillo para preservar los valores de UDP enteras. El alias es una variable acotada implícitamente que puede utilizarse como una forma abreviada o para distinguir entre dos campos (UDP o PSA) que tienen el mismo nombre.
Ejemplo D-28
- Uso de alias:
N-PAS? IndN-DATOS[UserData^\^UD1 ~ UDPT-CR [UserData^\^UD2 ~ UDP-TM]] CR1, TM1
los alias UD1 y UD2 están ligados a sus respectivos UserData [o, de una manera más precisa, ligados a las limitaciones CR (CR1) y TM(TM1)]. Supóngase que F1 es un campo de UDPT-CR (CR1) y que F2 es un campo de la limitación TM(TM1). Entonces estos campos deben referenciarse como UD1.F1 y UD2.F2.
D.6.9
árboles paralelos
A veces conviene poder describir el comportamiento en términos de descripciones de comportamiento separadas que se presentan en paralelo. Típicamente, cada descripción separada se referirá al comportamiento en un PCO diferente.
Los árboles paralelos se designan como sigue:
||
árbol
1, ^.^.^. ,
árbol
n
Se aplican las siguientes reglas:
a)el subíndice no deberá ser mayor que 1;
b)el árbol que divide su comportamiento en árboles paralelos tendrá un número de PCO que será siempre mayor que uno y no inferior al número de los árboles paralelos;
c)todos los PCO del árbol vigente serán un PCO, y exactamente uno de los árboles paralelos;
d)no podrá haber ningún temporizador en curso o suspendido;
e)no debe haber ningún otro suceso al mismo nivel de alternativa;
f)sólo el primer árbol en el enunciado (es decir, árbol1) puede asignar un veredicto;
g)cuando el primer árbol (es decir, árbol1) termina:
1)Si árbol1 termina con un veredicto asignado, el caso de prueba termina con ese veredicto.
2)Si árbol1 termina sin asignar un veredicto (es decir, se llega a un extremo de árbol1), el comportamiento continúa como si árbol1 estuviese asociado:
A)árbol2 .^.^. árboln no se tienen en cuenta;
B)los comportamientos ulteriores del árbol principal son agregados a los extremos de árbol1.
3)Si se alcanza un extremo de árboli (i > 1):
A)si ocurre un ulterior suceso en un PCO de árboli, entonces es un error;
B)en otro caso se aplica (g)2 (es decir, árbol1, tiene que terminar en algún punto).
Ejemplo D-29
- Comportamiento del probador inferior y
superior como árboles paralelos:
áRBOL-PRINCIPAL [UT,LT]
A
+ conectar-capa-enlace(LT)
A
+UT! PetN-CON
A
+U|| LT-áRBOL(LT), UT-áRBOL(UT)
A
+U|| + desconectar-capa-enlace(LT) éxito
UT-áRBOL [UT]
A
UT? CnfN-CON L
A
UUT! PetN-DATOS L
A
U?EnOtroCaso L
A
UT? EnOtroCaso L
LT-áRBOL [LT]
A
LT? IndN-DATOS [petición-llamada]
A
LLT! PetN-DATOS [aceptación-llamada]
A
LLLT? IndN-DATOS [paquete-datos]
áRBOL-POR-DEFECTO
UT? EnOtroCaso
U+ desconectar-capa-enlace fracaso1
D.6.10
Gestión de temporizador
Se supone que los temporizadores utilizados en una serie de pruebas siempre estarán en uno de los siguientes estados:
a)inactivo,
b)en curso,
c)suspendido.
D.6.10.1
Operaciones de temporizador
Para modelar la gestión de los temporizadores se hace uso de un conjunto de
`operaciones'
, que pueden utilizarse como asignaciones. Estas
operaciones pueden aplicarse a:
a)un conjunto de temporizadores:
Esto se especifica siguiendo la operación del temporizador con un nombre de tipo de temporizador exactamente;
b)un temporizador específico tomado de un conjunto de temporizadores del mismo tipo de temporizador.
Esto se especifica haciendo que la operación del temporizador vaya seguida del nombre del tipo de temporizador y de un identificador para el temporizador individual. Un identificador de temporizador es un nombre de variable.
Nota
- No es menester declarar explícitamente los
identificadores de temporizadores, sino que pueden enunciarse como un parámetro
de la operación
Arranque
.
D.6.10.2
Definición de las operaciones de
temporizador
Las operaciones de temporizador definidas son:
a)
Arranque
&lab;
tipo de
temporizador
> [, <
id de temporizador
> [,
&lab;
valor
>]]
La operación
arranque
se utiliza para indicar que un
termporizador inactivo, o un conjunto de temporizadores, debe comenzar a
discurrir. (Si se omite el parámetro de identificación de temporizador, se
interpretará que se trata del arranque de un temporizador del tipo de
temporizador dado. Sin embargo, no será entonces posible manipular este
temporizador separadamente de los otros temporizadores de este tipo que puedan
haber sido definidos.)
Se utilizará el parámetro de valor facultativo para asignar un tiempo de expiración (es decir, una duración) a un temporizador. Este valor no tiene que estar comprendido en la gama de valores definida para el temporizador. Esto permite probar situaciones de duración de temporizador. En otro caso puede utilizarse cualquier tiempo comprendido en la gama de valores especificada en la parte declaraciones.
b)
Cancelar
&lab;
tipo de
temporizador
> [, <
id de temporizador
>]
La operación
cancelar
se utiliza para indicar que un
temporizador en curso (o suspendido) debe pasar a inactivo. (Si se omite el
parámetro de identificador de temporizador, todos los temporizadores
suspendidos del tipo de temporizador dado pasarán a estar inactivos.)
c)
Suspender
&lab;
tipo de
temporizador
> [, <
id de temporizador
>]
La operación
suspender
se utiliza para indicar que un
temporizador en curso pasará a estar suspendido. (Si se omite el parámetro del
identificador de temporizador, todos los temporizadores del tipo de
temporizador dado pasarán a estar suspendidos.)
d)
Reanudar
&lab;
tipo de
temporizador
> [, <
id de temporizador
>]
La operación
reanudar
se utiliza para indicar que un
temporizador suspendido se pondrá de nuevo en marcha (es decir, se reanudará).
(Si se omite el parámetro del identificador de temporizador, todos los
temporizadores del tipo de temporizador dado se pondrán de nuevo en marcha.)
D.6.10.3
Seudosuceso de temporizador
Además de las operaciones de temporizador, se definen dos seudosucesos de temporizador:
a)El seudosuceso de
temporización
, que tiene la forma
siguiente:
?Temporización
&lab;
tipo de
temporizador
> [, <
id de temporizador
>]
Este seudosuceso puede utilizarse con un árbol de comportamiento para verificar la expiración del temporizador especificado. El parámetro identificador de temporizador puede omitirse si:
1)sólo hay un temporizador del tipo de temporizador definido;
2)hay varios temporizadores del tipo de identificador de temporizador definido, y no es necesario distinguir entre ellos.
D.6.10.4
Seudosuceso de transcurrir
Un enunciado de
transcurrir
es de la forma siguiente:
Transcurrir
&lab;
tipo de
temporizador
> [, <
valor
>]
Un enunciado de
transcurrir
fija una cota superior, al
tiempo en el que un árbol permanecerá a un nivel dado de sangrado (es decir, en
un estado dado). Cuando se utiliza
transcurrir
, deben
tenerse en cuenta los puntos siguientes:
a)el enunciado
transcurrir
no tendrá asociada ninguna
expresión booleana ni requisito de sincronización;
b)si se utiliza más de un
transcurrir
, sólo se
considerará el que, entre ellos especifique la menor duración;
c)se recomienda (sin que ello sea obligatorio) que
transcurrir
, si aparece, sea la última de un conjunto de
alternativas;
d)la alternativa especificada por
transcurrir
sólo ocurre
si, en el curso de la duración especificada:
1)no hay programada ninguna otra alternativa;
2)no se producen errores (es decir, un suceso para el que no haya una alternativa).
Nota
- Transcurrir, aunque utiliza un tipo de
temporizador, por ser ello conveniente para dar un valor y unidades, no implica
que haya comenzado cualquier temporizador accesible al usuario.
Ejemplo D-30
- Utilización de
Transcurrir
:
?A
?B
TRANSCURRIR
significa que el probador esperará solamente hasta que ocurra el suceso ?A o ?B, o hasta que expire TRANSCURRIR.
D.6.11
Sincronización
La posibilidad de especificar el orden relativo de los sucesos en árboles diferentes, que pueden o no tener la misma descripción de comportamiento, se proporciona mediante el enunciado de sincronización. El enunciado de sincronización es una expresión booleana de la forma:
a)(
TreeReference
1)/(
Label
1) <
(
TreeReference
2) (
Label
2), OR
b)(
TreeReference
1)/(
Label
1) >
(
TreeReference
2)/(
Label
2)
donde los predicados se interpretan de la siguiente forma:
a)el suceso etiquetado con (
Label
1) en el paso de
prueba (
TreeReference
1)
ocurre
antes
que el suceso etiquetado con
(
Label
2) en el paso de prueba
(
TreeReference
2);
b)el suceso etiquetado con (
Label
1) en el paso de
prueba (
TreeReference
1)
ocurrió
después
que el suceso etiquetado con
(
Label
2) en el paso de prueba
(
TreeReference
2).
Nota 1
- La sincronización se especifica en forma de
sucesos en árboles diferentes y no de selecciones dentro del mismo árbol.
Nota 2
- La sincronización sólo puede utilizarse entre
árboles paralelos, los cuales pueden o no formar parte de la misma descripción
de comportamiento.
Nota 3
- Una selección alternativa de árboles
paralelos sincronizados es un sólo árbol que afecte a varios PCO.
D.6.11.1
Interpretación de enunciados de
sincronización
Un enunciado de sincronización se interpretará de la manera siguiente:
Si,
a)un suceso tomado entre un conjunto de alternativas tiene una etiqueta L; Y
b)existe un enunciado de sincronización que contiene
(
TreeReference
/
Label
) en su parte
derecha o izquierda; y
c)(
TreeReference
) designa la descripción de
comportamiento en que está el suceso.
ENTONCES:
a la expresión booleana utilizada para decidir si se selecciona o no el suceso se agrega lo siguiente:
`Y el suceso designado por la etiqueta en la otra parte del enunciado de
sincronización que ya ocurrió (respectivamente, que ya no ocurrió).'
En consecuencia, un enunciado de sincronización no significa que el árbol
está
`suspendido'
hasta que se satisfaga el requisito de sincronización,
sino que el suceso implicado en la sincronización no es un candidato para
selección entre el conjunto normal de alternativas si no se satisface la
sincronización. Las reglas normales para la selección de un suceso se aplican,
considerando la sincronización como una expresión booleana suplementaria. Si no
puede seleccionarse un suceso, podrá producirse un error si hay un suceso
presente, en el PCO, que no puede ser objeto de control de flujo. El redactor
de la prueba deberá entonces incluir el suceso apropiado al mismo nivel de
sangrado.
Ejemplo D-31
:
PRIMER-áRBOL
LT! L-PetL-DATOS[paquete DT con bit D puesto] L1
LT!L
LT? IndL-DATOS[P(R) para este paquete]
L2 desfavorable1
LT!L
LT? IndL-DATOS[P(R) < este paquete] L2
LT!L
LT? IndL-DATOS[P(R) < este paquete]
L3 favorable
SEGUNDO-áRBOL
UT? IndN-DATOS L
con los requisitos de sincronización
PRIMER-áRBOL/L3 > SEGUNDO-áRBOL/L PRIMER-áRBOL/L2 < SEGUNDO-áRBOL/L
D.6.12
Construcción repetir
Esta sección describe un mecanismo en descripciones de comportamiento NCTA para repetir un paso de prueba un número variable de veces. La forma de la construcción es:
REPETIR
(
TreeReference
)
[(
Varid
)]
y debe ir seguida de un conjunto de expresiones booleanas alternativas
(guardas). Debe señalarse que:
a)las guardas no tienen que ser mutuamente exclusivas. Repetir termina cuando se cumple por lo menos una guarda;
b)no puede aparecer otro suceso ni seudosuceso al mismo nivel de sangrado que las guardas;
c)VARid (cuando se especifica):
1)puede utilizarse dentro del árbol repetido,
2)puede utilizarse dentro de las guardas,
3)no es una variable global (es decir, su alcance es local con respecto al REPETIR),
4)es implícitamente de tipo entero.
D.6.12.1
Repetir con ninguna VARid
Cuando no se especifica VARid, la construcción:
REPETIR TreeReference (a1, .^.^. , an) [b1] .^.^.^ .^ .^ .^ [bn] .^.^.^
se interpretará con el significado
+ TreeReference (a1, .^.^. , an)L [b1] .^.^.^ .^ .^ .^ [bn] .^.^.^ [verdadero] L
donde (a1, .^.^. , an) son los parámetros de árbol actuales (en su caso).
D.6.12.2
REPETIR con VARid
Cuando se especifica VARid está la construcción:
REPETIR TreeReference (a1, .^.^. , an) [VARid]
se amplía a:
+ repetir-árbol (a1, .^.^. , an, 0)
y este repetir-árbol se define como:
Repetir-árbol-ficticio (f1, .^.^. , fn, VARid) + TreeReference (f1, .^.^. , fn) [VARid] L (VARid:=VARid + 1) [b1] .^.^.^ .^ .^ .^ [bn] .^.^.^ [verdadero] L
donde (a1, .^.^.^, an) son los parámetros de árbol actuales (en su caso) y (f1, .^.^. , fn) son los parámetros de árbol formales, y las identificaciones de árbol (f1, .^.^. , fn) se redefinen como las identificaciones de árbol (f1, .^.^.^, fn, VARid).
D.6.13
Referencia de limitaciones
Esta columna permite hacer referencia a una PSA, PLA o UDP que están definidas en la parte declaración de limitaciones (véase el Î D.8 - que proporciona también más información sobre las limitaciones de la codificación).
Ejemplo D-32
- Referencia de limitación:
N-PAS? IndN-DATOS [UserData ~ UDPT-CR] IndN-DATOS(D1), UDPT-CR(CR1)
donde IndN-DATOS y UDPT-CR se definen en las secciones de declaración de tipo de datos de la serie de pruebas. Las limitaciones D1 y CR1 se definen en la sección de limitaciones de la serie de pruebas.
Si un suceso está calificado por una expresión booleana y tiene también una
referencia de limitaciones, esto se interpretará en el sentido de que
el suceso ocurre única y exclusivamente si se cumple la
expresión booleana y se cumple también la limitación.
Si un suceso va seguido de una cláusula de asignación y tiene una
referencia de limitaciones, o una expresión booleana, o ambas, esto se
interpreta en el sentido de que
la asignación se efectúa
únicamente si el suceso ocurre
, de acuerdo con la
definición dada anteriormente.
D.6.14
Veredictos
Un caso de prueba terminará con un veredicto. Este veredicto se da con respecto a la finalidad de la prueba, y puede ser:
a)Favorable.
b)Desfavorable1.
c)Desfavorable2 (se cumplió la finalidad de prueba, pero fracasó ulteriormente).
d)Desfavorable3 (error de protocolo, pero finalidad de prueba no concluyente).
e)Dudoso.
Se puede asignar un veredicto a un suceso de prueba utilizando la columna
de veredicto. Las inscripciones que aparecen en la columna de veredicto
contendrán una de las indicaciones que se darán más adelante, o estarán en
blanco (es decir, no hay veredicto). Este caso particular se designa en lo
sucesivo por el valor
ninguno
.
D.6.14.1
Reglas para aplicar veredictos
Las siguientes reglas son apliables a la asignación de veredictos:
a)en cualquier momento durante la ejecución de un caso de prueba, hay un
`veredicto por defecto'
.
Nota
- No debe confundirse ese veredicto con el que
aparece en una descripción de comportamiento por defecto.
b)Al principio de un caso de prueba, el veredicto por defecto es ninguno;
c)cuando se asocia un árbol, el veredicto por defecto para el árbol asociado
es el resultado de la aplicación de la figura D-28/X.290, parte 2.
`Vigente'
es el veredicto por defecto en curso y
`Nuevo'
es el
veredicto asignado en el punto de asociación;
d)cuando un suceso (que no sea una asociación) tiene asignado un veredicto
que no es
`ninguno'
es decir, la inscripción correspondiente en la
columna de veredicto no está en blanco), el caso de prueba termina con el
veredicto que se obtiene como resultado de aplicar la figura D-28/X.290, parte
2 al veredicto por defecto, asignándose el veredicto a ese suceso;
e)cuando se alcanza el extremo de un árbol que no es el árbol, principal, el caso de prueba termina con un veredicto que es el veredicto por defecto.
Nota
- En este caso no se asigna un veredicto explícito
al último suceso del árbol (en otro caso se aplicaría el Î D.6.14.1^d). Esto es
un error.
Ejemplo D-33
- Utilización de un veredicto asociado a
un subárbol:
áRBOL-A
!PetCON
?CnfCON
+ TransferenciaDatos(
`Hola'
)
[ok =
`sí'
]
+ adiós Favorable
[ok =
`no'
]
+ adiós Desfavorable
?IndDES Dudoso
Figure D-28/X.290, partie 2 [T28.290], p.1 (traiter comme tableau
MEP)
D.6.15
Comentarios
Esta columna contiene breves observaciones o referencias a comentarios más amplios indicados al final del cuadro.
D.6.16
Referencia a comportamientos por defecto
A fin de destacar el trayecto principal a través de una prueba, es posible especificar, separadamente de la descripción del comportamiento principal, comportamientos ulteriores por defecto para cualquier suceso que un probador pueda recibir. Las descripciones de comportamiento principal de la parte dinámica se completan agregando a cada conjunto de alternativas un comportamiento ulterior a partir de una descripción de comportamiento por defecto.
A fin de asegurar que una especificación de caso de prueba esté completa, toda especificación de prueba NCTA deberá especificar el comportamiento ulterior para cada suceso posible, bien sea en una descripción de comportamiento principal, o por medio de una descripción asociada de comportamiento por defecto.
Nota
- Esto puede hacerse simplemente con ?OTHERWISE.
Los comportamientos por defecto sólo son aplicables donde sea posible el suceso de prueba en cuestión.
Ejemplo D-34
- El siguiente caso de prueba podría
dividirse en dos descripciones de comportamiento, a saber:
EJEMPLO-DE-áRBOL
!PetCON
?CnfCON
PetDATOS
?IndDATOS
!PetDES
con una situación por defecto trivial (pues no tiene asociado un comportamiento ulterior) de:
áRBOL-POR-DEFECTO
?IndDES
Se utiliza la referencia a comportamiento por defecto para asociar un conjunto de comportamientos por defecto a una descripción de comportamiento principal.
D.6.17
Especificación de comportamientos por defecto
Las descripciones de comportamiento por defecto se presentrán en cuadros en la sección situación por defecto de la parte dinámica de una serie de pruebas. Estos cuadros tendrán el formato presentado en la figura D-29/X.290, parte 2.
Figura D-29/X.290, parte 2 [T29.290], p. (traiter comme tableau
MEP)
Estos cuadros son exactamente iguales a las descripciones de comportamiento
principal, con las que sólo presentan las siguientes diferencias:
a)el árbol de comportamiento por defecto no tendrá nombre;
b)deberá contener un solo árbol sin nombre (/Rightarrow PCO y parámetros no pueden pasarse a situaciones o valores por defecto);
c)no podrá contener una inscripción de requisitos de sincronización.
Nota
- Las referencias a comportamientos dinámicos por
defecto obedecen a las mismas reglas que los pasos de prueba (Î D.3.3.2).
Ejemplo D-35
- Las figuras D-30, D-31 y D-32/X.290,
parte 2 presentan una versión ligeramente aumentada de EJEMPLO-DE-áRBOL. Los
comportamientos por defecto en las figuras D-31 y D-32, en combinación, son
exactamente equivalentes al comportamiento indicado en la figura D-33/X.290,
parte 2.
Figure D-30/X.290, partie 2 [T30.290], p.3 (traiter comme tableau
MEP)
Figure D-31/X.290, partie 2 [T31.290], p.4 (traiter comme tableau
MEP)
Figure D-32/X.290, partie 2 [T32.290], p.5 (traiter comme tableau
MEP)
Figure D-33/X.290, partie 2 [T33.290], p.6 (traiter comme tableau
MEP)
Interpretación de árboles
En este apartado se explica la manera de interpretar las descripciones de comportamiento descritas en NCTA y la forma de asignar un veredicto a un caso de prueba. Está constituida de dos partes destinadas a dos tipos diferentes de situaciones:
a)una primera parte proporciona un conjunto de reglas junto con un algoritmo simple destinado a ayudar a la comprensión de la NCTA;
b)la segunda parte proporciona un algoritmo más amplio (las reglas han sido integradas en el algoritmo), destinado a faciliar la aplicación de la NCTA.
D.7.1
Interpretación de la NCTA (algoritmo parcial)
a)un árbol NCTA tiene cierto número de niveles de jerarquía de sucesos; este número es mayor o igual que uno. La ejecución de los sucesos en el árbol terminará en algún nivel por:
1)la asignación de un veredicto, o
2)la aparición de un error de caso de prueba (es decir, se alcanza un extremo sin veredicto, o se recibe un suceso no esperado en un PCO);
b)cada nivel tiene un número de sucesos alternativos mayor o igual que uno;
c)se supone aquí que:
1)el desarrollo del árbol ya se ha efectuado de acuerdo con las reglas generales indicadas en el Î D.6.5,
2)el conjunto de situaciones por defecto que han de aplicarse se ha calculado de acuerdo con las reglas indicadas en el Î D.6.14.1,
3)las reglas para veredictos por defecto en el caso de un subárbol se ajustan a lo indicado en el Î D.6.14.1;
d)el algoritmo para interpretar lo que hay que hacer en un nivel dado es el siguiente:
1)agregar las situaciones por defecto al conjunto de alternativas,
2)utilizar el procedimiento del Î D.7.3 para determinar si aparece o no una concordancia,
3)si el procedimiento del Î D.7.3 da
no hay
concordancia
, entonces TERMINAR (error),
4)si se encuentra una concordancia, entonces:
A)si el suceso que causa la concordancia tiene asignado un veredicto, o si es el extremo de un subárbol con un veredicto por defecto, terminar el caso de prueba y retornar el veredicto final determinado de acuerdo con la figura D-29/X.290, parte 2.
B)en otro caso, determinar el siguiente nivel de sangrado como el siguiente al suceso que causó la concordancia y:
i)si ese nivel designa un conjunto no vacío de alternativas, se rearranca el procesamiento para ese nivel,
ii)en otro caso TERMINAR (error).
D.7.2
Reglas para situaciones por defecto
a)las situaciones por defecto de un subárbol tienen precedencia con respecto a (es decir, deberán considerarse antes) las situaciones por defecto del árbol que está asociado al subárbol:
Ejemplo D-36
- Situaciones por defecto del árbol
principal y en el árbol asociado:
áRBOL-PRINCIPAL
?A
+ Paso-1
áRBOL-POR-DEFECTO
?B desfavorable1
?E desfavorable1
Paso-1
?C
?D
Paso-por-defecto-1
?B favorable
y las secuencias:
?A ?C ?B => favorable
?A ?C ?E => desfavorable1
b)las situaciones por defecto de un subárbol sólo se consideran cuando se ha entrado efectivamente en ese subárbol (es decir, a un nivel de sangrado mayor que el correspondiente a los sucesos que causan la entrada en ese subárbol);
c)las situaciones por defecto dejan de aplicarse a la terminación de un
árbol y no deberán agregarse al
`conjunto alternativo vacío'
que sigue a
un extremo del árbol. Esto es aplicable tanto al árbol principal como al
subárbol;
Ejemplo D-37:
áRBOL-PRINCIPAL
?A
?B
?C desfavorable1
?OTHERWISE favorable
áRBOL-POR-DEFECTO
?OTHERWISE dudoso
y la secuencia
?A ?B ?ANYTHING no es válida (es decir,
el caso de prueba está incompleto);
d)cuando se utilizan situaciones por defecto en un subárbol y ocurre un suceso que concuerda con la situación por defecto, si la secuencia especificada por la situación por defecto no tiene un veredicto la ejecución continuará en el árbol principal después de alcanzarse un extremo de la situación por defecto, salvo, desde luego, ²el caso del subárbol que tiene un veredicto por defecto!:
Ejemplo D-38
- árbol con veredicto por defecto:
áRBOL-PRINCIPAL
?A
+ Paso-1
?X favorable
?B desfavorable1
Paso-1 ?D ?E
Situación-por-defecto ?B !C
y la secuencia
?A ?D ?B ?C ?X =>favorable
D.7.3
Sucesos concordantes
A continuación se facilitan, para cada posible tipo de suceso o seudosuceso NCTA, las reglas para determinar si un suceso, entre un conjunto de alternativas, concuerda (es decir, se evalúa como si hubiera ocurrido):
a)
!(idPAS | idPLA | idUDP)
- para que el suceso SEND
(ENVIAR) concuerde tiene que ser posible enviar PSA, PLA o UDP (es decir,
considerando control de flujo). Si un PCO ha sido especificado, esta
determinación se hace considerando ese PCO particular. Además deben cumplirse
todas las expresiones booleanas calificativas y/o restricciones relacionadas
con las PSA, PSLA o UDP;
b)
?(idPSA | idPLA | idUDP)
- para que el suceso RECEIVE
(RECIBIR) concuerde, las PSA, PLA, o UDP especificadas tienen que haberse
recibido y todas las restricciones especificadas deben cumplirse. Si un PCO ha
sido especificado, las PSA, PLA o UDP tienen que haber sido recibidas en ese
PCO particular. Adicionalmente, tienen que cumplirse todas las expresiones
booleanas calificativas y/o restricciones relacionadas con las PSA, PSLA o UDP;
c)
?TIMEOUT (TEMPORIZACIóN)
- para que el seudosuceso
temporización concuerde debe haber expirado un temporizador con el mismo nombre
de tipo. Si se especifica un identificador de temporizador facultativo, se
considera la expiración de ese temporizador individual solamente;
d)
ELAPSE (TRANSCURRIR)
- para que el suceso transcurrir
concuerde, el temporizador que fue arrancado implícitamente (por la
especificación de transcurrir) tiene que haber expirado antes de que hayan
concordado los sucesos anteriores a trancurrir;
e)
?OTHERWISE (ENOTROCASO)
- para que el suceso enotrocaso
concuerde, tiene que haberse recibido algún suceso que no ha concordado con
ninguna de las alternativas anteriores a enotrocaso. Si está especificado un
PCO, el suceso tiene que haberse recibido en ese PCO particular;
f)
ATTACH (ASOCIAR)
- este suceso nunca se considerará
para una concordancia, porque se supone que las asociaciones de árbol han sido
totalmente desarrolladas antes de tratar de concordar una alternativa;
g)
REPEAT (REPETIR)
- este suceso nunca se considerará
para una concordancia porque tendrá que haber sido previamente desarrollado;
h)
GOTO
- este suceso siempre se evalúa como VERDADERO,
por lo que siempre concuerda;
i)
BOOLEAN EXPRESIONS (EXPRESIONES BOOLEANAS)
- una
expresión booleana enunciada como una alternativa concuerda si su evaluación da
VERDADERO (véase el Î D.6.7.2);
j)
ASSIGNEMENT CLAUSES (CLáSULAS DE ASIGNACIóN)
- una
cláusula de asignación siempre concuerda;
k)
PARALLEL TREES (áRBOLES PARALELOS)
- la ejecución de
árboles paralelos no se considerará nunca para las concordancias, porque
tendrán que haber sido totalmente desarrollados antes de tratar de concordar
una alternativa;
l)
TIMER OPS (OPERACIONES DE TEMPORIZADOR)
- Comenzar,
Cancelar, Suspender y Reanudar: todas las operaciones de temporizador
concordarán siempre.
Nota
- Todo suceso especificado como en el nivel
siguiente y en el mismo nivel de sangrado que un goto, cláusula de asignación u
operación de temporizador, nunca podrá alcanzarse.
D.7.4
Algoritmo comprensivo
A los efectos de este apartado:
a)un veredicto habrá de ser uno de los siguientes:
1)favorable, desfavorable1, desfavorable2, desfavorable3, dudoso;
2)ninguno, que se utiliza:
A)como un valor especial devuelto cuando se alcanza un extremo de un subárbol sin un veredicto;
B)como un valor de veredicto por defecto cuando se asocia un subárbol para el cual no hay valor por defecto;
C)como el veredicto asignado a un suceso cuando la columna de veredicto está vacía;
3)una unión ordenada de un conjunto ordenado es .^.^. (³agregada?);
b)sea EVALUATE-DEFAULT (
R
) una función:
1)de una referencia de comportamiento (
R
);
2)que devuelve un conjunto ordenado de sucesos alternativos;
3)que este conjunto ordenado está definido como sigue:
A)sea
d
la referencia del comportamiento por defecto
asociado con la descripción de comportamiento referenciada por
R
;
B)si no hay
d
retornar el conjunto vacío;
C)en otro caso, retornar la unión ordenada de:
i)todos los sucesos en el primer nivel de sangrado de la descripción de
comportamiento referenciada por
d
,
ii)y evaluar EVALUATE-DEFAULT (
d
);
c)sea SELECT (
E
) una función:
1)de un conjunto ordenado de
E
de sucesos alternativos;
2)que devuelve un suceso de su conjunto de entrada, o el valor especial
error
;
3)que se define como sigue:
A)Sea
E`
un conjunto de parejas, { suceso, suceso, }
inicializado como:
{ { e1, e1 }, { e2, e2 }, .^.^. { en, en }}
donde e1 .^.^. en son los elementos de
E
.
B)
Sustitúyase
todo elemento
E`
de
la forma
{ + árbol, e }, .^.^. V e por { t1, e } .^.^.^{ tn, e }
donde t1, .^.^. tn son los sucesos del primer nivel de sangrado del árbol.
Nota 1
- Esto tendrá que hacerse (posiblemente de
manera recurrente) hasta que ningún elemento sea de la forma { +árbol, e } pues
un árbol puede asociar un subárbol en su primer nivel de sangrado.
Nota 2
- El segundo elemento de la pareja mantiene el
rastro del nombre del suceso original en el ??? de ???. SELECT devolverá este
elemento.
Nota 3
-
E`
es un conjunto
ordenado.
C)Si hay algún
ELAPSE
entre las alternativas, calcular T
= unidad de tiempo (valor de transcurrir), en otro caso hacer T = infinito.
D)Para cada elemento en {
x
,
e
}
en
E`
hacer lo siguiente:
Si se cumple lo siguiente:
i)Si hay una expresión booleana y si ésta se cumple
y
-O BIEN x es PCO? En otro caso y cualquier suceso PSA está listo en ese PCO.
-O x es PCO? PSA y la PSA está lista y toda expresión booleana que utiliza parámetros de esta PSA se cumple, y todas las restricciones (si existen) están satisfechas.
-O x es PCO! PSA y la PSA puede enviarse a este PCO (es decir, el control de flujo permite ese envío) y todas las restricciones (si existen) son satisfechas.
-O x no es ni ? ni !
ENTONCES SELECT termina y devuelve el suceso.
E)Si hay alguna PSA lista en cualquier PCO y esa PSA no puede ser controlada
en flujo, o ha transcurrido un temporizador, SELECT termina y devuelve
`error'
.
F)En otro caso:
i)si ha transcurrido un periodo de tiempo mayor que T desde que c(3)D se
introdujo por primera vez, entonces seleccionar el suceso
`transcurrir'
que fue utilizado para calcular T;
ii)en otro caso recomenzar en c(3)D; es decir,
esperar al próximo suceso (bucle de ocupado);
d)sea EXECUT (x) una función:
1)de un suceso x;
2)que termina sin devolver un valor;
3)se define como sigue:
A)si x es ?OTHEWISE, se descarta el suceso actual (?PSA) que hizo que la función SELECT retornara, y entonces:
B)si x es PCO? PSA, tomar la PSA del PCO, acotar cualesquiera parámetros conexos o variables libres con los valores recibidos; y entonces:
C)acotar cualesquiera variables globales no acotadas de modo que la expresión booleana (si existe) se cumpla; y entonces:
D)si x es PCO! PSA, acotar los parámetros a valores de manera que la expresión booleana se cumpla y emitir la PSA en el PCO; y entonces:
E)efectuar las eventuales asignaciones (incluidas eventuales operaciones de temporizador);
e)sea EVAL-TREE una función:
1)de:
-el nivel vigente de sangrado (L) que designa un conjunto de sucesos alternativos en una descripción de comportamiento;
-el veredicto por defecto (V) habitual que identifica, en el caso de asociación de árbol, si un veredicto fue o no asignado en el punto de asociación del árbol.
Nota
- Ninguno significa
no hay
veredicto
;
-el conjunto ordenado de sucesos por defecto (
D
) que ha
de utilizarse para interpretar el árbol;
2)EVAL-TREE devuelve un valor como se define en a);
3)EVAL-TREE se define como:
A)evaluar
K
= conjunto de sucesos a L;
B)invoca SELECT (
K
U
D
);
C)si e(3)B retorna
error
, entonces EVAL-TREE TERMINA
(error);
D)si e(3)B retorna un suceso de la forma +árbol entonces;
i)calcular V = EVAL-TREE (
L
`,
V
`,
D
`) donde:
-
L
` designa el primer nivel de sangrado en el árbol
asociado;
-
V
` es el resultado de aplicar la figura D-29/X.290,
parte 2 a V y el veredicto asignado al árbol;
-
D
` es la unión ordenada de EVAL-DEFAULT (ref-árbol) y
D;
ii)si V ninguno, retornar V;
E)en otro caso:
-invocar EXECUTE(e) donde e es el suceso devuelto por e(3)B;
-si e tiene un veredicto, calcular V como el resultado de aplicar la figura D.29/X.290, parte 2 a V y el veredicto asignado al suceso, devolver V;
F)calcular L = nivel siguiente de sangrado, teniendo en cuenta cualquier
GOTO
que exista;
G)si L designa un conjunto vacío, terminar y devolver V, en otro caso continuar con e(3)A;
4)la interpretación en un caso de prueba se da por EVAL-TREE (L, ninguno, D) donde:
L = primer nivel de sangrado del primer árbol en la descripción de comportamiento del caso de prueba;
D = EVAL-DEFAULT (referencia caso prueba);
A)si EVAL-TREE devuelve
`error'
, entonces la especificación está
incompleta;
B)si el resultado es
`ninguno'
, entonces la especificación de caso de
prueba está incompleta;
C)en otro caso EVAL-TREE devuelve el veredicto.
D.8
Parte declaración de limitaciones
Es necesario describir en detalle la codificación de parámetros en UDP y PSA. La codificación de parámetros se describe utilizando un método tabular (Î D.8.1.1), o un método que aproveche la ventaja de la notación NSA.1 (Î D.8.3). En la columna referencia de limitaciones de los cuadros utilizados en la parte dinámica se hace referencia a valores particulares (Î D.6.13).
D.8.1
Codificaciones de parámetros
Una PSA o una UDP pueden considerarse como una lista de parámetros. Sin embargo, dada la importancia de la codificación de las UDP en las pruebas, puede ser más adecuado no sustraerse a la codificación de las UDP y considerar una UDP como una lista de campos tales como longitud, tipo de parámetro, valor de parámetro.
D.8.1.1
Método tabular
Si se asigna a cada campo un valor efectivo, la UDP o PSA efectiva pueden representarse por una lista de valores. En segundo lugar, se puede formar un conjunto de listas, siendo cada elemento de este conjunto una posible lista de valores de todas las combinaciones. Entonces, para cada UDP o PSA, este conjunto puede representarse por un cuadro. El cuadro de declaraciones de limitaciones de UDP deberá tener el formato indicado en la figura D-34/X.290, parte 2.
Figura D-34/X.290, Parte 2 [T34.290], p. (traiter comme tableau
MEP)
Nota
- En el texto que sigue hay una tabla
correspondiente de PSA o PLA para cada cuadro de UDP que aparezca. La proforma
de PSA o PLA es similar en todos sus detalles con excepción de que para cada
ocurrencia de UDP en el cuadro, campos sustituyen la palabra PSA o PLA.
Cada inscripción de campo en la columna de nombre de campo deberá haber sido declarada en la declaración de UDP (o PSA, PLA). Los valores asignados a cada campo serán del tipo especificado en la declaración de UDP (o PSA, PLA).
En los casos en que una limitación contenga sólo un pequeño número de campos, o cuando sólo haya un pequeño número de limitaciones, puede usarse la forma compacta de la proforma de las tablas de limitaciones, indicada en la figura D-35/X.290, parte 2
Figura D-35/X.290 Parte 2, [T35.290], p. (traiter comme tableau
MEP)
El ejemplo D-39 muestra nombres de campo en la parte superior del cuadro, y
diferentes ejemplos de UDP en las filas del cuadro. Sin embargo, cuando el
número de campos es demasiado grande para que puedan situarse convenientemente
en una página, se permite una transposición del cuadro.
Ejemplo D-39
- Dada una UDP X, con dos campos P1 y P2,
si los valores posibles para P1 y P2 son 0 y 1, se tiene el cuadro representado
en la figura D-36/X.290, parte 2.
Las columnas referencia de limitaciones de la parte dinámica podrían entonces contener inscripciones tales como X(S1) y X(S4).
D.8.1.2
Valores genéricos
Las limitaciones pueden parametrizarse utilizando valores genéricos. Estos deberán presentarse en el formato indicado en la figura D-37/X.290, parte 2. También en este caso puede utilizarse una versión compacta del formato, como el representado en la figura D-38/X.290, parte 2.
Figure D-36/X.290, partie 2 [T36.290], p.9 (traiter comme tableau
MEP)
Figure D-37/X.290, partie 2 [T37.290], p.10 (traiter comme
tableau MEP)
Figure D-38/X.290, partie 2 [T38.290], p.11 (traiter comme
tableau MEP)
Estos conceptos se ilustran en los ejemplos D-39 y D-40.
Ejemplo D-40
- La invocación de la UDP X (figura
D-39/X.290, parte 2) en un paso de prueba puede efectuarse como sigue: X(S1),
X(S2), X(S3), X(S4), X(S5(0)), X(S5(1)) o X(S5(Var)), donde Var es o una
variable (véanse los Î D.5.6 y D.8.2) o un nombre de campo de una UDP recibida
(véase Î D.5.9) o una expresión.
Figure D-39/X.290, partie 2 [T39.290], p. (traiter comme tableau
MEP)
Ejemplo D-41
- La forma de definir valores genéricos
ilustrada en el ejemplo D-40 puede aplicarse también a un grupo de campos:
Dada la UDP Y con tres campos Q1, Q2 y Q3 y con posibles valores 0 y 1, el cuadro puede representarse como se indica en las figuras D-40/X.290, D-41/X.290 y D-42/X.290, parte 2.
Figure D-40/X.290, partie 2 [T40.290], p.13 (traiter comme
tableau MEP)
Figure D-41/X.290, partie 2 [T41.290], p.14 (traiter comme
tableau MEP)
Figure D-42/X.290, partie 2 [T42.290], p.15 (traiter comme
tableau MEP)
La invocación de la UDP Y en un paso de prueba puede hacerse como sigue:
Y(TI), Y(T2(C1)), (T2(C2)), (Y(T2(D1))), etc.
A los cuadros que definen valores genéricos no se hará referencia directamente en la parte de comportamiento principal, sino solamente a través de un nombre de limitación parametrizada [por ejemplo, B1 se utiliza como Y(T2(B1)) en el ejemplo D-41].
D.8.2
Variables libres
D.8.2.1
Introducción
En muchos casos es necesario utilizar los valores recibidos en una UDP (por ejemplo SRC-REF en una CC) para llenar un campo correspondiente cuando se envía otra UDP (por ejemplo, DST-REF en DT). Aunque ello puede lograrse siguiendo el rastro del valor en una variable desde la parte dinámica, puede ser también conveniente representar esto en una forma más concisa utilizando una variable libre en la parte de limitaciones. Esta variable se declarará al comienzo de la parte de limitaciones, al declarar éstas. Los ejemplos D-40 y D-41 no son ejemplos de variables libres. En este caso, se puede representar ese valor por una variable libre que se considerará global a la parte de limitaciones.
Estas variables libres se declararán utilizando la proforma indicada en la figura D-43/X.290, parte 2.
Una variable está acotada a un valor cuando una UDP en la cual ella aparezca ocurre como un parámetro de una PSA recibida.
D.8.2.3
Variables en limitaciones
Donde se aplique una limitación, toda variable que aparezca en el campo de una limitación tiene, o adopta, el valor real enviado o recibido.
a)Si la variable ya está acotada a un valor:
1)se envía ese valor; o
2)ese valor tendrá que ser el valor recibido en ese campo si se aplica la limitación. (En otro caso, la limitación no se aplica.)
b)Si la variable no está acotada:
1)se puede enviar cualquier valor del tipo apropiado; o
2)la variable pasa a estar acotada al valor recibido como resultado de la aplicación de la limitación.
Una aplicación típica de esta propiedad podría ser preservar direcciones, o referencias de conexiones de UDP a UDP. Esto puede que no ofrezca interés en la mayor parte de los casos, pero es importante que el mismo valor esté presente en varias UDP diferentes.
Figure D-43/X.290, partie 2 [T43.290], p.16 (traiter comme
tableau MEP)
D.8.2.4
Convenios
Los convenios indicados en el cuadro D-1/X.290, parte 2 se aplican a las inscripciones en el cuadro de limitaciones.
Tableau D-1/X.290, partie 2 [T44.290], p.17
D.8.2.4.1
Concordancia de patrones en una cadena de
caracteres
Dentro de una cadena de caracteres, un ? en el lugar de un carácter significa que se acepta cualquier carácter simple. Cuando la cadena de caracteres deba incluir el símbolo ? propiamente dicho, éste se indicará haciéndolo preceder por el carácter especial . El carácter propiamente dicho se escribe .
Dentro de una cadena de caracteres, un * significa que son aceptables cero, uno o más caracteres. Este * deberá concordar con la secuencia de caracteres más larga posible, de acuerdo con el patrón especificado por los símbolos que rodean al *. (Cuando la cadena de caracteres incluye el propio símbolo *, éste se indicará haciéndolo preceder del carácter especial .)
D.8.3
Método modular NSA.1
D.8.3.1
Objeto del método
Este método presupone que están disponibles descripciones NSA.1 de las UDP o PSA, las cuales se utilizan como una base conveniente para la descripción de las limitaciones.
D.8.3.2
Descripción del método modular NSA.1
Cuando un parámetro de UDP o de PSA está definido en la parte declaraciones utilizando NSA.1, es aplicable el método modular NSA.1. Este método proporciona las siguientes facilidades principales:
a)
Especificación:
la especificación (parcial) de valores
NSA.1. Típicamente, habrá UDP correctas, pero podrán construirse y utilizarse
valores NSA.1 arbitrarios.
Nota
- NSA.1 requiere valores explícitos, en tanto que
el método modular permite valores intrascendentes.
b)
Denominación:
estos valores pueden tener un nombre, de
modo que pueda hacerse referencia a los mismos desde la parte dinámica.
c)
Anotación:
los valores pueden ser anotados con una
forma ampliada de una notación de tipo NSA.1. Las codificaciones de valores
pueden especificarse de modo que puedan conseguirse dos valores idénticos
codificados por dos métodos diferentes. Pueden imponerse restricciones a
componentes de valores mediante el uso de variables libres, o los convenios
sobre - y ?, de la misma manera que pueden imponerse restricciones a los
valores de campo en el método tabular.
d)
Sustitución:
pueden construirse valores nuevos a partir
de valores viejos sustituyendo componentes de los valores existentes por
valores nuevos.
D.8.3.3
Especificación de valores
Cuando se especifique un valor NSA.1, deberán suministrarse las siguientes informaciones adicionales:
a)Un nombre.
Es necesario para identificar el valor.
Cuando se especifican valores NSA.1 grandes y complejos, a veces conviene poder imponer limitaciones a los componentes seleccionados de un valor solamente. Estos componentes pueden definirse señalando un trayecto a través de la declaración de tipo NSA.1 que corresponde al valor, identificando elementos en cada nivel por un nombre, y utilizando un punto (símbolo . ) para separar cada nombre de elemento.
b)El tipo NSA.1 del valor.
Es necesario para fines de documentación, de modo que el valor NSA.1 pueda relacionarse con una definición apropiada de tipo NSA.1 que se encontrará en la norma de protocolo correspondiente.
A fin de hacer que una definición de tipo NSA.1 sea adecuada para documentar definiciones de valor NSA.1 es necesario cierto número de abreviaturas y limitaciones de la notación de tipo NSA.1, las cuales se indican a continuación. Algunas de ellas representan modificaciones de la gramática que figura en (Recomendación X.208, anexo F).
Se utiliza la siguiente notación:
&lab;
NonTerminal
> ::=
.^.^.
| <
NewProds
>
donde <
NonTerminal
> se define en (Recomendación
X.208, anexo F) y .^. representa esa definición.
&lab;
NewProds
> representa las ampliaciones de la NCTA.
1)Se permite omitir el <
Type
> en una combinación
&lab;
identifier
> <
Type
>. Las
siguientes producciones se añaden a (Recomendación X.208, anexo F):
&lab;
ElementType
> ::=
.^.^.
| <
TTCNElementType
>
&lab;
TTCNElementType
> ::=
&lab;
TTCNNamedType
>
&lab;
TTCNNamedType
> ::=
&lab;
identfier
>
| <
NamedType
>
2)En un <
ChoiceType
>, sólo puede utilizarse el
tipo de la elección efectuada. Sin embargo, a fin de recordar al lector que se
ha hecho una elección, puede retenerse la palabra clave CHOICE. La siguiente
producción reemplaza a la producción para
&lab;
ChoiceType
> en (Recomendación X.208, anexo F):
&lab;
ChoiceType
> ::=
&lab;
TTCNNamedType
>
| CHOICE <
TTCNNamedType
>
3)El <
SelectionType
> no se utilizará. Se
utilizará en su lugar, el tipo real seleccionado.
&lab;
SelectionType
> se suprime de la lista de posibles
&lab;
BuiltinTypes
> en (Recomendación X.208, anexo F).
4)El <
SequenceOfType
> se modifica para permitir
la denominación de los valores reales que han de enviarse hacia el exterior. La
siguiente producción reemplaza la producción para
&lab;
SequenceOfType
> en (Recomendación X.208, anexo F).
&lab;
SequenceOfType
> ::= SEQUENCE OF
{ <
SequenceOfTypeList
> }
&lab;
SequenceOfTypeList
> ::=
.^.^.
| <
SequenceOfTypeList
>
&lab;
SequenceOfTypeType
>
&lab;
SequenceOfTypeType
> ::=
&lab;
Type
> . <
number
>
Todos los Tipos que aparecen en una
&lab;
SequenceOfTypeList
> serán idénticos. Los números en
una <
SequenceOfTypeList
> serán distintos. Se
utilizarán para indexar los tipos.
c)Una especificación de las limitaciones de codificación sobre el valor.
Si es aceptable cualquier codificación válida del valor puede omitirse la especificación de las limitaciones de codificación para el valor. En otro caso, la especificación de codificación constará de dos partes:
1)Una especificación del <
Identifier
> que aparece
en la codificación del valor. El <
Identifier
>
consistirá en un número entero de octetos.
&lab;
Identifier
> ::= [
&lab;
IdentifierValue
> ]
&lab;
IdentifierValue
> ::=
&lab;
hstring
>
| <
bstring
>
| <
variable
>
No es necesario que el <
IdentifierValue
> sea
correcto con respecto a la especificación de tipo NSA.1. Esto significa que
pueden especificarse UDP codificadas incorrectamente.
2)Una especificación de la <
Length
> que ha de
utilizarse en la codificación del valor. La <
Length
>
consistirá en un número entero de octetos.
&lab;
Length
> ::= [
&lab;
LengthValue
> ]
&lab;
LengthValue
> ::=
| <
hstring
>
| <
bstring
>
| <
variable
>
| LI
| SD
| LD
| LD &lab;number>
| IN
LI especifica que puede utilizarse cualquier codificación válida de la longitud correcta.
SD especifica que el tipo de longitud Corta Definida aparecerá en la codificación.
LD especifica que el tipo de longitud Larga Definida aparecerá en la
codificación. Si aparece <
number
>, la longitud se
rellenará hasta <
number
> octetos.
IN especifica que el tipo de longitud
Indefinida
aparecerá en la codificación.
3)Una especificación del valor propiamente dicho.
&lab;
Value
> ::= [
&lab;
TTCNNamedValue
> ]
&lab;
TTCNNamedValue
> ::=
| <
NamedValue
>
| <
valuereference
>
| ?
| -
| <
in
> <
identifier
>1
| REPLACE <
identifier
>2
| BY <
TTCNNamedValue
>
&lab;
in
> ::= IN | <
empty
>
&lab;
BuiltinValue
> ::=
.^.^.
| <
TTCNNamedValue
>
Los valores se especifican utilizando la notación de valor NSA.1 normalizada con las siguientes ampliaciones:
A)Podrán ser referenciados valores definidos en el Î D.5.4, parámetros de series de pruebas, o en cualquier otro lugar de la parte restricciones.
B)Los valores <
CharacterString
> pueden designarse
encerrando la cadena entre comillas. Dentro de estas comillas, deberá
utilizarse un par de comillas consecutivas para designar el propio carácter de
comillas.
C)Se utiliza un ? para especificar valores
`intranscendentes'
. Un ?
que enviará el probador puede adoptar cualquier valor que esté autorizado en
ese contexto (de acuerdo con la norma de servicio o de protocolo
correspondiente). Un probador no tiene necesidad de verificar valores recibidos
especificados como ?.
D)Se utiliza un - para especificar que la codificación del valor estará ausente.
E)La operación de sustitución permite reemplazar componentes de valores
existentes por valores NSA.1 (con sus limitaciones correspondientes de tipo y
de codificación), produciendo así nuevos valores, con el significado
sustituir el componente denominado
&lab;
identifier
>1
del valor
&lab;
identifier
>1
por el
&lab;
TTCNNamedValue
>.
Esta información se proporcionará en el formato indicado en la figura D-44/X.290, parte 2. El dibujo de las líneas de casillas es facultativo en este caso.
Figure D-44/X.290, partie 2 [T45.290], p. (traiter comme tableau
MEP)
Ejemplo D-42
- Este ejemplo ilustra cómo referenciar
valores UDP desde la parte dinámica. Se define una UDP denominada UDP A:
UDPA ::= SEQUENCE {INTEGERBOOLEAN}
y la variable global N. Un ejemplo de UDP podría ser:
UDPEsperada ::= SEQUENCE {INTEGER [10] [LI] NBOOLEAN [ID] [LI] TRUE}
Entonces, en la descripción de comportamiento se puede
escribir:
?Dataind[(UserData ExpectedPDU) AND (N = 27)]
APéNDICE I (a la Recomendación X.290, Parte 1)
Aplicabilidad
de los
métodos de prueba a protocolos
ISA*
Introducción
Los protocolos de la capa física y los protocolos de control del acceso a los medios están fuera del ámbito de esta Recomendación. Ninguno de los cuatro métodos definidos en esta Recomendación está destinado a aplicarse a esos protocolos.
I.2
Protocolos de enlace de datos
Para probar protocolos de enlace de datos deben considerarse los siguientes puntos:
a)El método de prueba local monocapa es aplicable solamente si la frontera de la capa física de la RSP es accesible. En la práctica este caso es improbable, salvo cuando se prueba un prototipo o el diseño de un algoritmo antes de llevarlo a soporte físico o soporte firme.
b)Dado que el servicio físico no es de extremo a extremo, los métodos de prueba distribuida, coordinada y a distancia, monocapa, son aplicables solamente cuando el probador inferior externo está conectado al SSP por un solo enlace, y no cuando está conectado mediante una red.
c)Los métodos de prueba distribuida, coordinada y a distancia, monocapa, sólo son aplicables si el probador inferior puede realizarse de modo que ejerza control sobre las primitivas del servicio físico (o quizás, de una manera más realista, sobre las UDP del enlace físico y del enlace de datos). Esto pudiera ser difícil en algunos tipos de subred.
d)La mayor parte de los protocolos para las subredes reales se definieron antes de que se pensara en servicios físicos o de enlace de datos. En consecuencia, las fronteras de servicio por debajo del servicio de red, por lo general, no están disponibles o no están bien definidas. Por tanto, la opinión general es que el control y la observación para pruebas de la capa de enlace de datos deben interpretarse en base a UDP y no a PSA. Sin embargo hay algunos sistemas que proporcionan, en efecto, una frontera del servicio de enlace de datos o un interfaz similar que depende de la tecnología.
Si no es posible la prueba monocapa de un protocolo de enlace de datos, deben considerarse métodos de prueba multicapa o métodos de prueba monocapa insertada.
I.3
Protocolos de red
Para los protocolos de red deben utilizarse métodos de prueba que dependen de que la RSP sea un sistema final o un sistema abierto de relevo.
Dado que los servicios por debajo del servicio de red generalmente no están disponibles o bien definidos, existe la opinión general de que el control y la observación para las pruebas de la capa de red deben interpretarse en base a UDP y no a PSA.
Debe reconocerse que con algunas tecnologías de subred se requieren más de tres protocolos para proporcionar el servicio de red. Cada uno de estos protocolos puede probarse separadamente, o en una combinación cualquiera de protocolos adyacentes.
Considerando la capa en su conjunto, tanto las primitivas de servicio abstracto de red como las del servicio abstracto de enlace de datos pueden ser controladas y observadas. En consecuencia, para sistemas finales, son aplicables los cuatro métodos de prueba monocapa (no insertada), pero como el servicio de enlace de datos no es de extremo a extremo, el probador inferior tiene que conectarse al SSP por medio de un enlace simple cuando se utilizan métodos de prueba distribuida, coordinada y a distancia en una sola capa.
Tanto el método de prueba en bucle como el método de prueba transversal son aplicables a la prueba de sistemas de relevo de red.
I.4
Protocolo de transporte
Todos los métodos de prueba abstracta definidos en esta Recomendación son aplicables a las pruebas de conformidad del protocolo de transporte.
I.5
Protocolo de sesión
Todos los métodos de prueba abstracta definidos en esta Recomendación son aplicables a las pruebas de conformidad del protocolo de sesión.
En el caso de un grupo grande de sistemas será conveniente probar el protocolo de sesión en combinación con los protocolos de presentación y de aplicación. La prueba del protocolo de sesión debe por tanto efectuarse normalmente de una de las maneras siguientes:
a)como una realización monocapa o en combinación con protocolos subyacentes, para probar la prestación de un servicio de sesión universal, capaz de admitir varias aplicaciones diferentes; probablemente sean apropiados los métodos de prueba distribuida monocapa o coordinada monocapa;
b)en combinación con protocolos de presentación y de aplicación, para realizar la prueba en un contexto de aplicación específico; probablemente sean apropiados los métodos de prueba a distancia monocapa o distribuida monocapa.
I.6
Protocolos de presentación y aplicación
I.6.1
Comentarios generales
Las pruebas de conformidad pueden especificarse en forma abstracta mediante primitivas de servicio, independientemente de que tengan asociada cualquier noción de un punto de acceso al servicio. Así, siempre que exista cierta relación de correspondencia entre las primitivas del servicio de aplicación y efectos reales que puedan observarse y»o controlarse, podrán especificarse pruebas mediante primitivas del servicio de aplicación. La observación y control de las primitivas de servicio pueden ser indirectos, debido a la naturaleza de la correspondencia con los efectos reales, pero en la medida en que sea posible dicha correspondencia, pueden efectuarse las pruebas especificadas de esta forma. Es difícil encontrar un ejemplo de una primitiva del servicio de aplicación que nunca pueda tener una realización capaz de ser observada y controlada; en realidad, si hubiera alguna, lo más probable sería que no debieran definirse como primitivas, en absoluto.
Se acepta que, en algunas circunstancias, las normas o Recomendaciones
sobre los protocolos puedan especificar requisitos de efectos reales que deban
obtenerse como resultado de intercambios de protocolo [en particular, esto es
evidente en la manipulación y transferencia de trabajos (MTT)]. Sin embargo,
estos requisitos sobre efectos reales deben mantenerse bien diferenciados de
los requisitos normales de conformidad de protocolo, si es posible en normas o
Recomendaciones separadas (tal vez funcionales). Algunos de estos requisitos de
conformidad
`no relativos a los protocolos'
podrían comprobarse por
medio de métodos de prueba abstracta, de uso general, definidos en esta
Recomendación, pero en general requerirán métodos de prueba específicos de la
aplicación, que están fuera del ámbito de la presente Recomendación.
I.6.2
Control de asociación
El control de asociación es inhabitual ya que comprende tres fases, la segunda de las cuales está definida por otro elemento del servicio de aplicación (ESA). Las primitivas del servicio de control de asociación podrían ser observadas y controladas en algunos sistemas. En tales casos, sería posible probar el protocolo de control de asociación (posiblemente en combinación con el protocolo de presentación) aislado de cualquier otro ESA. Para la prueba aislada del control de asociación tendría que utilizarse un ESA ficticio para fines de prueba. Podría utilizarse cualquiera de los métodos de prueba, incluso el método de prueba coordinada con un protocolo de gestión de pruebas definido como un ESA ficticio. Sin embargo, estas pruebas aisladas tienen un valor limitado, pues sólo podrían probar la máquina de protocolo, y quedaría sin probar la correspondencia entre la sintaxis abstracta y la sintaxis de transferencia. Este aspecto sólo puede probarse para un ESA dado. La utilización de un ESA ficticio en la prueba del control de asociación no implicaría en general las correspondencias de sintaxis que otras ESA reales sí comprenderían. En consecuencia, se debe dar prioridad a la prueba del control de asociación en combinación con el protocolo de presentación y otro ESA real, utilizando métodos de prueba a distancia o distribuida, monocapa, insertada. En otras palabras, se debe hacer énfasis en la prueba de operaciones en un contexto de aplicación.
El protocolo de control de asociación no tiene requisitos de conformidad no relativos a los protocolos.
I.6.3@
Terminal Virtual (TVI)
\
Un protocolo de terminal virtual puede utilizarse de tres modos: terminal a TVI anfitrión, terminal a terminal y TVI anfitrión a anfitrión. En los tres casos, las primitivas de servicio TVI podrían ser observables y controlables en una proporción suficientemente grande de sistemas para que su uso en una especificación de prueba sea realista. Los TVI anfitriones pueden proporcionar interfaces de servicio TVI para permitir el establecimiento de procesos de usuario arbitrarios, de modo que en una realización de un probador superior pueda utilizarse tal interfaz. Los terminales, por otra parte, probablemente proporcionarán el control y observación de primitivas de servicio TVI sólo indirectamente a través de un interfaz de usuario que puede ser muy diferente del servicio TVI. Algunos terminales podrían, además, proporcionar un acceso directo a un interfaz del servicio TVI.
En consecuencia, los métodos de prueba a distancia y distribuida en una sola capa, son aplicables a las pruebas de protocolos TVI.
I.6.4@
Transferencia, acceso y gestión de ficheros
(TAGF)
\
En la práctica, la observación y el control de primitivas de servicio es
diferente para los iniciadores y los respondedores de TAGF. En general, pueden
ser observadas y controladas cuando se prueban iniciadores, pero no cuando se
prueban respondedores. El problema de los respondedores TAGF es que habrá
efectos reales asociados con sus primitivas de servicio, pero la observación y
el control de éstas serán muy específicos del sistema. Esto se debe a que,
aunque el
`usuario'
del servicio TAGF en un respondedor es el
dispositivo virtual de almacenamiento de ficheros (DVAF), dentro del sistema
sometido a prueba, los efectos sobre el DVAF sólo pueden percibirse a través
del dispositivo real de almacenamiento de ficheros. Por eso, el método de
prueba a distancia monocapa es aplicable tanto a los iniciadores como a los
respondedores TAGF, mientras que el método de prueba distribuida monocapa sólo
es aplicable a los iniciadores TAGF.
La prueba de la gestión de ficheros puede efectuarse por sí misma si es necesario, y no depende de que se hayan establecido las unidades funcionales de lectura y escritura. La prueba de la transferencia y acceso de ficheros, sin embargo, sí depende de las unidades funcionales que están establecidas.
Las pruebas de la transferencia y acceso de ficheros para sistemas de lectura solamente, o para sistemas de lectura/escritura, son relativamente simples. Los sistemas de lectura/escritura pueden probarse transfiriendo ficheros al sistema y releyéndolos. Aunque, en general, nada puede evitar una modificación local de esos ficheros entre la lectura y la escritura, dicha modificación podría evitarse durante la ejecución de la serie de pruebas, manteniendo a los otros usuarios fuera del sistema. Los sistemas de sólo lectura, pueden probarse cargando previamente el conjunto requerido de ficheros por medios locales y aplicando las pruebas para leerlas utilizando TAGF. En la prueba de sistemas de escritura solamente, la asignación de veredictos a resultados tiene que basarse en una interpretación sumamente específica con respecto al sistema (posiblemente subjetiva), de lo que es el resultado (es decir, un registro detallado de sucesos de prueba observados).
Otra forma de examinar esta situación es reconocer que el TAGF tiene requisitos de conformidad no relativos a los protocolos que se relacionan con los efectos reales que deben producirse como resultado de intercambios de UDP. Estos requisitos pueden probarse por métodos de prueba general a condición de que los métodos comprendan la observación de primitivas de servicio TAGF (es decir, la ejecución de la prueba implica la observación de efectos reales asociados con tales primitivas). Para que los efectos reales se observen durante las pruebas, será necesario suministrar al laboratorio de pruebas una descripción detallada de la correspondencia de las primitivas de servicio con efectos reales. Esto equivale a hacer que sea necesaria una definición completa del dispositivo real de almacenamiento de ficheros. Esta información debe entonces referenciarse por la ISRPP, siendo su volumen mayor que el que sería deseable incluir explícitamente en la ISRPP o en el ECRP.
Hay un requisito de conformidad según el cual, a los efectos de las pruebas, una realización TAGF debe poder utilizarse sin los atributos de uso privado o calificación legal. Sin embargo, hay otros atributos que son difíciles o prácticamente imposibles de probar. Por ejemplo, los atributos de protección de datos y seguridad pertenecen a esta categoría, porque la información necesaria para probarlos probablemente no esté disponible. Por otra parte, probablemente será también imposible verificar la posibilidad de utilizar atributos de almacenamiento para bloquear un fichero contra un acceso no-ISA, porque el hecho de que el laboratorio de pruebas no pueda acceder a tal fichero no da indicación alguna sobre las capacidades de un usuario que tenga un permiso de acceso más amplio.
I.6.5
Transferencia y manipulación de trabajos (TMT)
La situación relativa a la observación y el control de las primitivas de servicio es similar a la que ya se ha visto para la TAGF. Para los iniciadores de la TMT, probablemente será posible la observación y el control de las primitivas de servicio y por eso son aplicables el método de prueba distante monocapa y el método de prueba distribuida monocapa. Para los respondedores TMT, sólo puede utilizarse el método de prueba distribuida monocapa si pueden observarse los efectos asociados con las primitivas de servicio. Esto implicará conocer una relación de correspondencia, que puede ser compleja. Sin embargo, la norma de los protocolos TMT plantea exigencias al realizador, que deberá indicar los efectos que se producen y presentar cierta información de un modo legible por el ser humano. Típicamente, estos efectos se refieren a diversos documentos que se están creando y haciendo circular. Así, para los iniciadores TMT, es posible utilizar tanto el método de prueba distribuida monocapa como el método de prueba distante monocapa.
Las primitivas de indagación/estado pueden comprobarse fácilmente. Pueden observarse informes sobre la progresión de un trabajo.
Se necesita un método de prueba multisistema para probar aspectos
fundamentales de la TMT. Todos los sistemas, menos uno, podrían ser probadores
(inferiores) y varios probadores (inferiores) podrían estar realizados en un
mismo sistema real. Sin embargo, es necesario que haya por lo menos un probador
(inferior) externo desde el punto de vista abstracto. Por ejemplo, las pruebas
de situaciones de fallo deben abarcar la situación en que un sistema
`quiebra'
, y se espera que los sistemas restantes se restablecerán.
Puede ser también conveniente probar una colección de sistemas más bien que un
sólo sistema. Así, como mínimo, podría haber dos nuevos conjuntos de métodos de
prueba, uno en que hubiese un solo SSP y dos probadores (inferiores), y otro
con dos SSP y un solo probador (inferior). Tales métodos de prueba multisistema
están fuera del ámbito de esta Recomendación.
Nota
- Para el STM existe una exigencia similar en
cuanto al método de prueba multisistema.
I.6.6
Protocolos de tratamiento de mensajes
Hay series de pruebas normalizadas por el CCITT para tres protocolos, a saber, el servicio de mensajería interpersonal (SMIP) (Protocolo P2), el servicio de transferencia de mensajes (STRM) (Protocolo P1) y el servidor de transferencia fiable (STF). Existen también dos configuraciones de sistema básico que deben ser consideradas.
La primera es la
`configuración de prueba de sistema final'
que
puede utilizarse para probar P2, P1 y STF. La segunda es la
`configuración
de prueba de agente de transferencia de mensajes de relevo'
que puede
utilizarse para probar los aspectos del protocolo P1 relacionados con el
relevo.
En la serie de pruebas del protocolo P2 se utiliza un PCO externo en la
frontera entre la capa de agente de usuario y el STRM y un PCO en la frontera
superior de la RSP. Sin embargo, el protocolo P2 no incluye definiciones de
PSA, por lo que ha sido necesario construir PSA
`ficticios'
para
describir la serie de pruebas abstractas de una manera formal.
La serie de pruebas de protocolo P1 para comprobar los sistemas de extremo utilizan un PCO externo en la frontera entre la capa de transferencia de mensajes y el STF, y un PCO en la frontera superior de la RSP. Sin embargo, para la prueba de la entrega a múltiples destinos es necesario que haya más de un agente de usuario, lo que a su vez exige que haya más de un PCO en la frontera superior de la RSP. En la serie de pruebas de protocolo P1 para la prueba del relevo se utilizan dos PCO externos en la frontera entre la capa de transferencia de mensajes y el STF.
Para la serie de pruebas del STF se utiliza un PCO externo en la frontera entre la capa del servidor de transferencia fiable y la capa de sesión y un PCO en la frontera superior de la capa de agente de usuario dentro del SSP. La serie de pruebas del STF incluye también un tercer punto de acceso al servicio en la descripción de los casos de prueba; este punto se encuentra entre la capa de transferencia de mensajes y el STF dentro de la SSP; se utiliza para aclaración solamente y no es un PCO.
En consecuencia, se utiliza el método de prueba distribuida monocapa para la prueba de extremo a extremo de los protocolos P1 y P2; se utiliza el método de prueba distribuida monocapa insertada para probar el STF; y se utiliza el método de prueba transversal para probar los aspectos del protocolo P1 relacionados con el relevo. En todos los casos de prueba de sistema de extremo, es también aplicable el método de prueba distante monocapa.
Otro punto a señalar es que las series de pruebas abstractas para los protocolos P1 y P2 incluyen las pruebas de codificación y decodificación de la Recomendación X.409.
Nota
- Las series de prueba a que se hace referencia
en esta Recomendación se relacionan con las realizaciones de pruebas conformes
a las versiones de 1984 de las Recomendaciones de la serie X.400 del CCITT.
I.6.7@
Compromiso de concurrencia y recuperación (CCR)
\
Por razones similares a las indicadas en el Î I.6.2 para el control de asociación, el CCR debe probarse como parte de un contexto de aplicación, como es el requerido por la TMT. Así, son aplicables métodos de prueba distante monocapa insertada, y distribuida monocapa insertada.
El CCR entraña una exigencia para conservar datos seguros en el caso de grandes rupturas, aunque se reconoce que no es posible su realización en la práctica en ciertas situaciones de error demasiado graves (por ejemplo, explosión de bombas en las instalaciones). A fin de probar que se satisface la exigencia de conservar datos seguros aun en tales situaciones, es necesario que el realizador declare en el ECRP o la ISRPP qué situaciones de error no afectarían a la conservación de datos seguros.
I.6.8
Presentación
Las primitivas de servicio son potencialmente observables y controlables en la misma medida que para las capas inferiores. Así son teóricamente aplicables, los cuatro métodos de prueba monocapa (no insertada). Sin embargo, como se ha expresado anteriormente en relación con el control de asociación, la prueba de protocolo de presentación de manera aislada con respecto a un ESA tiene un valor limitado, porque con ella podría sólo probarse la máquina de protocolo, y quedaría sin probar el aspecto de mayor interés de la capa de presentación: la correspondencia entre la sintaxis abstracta y la sintaxis de transferencia. En consecuencia, debe preferirse la prueba de protocolo de presentación insertada bajo control de asociación, y otro ESA. Por lo tanto, los métodos de prueba aplicables correspondientes son el método de prueba distante monocapa insertada y el método de prueba distribuida monocapa insertada.
I.6.9
Sintaxis de transferencia
La sintaxis de transferencia (por ejemplo, NSA.1 o X.409) son algo diferentes de las Recomendaciones* sobre protocolos ISA* en lo que concierne a la conformidad. En general, no habría pruebas de conformidad de las reglas de codificación de una sintaxis de tranferencia independiente del protocolo de aplicación, si se utilizan esas reglas.
Se señala que existen, por ejemplo, requisitos de conformidad en la Recomendación sobre las reglas de codificación básicas NSA.1. El hecho de que se requiera que cuando haya codificaciones alternativas éstas se proporcionen como una opción del emisor y que los receptores conformes deban soportar esas alternativas, requiere, en efecto, una prueba específica de conformidad de la NSA.1. Sin embargo, las reglas de codificación básicas de NSA.1 serán siempre probadas con el protocolo de presentación y se eligirán los métodos apropiados para ese protocolo.
I.7
Protocolos de gestión
Puesto que la gestión de sistema y la gestión de aplicación residen en la capa de aplicación, los comentarios generales sobre cuál de las dos gestiones es aplicable a los protocolos de gestión conciernen también a los protocolos de gestión de sistema y de aplicación. En particular, pueden especificarse casos de prueba para tales protocolos en forma de primitivas de servicio de gestión, a condición de que haya alguna correspondencia entre las primitivas de servicio de gestión y los efectos reales que pueden observarse y/o controlarse. Si existen esas primitivas de servicio y esa correspondencia, las pruebas pueden realizarse por el método de prueba distribuida. En otro caso, la prueba puede efectuarse mediante el método de prueba distante.
Asimismo, como ocurre con otros protocolos de aplicación, el intercambio de
UDP de un protocolo de gestión de sistema puede probarse utilizando los métodos
de prueba descritos en esta Recomendación. La aplicación de pruebas de
conformidad a otros aspectos de los servicios de gestión de aplicación y
sistema y las actividades
`no relativas al protocolo'
conexas de
entidades de gestión están, sin embargo, fuera del ámbito de esta
Recomendación.
En consecuencia, y por el hecho de que los protocolos de gestión de sistema
llevan asociados requisitos de conformidad
`no relativos al protocolo'
,
la prueba de conformidad de acuerdo con estos protocolos no puede efectuarse
totalmente mediante los métodos descritos en esta Recomendación. Por ejemplo,
la operación correcta de la función gestión de sistema de modificar la
información en una guía no puede probarse simplemente intercambiando UDP.
Por otra parte, las funciones de gestión de sistema no se relacionan solamente con la capa de aplicación sino también con las operaciones de los protocolos subyacentes. En consecuencia, para la prueba del protocolo de gestión de sistema es necesario utilizar una realización de los protocolos subyacentes que ya han sido probados.
La prueba de protocolos de gestión de capa depende de la existencia de los protocolos correspondientes pero, dado que éstos existen, debe ser posible probarlos mediante los métodos de prueba descritos en esta Recomendación.
I.8
Protocolos en modo sin conexión
Dado que cada uno de los métodos de prueba descritos en esta Recomendación se define en base a la observación y el control de PSA y UDP, y no en base a conexiones, todos los métodos son aplicables a la prueba de los protocolos en el modo sin conexión, teniendo en cuenta las restricciones aplicables a cada capa.
APéNDICE II (a la Recomendación X.290, Parte 1)
índice de las
definiciones de términos Término
Sección
Capacidades de una RSP3.4.5
Caso de prueba3.6.13
Caso de prueba abstracta3.6.3
Caso de prueba abstracta parametrizada3.6.22
Caso de prueba ejecutable3.6.4
Caso de prueba ejecutable parametrizada3.6.23
Caso de prueba genérica3.6.6
Cliente3.4.12
Comparabilidad (de resultados)3.7.2
Cuerpo de prueba3.6.8
ECRP3.4.6
Enunciado de conformidad de realización de protocolo3.4.6
Enunciado de conformidad de sistema3.4.11
Epílogo3.6.9
Examen de conformidad estática3.5.7
Finalidad de la prueba3.6.5
Grupo de pruebas3.6.14
Informe de prueba de conformidad de protocolo3.7.8
Informe de prueba de conformidad de sistema3.7.7
IPCP3.7.8
IPCS3.7.7
ISRPP3.4.8
Laboratorio de pruebas3.4.13
Método de prueba a distancia3.8.12
Método de prueba abstracta3.6.1
Método de prueba coordinada3.8.11
Método de prueba distribuida3.8.10
Método de prueba local3.8.8
Metodología de comprobación abstracta3.6.2
Métodos de prueba externa3.8.9
Paso de prueba3.6.10
PCO3.8.1
PLA3.8.5
Preámbulo3.6.7
Primitiva de servicio (N) abstracta3.8.4
Primitiva local abstracta3.8.5
Probador inferior3.8.2
Probador real3.8.13
Probador superior3.8.3
Procedimiento de coordinación de pruebas3.8.6
Proceso de evaluación de conformidad3.5.10
Proforma de ECRP3.4.7
Proforma de la ICRPP3.4.9
Término Sección
Protocolo de gestión de pruebas3.8.7
Prueba activa3.5.1
Prueba de comportamiento3.5.8
Prueba de interconexión básica3.5.5
Prueba multicapa3.5.3
Prueba pasiva3.5.2
Pruebas de capacidades3.5.6
Pruebas insertadas3.5.4
PSA3.8.4
PSA (N)3.8.4
Punto de control y observación3.8.1
Realización conforme3.4.10
Realización sometida a prueba3.4.1
Realizador de la prueba3.8.14
Registro de conformidad3.7.15
Repetibilidad (de resultado)3.7.1
Requisitos de conformidad dinámica3.4.3
Requisitos de conformidad estática3.4.4
Resultado3.7.3
Resultado imprevisto3.7.5
Resultado previsto3.7.4
RSP3.4.1
Serie de pruebas3.6.12
Serie de pruebas abstractas3.6.16
Serie de pruebas abstractas parametrizadas3.6.24
Serie de pruebas abstractas seleccionadas3.6.20
Serie de pruebas de conformidad3.6.18
Serie de pruebas de interconexión básica3.6.19
Serie de pruebas ejecutables3.6.17
Serie de pruebas ejecutables parametrizadas3.6.25
Serie de pruebas ejecutables seleccionadas3.6.21
Serie de pruebas genéricas3.6.15
Sistema sometido a prueba3.4.2
SSP3.4.2
Suceso de prueba3.6.11
Suceso de prueba inoportuno3.7.11
Suceso de prueba sintácticamente inválido3.7.10
Suceso de prueba válido3.7.9
Veredicto3.7.6
Veredicto de
`desfavorable'
3.7.13
Veredicto de
`dudoso'
3.7.14
Veredicto de
`favorable'
3.7.12
{tps.non.photo "Ver.. pour MONTAGEÓ"}
APéNDICE III (a la Recomendación X.290, Parte 2)
Ejemplos de
orientación para los especificadores de proformas del
ECRP
III.1
Abreviaturas
En los siguientes ejemplos se utilizan las abreviaturas:
`m'
para
obligatorio,
`c'
para condicional,
`o'
para opcional,
`n'
para negociable, y
`-'
para no aplicable, como se define en el
7.1.7
.
III.2
Ejemplo de UDP
[T46.290], p.
III.3
Ejemplo de parámetros
Cuadro[T47.290], p.
Una variante de este ejemplo sería un ejemplo de temporizador que pudiera
incluir una columna suplementaria para unidades.
III.4
Ejemplo de servicios admitidos
Cuadro [T48.290], p.
APéNDICE IV (a la Recomendación X.290, Parte 2)
Ejemplo de
elección de métodos de prueba abstracta
IV.1
Metodología
para la capa de transporte
Objetivo: Probar una entidad de transporte (RSP monocapa) en un sistema abierto real.
Supuesto 1: El sistema abierto real se utiliza para varias aplicaciones.
Supuesto 1.1: Todas las aplicaciones utilizan el servicio de transporte ISA a través de un interfaz accesible localmente definido.
Supuesto 1.2: Todas las aplicaciones utilizan el servicio de transporte ISA a través de un interfaz de servicio de sesión accesible y localmente definido; la frontera del servicio de transporte es inaccesible.
Supuesto 1.3: Todas las aplicaciones utilizan el servicio de transporte ISA a través del servicio de sesión ISA pero no están accesibles ni la frontera del servicio de transporte ni la frontera del servicio de sesión.
Supuesto 2: El sistema abierto real se utiliza solamente para una aplicación.
Supuesto 2.1: Todas las fronteras de capa son accesibles a través de interfaces localmente definidos.
Supuesto 2.2: Ninguna frontera de capa es accesible; el sistema no proporciona interfaces, salvo para el usuario de extremo (esto corresponde a los casos de los productos monolíticos teletex y STM).
Supuesto 2.3: Ninguna frontera de capa es accesible; el sistema no proporciona interfaces: incluso el usuario de extremo no puede ganar acceso a la frontera entre las partes ISA y no-ISA del proceso de aplicación.
Los métodos de prueba externos son aplicables a estos supuestos de la manera siguiente:
1.1 prueba directa CMO o DMO 1.2 prueba insertada a través de capa de
sesión CMOI o DMOI 1.3 RMO 2.1 prueba directa CMO o DMO o LMO 2.2 prueba
insertada a través detodas las capas superiores CMOI o DMOI 2.3 RMO
Conclusiones:
Los métodos de prueba CMO, CMOI, DMO, DMOI,
RMO y LMO son, todos ellos, aplicables a la capa de transporte. Los métodos de
prueba insertada pueden utilizarse por sí mismos a través de la capa de sesión
o de todas las capas superiores.
Prioridad:
Los supuestos 1.1, 1.2 y 2.2 parecen ser
los casos más usuales (respectivamente, el método de acceso directo, el método
de acceso por sesión, y los productos monolíticos teletex y STM). Por
consiguiente, se debe dar el nivel de prioridad más elevado a los métodos CMO,
CMOI y DMOI.
IV.2
Métodos de prueba principales para uso con la capa de
transporte
Figures IV-1 àIV-4, p.22 à 25
MONTAGE:
Page paire = blanche
(86.T.MAT.S)
(CCS) ($G01WP) = N (VIII.6)
(A4) FOLIOS: VII - VIII
Saisie ........ RM
Extraction et codification 10.04.89 PC
MEP 11.04.89 PC
Corr. MEP 24.04.89 PC
Corr. DIGISET ........ ..
MAJ s/disquettes 1.05.89 CD
íNDICE DEL FASCíCULO VIII.6 DEL LIBRO AZUL
Recomendaciones X.300 a X.370
Redes de comunicación de datos
Rec. N.o Página SECCIóN 1 -
Interfuncionamiento entre redes
X.300Principios generales de interfuncionamiento entre redes públicas de
datos, y entre éstas y otras redes para la prestación de servicios de
transmisión de datos 3
Sistemas de transmisión de datos móviles
X.350
Requisitos generales de interfuncionamiento para la transmisión de
datos en los sistemas móviles públicos internacionales por satélite 199
X.351 Requisitos especiales que deben satisfacer las facilidades de
empaquetado/desempaquetado de datos (EDD) situadas en estaciones
terrenas costeras, o en asociación con ellas, en el servicio marítimo
por satélite 208
X.352 Interfuncionamiento entre redes públicas de
Gestión de interfuncionamiento
X.370 Disposiciones para la transferencia de información de gestión interredes 233 NOTAS PRELIMINARES 1 Las Cuestiones asignadas a cada Comisión de Estudio para el periodo de estudios 1989-1992 figuran en la contribución N.o 1 de dicha Comisión.
2 En este fascículo, la expresión
`Administración'
se utiliza para
designar, en forma abreviada, tanto una Administración de telecomunicaciones
como una empresa privada de explotación de telecomunicaciones reconocida.
3 Salvo que se especifique de otra manera los términos anexo y apéndice a las Recomendaciones de la serie X deberán interpretarse como sigue:
- un
anexo
^ a una Recomendación forma parte
integrante de la misma;
-un
apéndice
^ a una Recomendación no forma parte
integrante de la misma y tiene solamente por objeto proporcionar
explicaciones o informaciones complementarias.
Anexo B
disque 222 NF01/013 OPM = 01
- NF01/014 OPM = 01
NF01/024 OPM = 01
(cs,1) NF01/043 OPM = 01
(1BT) (BT..)
(86.TE.01.S)
(A1.23s) / [26s]
FOLIOS: 1 - 20
(DO PRC.COSY.2)
MEP {TPS.NON.PHOTO "[PA1]"} : OK= [1]
Saisie 26.01.89 SD
ID + LASER + diskette MAJ 16.02.89 PM
Corr. LASER (1re épreuve) = 3eme 23.02.89 YB
Espaces réservés 28.02.89 PC
AJOUTER (PA1) (CL1,0,0,0) pour MEP
MEP + LASER 2.03.89 GH/PC
Corr. MEP ........ ..
Insertion des tableaux (tabulateurs 0) 2.03.89 PC
BAT 30.03.89 PM
MAJ s/disquettes 28.04.89 CD
FASCíCULO VIII.6
Recomendaciones X.300 a X.370
REDES DE COMUNICACIóN DE DATOS:
INTERFUNCIONAMIENTO ENTRE REDES, SISTEMAS
MóVILES DE TRANSMISIóN DE DATOS, GESTIóN
INTERREDES
MONTAGE:
PAGE 2 = PAGE BLANCHE
SECCIóN 1
INTERFUNCIONAMIENTO ENTRE REDES
Recomendación X.300
PRINCIPIOS GENERALES DE INTERFUNCIONAMIENTO ENTRE REDES
PúBLICAS DE DATOS, Y ENTRE éSTAS Y OTRAS REDES PARA LA
PRESTACIóN DE SERVICIOS DE TRANSMISIóN DE DATOS
(Antigua Recomendación X.87, Ginebra, 1980; modificada en
Málaga-Torremolinos, 1984, y Melbourne, 1988)
El CCITT,
considerando
(a) que la Recomendación X.1 define las clases de servicio internacionales de usuarios en redes públicas de datos y en la RDSI;
(b) que la Recomendación X.2 define los servicios y facilidades internacionales de usuarios en las RPD y en la RDSI;
(c) que la Recomendación X.10 define las diversas categorías de acceso de equipos terminales de datos (ETD) a los diferentes servicios de transmisión de datos proporcionados por redes públicas de datos (RPD) y la RDSI;
(d) que la Recomendación X.96 define las señales de progresión de la llamada, incluidas las que se utilizan conjuntamente con facilidades internacionales de usuario;
(e) que las Recomendaciones X.20, X.20^
bis
, X.21,
X.21^
bis
, X.25, X.28, X.29, X.30, X.31 y X.32 ya
especifican los procedimientos detallados aplicables a los diferentes tipos de
interfaces ETD/ETCD en las RPD y RDSI;
(f) que las Recomendaciones X.61, X.70, X.71 y X.75 ya especifican los procedimientos detallados aplicables al control de las llamadas entre dos RPD del mismo tipo;
(g) que las RPD y la RDSI sirven de soporte a servicios de telecomunicaciones y servicios definidos por el CCITT (por ejemplo, servicios telemáticos);
(h) que la Recomendación X.200 especifica el modelo de referencia de interconexión de sistemas abiertos (ISA) para aplicaciones del CCITT;
(i) que la Recomendación X.213 especifica la definición del servicio de capa de red con conexión en la interconexión de sistemas abiertos (ISA) para aplicaciones del CCITT;
(j) que la Recomendación X.301 contiene una descripción de las disposiciones generales aplicables al control de la llamada dentro de una subred y entre subredes para la prestación de servicios de transmisión de datos;
(k) que la Recomendación X.302 describe las disposiciones generales relativas a las utilidades internas de red dentro de una subred y entre subredes para la prestación de los servicios de transmisión de datos;
(l) que la Recomendación X.305 describe las funcionalidades de las subredes en lo que concierne al soporte del servicio de capa de red con conexión de ISA;
(m) la necesidad de examinar el interfuncionamiento con la red de señalización por canal común (RSCC), teniendo en cuenta las condiciones para la transferencia de información de explotación entre las Administraciones;
(n) la necesidad de que los ETD puedan comunicar a través de redes diferentes, y en diferentes condiciones de interfuncionamiento entre redes;
(o) la necesidad de establecer principios y disposiciones generales para el interfuncionamiento entre redes públicas de datos, y entre éstas y otras redes públicas, para la prestación de servicios de transmisión de datos;
(p) la necesidad de prestar servicios de transmisión de datos, y en particular:
-de establecer ciertas facilidades de usuario y utilidades de red para la comunicación, a través de redes nacionales, entre los protocolos de interfaz de equipo terminal de datos definidos en el plano internacional y los procedimientos de control y señalización internacionales entre centrales,
-de establecer ciertas utilidades de red definidas en el plano internacional para la explotación internacional de redes públicas de datos,
-de que los principios relativos al establecimiento de facilidades internacionales de usuario y utilidades de red en redes públicas sean compatibles y uniformes,
recomienda (por unanimidad)
que los principios generales para el interfuncionamiento entre redes públicas, y entre éstas y otras redes, y que los elementos necesarios:
-para la realización del interfuncionamiento de diferentes redes que suministran servicios de transmisión de datos, y
-para la realización de facilidades internacionales de usuarios y utilidades de red para servicios de transmisión de datos,
concuerden con los principios y procedimientos especificados en esta Recomendación
íNDICE
0
Introducción
1
Objeto y campo de aplicación
2
Referencias
3
Definiciones
3.1Terminología definida en otras Recomendaciones
3.2Terminología definida en esta Recomendación
3.3Convenios de dibujo
4
Abreviaturas
5
Redes reales interconectadas y servicios de transmisión de
datos ofrecidos
5.1Red pública de datos con conmutación de paquetes (RPDCP)
5.2Red pública de datos con conmutación de circuitos (RPDCC)
5.3Red digital de servicios integrados (RDSI)
5.4Red telefónica pública con conmutación (RTPC)
5.5Red de señalización por canal común (RSCC)
5.6Sistemas móviles
5.7Redes privadas
6
Principios del interfuncionamiento cuando sólo
intervienen capacidades de transmisión
6.1Composición y descomposición de subredes
6.2Categorías de interfuncionamiento
6.3Clasificación de las subredes respecto a la prestación del SR de ISA
6.4Relaciones con respecto a la gestión
6.5Principios básicos en relación con los parámetros de indicación de servicios
7
Principios del interfuncionamiento cuando intervienen
capacidades de transmisión y de comunicación
7.1Composición y descomposición de sistemas de relevo de aplicación
7.2Categorías de interfuncionamiento
7.3Identificación de tipos de sistemas de relevo de aplicación
7.4Relación entre FIF de aplicación, redes reales y tipos de sistemas de relevo de aplicación
7.5Interconexión de tipos de sistemas de relevo de aplicación
7.6Utilización de tipos de sistemas de relevo de aplicación
7.7Relaciones con respecto a la gestión
7.8Relaciones con el modelo de referencia de ISA para aplicaciones del CCITT
7.9Principios básicos en relación con los parámetros de indicación de servicio
8
Descripción de las diferentes condiciones de
interfuncionamiento
8.1Generalidades
8.2Interfuncionamiento vía un adaptador no ISA entre RTPC y RPDCP
8.3Interfuncionamiento con la RDSI para la prestación de servicios de transmisión de datos
Anexo A
-Categorías básicas de subredes
Anexo B
-Ejemplos de tipos de subredes
0 Introducción
0.1 La rápida evolución de los servicios de transmisión de datos ha dado lugar al establecimiento de un gran número de normas internacionales al respecto. La creciente complejidad del conjunto de estas normas conlleva la necesidad de racionalizar los aspectos comunes con objeto de obtener una relación coherente entre las mismas.
0.2 Diferentes tipos de redes públicas, tales como las redes públicas de datos y las redes digitales de servicios integrados (RDSI), pueden proporcionar servicios de transmisión de datos y facilidades de usuario (véanse también las Recomendaciones I.500 e I.510). En consecuencia, puede solicitarse la interconexión de estas redes de modo que un ETD de una red pueda comunicar de manera uniforme con un ETD de la misma red, o con un ETD de otra red del mismo tipo, o con un ETD de una red de otro tipo.
0.3 La señalización interredes entre los diversos tipos de redes podrá ser del tipo definido por Recomendaciones tales como las X.70, X.71, X.75, o señalización por canal común como la descrita en la Recomendación X.61.
En particular, en un interfaz de señalización interredes se pueden intercambiar utilidades de red (o servicios utilitarios inherentes a las redes) entre las redes participantes. Estas utilidades de red podrán ser tratadas por tipos de redes diferentes.
0.4 Además, como el propósito de la Recomendación X.200 (Modelo de referencia de interconexión de sistemas abiertos para aplicaciones del CCITT) es, en parte, permitir que usuarios diferentes puedan comunicar entre sí, promoviendo la introducción de características de comunicación compatibles, se prevé que en el futuro aumente la utilización de este modelo de referencia en los diseños de terminales de usuarios.
0.5 Como se define por este modelo de referencia, una de las funciones fundamentales de la capa de red consiste en establecer una conexión de red entre usuarios del servicio de red (dentro de sistemas de extremo). Esto puede entrañar la concatenación de redes disímiles.
Por tanto, las disposiciones y procedimientos para señalización interredes entre RPD y otras redes públicas deberán proporcionar a los usuarios la capacidad de operar servicios de transmisión de datos, servicios telemáticos y el servicio de capa de red con conexión ISA a través de conexiones obtenidas por conducto de una red o redes concatenadas.
Nota
- Esto no significa que cualquier red pública
individual participante tenga que disponer de todos los mecanismos relativos al
servicio de capa o red con conexión ISA.
0.6 Esta Recomendación forma parte de un grupo de Recomendaciones sobre interfuncionamiento. La figura 0-1/X.300 recapitula las Recomendaciones pertinentes sobre interfuncionamiento, reunidas en tres categorías principales, a saber:
a)Aspectos generales del interfuncionamiento,
b)Descripción de cada caso de interfuncionamiento,
c)Descripción de interfaces de señalización interredes.
Figura 0.1/X.300, p.
1 Objeto y campo de aplicación
1.1 El interfuncionamiento entre más de dos redes está incluido en el ámbito de esta Recomendación.
1.2 Esta Recomendación tiene por objeto:
-definir principios y disposiciones detalladas para el interfuncionamiento de redes diferentes con el fin de suministrar un servicio de transmisión de datos;
-especificar, en el contexto general de red, la interacción necesaria entre los elementos de los interfaces de usuario, los sistemas de señalización entre centrales y otras funciones de red para el soporte de servicios de transmisión de datos, de servicios telemáticos y del servicio de capa de red con conexión ISA, cuando proceda;
Nota
- El soporte del servicio de red sin conexión ISA
definido en ISO 8348/Ad 1 se deja para ulterior estudio.
-definir los principios para el establecimiento de facilidades internacionales de usuario y utilidades de red para servicios de transmisión de datos.
2
Referencias
I.112Vocabulario de términos relativos a la RDSI.
I.210Principios de los servicios de telecomunicación soportados por una RDSI.
Serie I.230Servicios portadores soportados por una RDSI.
Serie I.240Teleservicios soportados por una RDSI.
Serie I.250Definiciones y descripción de servicios suplementarios.
I.340Tipos de conexión de la RDSI.
I.411Interfaces usuario-red de la RDSI - Configuraciones de referencia.
I.420Interfaz usuario-red básico.
I.421Interfaz usuario-red a velocidad primaria.
I.500Estructura general de las Recomendaciones de interfuncionamiento de la RDSI
I.510Definición y principios generales para el interfuncionamiento de la RDSI.
Serie Q.700Especificaciones del sistema de señalización N.o 7.
X.1Clases de servicio internacional de usuario en redes públicas de datos y en redes digitales de servicios integrados (RDSI).
X.2Servicios de transmisión de datos y facilidades facultativas de usuario internacionales en redes públicas de datos.
X.10Categoría de acceso para el equipo terminal de datos (ETD) a los servicios públicos de transmisión de datos.
X.20Interfaz entre el equipo terminal de datos (ETD) y el equipo de terminación del circuito de datos (ETCD) para servicios de transmisión arrítmica en las redes públicas de datos.
X.20^
bis
Utilización, en las redes públicas de datos,
de equipos terminales de datos (ETD) diseñados para su conexión con modems
dúplex asíncronos de la serie V.
X.21Interfaz entre el equipo terminal de datos (ETD) y el equipo de terminación del circuito de datos (ETCD) para funcionamiento síncrono en redes públicas de datos.
X.21^
bis
Utilización, en las redes públicas de datos,
de equipos terminales de datos (ETD) diseñados para su conexión con modems
síncronos de la serie V.
X.22Interfaz múltiplex ETD/ETCD para las clases de servicio de usuario 3 a 6.
X.25Interfaz entre el equipo terminal de datos (ETD) y el equipo de terminación del circuito de datos (ETCD) para equipos terminales que funcionan en el modo paquetes y conectados a redes públicas de datos por circuitos especializados.
X.28Interfaz ETD/ETCD para un equipo terminal de datos arrítmico con acceso a la facilidad de empaquetado/desempaquetado de datos (EDD) en una red pública de datos situada en el mismo país.
X.29Procedimientos para el intercambio de información de control y datos de usuario entre una facilidad de empaquetado/desempaquetado de datos (EDD) y un ETD de paquetes u otro EDD.
X.30/I.461Soporte de equipos terminales de datos (ETD) basados en las
Recomendaciones X.21, X.21^
bis
y
X.20^
bis
por una red digital de servicios integrados
(RDSI).
X.31/I.462Soporte de equipos terminales en modo paquete por una red digital de servicios integrados (RDSI).
X.32Interfaz entre el equipo terminal de datos (ETD) y el equipo de terminación del circuito de datos (ETCD) para terminales que funcionan en el modo paquete y acceden a una red pública de datos con conmutación de paquetes a través de una red telefónica pública con conmutación o una RDSI o una red pública de datos con conmutación de circuitos.
X.60Señalización por canal común para aplicaciones de datos con conmutación de circuitos.
X.61Sistema de señalización N.o 7 - Parte de usuario de datos.
X.70Sistema de señalización de control terminal y de tránsito para servicios arrítmicos en circuitos internacionales entre redes anisócronas de datos.
X.71Sistema de señalización descentralizada de control terminal y de tránsito para circuitos internacionales entre redes síncronas de datos.
X.75Sistema de señalización con conmutación de paquetes entre redes públicas que prestan servicios de transmisión de datos.
X.80Interfuncionamiento de sistemas de señalización entre centrales para servicios de datos con conmutación de circuitos.
X.81Interfuncionamiento entre una RDSI y una RPDCC.
X.82Disposiciones detalladas para el interfuncionamiento RPDCC/RPDCP basado en la Recomendación T.70.
X.96Señales de progresión de la llamada en redes públicas de datos.
X.180Disposiciones administrativas para los grupos cerrados de usuarios (GCU) internacionales.
X.181Disposiciones administrativas para la provisión de circuitos virtuales permanentes (CVP) internacionales.
X.200Modelo de referencia de interconexión de sistemas abiertos para aplicaciones del CCITT.
X.210Convenios relativos a la designación del servicio de capas en la interconexión de servicios abiertos (ISA).
X.213Definición del servicio de red para la interconexión de sistemas abiertos (ISA) para aplicaciones del CCITT.
X.301Descripción de las disposiciones generales para el control de la llamada en una subred y entre subredes para la prestación de servicios de transmisión de datos.
X.302Descripción de las disposiciones generales para las utilidades de red internas en una subred y entre subredes para la prestación de servicios de transmisión de datos.
X.305Funcionalidades de subredes relativas a la prestación del servicio de red en modo conexión de ISA.
X.320Disposiciones generales para el interfuncionamiento entre RDSI para la prestación de servicios de transmisión de datos.
X.321(I.540)Disposiciones generales para el interfuncionamiento entre RPDCC y RDSI para la prestación de servicios de transmisión de datos.
X.322Disposiciones generales para el interfuncionamiento entre RPDCP y RPDCC para la prestación de servicios de transmisión de datos.
X.323Disposiciones generales para el interfuncionamiento entre RPDCP.
X.324Disposiciones generales para el interfuncionamiento entre RPDCP y sistemas móviles públicos para la prestación de servicios de transmisión de datos.
X.325(I.550)Disposiciones generales para el interfuncionamiento entre RPDCP y RDSI para la prestación de servicios de transmisión de datos.
X.326Disposiciones generales para el interfuncionamiento entre RPDCP y RSCC para la prestación de servicios de transmisión de datos.
X.327Disposiciones generales para el interfuncionamiento entre RPDCP y redes privadas para la prestación de servicios de transmisión de datos.
X.350Requisitos generales para la transmisión de datos en sistemas móviles públicos por satélite internacionales.
X.351Requisitos especiales que deben satisfacer las facilidades de empaquetado/desempaquetado de datos (EDD) situadas en estaciones terrenas costeras, o en asociación con ellas, en el servicio móvil público por satélite.
X.352Interfuncionamiento entre RPDCP y el sistema de transmisión de datos del servicio móvil público por satélite.
X.370Disposiciones para la transferencia de información de gestión interredes.
3
Definiciones
3.1
Terminología definida en otras Recomendaciones
Esta Recomendación utiliza los siguientes conceptos y términos definidos en otras Recomendaciones.
Concepto o término Recomendación
a)Servicio portador (véase también el 3.2.8 Servicio de transmisión de datos)I.112 y I.210 b)CentralI.112 c)Red digital de servicios integradosI.112 d)Sistema de transmisión de datos por satélite marítimoX.350 e)Capa de red ISAX.200 f)Servicio de red ISAX.200 g)Empaquetado/desempaquetado de datos (nota) h)Red pública de datos (nota) i)Red del servicio móvil terrestre público (o red móvil terrestre pública)Q.70 j)Proveedor del servicioX.210 k)Usuario del servicioX.210 l)Servicio de telecomunicación (véase también el 3.2.5 Servicio del CCITT)I.112 m)TeleservicioI.112 n)Adaptador de terminalI.411
Nota
- Este término figura en el Libro Azul (Tomo
I.3).
3.2
Terminología definida en esta Recomendación
Esta sección presenta conceptos y definiciones adicionales a los ya definidos en otras Recomendaciones. Algunos conceptos y términos presentados en esta sección se definen gracias a las figuras 3-1/X.300 y 3-2/X.300, que forman parte de la definición. (Para los convenios de dibujo, véase el 3.3 .)
3.2.1@
sistema de relevo de aplicación
@
\Abstracción funcional de una función de interfuncionamiento (FIF) de aplicaciones.\
3.2.2@
función de interfuncionamiento de aplicaciones
@
\Colección de procesos que intervienen en un flujo de información asociado también con aplicaciones, que relacionan el o los protocolos de entrada a esta colección con el o los protocolos de salida de la colección.
Función de interfuncionamiento que también actúa sobre información relacionada con esa aplicación.\
3.2.3
Servicio de relevo de aplicación
(Requiere estudio adicional.)
Figure 3-1/X.300, p. 2
Figure 3-2/X.300, p. 3
3.2.4
Funcionalidad del relevo de aplicación
(Requiere estudio adicional.)
3.2.5@
servicio del CCITT
@
(
Nota
- se supone que este concepto es equivalente a
servicio de telecomunicación.)
\Servicio definido en Recomendaciones del CCITT, que las Administraciones ofrecen comercialmente a los usuarios. Pueden comercializarse diferentes tipos de servicios del CCITT, como son:
a)Servicios de transmisión de datos, definidos en las Recomendaciones X.1 y X.2 (es decir, servicios de transmisión de datos con conmutación de circuitos y con conmutación de paquetes, así como servicios de circuitos arrendados);
b)Servicios que incluyen funciones adicionales, además de las funciones que proporcionan la capacidad de transmisión (por ejemplo, EDD, télex, teletex).
Además de un servicio de transmisión de datos, los usuarios pueden establecer una aplicación definida privadamente.\
Figura 3-3/X.300 p.
3.2.6@
capacidad de comunicación
@
\La capacidad de comunicación consiste en el medio de comunicación entre dos sistemas, relacionado con funciones por encima de la capacidad de transmisión. Una capacidad de transmisión puede estar definida por el CCITT; puede también estar definida privadamente por los propios usuarios.\
3.2.7@
protocolo de convergencia
@
\Protocolo utilizado por encima de un servicio de subred (servicio transparente para la subred correspondiente), a fin de construir otro servicio de subred. Este protocolo puede estar activo durante todas o algunas solamente de las fases de la llamada relacionada con el servicio de subred construido.\
3.2.8@
servicio de transmisión de datos
@
\El servicio de transmisión de datos es el servicio ofrecido por una Administración, EPER o por cualquier operador de red privada a fin de satisfacer una exigencia de telecomunicación y se compone de los atributos técnicos percibidos por el cliente y de otros atributos asociados con la prestación del servicio, por ejemplo, de explotación. La utilización de los atributos técnicos requiere los mecanismos de acceso a subredes definidos en la Recomendación X.1 (servicio con conmutación de circuitos, servicio con conmutación de paquetes, y servicio de circuitos arrendados) y en las Recomendaciones de la serie I.230 y en la Recomendación X.10, en lo relativo a transmisión transparente.
Nota
- Se supone que este concepto es equivalente al
de servicio portador.\
3.2.9@
sistema de extremo
@
\Abstracción funcional de un sistema de extremo real.\
3.2.10@
interfuncionamiento por correspondencia del control de
la llamada
@
\Técnica de interfuncionamiento en la que toda la información de control de la llamada (incluido el direccionamiento), transportada por el protocolo o los protocolos utilizados para la conmutación por una de las subredes se hace corresponder con la información de control de la llamada (incluida la dirección), transportada por el protocolo o los protocolos utilizados para la conmutación por la otra subred.\
3.2.11@
interfuncionamiento mediante acceso por puerto
@
\Técnica de interfuncionamiento en la que toda la información de control de llamada (incluido el direccionamiento) transportada por el protocolo o los protocolos utilizados para la conmutación por una subred se utiliza para seleccionar/direccionar el punto de interfuncionamiento. Posteriormente se utiliza en esta subred un protocolo de convergencia que transporta toda la información de control de llamada (incluido el direccionamiento) que se hará corresponder con la información de direccionamiento transportada por los protocolos utilizados para la conmutación por la otra subred.\
3.2.12@
función de interfuncionamiento
@
3.2.12.1 \Las funciones de interfuncionamiento (FIF) consideradas en esta Recomendación son entidades funcionales que participan en el establecimiento de una llamada entre dos sistemas de extremo (o sistemas terminales), cuando dos redes intervienen entre estos dos sistemas de extremo.
Nota 1
- La descripción de funciones de
interfuncionamiento en ejemplos que figuran en otros puntos de esta
Recomendación no contiene ninguna suposición acerca de la realización de tales
funciones, que pueden formar parte de una red participante, o constituir un
equipo distinto. Además, varias funciones de interfuncionamiento entre dos
redes se pueden combinar y reunir en un solo equipo.
Nota 2
- Una función de interfuncionamiento (FIF)
puede intervenir también en casos en que participan dos redes disímiles, o dos
redes del mismo tipo.
Nota 3
- Una función de interfuncionamiento actúa
solamente para la transferencia transparente de información (cualquiera que sea
la aplicación).
Nota 4
- Una unidad de acceso (UA), un manipulador de
paquetes (MP) o un adaptador de terminal RDSI puede también considerarse una
FIF.
3.2.12.2 En algunos casos de interconexión entre dos redes pueden intervenir varias funciones de interfuncionamiento (FIF). Sin embargo, para una comunicación determinada entre dos sistemas de extremo sólo intervendrá una de esas FIF.
3.2.12.3 La figura 3-4/X.300 presenta un ejemplo de interfuncionamiento entre dos redes por medio de funciones de interfuncionamiento. En otros casos en los que intervengan más de dos redes podrá actuar un número mayor de funciones de interfuncionamiento.\
Figura 3-4/X.300 p.
3.2.13@
red
@ (ampliación de la definición de la
Recomendación I.112)
\Conjunto de nodos y enlaces que provee conexiones entre dos o más puertos definidos a fin de facilitar la telecomunicación entre ellos. En particular, una red real puede, para una instancia de comunicación determinada:
a)actuar para la transferencia transparente de información únicamente (cualquiera que sea la aplicación), o
b)actuar también sobre la información relativa a la aplicación en sí.\
3.2.14@
red*
@
\Cualquier combinación de conmutador(es) o central(es) y/o redes y/o funciones de interfuncionamiento (FIF).\
3.2.15@
sistema de relevo de aplicación real
@
\Toda combinación de subredes, redes reales*, y FIF de aplicación en que por lo menos una red real y/o FIF de aplicación actúa también sobre la información relacionada con dicha aplicación.\
3.2.16@
sistema de extremo real
@
\ETD o ET que tiene la capacidad de comunicar, y que sirve como origen o destino de una instancia de comunicación relacionada con su aplicación o aplicaciones, y que no es un sistema o subred intermedio.\
3.2.17@
subred
@
\Abstracción funcional de un conjunto de uno o más sistemas intermedios que proporcionan relevo y a través de los cuales los sistemas de extremo pueden establecer conexiones de red, relacionadas únicamente con las tres capas inferiores del modelo de ISA (véase la Recomendación X.200).\
3.2.18@
funcionalidad de subred
@
\Las funcionalidades existentes en una subred guardan relación con la forma en que la subred sirve de soporte a conexiones a través de ella. Estas funcionalidades pueden ser diferentes en cada tipo de subred, y dependerán de las fases de control de la llamada y de transferencia de datos.\
3.2.19@
servicio de subred
@
\Servicio soportado por los protocolos utilizados en una subred para una instancia de comunicación. Este servicio es igual en los puntos de acceso al servicio.\
3.2.20@
tipo de subred
@
\Subred con una funcionalidad definida en función de la capacidad para soportar el servicio de red con conexión de ISA. El término es válido únicamente en este contexto específico.\
3.2.21@
capacidad de transmisión
@
\La capacidad de transmisión consiste en todos los mecanismos necesarios solicitados a través de una subred (o de varias subredes en interfuncionamiento) para la transferencia transparente de datos entre equipos de usuarios o sistemas intermedios de aplicación, incluidos los mecanismos conexos comprendidos en los sistemas de extremo. Esto incluye todos los mecanismos requeridos para acceder a las subredes, definidos en las Recomendaciones de la serie I.230 y en la Recomendación X.10 en lo relativo a la transmisión transparente de información. También puede incluir funciones de gestión especiales, que se dejan para ulterior estudio.
Nota
- Se entiende que algunas facilidades
facultativas de usuario/servicios suplementarios definidos en la Recomendación
X.2 y en las Recomendaciones de la serie I.250 están relacionados únicamente
con la capacidad de transmisión, mientras que otros están relacionados también
con la capacidad de comunicación. Las listas exactas de cada categoría no son
objeto de esta Recomendación.\
3.2.22@
capacidad de telecomunicación
@
\Funcionalidad combinada de la capacidad de comunicación y de la capacidad de transmisión.\
3.2.23 El cuadro 3-1/X.300 ilustra la relación entre algunos de los términos antes definidos.
Cuadro 3-1/X.300 [T1.300] p.
3.3
Convenios de dibujo
Esta sección define la relación entre algunos términos utilizados en esta Recomendación y la representación gráfica utilizada para los mismos en esta Recomendación. Además, define la relación entre algunos términos relativos a objetos del mundo real y los términos relativos a su abstracción para una determinada instancia de comunicación. Los cuadros 3-2/X.300 y 3-3/X.300 resumen los símbolos y objetos que aparecen en la presente Recomendación.
La indicación gráfica de la funcionalidad de una subred corresponde a los tipos particulares de subred asignados en esta Recomendación. La indicación gráfica se expresará en números romanos, como sigue (utilizando la forma de Backus-Naur):
&lab;indicación> ::= &lab;tipo de subred I>|&lab;tipo de subred II>|&lab;tipo de subred III>
&lab;tipo de subred I> ::= &lab;I>
&lab;tipo de subred II> ::= &lab;II>
&lab;tipo de subred III> ::= &lab;III>
4
Abreviaturas
@ATAdaptador de terminal\
@CICDCentral internacional de conmutación de datos\
@CCDCentral (o centro) de conmutación digital\
@CNCDCentral (o centro) nacional de conmutación de datos\
@CCConmutación de circuitos\
@CPConmutación de paquetes\
@EDDEmpaquetado/desempaquetado de datos\
@ETCDEquipo de terminación del circuito de datos\
@ETDEquipo terminal de datos\
@ETEquipo terminal (utilizado en Recomendaciones sobre la RDSI)\
@FIFFunción de interfuncionamiento\
@ISAInterconexión de sistemas abiertos\
@MPManipulador de paquetes\
@RSCCRed de señalización por canal común (SS N.o 7)\
@RDSIRed digital de servicios integrados\
@RMTPRed móvil terrestre pública\
@RPDRed pública de datos\
@RPDCCRed pública de datos con conmutación de circuitos\
@RPDCPRed pública de datos con conmutación de paquetes\
@RTPCRed telefónica pública con conmutación\
@SRServicio de red\
@SS N.o 7Sistema de señalización N.o 7\
@UAUnidad de acceso\
Tableau 3-2/X.300, p. 7
Tableau 3-3/X.300, p. 8
5 Redes reales interconectadas y servicios de
transmisión de datos ofrecidos
En esta sección se enumeran las redes reales consideradas en la presente Recomendación para la prestación de servicios de transmisión de datos, y se indica, si procede, la medida en que estas redes reales admiten la capacidad completa del servicio de capa de red con conexión ISA en el interfaz ETD/ETCD.
Se pueden suministrar servicios internacionales de transmisión de datos mediante el interfuncionamiento de diferentes tipos de redes, a saber:
-@Redes públicas de datos (RPD)\
-@Red digital de servicios integrados (RDSI)\
-@Red telefónica pública conmutada (RTPC)\
-Redes o sistemas móviles
-Redes privadas.
Nota 1
- Se podrán asimismo proporcionar otros
servicios, no relacionados con servicios de transmisión de datos, por
interfuncionamiento entre RPDs. En particular, en la Recomendación X.340 se
definen los requisitos que debe cumplir una RPD que interfuncione con la red
télex pública en relación con el servicio télex recomendado por el CCITT.
Nota 2
- También se considera en la presente
Recomendación la red de señalización por canal común (RSCC), en lo que respecta
a su interfuncionamiento con RPDs, y como medio para la transmisión de datos
constituido por información de explotación (véase asimismo el
5.5
,
en particular la nota al
5.5.2
).
5.1@
Red pública de datos con conmutación de paquetes
(RPDCP)
\
5.1.1 En esta Recomendación se consideran las redes públicas de datos con conmutación de paquetes (RPDCP).
5.1.2 Los servicios de transmisión de datos y facilidades de usuario ofrecidos a través de las RPDCP se describen en las Recomendaciones X.1 y X.2; estos son los servicios de transmisión de datos con conmutación de paquetes.
5.1.3 Las categorías de acceso de los ETD a los servicios de transmisión de datos ofrecidos a través de RPDCPs se especifican en la Recomendación X.10.
5.1.4 Además de los servicios de transmisión de datos y de los servicios telemáticos, las RPDCP se pueden utilizar como soporte de aplicaciones ISA.
5.2@
Red pública de datos con conmutación de circuitos
(RPDCC)
\
5.2.1 Las redes públicas de datos con conmutación de circuitos (RPDC) se tratan en esta Recomendación.
5.2.2 Los servicios de transmisión de datos y facilidades de usuario ofrecidos a través de las RPDCC se describen en las Recomendaciones X.1 y X.2, y son los siguientes:
-servicios de transmisión de datos síncronos, o
-servicios de transmisión de datos asíncronos.
5.2.3 Las categorías de acceso de los ETD a servicios de transmisión de datos ofrecidos a través de RPDCCs se especifican en la Recomendación X.10.
5.2.4 Además de los servicios de transmisión de datos y de los servicios telemáticos, una RPDCC puede utilizarse como soporte de aplicaciones ISA.
Nota
- La medida en que las RPDCC suministran la
capacidad completa del servicio de capa de red con conexión ISA deberá
estudiarse ulteriormente. Se tiene el propósito de reflejar el resultado de
este estudio en la presente Recomendación, cuando proceda.
5.3
Red digital de servicios integrados (RDSI)
5.3.1 La red digital de servicios integrados (RDSI) se considera en esta Recomendación para el interfuncionamiento con redes públicas de datos y para la prestación de servicios de transmisión de datos.
Nota
- Uno de los objetivos de la RDSI es proporcionar
servicios de transmisión de datos que actualmente se proporcionan a través de
RPDs (véanse las Recomendaciones de la serie I.230).
5.3.2 Los servicios de transmisión de datos a través de la RDSI considerados en la presente Recomendación se describen en la Recomendación X.1, y son los siguientes:
a)servicios de transmisión de datos con conmutación de circuitos;
b)servicios de transmisión de datos con conmutación de paquetes.
Nota
- Además, habrá que considerar otros tipos de
servicios de transmisión de datos para el interfuncionamiento con la RDSI, para
nuevas aplicaciones (por ejemplo, telemedida).
5.3.3 Las categorías de acceso de los ETD a servicios de transmisión de datos en la RDSI se describen en la Recomendación X.10.
5.4
Red telefónica pública conmutada (RTPC)
5.4.1 La red telefónica pública conmutada (RTPC) se considera en la presente Recomendación para el interfuncionamiento con redes públicas de datos y para la prestación de servicios de transmisión de datos.
Nota
- Para el interfuncionamiento deberá considerarse
una RTPC con capacidad mejorada de señalización (por ejemplo, capacidad de
identificación de la línea llamante), o sin dicha capacidad.
5.4.2 Los servicios de transmisión de datos a través de la RTPC que deben considerarse para el interfuncionamiento con RPDs dependen de la situación precisa de interfuncionamiento (véase también el 8 ). Según la situación de interfuncionamiento, esos servicios de transmisión de datos se basan en servicios de transmisión de datos síncronos o asíncronos o en servicios de transmisión de datos con conmutación de paquetes que se prevé sean equivalentes al servicio de capa de red con conexión ISA.
5.5
Red de señalización por canal común (RSCC)
5.5.1 La red de señalización por canal común (RSCC) tiene por objeto controlar la señalización destinada a otra red (por ejemplo, RDSI, RPDCC).
La red controlada puede interfuncionar con otra RPD, como se ilustra en la figura 5-1/X.300. Este interfuncionamiento no se considera en la presente Recomendación como interfuncionamiento entre RSCC y RPD.
Figura 5-1/X.300 p.
5.5.2 Para la transmisión de información de explotación entre
Administraciones, la RSCC y la RPD pueden también tener necesidad de
interfuncionar en el mismo nivel, para proporcionar un medio de transmisión
entre centros de operación y/o terminales de esas Administraciones, como se
muestra en la figura 5-2/X.300. Este interfuncionamiento se considerará un
interfuncionamiento entre RSCC y RPD (véase la nota).
Nota
- Esto no excluye la consideración del
interfuncionamiento entre la RPD y las redes de señalización por canal común
para la transferencia de datos de usuario. La provisión de esta capacidad será
objeto de ulterior estudio.
Figure 5-2/X.300 p. 10
5.5.3 Para el interfuncionamiento con una RPD, y para transmisión de
información operacional, una RSCC se considerará asociada con cualquier función
de interfuncionamiento apropiada, para el suministro del servicio de capa de
red con conexión ISA.
5.6
Sistemas móviles públicos
5.6.1
Sistemas de transmisión de datos en el servicio móvil
público por satélite
5.6.1.1 Los requisitos generales de interfuncionamiento para la transmisión de datos en el sistema móvil público por satélite se definen en la Recomendación X.350.
5.6.1.2 Los requisitos para el interfuncionamiento entre las RPDCP y el servicio móvil público por satélite mediante el empleo de una unidad de EDD se indican en la Recomendación X.351.
5.6.1.3 Los requisitos para el interfuncionamiento por correspondencia de control de llamada entre redes públicas de datos por conmutación de paquetes (RPDCP) y los sistemas de transmisión de datos en el servicio móvil público por satélite se definen en la Recomendación X.352.
5.6.2@
Redes móviles terrestres públicas (RMTP)
\
5.6.2.1 El interfuncionamiento entre RPDCP y RMTP que emplean técnicas de radiotransmisión analógica puede obtenerse mediante funciones de interfuncionamiento (FIF) diseñadas de conformidad con la Recomendación X.32. En este caso, los canales telefónicos del sistema móvil público se utilizan como circuitos de acceso a la FIF. La RMTP puede interconectarse también con la RPDCP a través de circuitos conmutados de la RTPC.
5.6.2.2 El interfuncionamiento entre RPDCPs y RDSIs y RMTPs con capacidades de acceso equivalentes a las de la RDSI deberá ser objeto de ulterior estudio.
5.6.2.3 Pueden utilizarse RPDCCs para ganar acceso a RMTPs en la forma definida en 5.6.2.1 utilizando protocolos que provean corrección de errores y control de flujo. Este punto queda para ulterior estudio.
5.6.3
Otros sistemas móviles
El interfuncionamiento con sistemas móviles públicos en otros casos será objeto de ulterior estudio.
5.7
Redes privadas
Las redes privadas se consideran en relación con el interfuncionamiento con las RPDCP y las RDSI para la prestación de servicios de transmisión de datos (véase la Recomendación X.327).
Nota
- El interfuncionamiento con las RPDCC se deja
para ulterior estudio.
(H.T.=OUI)
TAB.???
FICHIERS H.T. =
(86.TA.269.S)
(SANS FORMULE) Tableaux: 6 - Tabulateurs: 2 O: NF01/004 a) NF05/003
(1BT) (BT..)
(86.TE.02.S)
(A1.23s) / [26s]
FOLIOS: 21 - 52 (AS)
(DO PRC.COSY.2)
MEP {TPS.NON.PHOTO "[PA1]"} : OK= [1]
Saisie 26.01.89 RM
ID + LASER 16.02.89 CW
MAJ diskette 16.02.89 CW
Corr. LASER (1re épreuve) = 3eme ........ ..
Espaces réservés 07.03.89 PC
AJOUTER (PA1) (CL1,0,0,0) pour MEP
MEP + LASER 10.03.89 GH/PC
Corr. MEP 10.03.89 PC
Insertion des tableaux (tabulateurs 2) 10.03.89 PC
BAT Corr. 30.03.89 DD
MAJ s/disquettes 28.04.89 CD
6
Principios de
interfuncionamiento con intervención de capacidad de transmisión
únicamente
Las diferentes categorías de interfuncionamiento pueden incluir diferentes niveles de funciones:
a)en algunos casos, únicamente las funciones relativas a la transferencia transparente de información entre dos ETD a través de la red o redes (capacidad de transmisión);
b)en otros casos, también funciones adicionales construidas con base en las funciones relacionadas con la transferencia transparente de información (capacidad de comunicación).
Esta sección describe los conceptos y principios básicos relativos a los casos mencionados en a).
6.1
Composición y descomposición de subredes
La consideración de las diferentes condiciones de interfuncionamiento con intervención únicamente de capacidad de transmisión requiere el desarrollo de conceptos adecuados para los diferentes tipos de red que pueden intervenir. En particular, los conceptos de subred y de diferentes tipos de subredes tienen por objeto servir de ayuda en el desarrollo de un marco adecuado para el estudio del interfuncionamiento entre redes.
6.1.1
Concepto de subred
6.1.1.1Las entidades correspondientes cooperan como se indica en el ejemplo de las figuras 6-1/X.300 y 6-2/X.300.
Figura 6-1/X.300, p.
Figura 6-2/X.300, p.
6.1.1.2No siempre es necesario considerar sistemas intermedios individuales
que intervienen en una llamada determinada. Por ejemplo, no es necesario
considerar centrales (o centros) nacionales de conmutación de datos (CNCD)
individuales de una red pública de datos nacional, pues la cuestión de los
protocolos entre estas CNCD es un asunto que sólo interesa en el plano
nacional. Asimismo, la cuestión de los protocolos entre una CNCD y una central
(o centro) internacional de conmutación de datos (CICD) en la misma RPD
nacional es un asunto de interés en el plano nacional. Por tanto, en lo que
respecta al estudio de las disposiciones de interfuncionamiento entre redes,
puede ser importante considerar las CCD que pertenecen a la misma RPD nacional
como un solo sistema abstracto intermedio que interviene en la llamada, como se
indica en la siguiente figura 6-3/X.300 (en la que se dan dos representaciones
equivalentes de sistemas intermedios que intervienen en una llamada).
Figura 6-3/X.300, p.
6.1.1.3Una subred puede contener varias combinaciones de equipos de red,
incluidas una o más redes públicas, funciones de interfuncionamiento (FIF).^.^.
Esto se puede representar gráficamente como en la figura 6-4/X.300.
Figura 6-4/X.300, p.
6.1.1.4Una subred puede utilizarse para representar la interconexión de:
a)dos ETD (de extremo), en cuyo caso una sola subred interviene en la conexión;
b)un ETD (de extremo) y otra subred, en cuyo caso intervienen en la conexión por lo menos dos subredes;
c)otras dos subredes; en este caso, la subred actúa como subred de tránsito; puede consistir en una sola FIF, o ser una red de tránsito propiamente dicha (véase la figura 6-4/X.300).
La misma colección de equipos, considerada como subred, se puede utilizar en uno o más de los mencionados casos a), b) y c).
6.1.1.5Desde el punto de vista de los usuarios, se distinguen dos situaciones básicas:
Diagrama/X.300, p.
En el caso (B), no es necesario, desde el punto de vista de los usuarios,
considerar la configuración exacta de la red. Esta puede ser, por ejemplo, una
sola red, dos redes interconectadas (vía una FIF, o no), etc.
También en el caso (B), los protocolos en los interfaces ETD X y ETD Y pueden ser diferentes.
6.1.1.6Desde el punto de vista de los proveedores de redes se distinguen las siguientes configuraciones:
Diagrama/X.300, p.
En los casos (Y) y (Z) una FIF puede participar en cualquiera de las subredes
utilizadas. En el caso (Z), la red intermedia puede estar constituida por una
sola FIF.
El procedimiento utilizado en el interfaz del ETD A no debe depender de la red o redes utilizadas en la conexión con el correspondiente ETD B.
6.1.1.7Según los casos de los 6.1.1.5 y 6.1.1.6, una determinada configuración de equipos de red puede considerarse como una sola subred, o como varias subredes distintas interconectadas, según el punto de vista del que se considere. Esto se ilustra en la figura 6-5/X.300:
Figura 6-5/X.300, p.
6.1.2
Descomposición de subredes con respecto a
protocolos y
servicios
Cuando los sistemas de extremo están interconectados a través de subredes, desde el punto de vista del sistema de extremo, es necesario considerar una sola subred (es decir, la subred compuesta de todas las subredes que hay entre los sistemas de extremo).
En la figura 6-6/X.300, esta subred se denomina subred S. La subred S puede
estar compuesta de las subredes S1 y S2. Se puede tener acceso a la subred S1
utilizando el protocolo
`a'
. El accesso a la subred S2 puede obtenerse
por el protocolo
`d'
. Se supone que las capacidades funcionales de la
subred S2 son más completas que las de la subred S1.
En lo que respecta al interfuncionamiento de red entre las subredes S1 y S2, se pueden aplicar diferentes conceptos:
a)El interfuncionamiento de red se basa en la funcionalidad de la subred S2. Esto implica la necesidad de un protocolo de convergencia transparente para la subred S1. Esta posibilidad se expone con mayor detalle en el 6.1.2.1 .
b)El interfuncionamiento de red se basa en la funcionalidad de la subred S1.
Esto implica que los elementos específicos del protocolo
`d'
no pueden
hacerse corresponder con los elementos del protocolo
`a'
utilizado entre
el ETD A y la subred S1. Este caso se describe en el
6.1.2.2
.
c)En muchas situaciones prácticas de interconexión de subredes, el interfuncionamiento de red puede corresponder a un nivel funcional que se encuentre entre los niveles funcionales realizados por las subredes S1 y S2. En este caso es necesario ya sea mejorar la subred S1 o contar con un protocolo de convergencia transparente a la subred S1. Sin embargo, el nivel funcional en que tiene lugar el interfuncionamiento de red es inferior al nivel funcional realizado por la subred S2. Este caso no se describe con más detalle, ya que se encuentra entre las posibilidades definidas en los 6.1.2.1 y 6.1.2.2 y no requiere más aclaraciones.
El concepto que debe elegirse para el interfuncionamiento de red depende de los requisitos de los servicios que deban prestarse mediante las disposiciones de interfuncionamiento. En los casos a), b) y c), un servicio de aplicación específico puede requerir un protocolo de convergencia adicional, transparente a las subredes S1 y S2. Un ejemplo de este caso es la prestación de servicios telemáticos por medio de servicios de transmisión de datos con conmutación de circuitos.
6.1.2.1 En este caso, se accede a la subred S (véase la figura 6-6/X.300, caso A) por los protocolos (a+b) o por el protocolo (d). Sin embargo, la descomposición de la subred S revela dos subredes participantes, S1 y S2. La subred S2 utiliza el protocolo (d) y se puede también tener acceso a ella por los protocolos (i+b). Se puede acceder a la subred S1 por medio del protocolo (a) y también por medio del protocolo (i).
Figura 6-6/X.300, p.
Toda la funcionalidad de subred (y) reside en realidad en la subred S2. La
subred S1 no proporciona la funcionalidad (y), pero proporciona una
funcionalidad diferente, (x). La compensación de la diferencia de funcionalidad
la ofrece el protocolo (b), en forma transparente para la subred S1.
La operación de descomposición se puede repetir cuantas veces sea necesario o conveniente para especificar los sistemas interconectados. Esta repetición se ilustra en la figura 6-7/X.300, que muestra también el papel desempeñado por diferentes servicios de subred (relacionados con las funcionalidades de subred). En general, se aplica lo siguiente:
[Servicio de subred (x) + protocolo de convergencia] = servicio de subred (y).
6.1.2.2 La figura 6-6/X.300, caso B, muestra el interfuncionamiento de red a base de la funcionalidad de la subred S1.
Varios elementos del protocolo
`d'
no pueden hacerse corresponder
directamente con los elementos del protocolo
`a'
utilizado entre el ETD
A y la subred S1. Por lo tanto, estos elementos del protocolo
`d'
no
están disponibles para el servicio de transmisión de datos resultante. La
funcionalidad general de la subred S es equivalente al nivel funcional
realizado por la subred S1. La pérdida de elementos del protocolo
`d'
cuando la funcionalidad de la subred S está al nivel de la subred S1 puede
provocar una pérdida de prestaciones de servicio para la comunicación desde el
punto de vista del ETD B.
La aplicación de este concepto de descomposición de una subred supone que se mantienen los atributos dominantes del servicio ofrecidos a cada lado de la comunicación y que únicamente se pierden las prestaciones de servicio que no son esenciales para los servicios de transmisión de datos requeridos.
Figure 6-7/X.300, p.
La figura 6-8/X.300 ilustra la relación existente entre los protocolos de
acceso a una subred, un protocolo de convergencia y los servicios de subred en
un sistema de extremo.
Figure 6-8/X.300, p.
6.1.3
Principios de interfuncionamiento entre subredes.
El interfuncionamiento entre subredes debe basarse en consideraciones sobre la funcionalidad de las subredes en cuestión. En tal interfuncionamiento no es necesario considerar ningún sistema intermedio que intervenga en una conexión de red dada. Cada red debe considerarse globalmente, en asociación con las funciones de interfuncionamiento adecuadas, cuando sea necesario. Para el interfuncionamiento entre dos redes, las partes de equipo de red se representarán como subredes interconectadas.
6.2
Categorías de interfuncionamiento
Esta sección describe las categorías de interfuncionamiento en que intervienen funciones relacionadas únicamente con la capacidad de transmisión (véase también el 3 ). Dos categorías de interfuncionamiento distintas entre dos redes han de considerarse en esta sección:
a)interfuncionamiento mediante correspondencia del control de llamada;
b)interfuncionamiento mediante acceso por puerto.
Nota
- Las flechas utilizadas en las figuras del
6.2
indican, en forma genérica, el intercambio de información que se
realiza en el interfaz de la subred. Su propósito no es representar las
primitivas del servicio de red (SR) transmitidas a través del interfaz
abstracto horizontal entre la capa de red y la capa de transporte.
6.2.1
Interfuncionamiento mediante correspondencia del
control de llamada
El interfuncionamiento mediante correspondencia del control de llamada se muestra en forma abstracta en la figura 6-9/X.300.
Figure 6-9 /X.300, p.
Algunos ejemplos posibles de este tipo de interfuncionamiento son el
interfuncionamiento entre RPDCC según la Recomendación X.71, el
interfuncionamiento entre una RPDCP y una RDSI según la Recomendación X.75, y
el interfuncionamiento entre una RPDCC y una RPDCP en el caso en que la
información del control de la llamada de la RPDCC se hace corresponder con la
información de control de llamada de la RPDCP.
6.2.2
Interfuncionamiento mediante acceso por
puerto
El interfuncionamiento mediante acceso por puerto se muestra en forma abstracta en la figura 6-10/X.300.
Un ejemplo posible de este tipo de interfuncionamiento es el interfuncionamiento entre una RTPC y una RPDCP donde primero se establece una conexión (conmutada o directa especial) a través de la RTPC con un puerto de la RPDCP, después de lo cual se aplican los procedimientos a través de dicha conexión para establecer una conexión a través de la RPDCP.
6.3
Clasificación de las subredes con respecto al
soporte del SR de ISA
Nota
- En esta sección, la clasificación de las
subredes en tipos se basa en el soporte por la red^* del SR con conexión de
ISA, y por lo tanto es válida únicamente en este contexto.
Otros tipos de subredes que permiten otros servicios y aplicaciones requieren ulterior estudio.
Figure 6-10/X.300, p.
6.3.1
Identificación de tipos de subred
En el 6.1 se definió cómo pueden intervenir, en la comunicación, subredes con funcionalidades diferentes. En esta sección se consideran ciertas funcionalidades de subredes, designadas como tipos de subred. En el cuadro 6-1/X.300 se indican las funcionalidades de los respectivos tipos de subred. Las funcionalidades se expresan en relación con el servicio de subred recomendado por el CCITT (definido en la Recomendación X.213) en las diferentes fases de una llamada.
La identificación de los tipos especiales de subred no implica ninguna obligación de mejorar dichas redes para fines de ISA ni limita el uso de dichas subredes a la ISA. Su propósito es más bien sentar una base general, al mismo tiempo que puede ser utilizada en cualquier aplicación.
Cuadro 6-1/X.300 [T4.300], p.
Para más detalles acerca de la identificación de tipos de subred, véase el
anexo A.
6.3.2
Relación entre redes y tipos de subred
En el 5 de la presente Recomendación se consideran las redes. La funcionalidad abstracta de estas redes reales corresponden a los tipos de subred indicados en el cuadro 6-2/X.300.
Cuadro 6-2/X.300 [T5.300], p.
Para ejemplos de los tipos de subred, véase el anexo B.
6.3.3
Interconexión de distintos tipos de subredes
En el 6.3.1 se identifican diferentes tipos de subredes. El cuadro 6-3a/X.300 indica como se aplican las diferentes categorías cuando se interconectan dos subredes.
Cuadro 6-3a/X.300 [T6.300], p.
En el
6.2
se definen diferentes categorías de interfuncionamiento.
En el
6.3.1
se identifican diferentes tipos de subred. En el cuadro
6-3b/X.300 se define la forma de aplicar las diferentes categorías cuando se
interconectan las subredes identificadas.
En el 8 se describen las disposiciones de interfuncionamiento detalladas relativas a los diferentes casos en materia de redes.
6.3.4
Utilización de los tipos de subred
Una subred determinada implica un servicio de subred en los sistemas de extremo. Cuando un determinado servicio de subred está disponible en los sistemas de extremo, toda realización en los sistemas de extremo que esté habilitada y sea capaz de utilizar un subconjunto o la totalidad del servicio de subred puede comunicar debidamente a través de la subred.
Por ejemplo, supóngase que dos sistemas de extremo se comunican a través de una subred de tipo III (por ejemplo, interconexión de RTPC). Dadas las posibilidades del servicio inherente a la subred, podrían comunicar a través de esta subred aplicaciones muy diferentes, desde el modo carácter hasta la ISA.
Los sistemas de extremo diseñados de conformidad con la ISA deben, a fin de estar abiertos los unos a los otros, admitir el servicio de subred normalizado para la ISA, a saber, el servicio de capa de red con conexión ISA.
Una determinada subred implica un determinado servicio de subred en los sistemas de extremo. Cuando en los sistemas de extremo está disponible cierto servicio de subred, la convergencia hacia el servicio de capa de red con conexión ISA será conforme al cuadro 6-4/X.300. En la Recomendación X.305 se definen las disposiciones precisas para tal convergencia.
Table 6-3b/X.300 [T7.300] p.
Table 6-4/X.300 [T8.300] p.
6.4
Relaciones con respecto a la gestión
La información de gestión para el control de las llamadas de usuario, la gestión interna de red, o el intercambio entre redes de tal información, puede ser suministrado, o efectuado, por la misma entidad y/o por entidades separadas que intercambian información de control de una llamada pedida por un usuario, e información de usuario a usuario. Las figuras 6-11/X.300 y 6-12/X.300 ilustran tales situaciones. La red puede descomponerse en dos o más entidades lógicas, a saber:
a)entidades que intercambian información de usuario a usuario y, en algunos casos, información de control de la llamada por el usuario; y/o
b)entidades, distintas de las anteriores, que efectúan un intercambio de información de gestión.
Ejemplo: La RTPC con SS N.o 7 - SS N.o 7 utiliza protocolos estratificados para intercambiar información de control de la llamada e información de gestión fuera del flujo de información de usuario.
Las disposiciones detalladas relativas al intercambio de información de gestión son objeto de Recomendaciones distintas (por ejemplo, la Recomendación X.370 y las Recomendaciones de la serie Q.700).
Figure 6-11/X.300, p.
Figure 6-12/X.300, p.
6.5
Principios básicos en relación con los
parámetros de indicación de servicio
6.5.1 Las RPD y la RDSI se utilizarán para suministrar diversos servicios telemáticos, a saber, servicios del CCITT en que se utilicen capacidades de comunicación definidas por el CCITT.
6.5.2 El mecanismo o mecanismos que se utilizarán para satisfacer cualesquiera requisitos relacionados con las indicaciones de servicio, por ejemplo, verificación de compatibilidad, deberán en particular tener en cuenta el caso de los servicios del CCITT que se hayan diseñado de conformidad con la Recomendación X.200 (Modelo de referencia de ISA para aplicaciones del CCITT) y otras Recomendaciones aplicables a protocolos ISA de las capas 4 y 7.
6.5.3El equipo que interviene en la concretización de la capacidad de transmisión actuará sólo sobre los parámetros relativos a esta capacidad de transmisión.
6.5.4Los parámetros relativos a la capacidad de comunicación no los verá el equipo que realiza la capacidad de transmisión, y se codificarán independientemente de los parámetros que definen la capacidad de transmisión.
6.5.5Para un tratamiento eficaz por la red, los parámetros de cada categoría pueden transmitirse globalmente en uno o varios perfiles.
6.5.6En una petición de llamada, una facilidad/utilidad sólo puede considerarse en el contexto de ISA, como un elemento de protocolo en la capa de red (capa 3). No puede considerarse como un elemento de protocolo en capas superiores a la capa de red.
Nota
- Un paquete de petición de llamada que atraviesa
una RPDCP puede contener datos de usuario con elementos de protocolo
relacionados con la capacidad de comunicación (esto es, en una o más capas
superiores a la capa de red). De manera similar, un mensaje ESTABLECIMIENTO que
atraviesa una RDSI puede contener información de usuario.
6.5.7Asimismo, una facilidad/utilidad puede contener información relacionada con servicios definidos por el CCITT (por ejemplo, servicios telemáticos).
7 Principios de
interfuncionamiento con intervención de capacidades
de transmisión y de comunicación
La diferentes categorías de interfuncionamiento pueden incluir diferentes niveles de funciones:
a)en algunos casos, únicamente las funciones relacionadas con la transferencia transparente de información entre dos ETD a través de la red o redes (capacidad de transmisión);
b)en otros casos, también funciones adicionales construidas sobre la base de las funciones relacionadas con la transferencia transparente de información (capacidad de comunicación).
Esta sección describe los conceptos y principios básicos relativos a los casos mencionados en b).
7.1
Composición y descomposición de sistemas de relevo
de aplicación
7.1.1
Concepto de sistema intermedio de aplicación
7.1.1.1Las entidades correspondientes cooperan, como se indica en el ejemplo de las siguientes figuras 7-1/X.300 y 7-2/X.300.
Figura 7-1/X.300, p.
Figura 7-2/X.300, p.
7.1.1.2Al igual que en el caso de una subred, no siempre es necesario
considerar los sistemas intermedios que intervienen en una llamada determinada.
Por tanto, en lo que respecta al estudio de las disposiciones de
interfuncionamiento entre redes reales, puede resultar interesante considerar
esas combinaciones de sistemas intermedios como un sólo sistema intermedio
abstracto, que interviene en la comunicación, como se indica en la siguiente
figura 7-3/X.300 (que muestra dos representaciones equivalentes de sistemas
intermedios que intervienen en la llamada).
Figure 7-3/X.300, p.
7.1.1.3Un sistema de relevo de aplicación puede contener diversas
combinaciones de equipos, incluidas diferentes unidades de interfuncionamiento
de aplicaciones reales y redes reales*. Siempre hay por lo menos una FIF de
aplicación real. Esto se puede representar gráficamente como se muestra en la
figura 7-4/X.300.
Figura 7-4/X.300, p.
7.1.1.4Un sistema de relevo de aplicación puede utilizarse para representar la
interconexión de:
a)dos ETD de extremo, en cuyo caso interviene en la conexión un solo sistema de relevo de aplicación;
b)un ETD de extremo y otro sistema de relevo de aplicación, en cuyo caso intervienen en la conexión por lo menos dos sistemas de relevo de aplicación;
c)otros dos sistemas de relevo de aplicación; el sistema de relevo de aplicación actúa como un sistema de relevo de aplicación de tránsito; puede consistir en una sola FIF de aplicación, o ser una red de tránsito propiamente dicha constituida por más FIF de aplicación (véase la figura 7-4/X.300);
d)los sistemas de extremo y/o sistemas de relevo de aplicación pueden también estar interconectados por subredes, y no directamente.
La misma colección de equipos, considerada como un sistema de relevo de aplicación, se puede utilizar en uno o más de los mencionados casos a), b) c) y d).
7.1.1.5Desde el punto de vista de los usuarios, existen dos situaciones básicas, a saber:
Diagrama/X.300, p.
En el caso (B), no es necesario, desde el punto de vista del usuario,
considerar la configuración exacta del sistema de relevo de aplicación. El
sistema de relevo de aplicación puede, por ejemplo, ser: una sola FIF de
aplicación, dos FIF de aplicación interconectadas, etc.
7.1.1.6Desde el punto de vista de los proveedores de red, se han de considerar diferentes configuraciones, a saber:
Diagrama/X.300, p.
En los casos (Y) y (Z), una FIF de aplicación puede participar en cualquiera
de los sistemas de relevo de aplicación utilizados. En el caso (Z), el sistema
de relevo de aplicación puede consistir en una sola FIF de aplicación. En todos
los casos, los sistemas de relevo de aplicación y los ETD pueden comunicar
entre sí directamente o a través de una subred.
El procedimiento utilizado en el interfaz de ETD A no debe depender del sistema o sistemas de relevo de aplicación en la conexión con el correspondiente ETD B.
7.1.1.7Según los casos de 7.1.1.5 y 7.1.1.6, una determinada configuración de equipos puede considerarse como un solo sistema de relevo de aplicación, o como varios sistemas de relevo de aplicación distintos interconectados, según el punto de vista desde el que se considere. Esto se ilustra en la figura 7-5/X.300:
Figura 7-5/X.300, p.
7.1.2
Descomposición de sistemas de relevo de aplicación con
respecto a protocolos y servicios
Cuando los sistemas de extremo están interconectados a través de sistemas de relevo de aplicación y subredes, desde el punto de vista del sistema de extremo, sólo se requiere considerar un sistema de relevo de aplicación (es decir, el sistema de relevo de aplicación compuesto de todos los sistemas de relevo de aplicación y de todas las subredes que hay entre los sistemas de extremo).
Esta observación se muestra en la figura 7-6/X.300. En este ejemplo, se accede al sistema de relevo de aplicación A mediante los protocolos (a+b) o mediante los protocolos (c+d). Sin embargo, al descomponer el sistema de relevo de aplicación A, se observa la participación de dos subredes, a saber, S1 y S2. La subred S2 utiliza el protocolo (d), y también se puede acceder a ella mediante el protocolo (e). Para acceder a la subred S1 se puede utilizar el protocolo (a) o el protocolo (f). Para acceder al sistema de relevo A1 se pueden utilizar los protocolos (b+f) o (c+e).
De hecho, la funcionalidad completa del sistema de relevo de aplicación A reside en el sistema de relevo A1.
Figure 7-6/X.300, p.
7.2
Categorías de interfuncionamiento
Esta sección describe las categorías de funcionamiento en que intervienen funciones relacionadas con la capacidad de comunicación. En esta sección se identifican tres categorías diferentes de interfuncionamiento:
a)interfuncionamiento en capas superiores de ISA;
b)interfuncionamiento mediante correspondencia del control de la llamada a través de un adaptador no ISA;
c)interfuncionamiento mediante acceso por puerto a través de un adaptador no ISA.
7.2.1
Interfuncionamiento en capas superiores de ISA
En esta categoría de interfuncionamiento interviene una función de interfuncionamiento, que actúa con funciones hasta la capa de aplicación inclusive, como se ilustra en la figura 7-7/X.300.
Figura 7-7/X.300, p.
En este caso, se establecen dos conexiones diferentes de la capa de red; la
FIF actúa como un relevo de capa de aplicación entre estas dos conexiones de la
capa de red.
Interfuncionamiento mediante correspondencia del control
de la llamada a través de un adaptador no ISA
La figura 7-8/X.300 ilustra este tipo de interfuncionamiento, en el que el ETD A y el ETD B comunican a través de un adaptador no ISA, y en el que el ETD A tiene la posibilidad de indicar directamente la dirección del ETD B.
Figura 7-8/X.300, p.
7.2.3
Interfuncionamiento mediante acceso por puerto a través
de un adaptador no ISA
En este método, se utiliza la red 1 para establecer una conexión física entre el ETD A y un adaptador no ISA, con carácter provisional, como se muestra en la figura 7-9/X.300.
Figura 7-9/X.300, p.
7.2.4
Ejemplos de adaptadores no ISA
El EDD de la Recomendación X.28 constituye un ejemplo de adaptador no ISA.
7.3
Identificación de tipos de sistemas de relevo de
aplicación
(Para ulterior estudio).
7.4
Relación entre FIF de aplicación, redes reales y tipos
de sistemas de relevo de aplicación
{tps.non.photo ""} (Para ulterior estudio).
7.5
Interconexión de tipos de sistemas de relevo de
aplicación
(Para ulterior estudio).
7.6
Utilización de tipos de sistemas de relevo de
aplicación
7.6.1
Todas las aplicaciones
(Para ulterior estudio).
7.6.2
Aplicaciones ISA
(Para ulterior estudio).
7.7
Relaciones con respecto a la gestión
(Para ulterior estudio).
7.8
Relaciones con el modelo de referencia de ISA para
aplicaciones del CCITT
(Para ulterior estudio).
7.9
Principios básicos en relación con los parámetros de
indicación de servicio
(Para ulterior estudio).
8. Descripción de las
diferentes condiciones de
interfuncionamiento
En esta sección se describen las diferentes condiciones para el interfuncionamiento entre las redes mencionadas en el 5 , sobre la base de las categorías de interfuncionamiento descritas en el 6 .
8.1
Generalidades
En el cuadro 8-1/X.300 se describen las condiciones para el interfuncionamiento entre dos RPD o entre una RPD y otra red, para proporcionar servicios de transmisión de datos. En los casos en que intervienen más de dos redes en una conexión determinada, se aplica el cuadro 8-1/X.300, en la forma adecuada, para cada interfuncionamiento entre dos redes.
Nota.
- De momento no se describen las condiciones
para el interfuncionamiento entre dos RPD o entre una RPD y otra red para
proporcionar servicios no relacionados con la transmisión de datos. En
particular, serán objeto de ulterior estudio los requisitos de una RPD, cuando
interfuncione con la red télex pública en relación con servicios télex del
CCITT.
8.2
Interfuncionamiento vía un adaptador no ISA entre
la RTPC y la RPDCP
8.2.1
Interfuncionamiento directo vía un adaptador no
ISA
En este método de interfuncionamiento, una RTPC puede ofrecer un adaptador no ISA que proporcione, por ejemplo, la función EDD. Además, una RTPC puede ofrecer la selección de encaminamiento de adaptador no ISA para interfuncionamiento directo, a fin de indicar directamente la dirección del ETD B.
En el acceso de salida de la RTPC a la RPDCP, un ETD llamante origina una petición de llamada de RTPC indicando la dirección de un ETD llamado conectado a la RPDCP, de manera que la RTPC pueda proporcionar la dirección del ETD llamado al adaptador no ISA. Por lo tanto, no se requiere un procedimiento independiente de petición de llamada según la Recomendación X.28.
En la figura 8-1/X.300 se ilustra una disposición posible de interfuncionamiento entre una RTPC y la RPDCP.
En este interfuncionamiento:
a)la disposición entre el adaptador no ISA de la RTPC y la RPDCP se basa en la Recomendación X.75;
b)el adaptador no ISA proporciona la conversión entre la señalización telefónica convencional y la de la Recomendación X.75 durante la fase de establecimiento de llamada;
c)durante la fase de transferencia de datos, los protocolos definidos en las Recomendaciones X.28 y X.29 son utilizados en la RTPC y RPDCP, respectivamente.
Nota
- La condición para utilizar la Recomendación
X.75, como se mencionan en a) y b), requiere ulterior estudio.
8.2.2
Interfuncionamiento vía un adaptador no ISA
por el método de acceso por puerto
En el acceso de salida de la RTPC a la RPDCP, un ETD llamante origina una
`petición de llamada'
X.28 a un adaptador no ISA indicando la dirección
de un ETD llamado conectado a la RPDCP, después de establecer una conexión RTPC
con el adaptador no ISA, lo que significa un procedimiento de petición de
llamada en dos etapas.
En el acceso de salida de la RPDCP a la RTPC, un ETD llamante origina una petición de llamada X.29 indicando la dirección de un ETD llamado conectado a la RTPC.
En este método de interfuncionamiento, una RPDCP puede ofrecer un adaptador no ISA que proporcione, por ejemplo, la función EDD.
En la figura 8-2/X.300 se ilustra una disposición posible de interfuncionamiento entre la RTPC y la RPDCP.
Tableau 8-1/X.300 [T9.300], plus Notes p.
FIGURE 8-1/X.300, p.
FIGURE 8-2/X.300, p.
En esta disposición de interfuncionamiento:
a)el adaptador no ISA (EDD X.3) proporciona la conversión entre los interfaces ETD/ETCD de las Recomendaciones X.28 y X.29;
b)se utiliza el protocolo del interfaz X.28 ETD/ETCD para establecer la llamada desde el adaptador no ISA al ETD B llamado;
c)se utiliza el protocolo del interfaz X.29 ETD/ETCD para establecer la llamada desde el ETD B al ETD A;
d)durante la fase de transferencia de datos, se utilizan los protocolos definidos en las Recomendaciones X.28 y X.29 en los interfaces ETD/ETCD de la RTPC y la RPDCP, respectivamente.
8.3
Interfuncionamiento con intervención de la RDSI
para la prestación de servicios de transmisión de
datos
8.3.1
Interfuncionamiento entre la RDSI y las
RPD
En las situaciones de interfuncionamiento entre la RDSI y las RPD, se deben considerar los tipos de conexión RDS definidos en la Recomendación I.340. En especial para la fase de transferencia de datos se debe distinguir claramente entre servicios modo paquete y en modo circuito. Los escenarios para la conexión a la RDSI de terminales que permiten estos modos se describen en la Recomendación X.30 para el modo circuito y en la Recomendación X.31 para el modo paquete y el modo circuito.
Se consideran diferentes casos de interfuncionamiento que están basados en el interfuncionamiento mediante correspondencia de control de la llamada de ISA (véase el 6.2.1 ) o en el interfuncionamiento mediante acceso por puerto (véase el 6.2.2 ):
i)RDSI donde se solicita un portador de conmutación de circuitos - RPDCC (véase la Recomendación X.321).
ii)RDSI donde se solicita un portador de conmutación de paquetes - RPDCP (véase la Recomendación X.325).
iii)RDSI donde se solicita un portador de conmutación de circuitos - RPDCP (véase la Recomendación X.325).
Debe considerarse tanto el caso de
`acceso a los servicios de transmisión
de datos proporcionados por RPDCP (servicios RPDCP)'
como el de
`servicio portador de circuito virtual RDSI'
de acuerdo con la
Recomendación X.31.
Se debe considerar tanto el interfuncionamiento mediante correspondencia de control de la llamada como el interfuncionamiento mediante acceso por puerto.
iv)RDSI donde se solicita un portador de conmutación de paquetes-RPDCP (véase la Recomendación X.321).
En este caso, únicamente es aplicable el servicio portador de circuito virtual RDSI acorde con la Recomendación X.31.
8.3.2
Interfuncionamiento entre dos RDSI para la
prestación de servicios de transmisión de
datos
Cuando se utiliza un portador de conmutación de circuitos para acceder a la RDSI en un interfaz (CC), y un servicio portador de circuito virtual para acceder a la RDSI en otro interfaz (CP) (véase la figura 8-3/X.300), la configuración puede descomponerse como se ilustra en la figura 8-3/X.300, caso b). Las disposiciones de interfuncionamiento se presentan en los puntos siguientes de la presente Recomendación, con arreglo a esta descomposición.
FIGURE 8-3/X.300, p.
En las situaciones de interfuncionamiento entre RDSI, hay que considerar los
tipos de conexión RDSI definidos en la Recomendación I.340. Hay que distinguir
en especial entre transferencia de información en modo circuito y en modo
paquetes. Los escenarios para la conexión a la RDSI de terminales que permiten
estos modos se describen en la Recomendación X.30 para el modo circuito y en la
Recomendación X.31 para los servicios modo paquete y modo circuito.
Se consideran diversos casos de interfuncionamiento basados en el interfuncionamiento mediante correspondencia de control de la llamada (véase el 6.2.1 ) o el interfuncionamiento mediante acceso por puerto (véase el 6.2.2 ):
i)RDSI/RDSI cuando en ambas RDSI se solicita un portador de conmutación de paquetes; se debe tener en cuenta tanto el acceso a los servicios de transmisión de datos proporcionados por la RPDCP (servicios RPDCP) como al servicio portador de circuito virtual RDSI definido en la Recomendación X.31;
ii)RDSI/RDSI cuando en ambas RDSI se solicita un portador de conmutación de circuitos;
iii)RDSI/RDSI cuando en una RDSI se solicita un portador de conmutación de paquetes y en la otra RDSI un portador de conmutación de circuitos. Se debe tener en cuenta tanto el interfuncionamiento mediante correspondencia del control de la llamada como el interfuncionamiento mediante acceso por puerto.
Para la descripción de estas disposiciones de interfuncionamiento, véase la Recomendación X.320.
ANEXO A (a la Recomendación X.300)
Categorías básicas
de subredes
-Subred de tipo I,
-Subred de tipo II,
-Subred de tipo III,
-Subred de tipo IV.
Estos tipos de subred se describen en la secciones A.1, A.2, A.3 y A.4 respectivamente.
Nota
- En este anexo, la clasificación de las subredes
en tipos se basa en el soporte por la red* del SR con conexión ISA, y por lo
tanto es válida únicamente en este contexto.
Otros tipos de subredes que permiten otros servicios y aplicaciones requieren ulterior estudio.
A.1
Subred de tipo I
A.1.1 Las subredes de tipo I funcionan durante las diferentes fases de una conexión, como se indica en el 6 .
A.1.2 Las redes que corresponden a la funcionalidad de la subred de tipo I son la RPDCP y la RDSI(CP). La figura A-1/X.300 presenta un ejemplo de la RPDCP.
A.2
Subred de tipo II
A.2.1 Las subredes de tipo II funcionan durante las diferentes fases de una conexión como se indica en el 6 :
A.2.2 Una red que corresponde a la funcionalidad de la subred de tipo II es la RDSI(CC), y se ilustra en la figura A-2/X.300.
Nota 1
- Los detalles de esta correspondencia están en
estudio.
Nota 2
- Actualmente se está estudiando cómo mejorar
las RPDCC a fin de que incluyan la funcionalidad de este tipo de subred.
Figure A-1/X.300, p.
Figure A-2/X.300, p.
A.3
Subred de tipo III
A.3.1 Las subredes de tipo III funcionan durante las diferentes fases de una conexión como se indica en el 6 .
A.3.2 Las redes que corresponden a la funcionalidad de subred de tipo III son las RPDCC y las RTPC (para el suministro de servicios de transmisión de datos). La figura A-3/X.300 ilustra este ejemplo.
FIGURE A-3/X.300, p.
A.4
Subred de tipo IV
A.4.1 Las subredes de tipo IV funcionan durante las diferentes fases de una conexión como se indica en el 6 .
A.4.2 Los ejemplos de las redes que corresponden a la funcionalidad de las subredes de tipo IV requieren ulterior estudio.
ANEXO B (a la Recomendación X.300)
Ejemplos de
composiciones de subredes
B1:Interconexión tipo I - tipo II;
B2:Interconexión tipo I - tipo III;
B3:Interconexión tipo II - tipo III;
B4:Interconexión tipo IV - tipo I.
En B1 y B2 se presentan también otras combinaciones con subredes del tipo IV.
La aplicabilidad de estas composiciones depende de las capacidades del equipo terminal conectado a las subredes.
Nota
- En este anexo, la clasificación de las subredes
en tipos se basa en el soporte por la red* del SR con conexión ISA, y por lo
tanto es válida únicamente en este contexto.
Otros tipos de subredes que permiten otros servicios y aplicaciones requieren ulterior estudio.
B.1
Ejemplos de interconexión tipo I - tipo II
De acuerdo con el 6.1.2 a), la funcionalidad de la subred S1 puede ser del tipo I (véase la figura B1-1/X.300). Esto se realiza por medio de una FIF adecuada. En este caso, la funcionalidad de la subred S corresponde también al tipo I.
FIGURE B1-1/X.300, p.
De acuerdo con el
6.1.2
b), la funcionalidad de la subred S1 puede
ser del tipo II (véase la figura B1-2/X.300). Esto se realiza por medio de una
función de interfuncionamiento adecuada. En este caso, la funcionalidad de la
subred S corresponde también al tipo II.
FIGURE B1-2/X.300, p.
De acuerdo con el
6.1.2
c), la funcionalidad de la subred S1 no
puede ser asignada a ninguno de los tipos de subconjunto (véase la figura
B1-3/X.300). Su uso está sujeto a acuerdos bilaterales.
FIGURE B1-3/X.300, p.
B.2
Interconexión tipo I - tipo III
De acuerdo con el 6.1.2 a), la funcionalidad de la subred S1 puede ser del tipo I (véase la figura B2-1/X.300). Esto se realiza por medio de una FIF adecuada. En este caso, la funcionalidad de la subred S corresponde también al tipo I.
FIGURE B2-1/X.300, p.
De acuerdo con el
6.1.2
b), la funcionalidad de la subred S1 puede
ser del tipo III (véase la figura B2-2/X.300). Esto se realiza por medio de una
FIF adecuada. En este caso, la funcionalidad de la subred S corresponde también
al tipo III.
FIGURE B2-2/X.300, p.
De acuerdo con el
6.1.2
c), la funcionalidad de la subred S1 no
puede asignarse a uno de los tipos de subred (véase la figura B2-3/X.300). Su
utilización está sujeta a acuerdos bilaterales.
FIGURE B2-3/X.300, p.
B.3
Interconexión tipo II - tipo III
De acuerdo con el 6.1.2 a), la funcionalidad de la subred S1 puede ser del tipo II (véase la figura B3-1/X.300). Esto se realiza por medio de una FIF adecuada. En este caso, la funcionalidad de la subred S corresponde también al tipo II.
FIGURE B3-1/X.300, p.
De acuerdo con el
6.1.2
b), la funcionalidad de la subred S1 puede
ser del tipo III (véase la figura B3-2/X.300). Esto se realiza por medio de una
FIF adecuada. En este caso, la funcionalidad de la subred S corresponde también
al tipo III.
FIGURE B3-2/X.300, p.
De acuerdo con el
6.1.2
c), la funcionalidad de la subred S puede
ser del tipo IV (véase la figura B3-3/X.300). Esto se realiza por medio de una
FIF adecuada.
FIGURE B3-3/X.300, p.
B.4
Interconexión tipo IV - tipo I
Los ejemplos de las disposiciones de interfuncionamiento de este grupo de interconexiones requieren ulterior estudio.
MONTAGE : RECOMMANDATION X.301 SUR LE RESTE DE CETTE PAGE
(H.T.=OUI)
TAB.???
FICHIER: H.T. =
(86.TA.270.S)
(SANS FORMULE) Tableaux: 14 Tabulateurs: 1 - NF07/003
(1BT) (BT..)
(86.TE.03.S)
(A1.23s) / [26s]
FOLIOS: 52 - 110 (AS)
(DO PRC.COSY.2)
MEP {TPS.NON.PHOTO "[PA1]"} : OK= [1]
Saisie 26.01.89 PR
ID + LASER 21.02.89 CW
MAJ diskette 22.02.89 CW
Corr. LASER (1re épreuve) = 3eme 01.03.89 YB
Espaces réservés 7.03.89 PC
AJOUTER (PA1) (CL1,0,0,0) pour MEP
MEP + LASER 13.03.89 GH/PC
Corr. MEP ........ ..
Insertion des tableaux (tabulateurs 1) 13.03.89 PC
BAT 6.04.89 PM
MAJ s/disquettes 28.04.89 CD
MONTAGE : FIN DE LA RECOMMANDATION X.300 EN-TêTE DE CETTE
PAGE
Recomendación X.301
DESCRIPCIóN DE LAS
DISPOSICIONES
GENERALES PARA EL CONTROL DE LA LLAMADA
DENTRO DE UNA SUBRED Y ENTRE SUBREDES PARA LA PRESTACIóN DE
SERVICIOS DE TRANSMISIóN DE DATOS
(incluida anteriormente en la Recomendación X.300,
Málaga-Torremolinos, 1984; modificada en Melbourne, 1988)
El CCITT,
considerando
(a) que la Recomendación X.1 define las clases de servicio internacionales de usuario en redes públicas de datos y en la RDSI;
(b) que la Recomendación X.2 define los servicios y facilidades internacionales de usuario en las RPD y en la RDSI;
(c) que la Recomendación X.10 define las diversas categorías de acceso de equipos terminales de datos (ETD) a los diferentes servicios de transmisión de datos proporcionados por redes públicas de datos (RPD) y la RDSI;
(d) que la Recomendación X.96 define las señales de progresión de la llamada, incluidas las que se utilizan conjuntamente con facilidades internacionales de usuario;
(e) que las Recomendaciones X.20, X.20^
bis
, X.21,
X.21^
bis
, X.25, X.28, X.29, X.32, X.351 y X.352 ya
especifican los procedimientos detallados aplicables a los diferentes tipos de
interfaces ETD/ETCD en las RPD y que las Recomendaciones X.30, X.31 (I.420 e
I.421) especifican los procedimientos detallados de acceso a la RDSI;
(f) que las Recomendaciones X.61, X.70, X.71 y X.75 ya especifican los procedimientos detallados aplicables al control de las llamadas entre dos RPD del mismo tipo y que la Recomendación X.75 puede aplicarse también al interfuncionamiento entre diferentes RPD y al interfuncionamiento con intervención de la RDSI;
(g) que las RPD se pueden utilizar para facilitar servicios recomendados por el CCITT (en particular, servicios telemáticos);
(h) que la Recomendación X.200 especifica el modelo de referencia de interconexión de sistemas abiertos para aplicaciones del CCITT;
(i) que la Recomendación X.213 define el servicio de capa de red en el modo conexión de la interconexión de sistemas abiertos para las aplicaciones del CCITT;
(j) que las Recomendaciones X.130, X.131, X.134, X.135, X.136, X.137 y X.140 definen los parámetros y valores requeridos de la calidad de servicio para servicios públicos de transmisión de datos;
(k) que la Recomendación X.300 define los principios generales de interfuncionamiento entre redes públicas de datos y entre redes públicas de datos y otras redes para la prestación de servicios de transmisión de datos;
(l) que la Recomendación X.302 describe las disposiciones generales relativas a las utilidades de red internas, en una subred, y las utilidades intermedias entre subredes para la prestación de servicios de transmisión de datos;
(m) la necesidad de considerar el interfuncionamiento con la red de señalización por canal común (RSCC), teniendo en cuenta las condiciones para la transferencia de información de explotación entre las Administraciones;
(n) la necesidad de que los ETD puedan comunicar a través de redes diferentes, y en diferentes condiciones de interfuncionamiento entre redes;
(o) la necesidad de disposiciones para el interfuncionamiento entre redes públicas de datos, y entre éstas y otras redes públicas a efectos del suministro de servicios de transmisión de datos;
(p) la necesidad, en particular:
-de establecer ciertas facilidades de usuario y utilidades de red para la comunicación, a través de redes nacionales, entre los protocolos de interfaz de equipo terminal de datos definidos en el plano internacional y los procedimientos de control y señalización internacionales entre centrales,
-de establecer ciertas utilidades de red definidas en el plano internacional para la operación internacional de las redes públicas,
-de que los principios relativos al establecimiento de facilidades internacionales de usuario y de utilidades de red en las redes públicas sean compatibles y uniformes,
recomienda (por unanimidad)
que las disposiciones de control de la llamada para el interfuncionamiento entre redes públicas, y entre éstas y otras redes, y los elementos necesarios:
-para la realización del interfuncionamiento de diferentes redes que suministran servicios de datos, y
-para la realización de facilidades internacionales de usuario y utilidades de red para servicios de transmisión de datos,
concuerdan con los principios y procedimientos especificados en esta Recomendación.
íNDICE
0
Introducción
1
Objeto y campo de aplicación
2
Referencias
3
Definiciones
4
Abreviaturas
5
Aspectos generales del control de la llamada
5.1Modelo aplicable a disposiciones interredes 5.2Clasificación de señales interredes 5.3Principios generales relativos a las señales interredes
6
Transferencia de información de direccionamiento
6.1Generalidades 6.2Transferencia de la dirección llamante X.121 6.3Transferencia de la dirección llamante E.164 6.4Transferencia de la dirección llamada X.121 6.5Transferencia de la dirección llamada E.164 6.6Formato de direcciones X.121 6.7Codificación de direcciones E.164 6.8Transferencia de información de dirección adicional a la mencionada en las Recomendaciones X.121 y E.164
7
Disposiciones para facilidades de usuario
7.1Facilidades relacionadas con la calidad de servicio (CDS) de la llamada 7.2Facilidades relacionadas con las condiciones de tarificación aplicables a la llamada 7.3Facilidades relacionadas con las condiciones específicas de encaminamiento solicitadas por el usuario de la llamada 7.4Facilidades relacionadas con los mecanismos de protección solicitados por el usuario de la llamada 7.5Facilidades para transportar datos de usuario, además del flujo normal de datos en la fase de transferencia de datos 7.6Otras facilidades
8
Disposiciones para señales de progresión de la
llamada
8.1Señales de progresión de la llamada durante el establecimiento de la llamada 8.2Señales de progresión de la llamada de liberación durante la transferencia de datos 8.3Señales de progresión de la llamada de reiniciación durante la transferencia de datos 8.4Disposiciones interredes con intervención de señales de progresión de la llamada definidas en las Recomendaciones X.96 y Q.931 8.5Disposiciones interredes con intervención de señales de progresión de la llamada definidas en las Recomendaciones X.96 y Q.699 8.6Disposiciones interredes con intervención de señales de progresión de la llamada definidas en las Recomendaciones Q.931 y Q.699
Apéndice I
-Elementos de protocolo de diferentes redes
utilizados para las facilidades y disposiciones descritas en esta Recomendación
Apéndice II
-Disposiciones para el soporte del servicio
de red ISA.
0 Introducción
Esta Recomendación forma parte de un conjunto de Recomendaciones elaboradas
para facilitar la consideración del interfuncionamiento entre redes. Se
relaciona con la Recomendación X.300, que define los principios generales del
interfuncionamiento entre redes públicas y entre redes públicas y otras redes a
efectos del suministro de servicios de transmisión de datos. La Recomendación
X.300 indica, en particular, cómo colecciones de equipos físicos pueden ser
considerados como
`subredes'
para el análisis de situaciones de
interfuncionamiento.
Esta Recomendación describe las disposiciones generales para el control de la llamada dentro de subredes, y entre subredes, para el suministro de los servicios de transmisión de datos. Sólo se describen las disposiciones que pueden (también) ser importantes para los usuarios de extremo de una llamada. Las facilidades que no son visibles para los usuarios de extremo de una llamada son objeto de otras Recomendaciones (por ejemplo, las disposiciones descritas en la Recomendación X.302).
1 Objeto y campo de aplicación
Esta Recomendación tiene por objeto describir las disposiciones interredes detalladas para el control de la llamada que se aplican al m interfuncionamiento en la capa de red de ISA, incluidas algunas de las disposiciones necesarias para servir de soporte a la capacidad del servicio de capa de red con conexión ISA.
Estas disposiciones no son aplicables al interfuncionamiento con intervención de capacidad de comunicación descrito en la sección 7.2 de la Recomendación X.300.
Se estudiará ulteriormente si algunas de estas disposiciones se aplican también a otros tipos de interfuncionamiento, por ejemplo, el interfuncionamiento mediante acceso por puerto descrito en la Recomendación X.300.
En esta Recomendación no se describen las disposiciones utilizadas únicamente para la operación interna o interredes y que no son visibles por los usuarios de extremo. Para tales disposiciones, véase la Recomendación X.302.
2
Referencias
E.164/I.331Plan de numeración de la RDSI.
Serie I.230Servicios portadores soportados por una RDSI.
Serie I.250Servicios suplementarios soportados por una RDSI.
I.420Interfaz usuario-red básico.
I.421Interfaz usuario-red a velocidad primaria.
Q.699Interfuncionamiento entre el protocolo de interfaz usuario-red de la RDSI y la parte usuario RDSI del sistema de señalización N.o 7.
Q.931/I.451Especificación de la capa 3 del interfaz usuario-red de la RDSI.
X.1Clases de servicio internacional de usuario en redes públicas de datos y en redes digitales de servicios integrados (RDSI).
X.2Servicios de transmisión de datos y facilidades facultativas de usuario internacionales en redes públicas de datos y en redes digitales de servicios integrados.
X.10Categorías de acceso para el equipo terminal de datos (ETD) a los servicios públicos de transmisión de datos.
X.20Interfaz entre el equipo terminal de datos (ETD) y el equipo de terminación del circuito de datos (ETCD) para servicios de transmisión arrítmica en las redes públicas de datos.
X.20^
bis
Utilización, en las redes públicas de datos,
de un equipo terminal de datos (ETD) diseñado para su conexión con modems
dúplex asíncronos de la serie V.
X.21Interfaz entre el equipo terminal de datos (ETD) y el equipo de terminación del circuito de datos (ETCD) para funcionamiento síncrono en redes públicas de datos.
X.21^
bis
Utilización, en las redes públicas de datos,
de un equipo terminal de datos (ETD) diseñado para su conexión con modems
síncronos de la serie V.
X.22Interfaz múltiplex ETD/ETCD para las clases de servicio de usuario 3 a 6.
X.25Interfaz entre el equipo terminal de datos (ETD) y el equipo de terminación del circuito de datos (ETCD) para equipos terminales que funcionan en el modo paquete y conectados a redes públicas de datos por circuitos especializados.
X.28Interfaz ETD/ETCD para un equipo terminal de datos arrítmico con acceso a la facilidad de empaquetado/desempaquetado de datos (EDD) en una red pública de datos situada en el mismo país.
X.29Procedimientos para el intercambio de información de control y datos de usuario entre una facilidad de empaquetado/desempaquetado de datos (EDD) y un ETD de paquetes u otro EDD.
bis
y
X.20^
bis
por una red digital de servicios integrados
(RDSI).
X.31/I.462Soporte de equipos terminales en modo paquete por una red digital de servicios integrados (RDSI).
X.32Interfaz entre el equipo terminal de datos (ETD) y el equipo de terminación del circuito de datos (ETCD) para terminales que funcionan en el modo paquete y acceden a una red pública de datos con conmutación de paquetes a través de una red telefónica pública conmutada, una red digital de servicios integrados o una red pública de datos con conmutación de circuitos.
X.61Sistema de señalización N.o 7 - Parte de usuario de datos.
X.70Sistema de señalización de control terminal y de tránsito para servicios arrítmicos en circuitos internacionales entre redes anisócronas de datos.
X.71Sistema de señalización descentralizada de control terminal y de tránsito para circuitos internacionales entre redes síncronas de datos.
X.75Sistemas de señalización con conmutación de paquetes entre redes públicas que proporcionan servicios de transmisión de datos.
X.80Interfuncionamiento de sistemas de señalización entre centrales para servicios de datos con conmutación de circuitos.
X.96Señales de progresión de la llamada en redes públicas de datos.
X.110Principios de encaminamiento para servicios de datos públicos internacionales a través de redes públicas de datos del mismo tipo.
X.121Plan de numeración internacional para redes públicas de datos.
X.130Objetivos provisionales para los tiempos de establecimiento y liberación de la llamada en redes públicas síncronas de datos (con conmutación de circuitos).
X.131Objetivos provisionales para el grado de servicio en comunicaciones internacionales de datos a través de las RPDCP.
X.134Fronteras de porciones y sucesos de referencia de la capa paquete: base para la definición de los parámetros de comportamiento en el servicio con conmutación de paquetes.
X.135Valores de comportamiento con respecto a la velocidad de servicio (retardo y caudal) para las redes públicas de datos que prestan el servicio internacional de conmutación de paquetes.
X.136Valores de comportamiento con respecto a la exactitud y seguridad de funcionamiento para las redes públicas de datos que prestan servicios internacionales con conmutación de paquetes.
X.137Valores de comportamiento con respecto a la disponibilidad de las redes públicas de datos que prestan el servicio internacional de comunicación de datos con conmutación de paquetes.
X.140Parámetros generales de calidad de servicio para comunicación a través de redes públicas de datos.
X.180Disposiciones administrativas para los grupos cerrados de usuarios (GCU) internacionales.
X.200Modelo de referencia de interconexión de sistemas abiertos para aplicaciones del CCITT.
X.213Definición del servicio de red para la interconexión de sistemas abiertos (ISA) para aplicaciones del CCITT.
X.300Principios y disposiciones generales para el interfuncionamiento entre redes públicas de datos, y entre éstas y otras redes para el suministro de servicios de transmisión de datos.
X.302Descripción de las disposiciones generales relativas a las utilidades de red internas, dentro de una subred, y entre subredes, para la prestación de servicios de transmisión de datos.
X.351Requisitos especiales que deben satisfacer las facilidades de empaquetado/desempaquetado de datos (EDD) situadas en estaciones terrenas costeras, o en asociación con ellas, en el servicio marítimo por satélite.
X.352Interfuncionamiento entre redes públicas de datos con conmutación de paquetes y el sistema de transmisión de datos del servicio marítimo por satélite.
3
Definiciones
Esta Recomendación utiliza los siguientes términos definidos en la Recomendación X.300:
a)Capacidad de transmisión
b)Capacidad de comunicación
c)Servicio de transmision de datos
Esta Recomendación utiliza el siguiente término definido en la Recomendación X.135:
a)Retardo de tránsito
Esta Recomendación utiliza el siguiente término definido en la Recomendación X.140:
a)Velocidad de transferencia de la información de usuario
Esta Recomendación utiliza el siguiente término definido en el Fascículo X.1:
a)Facilidad facultativa de usuario.
4
Abreviaturas
@ADRAmpliación de dirección de red\
@AEAcceso de entrada\
@ASAcceso de salida\
@CCDCentral (o centro) de conmutación de datos\
@CDSCalidad de servicio\
@CECódigo de enclavamiento\
@CICDCentral (o centro) internacional de conmutación de datos\
@CIRDCódigo de identificación de red de datos\
@CRConexión de red\
@EPEREmpresa privada de explotación reconocida\
@ETCDEquipo de terminación del circuito de datos\
@ETDEquipo terminal de datos\
@FIFFunción de interfuncionamiento\
@GCUGrupo cerrado de usuarios\
@GCUBGrupo cerrado de usuarios bilateral\
@GCUBASGrupo cerrado de usuarios bilateral con acceso de salida\
@IAPInterfuncionamiento mediante acceso por puerto\
@ICCLInterfuncionamiento mediante correspondencia de control de la llamada\
@INDIndicativo nacional de destino\
@IPIndicativo de país\
@IPDIndicativo de país para datos\
@IPN/TDDIndicador de plan de numeración/Tipo de dirección (equivalente a INPD/TDD de la Recomendación Q.931)\
@IPND/TDDIndicador de plan de numeración y direccionamiento/Tipo de dirección (equivalente a INP/TDD de la Recomendación X.25)\
@IRTIndicación de retardo de tránsito\
@ISAInterconexión de sistemas abiertos\
@IURIdentificación de usuario de red\
@N.A.No aplicable\
@NANúmero de abonado\
@NRTEENegociación de retardo de tránsito de extremo a extremo\
@NTRNúmero terminal de red\
@PLEProhibición de llamadas entrantes\
@PLSProhibición de llamadas salientes\
@PRCPunto de referencia de calidad de servicio\
@RDCPRed de datos con conmutación de paquetes\
@RDSIRed digital de servicios integrados\
@RPDCCRed pública de datos con conmutación de circuitos\
@RPDCPRed pública de datos con conmutación de paquetes\
@RTARetardo de tránsito acumulado\
@RTDRetardo de tránsito deseado (o pretendido)\
@RTMARetardo de tránsito máximo aceptable\
@RTPCRed telefónica pública conmutada\
@SIRTSelección e indicación de retardo de tránsito\
@SMSServicio marítimo por satélite\
@SRServicio de red (perteneciente a la ISA)\
@SRTSelección de retardo de tránsito\
@TDDTipo de dirección\
@UEUlterior estudio\
5
Aspectos generales del control de
la llamada
Las disposiciones interredes descritas en esta sección se refieren a los aspectos generales del control de la llamada.
5.1
Modelo aplicable a disposiciones
interredes
Las disposiciones interredes para el control de la llamada se establecen de acuerdo con el modelo ilustrado en las figuras 5-1 y 5-2/X.301.
Figure 5-1/X.301, p.
Figure 5-2/X.301, p.
5.2
Clasificación de las señales
interredes
En las Recomendaciones que tratan de los sistemas de señalización interredes se describen diversas señales que se pueden clasificar como sigue:
5.2.1
Señales interredes de control del enlace de datos
Las señales de control del enlace de datos (por ejemplo, disponibilidad de circuitos físicos) están relacionadas con el enlace de datos considerado en particular y, por consiguiente, están normalmente confinadas dentro de los dos extremos del enlace propiamente dicho. Por lo tanto, normalmente estas señales no pasan a través de la función de interfuncionamiento.
Una excepción a lo expuesto puede darse, por ejemplo, cuando un gran número de enlaces de datos de una red no están disponibles o están averiados, lo que prejuzga el encaminamiento de las llamadas a partir de una red interconectada. En este caso, se pueden enviar señales de explotación adecuadas a la red interconectada en la medida en que así lo permitan las disposiciones de señalización previstas en la red interconectada.
Nota 1
- Un enlace de datos determinado puede
vehicular datos de señalización y/o datos de usuario.
Nota 2
- La Recomendación X.75 indica que entre dos
redes con conmutación de paquetes, un determinado enlace de datos puede emplear
varios circuitos físicos.
5.2.2
Señales interredes de control de la llamada
Este tipo de señal incluye todas las señales que transfieren entre dos redes la información de datos y control apropiada para una llamada determinada. Estas señales están esencialmente relacionadas con:
-el establecimiento de la llamada,
-la transferencia de datos,
-la liberación de la llamada.
Nota 1
- Algunas señales son esenciales para el
establecimiento de la llamada, por ejemplo, direcciones de ETD, indicaciones
para facilidades de usuario cuando se requieran, señales de progresión de la
llamada. Estas señales se ajustarán a las descripciones generales de las
Recomendaciones pertinentes (por ejemplo, direcciones de ETD en la
Recomendación X.121, señales de progresión de la llamada en la Recomendación
X.96). Además, la forma de transferir estas señales entre dos redes se describe
en las Recomendaciones que tratan de los sistemas de señalización interredes.
Nota 2
- Algunos sistemas de señalización interredes
especifican que todas las señales de control de la llamada emplean un solo
enlace de datos; este es el caso del sistema de señalización de la
Recomendación X.75. Otros sistemas de señalización interredes especifican que
las señales de control de la llamada emplean más de un enlace de datos; este es
el caso del sistema de señalización por canal común, en el que se utilizan para
la misma llamada un canal de señalización y un canal de datos.
5.2.3
Señales interredes de operación
Este tipo de señal comprende todas las señales que no están directamente relacionadas con el control de un enlace de datos específico o una llamada específica entre dos redes; estas señales de operación deben proporcionar la información de carácter general necesaria para el funcionamiento satisfactorio de las conexiones interredes, a saber:
-disponibilidad del sistema;
-eficiencia del circuito;
-congestión o condiciones de avería, etc.
Nota 1
- La transmisión de algunas señales interredes
de operación puede hacer que una red modifique las disposiciones generales
aplicables al funcionamiento de la red, por ejemplo, cambio del esquema de
encaminamiento, control de flujo de datos si ha lugar, liberación de algunas
llamadas, etc.
Nota 2
- La transmisión de tales señales interredes de
operación no impide que las redes procesen algunas de las señales utilizadas
para la operación interredes. En particular, una red puede desear registrar las
circunstancias exactas de una liberación de llamada relacionada con un fallo de
la red distante, a fin de ejecutar las acciones necesarias cuanto antes (cambio
del esquema de encaminamiento, etc.).
5.3
Principios generales relativos a las señales
interredes
En esta sección se describen algunas principios generales que se pueden utilizar como base para el interfuncionamiento entre tipos de redes diferentes.
5.3.1
Estado fundamental de un enlace de datos
En cada enlace de datos establecido en una red, las señales de control del enlace de datos deberán asegurar en ambos extremos la capacidad de controlar en cualquier momento el estado del enlace. En particular, cada extremo deberá poder saber si el enlace de datos es o no totalmente operacional; cuando el enlace de datos no sea totalmente operacional, si está o no todavía disponible para señales de transmisión de datos adicionales relativas a llamadas existentes, a señales relativas a nuevas llamadas; y también, si existen o no llamadas que deban liberarse (o bien reiniciarse), a causa de dicho problema en el enlace de datos.
Nota
- De acuerdo con este principio, en las
Recomendaciones pertinentes relativas a la señalización interredes deberán
adoptarse las disposiciones necesarias para que cada red pueda conocer el
estado de los enlaces en una red interconectada, siempre que ello sea
necesario.
5.3.2
Fases de petición de llamada y de confirmación de
llamada
El establecimiento de una llamada entre dos abonados deberá comprender dos fases consecutivas:
-En primer lugar, una fase de PETICIóN DE LLAMADA, en la que:
-el abonado pide una llamada, con parámetros específicos;
-esta petición de llamada se procesa y encamina a través de la red (o redes) a no ser que la red (o redes) no pueda aceptarla;
-la petición de llamada se indica al abonado llamado.
-A continuación, una fase de CONFIRMACIóN DE LLAMADA, en la que:
-el abonado llamado comunica la aceptación a menos que dicho abonado no acepte la llamada;
-se toman disposiciones definitivas a través de la red (o redes) para dicha llamada;
-se confirma al abonado llamante el establecimiento de la llamada.
Nota 1
- Durante cada una de estas dos fases, las
diversas acciones no se efectúan necesariamente por separado. Por ejemplo, un
equipo de red puede procesar algunas señales de petición de llamada procedentes
de un abonado, antes de que dicho abonado transmita otros parámetros
correspondientes a la petición de llamada.
Nota 2
- Actualmente, el establecimiento de una
llamada a través de determinadas combinaciones de redes requiere un número de
fases superior a las dos mencionadas en esta sección; por ejemplo, cuando se
gana acceso a una red con conmutación de paquetes a partir de una red con
conmutación de circuitos, se requiere generalmente el establecimiento completo
del acceso conmutado antes de que pueda pedirse la llamada virtual. De acuerdo
con el principio indicado en esta sección, deben tomarse las disposiciones
oportunas en el marco de las Recomendaciones pertinentes sobre señalización
interredes para el establecimiento de llamadas directas entre ambos usuarios de
extremo cuando esto sea posible. Por consiguiente, se tiene también que prever
en el plan de numeración la posibilidad de que una línea de abonado sea
identificada de forma directa y unívoca a partir de cualquier red.
Nota 3
- La forma de aceptar y encaminar una llamada a
través de diferentes redes puede depender no solamente de la dirección del ETD
llamado, sino también de parámetros o facilidades definidos para dicha llamada.
De acuerdo con el principio indicado en esta sección, en el caso en que algunos
parámetros o facilidades requieren una negociación durante el establecimiento
de la llamada:
-el ETD llamante sólo puede indicar sus exigencias específicas en cuanto a la llamada en el momento en que la solicita;
-el ETD llamado sólo puede modificar las características de la llamada cuando la acepta.
5.3.3
Fase de transferencia de datos
Diferentes tipos de redes pueden proveer diferentes funcionalidades en esta fase, por ejemplo capacidades de transferencia de trenes continuos de bits, transferencia de bloques de datos, así como servicios como control de flujo, secuenciación, notificación de error, reiniciación, confirmación de recepción y transferencia de datos acelerados.
5.3.4
Fase de liberación de la llamada
Toda red o usuario que participa en una llamada debe tener la posibilidad de liberarla inmediatamente.
En el momento en que se libera una llamada, toda red participante en la misma debe poder detener inmediatamente la transmisión de datos de usuario correspondientes a la llamada y comunicar la liberación de la llamada a las redes adyacentes, a no ser que éstas ya estén informadas de dicha liberación. La señal de liberación debe entonces transmitirse con todos los detalles necesarios, es decir, con los códigos de causa y diagnóstico.
Tan pronto como la liberación de una llamada se ha completado localmente, todo recurso que se haya utilizado para dicha llamada podrá ser utilizado por la red para otras llamadas.
Nota 1
- De acuerdo con este principio, la recepción
de una confirmación de liberación no entraña necesariamente que se haya
informado al usuario de extremo sobre la liberación, y confirmado ésta.
Nota 2
- El principio de liberación de la llamada
indicado en esta sección impide que ambos usuarios intercambien información de
extremo a extremo sobre la liberación de la llamada, si así lo desean, después
de terminada la transferencia de datos (ejemplo: paquetes de datos de
invitación a liberar en la Recomendación X.29).
Nota 3
- En algunos casos de colisión de liberaciones,
por ejemplo cuando un ETD y una red inician simultáneamente la fase de
liberación de la llamada, la información de parámetro suministrada por el ETD
puede perderse.
En esta Recomendación, un ETD que inicia la fase de liberación de la
llamada se designa por
`ETD liberante'
. Un ETD que no inicia la fase de
liberación de la llamada pero es informado por la red a este respecto se
designa por
`ETD liberado'
.
6
Transferencia de información de
direccionamiento
Las disposiciones interredes descritas en esta sección hacen posible la transferencia de todos los elementos de información de direccionamiento para la prestación de servicios de transmisión de datos. Esta información incluye la información de direccionamiento definida en las Recomendaciones E.164 y X.121, así como toda otra información de direccionamiento definida en la capa de red de ISA. El cuadro 6-1/X.301 indica las facilidades facultativas de usuario relativas a la información de direccionamiento descritas en esta sección.
Cuadro 6-1/X.301 [T1.301], p.
6.1
Generalidades
Para el suministro de los servicios de transmisión de datos se consideran diferentes planes de numeración, a saber, el plan de numeración de la Recomendación X.121 y el plan de numeración de la Recomendación E.164. Actualmente, la Recomendación X.121 es utilizada por las RPD y la Recomendación E.164 por la red telefónica y la RDSI. La Recomendación E.164 será utilizada por las RDSI. Por este motivo, en esta sección se hará referencia a las redes que trabajan con la numeración X.121 como un dominio X.121 (RPD), y a las redes que trabajan con numeración E.164 como un dominio E.164 (RDSI).
Para el interfuncionamiento entre los dominios X.121 y E.164 se requiere cierta indicación, en el protocolo, del plan de numeración de la dirección presente en el elemento o los elementos de protocolo de la dirección. Esta indicación puede ser en forma de un escape asociado directamente con la dirección o una indicación de elemento de protocolo distinta del elemento de protocolo de dirección. A este último método se hará referencia bajo la designación de identificador de plan de numeración/tipo de dirección (IPN/TDD), en cuyo caso los dominios pueden considerarse un dominio combinado. El valor real del código de escape en las RPD y en las RDSI se define en las Recomendaciones X.121 y E.166. La forma del IPN/TDD depende del protocolo real de acceso a la red utilizado.
Ha de observarse que no se requiere indicación de tipo de dirección o de plan de numeración si la llamada está contenida en un solo dominio de plan de numeración. Algunas redes pueden necesitar la presencia de la indicación en todos los casos.
El modelo que se muestra en la figura 6-1/X.301 se utiliza para describir las disposiciones interredes para el tratamiento del transporte de la información de dirección.
En dicha figura se indican los siguientes casos/términos:
a)número de datos internacional: CIRD + NTR, o bien IPD + NN, como se define en la Recomendación X.121;
b)formato internacional X.121: caso a), o bien escape + otro número internacional, como se define en la Recomendación X.121;
c)formatos X.121: prefijo (si lo hubiese) + caso b), o bien otro formato internacional;
d)número internacional E.164: IP + NN(s), como se define en la Recomendación E.164;
e)formato internacional E.164: caso d), o bien escape + otro número internacional;
f)formatos E.164: prefijo (si lo hubiese) + caso e), o bien otro formato internacional;
g)dirección de dominio combinado: el dominio se determina mediante IPN/TDD.
6.2
Transferencia de dirección llamante
X.121
En esta sección se describen las disposiciones para la transferencia de
información de dirección llamante definida en la Recomendación X.121 a través
de RPD y RDSI. Dicha información se ha designado en esta sección
`dirección
llamante X.121'
. En esta sección se supone que la red de origen es una RPD
(dominio X.121).
6.2.1
Transferencia en la fase de petición de llamada
La dirección llamante X.121 la proporcionará la RPD de origen. En algunos casos, esto se producirá automáticamente y en otros sólo se proporcionará cuando la solicite la RPD de destino (véase el 6.1.4 ). La RPD de origen es responsable de la exactitud de la dirección llamante X.121, cuando se ha proporcionado.
Se presentan, sin embargo, las siguientes situaciones particulares:
6.2.1.1 En algunos casos de interfuncionamiento con un dominio E.164 debe utilizarse un método que indique que la dirección llamante es una dirección X.121. Esto se hará utilizando un dígito de escape normalizado para indicar que sigue una dirección X.121, o mediante alguna forma de IPN/TDD que indique que la dirección llamante es una dirección X.121.
6.2.1.2 En algunos casos, aun cuando la transferencia de la dirección llamante X.121 sea técnicamente posible, pudiera haber razones administrativas por las cuales la identidad del usuario llamante, y por tanto la dirección llamante X.121 relacionada con el mismo, no pueden pasarse a través de una frontera internacional. En tal caso, se proporcionará la identificación de la red de origen en lugar de la dirección llamante X.121.
Figure 6-1/X.301 [1T2.301], p. 4
Figure 6-1/X.301 [2T2.301], p. 5
6.2.1.3 Las redes que no son RPD ni RDSI, cuando se utilizan conjuntamente con
una RPD para ofrecer un servicio de transmisión de datos deberán, en la medida
de lo posible, transferir la dirección llamante X.121. Sin embargo, esta
transferencia no es técnicamente posible a través de algunas redes actuales;
por ejemplo, para una llamada que pasa a través de una RTPC a una red pública
de datos, la red telefónica no siempre está en condiciones de indicar la
dirección llamante X.121 a la red de datos. Se ha dejado para ulterior estudio
la información que se transfiere a través de la red pública de datos en lugar
de la dirección llamante X.121.
6.2.1.4 En el servicio con conmutación de circuitos de las RPDCC, la
dirección llamante X.121 se puede transferir como identificación de la línea
llamante. Se transfiere al ETD llamado solamente si el ETD llamado está abonado
a la facilidad
identificación de la línea llamante
(véase
el
6.1.4
).
6.2.1.5 En el servicio con conmutación de paquetes de las RPDCP y las RDSI, así como en el servicio de transmisión de datos con conmutación de circuitos de las RDSI, la dirección llamante X.121 se transfiere al ETD llamado en el campo de dirección (según protocolo adecuado) señalizado al ETD llamado (véase el apéndice I a la presente Recomendación).
6.2.2
Transferencia en la fase de confirmación de la
llamada
A condición de que el encaminamiento de la llamada se seleccione en la fase de petición de llamada, la dirección llamante X.121 no tiene necesariamente que transferirse en sentido de retorno a través de las RPD y las RDSI en la fase de confirmación de llamada.
6.2.3
Transferencia en otras fases de la llamada
Es posible que la dirección llamante X.121 no tenga que transferirse a través de las RPD en ninguna otra fase de la llamada.
6.2.4
Identificación de la línea llamante
6.2.4.1
Generalidades
La identificación de la línea llamante es una facilidad facultativa de usuario, normalizada para servicios de transmisión de datos con conmutación de circuitos en una RPDCC, que permite a un usuario recibir información sobre la identidad del usuario llamante, en las llamadas entrantes. Cuando se proporciona, la facilidad se aplica a todas las llamadas entrantes.
La identificación de la línea llamante es una facilidad facultativa de usuario asignada al usuario durante un periodo acordado por contrato.
La identidad de la línea llamante es el número de datos X.121 del usuario llamante. En las llamadas internacionales, la identidad es el número de datos internacional X.121 completo, con inclusión de los componentes CIRD o IPD, según proceda.
Nota
- Deberá proseguirse el estudio de las
repercusiones que tendría la posible combinación de la facilidad
identificación de la línea
llamante y la facilidad de
grupo cerrado de usuarios bilateral
.
La información que indica que un usuario dispone de la facilidad
identificación de la línea
llamante está almacenada en la
central a la que está conectado dicho usuario. La identidad enviada al usuario
llamado se origina bajo el control de la central a la cual está conectado el
usuario llamante.
La Administración controla el registro de la facilidad.
6.2.4.2
Procedimiento de establecimiento de la llamada
El procedimiento de llamada a un usuario que dispone de la facilidad
identificación de la línea
llamante es diferente según que
la identidad de la línea llamante esté o no incluida en la información de
control inicial de la llamada recibida por la central de destino al establecer
la llamada.
a)Cuando la identidad de la línea llamante está incluida en la información de control de la llamada recibida por la central de destino, esta identidad es enviada al usuario llamado de conformidad con el protocolo de interfaz ETD/ETCD aplicable.
b)Cuando la identidad de la línea llamante no está incluida en la información de control de la llamada recibida por la central de destino, ésta envía una petición de identificación a la central de origen:
i)cuando la red de origen proporciona la facilidad
identificación de la línea
llamante, la central de origen
responde con la identidad de la línea llamante, que es enviada por la central
de destino al usuario llamado, de conformidad con el protocolo de interfaz
ETD/ETCD aplicable.
ii)cuando la red de origen no proporciona la facilidad
identificación de la línea
llamante, la central de origen
responde con la identidad de la red de origen (véase la Recomendación X.302).
En este caso, la identificación enviada por la central de destino al usuario
llamado es conforme al protocolo de interfaz ETD/ETCD aplicable.
La central de destino no debe efectuar la transconexión hasta que se haya enviado la identidad completa al usuario llamado. Asimismo, cuando se utiliza un sistema de señalización descentralizada, en determinadas situaciones, las centrales de tránsito tienen que demorar la transconexión hasta que se haya completado una posible identificación, de conformidad con los procedimientos aplicables de señalización entre centrales (véanse las Recomendaciones X.70 y X.71).
6.3
Transferencia de dirección llamante
E.164
Esta sección describe las disposiciones para la transferencia de información de dirección llamante definida en la Recomendación E.164.
6.3.1
Transferencia en la fase de petición de llamada
La dirección llamante E.164 la proporcionará la red E.164 de origen para las llamadas en el modo datos, cuando se proporciona la identificación de la línea llamante. La red E.164 de origen es responsable de la validación de la dirección llamante E.164, cuando se proporciona. En caso de que una dirección llamante se transporta transparentemente para la red E.164 (por ejemplo, en el caso de acceso por puesto), dicha validación, si la hubiese, se hará fuera de la red E.164.
Se presentan, sin embargo, las siguientes situaciones particulares:
6.3.1.1 En caso de interfuncionamiento con una red no-E.164, debe utilizarse un método que indique que la dirección llamante es una dirección E.164. Esto se hará mediante el empleo de un dígito de escape normalizado para indicar que sigue una dirección E.164 o mediante alguna forma de IPN/TDD que indique que la dirección llamante es una dirección E.164.
6.3.1.2 En algunos casos, aun cuando la transferencia de la dirección llamante E.164 sea técnicamente posible, pudiera haber razones administrativas por las cuales la identidad del usuario llamante, y por tanto la dirección llamante E.164 relacionada con el mismo, no pueden pasarse a través de una frontera internacional. En tal caso, los procedimientos quedan para ulterior estudio.
6.3.1.3 Las redes que no sean RPD ni RDSI, cuando se utilicen conjuntamente con éstas para ofrecer un servicio de transmisión de datos, deberán, en la medida de lo posible, transferir la dirección llamante E.164. Sin embargo, puede que esta transferencia no sea técnicamente posible a través de algunas redes actuales; por ejemplo, para una llamada que pasa a través de la red telefónica pública con conmutación a una red pública de datos o a la RDSI, la red telefónica no siempre está en condiciones de indicar la dirección llamante E.164 a la red E.164. En tal caso, queda para ulterior estudio la información de dirección llamante que se transfiere a través de la RPD o de la RDSI en lugar de la dirección llamante E.164.
6.3.1.4 En una RDP o en una RDSI, la dirección llamante E.164 se puede transferir al ETD llamado en el campo de dirección llamante (según el protocolo adecuado) señalizado al ETD llamado (véase el apéndice I).
Nota
- Después de la fecha T no todos los ETD estarán
en condiciones de aceptar el formato de paquete largo que se requerirá para
transmitir direcciones E.164 completas. La dirección llamante no podrá
entregarse a dichos ETD.
6.3.1.5 En una RDSI, la dirección llamante E.164 se transfiere al ETD llamado de modo primario en el campo de dirección del ETD llamante señalizado al ETD llamado. También se puede transferir, de modo duplicado, utilizando los procedimientos de notificación (X.31) en el elemento de información número de parte llamante contenido en el mensaje ESTABLECIMIENTO enviado a la parte llamada mediante el canal D. En este caso, el elemento de información número de parte llamante ha de codificarse de manera que indique que la dirección llamante es una dirección E.164.
Nota
- Después de la fecha T no todos los ETD estarán
en condiciones de aceptar el formato de paquete largo que se requerirá para
transmitir direcciones E.164 completas. La dirección llamante no podrá
entregarse a dichos ETD.
6.4
Transferencia de dirección llamada
X.121
En esta sección se describen las disposiciones para la transferencia, a
través de las RPD y las RDSI, de la información de dirección llamada definida
en la Recomendación X.121. Esta información se designa por
`dirección
llamada X.121'
.
Nota
- La dirección llamada X.121 reside únicamente en
una RPD.
6.4.1
Transferencia en la fase de petición de llamada
Por ser esencial para el establecimiento de la llamada, incluido el encaminamiento, la dirección llamada X.121 se transfiere sistemáticamente a través de las RPD y las RDSI en la fase de petición de llamada.
6.4.2
Transferencia en la fase de confirmación de
llamada
La red de destino no necesita suministrar la dirección llamada X.121 (o la identidad de la línea llamada) si ésta no es solicitada. Cuando se proporciona, la RPD de destino es responsable de la validación de la dirección llamada X.121.
Se presentan, sin embargo, las siguientes situaciones particulares:
6.4.2.1 En el servicio de transmisión de datos con conmutación de circuitos
de las RPDCC, la dirección llamada X.121 puede transferirse al ETD llamante
como identidad de la línea llamada. Se transfiere si el ETD llamante está
abonado a la facilidad
identificación de la línea llamada
(véase el
6.4.4
). Si la llamada ha sido redireccionada o si se ha
invocado una facilidad de grupo de búsqueda en la RPD de destino, se
transferirá la dirección del interfaz ETD/ETCD llamado por el que se haya
establecido la llamada.
6.4.2.2 En las RPDCP y en las RDSI, la dirección llamada X.121 puede
transferirse al ETD llamante. En el caso de la facilidad
redireccionamiento de llamada
, la
dirección del interfaz ETD/ETCD llamado por el que se haya establecido la
llamada siempre es transferida. En el caso de la facilidad
grupo de búsqueda
, esta dirección se transfiere siempre,
si se ha asignado una dirección específica al interfaz ETD/ETCD por el que se
estableció la llamada.
6.4.3
Transferencia en otras fases de la llamada
La dirección llamada X.121 no es necesario transferirla a través de la red en ninguna otra fase de la llamada.
Se presenta, sin embargo, la siguiente situación particular:
6.4.3.1 En el servicio de transmisión de datos con conmutación de paquetes, una petición de liberación enviada por un ETD al cual se ha redireccionado una llamada, o distribuida entre un grupo de búsqueda como respuesta directa a la fase de petición de llamada, debe contener la dirección del interfaz ETD/ETCD. Esto sólo es obligatorio en el caso de la facilidad de grupo de búsqueda si se han asignado direcciones específicas a los distintos interfaces ETD/ETCD del grupo de búsqueda. Cuando la petición de liberación está destinada a una red E.164, debe utilizarse algún método para indicar que se trata de un número X.121 (véase el 6.1 ).
6.4.4
Identificación de la línea llamada
6.4.4.1
Generalidades
La identificación de la línea llamada es una facilidad de usuario normalizada para los servicios de transmisión de datos con conmutación de circuitos en una RPDCC, que permite al usuario conocer, en las llamadas salientes, la identidad del usuario al cual se ha conectado la llamada. Cuando se dispone de esta facilidad, se aplica a todas las llamadas salientes.
Es una facilidad facultativa de usuario, asignada durante un periodo contractual convenido.
La identificación de la línea llamada es el número de datos X.121 del usuario al que se ha conectado la llamada. En las llamadas internacionales, la identidad es el número de datos internacional X.121 completo, con inclusión de los componentes CIRD o DPD, según proceda.
La información que indica que un usuario dispone de la facilidad
identificación de la línea llamada
está almacenada en la
central a la que está conectado dicho usuario. La identidad enviada al usuario
llamante se origina bajo el control de la central a la que está conectado el
usuario llamado.
6.4.4.2
Procedimientos de establecimiento de la llamada
En el caso de llamadas de un usuario que dispone de la facilidad
identificación de la línea llamada
, la información de
control de la llamada enviada por la central de origen al establecer la llamada
incluye una petición de identificación de la línea llamada. El procedimiento
depende entonces de si la red de destino proporciona o no la facilidad:
a)Cuando la red de destino proporciona la facilidad
identificación de la línea llamada
, responde con la
identidad de la línea llamada, que la central de origen devuelve al usuario
llamante de conformidad con el protocolo de interfaz ETD/ETCD aplicable.
b)Cuando la red de destino no proporciona la facilidad
identificación de la línea llamada
, responde, según el
tipo de señalización que se utilice, con la identidad de la red de destino
(Recomendación X.302) o con una identificación
`ficticia'
(Recomendaciones X.70 o X.71). La información enviada por la central de origen
al usuario llamante debe ser conforme al protocolo de interfaz ETD/ETCD
aplicable.
Para llamadas con conmutación de circuitos, la central de origen no debe efectuar la transconexión hasta que se haya enviado la identidad completa al usuario llamado. Asimismo, cuando se utiliza un sistema de señalización descentralizada, en determinadas situaciones, las centrales de tránsito tienen que demorar la transconexión hasta que se haya completado una posible identificación, de conformidad con los procedimientos aplicables de señalización entre centrales (Recomendaciones X.70 y X.71).
6.5
Transferencia de dirección llamada
E.164
Esta sección describe las disposiciones para la transferencia de información de dirección llamada definida en la Recomendación E.164.
6.5.1
Transferencia en la fase de petición de llamada
Por ser esencial para el establecimiento de la llamada, incluido el encaminamiento, la dirección llamada E.164 se transfiere sistemáticamente a través de las RPD y las RDSI en la fase de petición de llamada.
Se presenta, sin embargo, la siguente situación particular:
6.5.1.1 En caso de interfuncionamiento con una red que no sea E.164 cuando la red de tránsito sea una RPD, se debe utilizar un método que indique que la dirección llamada es una dirección E.164. Esto se hará mediante el empleo de un dígito de escape normalizado para indicar que sigue una dirección E.164, o mediante alguna forma de IPN/TDD que indique que la dirección llamada es una dirección E.164.
6.5.2
Transferencia en la fase de confirmación de
llamada
La red de destino no necesita proporcionar la dirección llamada E.164 (o la identidad de la línea llamada) si no se ha solicitado. Cuando se suministre, la red de destino es responsable de la validación de la dirección llamada E.164.
Se presenta, sin embargo, la siguiente situación:
6.5.2.1 En las RPD y RDSI, la dirección llamada E.164 puede ser transferida
al ETD llamante como la identificación de la línea llamada. En caso de
facilidad de
redireccionamiento de llamada
, se transfiere
siempre la dirección del interfaz ETD/ETCD llamado a través del cual se ha
establecido la llamada. En el caso de facilidad de
grupo de
búsqueda
, esta dirección se transfiere siempre, si se ha asignado una
dirección específica al interfaz ETD/ETCD a través del cual se estableció la
llamada.
Nota
- Después de la fecha T no todos los ETD estarán
en condiciones de aceptar el formato de paquete largo que se requerirá para
transmitir direcciones E.164 completas. La dirección llamante no podrá
entregarse a dichos ETD.
6.5.3
Transferencia en otras fases de la llamada
La dirección llamada E.164 no tiene que transferirse a través de la red en ninguna otra fase de la llamada.
Se presenta, sin embargo, la siguiente situación:
6.5.3.1 En el servicio de transmisión de datos con conmutación de paquetes,
una petición de liberación emitida por un ETD al cual se ha redireccionado la
llamada, o distribuida entre un grupo de búsqueda como respuesta directa a la
fase de petición de llamada, debe contener la dirección del interfaz ETD/ETCD.
Esto sólo es obligatorio en el caso de la facilidad de
grupo de
búsqueda
si se han asignado direcciones específicas a los distintos
interfaces ETD/ETCD del grupo de búsqueda. Cuando la petición de liberación
está destinada a una red X.121, debe utilizarse algún método para indicar que
se trata de un número E.164 (véase el
6.1
).
6.6
Formato de direcciones X.121
En la sección 6.1 se describen los diferentes casos correspondientes al formato de direcciones X.121.
La información de dirección definida en la Recomendación X.121 se designa
en esta sección
`dirección X.121'
.
Cuando deba hacerse pasar una dirección X.121 a través de un interfaz ETD/ETCD, o un interfaz X/Y de la RDSI de acuerdo con las condiciones indicadas en esta Recomendación, la transferencia deberá efectuarse de conformidad con los principios siguientes:
6.6.1 Para llamadas internacionales, la dirección X.121 debe darse explícitamente en forma del número de datos internacional completo, incluido el componente CIRD o IPD, según proceda.
6.6.2 El formato exacto de una señal de dirección puede no ser necesariamente el mismo en el plano nacional. Dicho formato es una cuestión a resolver específicamente en cada interfaz que interviene en la llamada: interfaz ETD/ETCD llamante, interfaz ETD/ETCD llamado e interfaces entre centrales.
Por ejemplo, en un interfaz X.21 o X.25, una misma dirección puede representarse en una de las formas ilustradas en las partes a) o b) y/o c) o d) y/o e) de la figura 6-2/X.301.
Figura 6-2/X.301, p.
Este ejemplo ilustra la utilización de un prefijo, como se reconoce en la
Recomendación X.121, como manera de distinguir entre diferentes formatos de una
misma dirección.
En el caso de los servicios móviles puede requerirse una conversión entre diferentes formatos de la dirección en diversos interfaces situados en cualquier parte de la red, para los abonados itinerantes.
Nota
- Un abonado móvil itinerante es un abonado que
puede obtener conexiones totalmente automáticas incluso cuando sale de su área
de operación normal.
6.6.3 El formato o los formatos específicos que pueden utilizarse en un interfaz dado se definen en la Recomendación CCITT pertinente sobre ese interfaz.
6.7
Formato de direcciones E.164
En la sección 6.1 se describen los diferentes casos correspondientes al formato de direcciones E.164.
La información de dirección definida en la Recomendación E.164 se designa
en esta sección
`dirección E.164'
.
Cuando deba hacerse pasar una dirección E.164 a través de un interfaz red/usuario o interfaz intercentrales de acuerdo con las condiciones indicadas en esta Recomendación, la transferencia deberá efectuarse de conformidad con los principios siguientes:
6.7.1 Para llamada interredes, la dirección E.164 debe darse explícitamente en forma del número de abonado internacional completo, incluidos el IP y el NN(s).
6.7.2 La codificación (formato) exacta de una señal de dirección puede no ser necesariamente la misma en el plano nacional. Este formato es una cuestión a resolver específicamente en cada interfaz que interviene en la llamada interfaz red/usuario llamante, interfaz red/usuario llamado e interfaces entre centrales.
Por ejemplo, en un interfaz RDSI, una misma dirección puede representarse en cualquiera de las formas ilustradas en a) o b) y/o c) o d) de la figura 6-3/X.301.
Figure 6-3/X.301, p.
Este ejemplo ilustra la utilización de un prefijo, como se reconoce en la
Recomendación E.164 como una manera de distinguir entre diferentes
codificaciones (o formatos) de la misma dirección.
6.7.3 Los formatos específicos que pueden utilizarse en un interfaz dado se definen en la Recomendación CCITT pertinente sobre ese interfaz.
6.8
Transferencia de información de dirección adicional a
la mencionada en las Recomendaciones X.121 y E.164
En esta sección se describen las disposiciones para la transferencia de información de dirección adicional a la definida en las Recomendaciones X.121 y E.164.
6.8.1
Generalidades
El mecanismo de ampliación de dirección de red (ADR)/subdirección (véase la nota) permite transferir a través de RPD, llamada por llamada, información de direccionamiento más allá del límite total establecido para las direcciones X.121/E.164. Este mecanismo está normalizado en el servicio de transmisión de datos con conmutación de circuitos y de paquetes como se muestra en el cuadro 6-2/X.301.
Cuadro 6-2/X.301 [T3.X.301], p.
Si existe espacio suficiente en los campos que contienen la información de
dirección X.121/E.164 y hay un acuerdo entre los usuarios y las redes
interesados, esto constituye una capacidad alternativa, disponible llamada por
llamada, sin que se requiera el mecanismo ADR, para la transferencia de
información de direccionamiento adicional a la definida en las Recomendaciones
X.121/E.164.
Nota
- Existen diferentes términos: En general, se
utiliza
`ADR'
en las Recomendaciones de la serie X, y
`subdirección'
en las Recomendaciones de la serie I.
6.8.2
Realización
La realización detallada del mecanismo ADR en cada tipo de interfaz interredes y de usuario se define independientemente en las Recomendaciones pertinentes sobre señalización e interfaces.
6.8.3
Principios
Los siguientes principios se aplican por igual y de forma independiente a la información de dirección tanto llamante como llamada:
6.8.3.1 La transferencia de información de direccionamiento en la capa de red ISA adicional a la definida en las Recomendaciones X.122/E.164 es posible durante cualquier fase de la llamada en que se pueda también transferir información de dirección definida en las Recomendaciones X.121/E.164 (véanse los 6.1 y 6.7).
6.8.3.2 La información de direccionamiento en la ADR/subdirección puede ser de longitud variable. Podrá comprender hasta 20 octetos de información binaria codificada (véase la nota). El contenido de la información no está sometido a ninguna limitación con respecto a la agrupación de los dígitos.
Nota
- La longitud máxima de 40 dígitos decimales se
deriva de la longitud máxima de la dirección del punto de acceso al servicio de
red (PASR) ISA, definido en la Recomendación X.213 (véase también ISO 8348
AD2). Las disposiciones exactas para el tratamiento de la dirección de PASR ISA
serán objeto de ulterior estudio.
6.8.3.3 Las redes públicas no tienen la obligación de supervisar ni actuar sobre una ADR/subdirección para ninguna finalidad, incluido el encaminamiento; no obstante, algunas redes públicas podrán supervisar la ADR/subdirección si así lo desean.
6.8.3.4 En los casos en que sea posible y exista un acuerdo entre los usuarios y las redes públicas interesadas, la transferencia de la información de direccionamiento completa (a saber, todos los elementos de direccionamiento en la capa de red ISA) podrá efectuarse sin utilizar el mecanismo ADR/subdirección.
6.8.3.5 Cada interfaz interredes deberá acomodar simultáneamente las siguientes particiones de la información de direccionamiento entre elementos de protocolo existentes para direccionamiento y ampliaciones de dirección de red/subdirecciones:
a)Todos los elementos de información de direccionamiento están contenidos en los elementos de protocolo existentes para el direccionamiento; no se requiere ADR/subdirección; la dirección de red del ETD completa está contenida en los elementos de protocolo existentes.
b)La dirección del ETD completa está contenida en la ampliación de direccionamiento de red/subdirección; todos los elementos de información de direccionamiento que necesitan las redes públicas que intervienen en la llamada están contenidos en los elementos de protocolo existentes para el direccionamiento. La información utilizada por las redes públicas puede derivarese de ADR/subdirección.
Nota
- En este caso, para algunas direcciones de red
ISA, una parte de la información de dirección de red ISA puede estar duplicada
en los elementos de protocolo existentes para el direccionamiento.
c)La información de direccionamiento se divide en dos elementos, uno contenido en los elementos de protocolo existentes para direccionamiento y el otro contenido en la ADR/subdirección.
d)La información de direccionamiento está contenida únicamente en ADR/subdirección. Este caso es típico de las redes privadas puesto que las redes públicas trabajan de ordinario sobre números X.121/E.164.
6.8.3.6 ADR/subdirección se utiliza:
-como se define en ISO 8348 AD2,
-o bien de otra manera diferente.
Cuando la ADR/subdirección se utiliza como se define en la Recomendación X.213 (véase también ISO 8348 AD2], no se aplica el apartado c) del 6.8.3.5 .
7
Disposiciones para facilidades de
usuario
(véase la nota 1)
Las disposiciones interredes descritas en esta sección se refieren a las facilidades facultativas de usuario definidas en las Recomendaciones X.2 y en las de la serie I.250 (véase la nota 4).
Nota 1
- Términos diferentes: En general, en las
Recomendaciones de la serie X se emplea el término
facilidades
facultativas de usuario
, y en las Recomendaciones de la serie I el término
servicios suplementarios
.
Nota 2
- El soporte de estas facilidades, por la RDSI,
en modos de funcionamiento distintos del modo paquete será objeto de ulterior
estudio (véanse las Recomendaciones de la serie I.230).
Nota 3
- Las disposiciones generales para el
tratamiento de procedimientos de registro (por ejemplo Recomendación X.32)
serán objeto de ulterior estudio.
Nota 4
- La armonización/interfuncionamiento de las
facilidades definidas en la Recomendación X.2 con los servicios suplementarios
definidos en las Recomendaciones de la serie I.250 será objeto de ulterior
estudio.
Lista alfabética de facilidades contenidas en esta
sección
Calidad del servicio de red ISA y del servicio de transmisión de datos7.1.1
Cobro revertido y aceptación de cobro revertido7.2.1
Conexión cuando se libere y espera permitida7.6.2
Confirmación de recepción7.6.3
Desviación de llamadas7.3.2
Grupo cerrado de usuarios7.4.1
Grupo cerrado de usuarios bilateral7.4.2
Grupo de búsqueda7.3.2
Identificación de usuario de red (IUR)7.4.5
Información de tarificación (o de tasación)7.2.3
Negociación de datos acelerados7.6.4
Notificación de modificación de la dirección de la línea llamada7.3.5
Notificación de redireccionamiento o desviación de llamada7.3.6
Parámetros de calidad de servicio7.1.2
Permiso para contraordenar la IUR7.4.6
Prevención de tarificación local7.2.2
Prohibición de llamadas entrantes7.4.3
Prohibición de llamadas salientes7.4.4
Redireccionamiento de llamadas7.3.1
Respuesta manual7.6.1
Selección de EPER7.3.3
Selección rápida7.5.2
7.1
Facilidades relacionadas con la calidad de
servicio (CDS) para la llamada
Esta sección describe las disposiciones requeridas para la calidad de servicio relacionada con la capacidad de transmisión.
7.1.1
Calidad del servicio de red ISA y del servicio de
transmisión de datos
El término
`calidad de servicio'
(CDS) se refiere a la
especificación de ciertas características de una conexión de red (CR) tal como
se define en el servicio de red ISA (Recomendación X.213). Sin embargo, la CDS
puede especificarse también en relación con el servicio de transmisión de datos
utilizado como soporte del servicio de red ISA. En las secciones que siguen se
describe cada una de estas especificaciones de calidad de servicio, así como la
relación entre las mismas.
7.1.1.1
Especificación de CDS en el servicio de red
ISA
El servicio de red ISA, junto con una definición detallada de los parámetros de CDS (o, más brevemente, parámetros CDS), se especifican en la Recomendación X.213. Los puntos de referencia entre los cuales se aplican los parámetros CDS se denominan puntos de acceso al servicio de red (PASR).
El valor de CDS se aplica a la totalidad de la CR. Cuando se determina o mide en ambos extremos de una CR, la CDS observada por los usuarios SR en ambos extremos de la CR es la misma. Esto se cumple también en el caso de que la conexión de red se proporcione mediante el interfuncionamiento de redes de diferentes tipos.
Existen dos categorías de interfuncionamiento en lo que respecta a las capacidades de transmisión, a saber: el interfuncionamiento en la capa de red, y el interfuncionamiento mediante acceso por puerto. Los puntos de referencia entre los cuales se aplican los parámetros CDS son, en ambos casos de interfuncionamiento, los PASR que intervienen (véanse las figuras 7-1/X.301 y 7-2/X.301). Sin embargo, el método de interfuncionamiento puede influir en el valor de la CDS entre los puntos de referencia.
La Capa de Transporte puede pedir al proveedor del servicio de red ISA una conexión de capa de red con ciertas características de calidad de servicio (por ejemplo, para decidir la clase de protocolo de transporte que ha de utilizarse). En respuesta a esa petición, el proveedor del servicio de red ISA puede ofrecer una conexión de capa de red con características de CDS que satisfacen (los márgenes de) la petición, o rechazar la petición si no puede satisfacer esas características de CDS.
La Recomendación X.224 (Protocolo de transporte) clasifica las conexiones de red en base a la CDS con respecto al comportamiento en caso de error, solicitado por el usuario; tiene por finalidad principal proporcionar una base para decidir la clase de protocolo que debe utilizarse por encima de una determinada conexión de red.
7.1.1.2
Especificación de CDS en el servicio de
transmisión de datos
La figura 7-3/X.301 ilustra un ejemplo del servicio de transmisión de datos cuando este servicio es proporcionado por una red pública de datos (RPD). Los parámetros CDS para el servicio de transmisión de datos deben especificarse en base a sucesos que ocurren dentro de la capa de red en el interfaz ETD/ETCD. Los puntos de referencia CDS son, por definición, interiores a las entidades de capa de red a través de las cuales se puede ganar acceso a la RPDC (por ejemplo los ETCD) y en las cuales se observan los sucesos de capa de red.
Estos puntos de referencia son aplicables tanto al interfuncionamiento de la capa de red como al interfuncionamiento mediante acceso por puerto.
Figure 7-2/X.301, p. 10
Figure omitted: 18 Figure 7-3/X.301
Figure 7-3/X.301, p. 11
7.1.1.3 La relación entre la CDS del servicio de red ISA y la CDS del servicio
de transmisión de datos se ilustra en la figura 7-4/X.301. La CDS del servicio
de red incluye un componente que es la CDS del servicio de transmisión de
datos, y otro componente que se debe a la operación del proveedor de servicio
de red fuera del servicio de transmisión de datos (es decir, el proveedor del
servicio de red entre los puntos PRC del servicio de transmisión de datos y los
PASR correspondientes. La operación del proveedor de servicio fuera del
servicio de transmisión de datos puede tener por efecto una degradación o una
mejora de la CDS según las circunstancias y los aspectos de la CDS que
intervienen. En el caso de una instancia de comunicación, la CDS del servicio
de red es diferente de la CDS del servicio de transmisión de datos. La relación
entre esos valores de CDS es responsabilidad del proveedor del servicio de red
fuera del servicio de transmisión de datos.
Figure omitted: 20 Figura 7-4/X.301
Figura 7-4/X.301, p.
7.1.2
Parámetros CDS
7.1.2.1
Parámetros CDS del servicio de red ISA
La CDS del servicio de red se describe mediante parámetros CDS. La definición de cada parámetro especifica la manera en que el valor del parámetro se mide o determina, haciendo referencia, cuando procede, a los sucesos representados por primitivas de servicio en el servicio de red.
La información sobre CDS se intercambia entre el proveedor del servicio de red y los usuarios SR en base a parámetros CDS del servicio de red.
Son ejemplos de parámetros CDS definidos en el servicio de red: el caudal, el retardo de tránsito y la tasa de error residual. La Recomendación X.213 contiene las definiciones del conjunto completo de parámetros CDS aplicables al servicio de red.
Valores de los parámetros de CDS
En algunas circunstancias, solo se transmite un valor único para un parámetro CDS (por ejemplo, el valor pretendido o deseado por el usuario del servicio de red, o el valor puesto a disposición por el proveedor del servicio de red). En otros casos, sin embargo, puede ser posible especificar un par de valores que definen una gama aplicable de valores (por ejemplo el usuario del servicio de red puede especificar una gama delimitada por un valor pretendido, o deseado, y por el valor mínimo que el usuario está dispuesto a aceptar). El número de valores que pueden transportarse depende del parámetro CDS de que se trate.
7.1.2.1.2
Categorías de parámetros CDS
Los parámetros CDS del servicio de red pueden dividirse en las dos categorías siguientes:
1)Parámetros negociados conexión por conexión; los valores de estos parámetros pueden transportarse entre usuarios SR pares por medio del SR durante la fase de establecimiento de una CR; como parte de este transporte puede tener lugar una negociación tripartita entre los usuarios SR y el proveedor SR para ponerse de acuerdo sobre un determinado valor de un parámetro CDS; y
2)Parámetros no negociados conexión por conexión; los valores de estos parámetros no pueden transportarse ni negociarse entre los usuarios SR y el proveedor SR. No obstante, se puede dar a conocer, por medios locales, información sobre estos parámetros, útil para el proveedor y para los usuarios del servicio de red.
Sólo dos parámetros CDS del SR, el caudal y el retardo de tránsito, pertenecen a la primera categoría, por lo que son transportados y negociados por medio del SR.
(Los procedimientos de negociación y sus limitaciones se describen en la Recomendación X.213. El mecanismo para la negociación de estos parámetros se describe en el 7.1.3.1 .)
Los demás parámetros CDS pertenecen a la segunda categoría. Los valores de estos parámetros CDS para una determinada CR no son objeto de una negociación tripartita, ni se transportan directamente de usuario SR a usuario SR. Como cuestión local, sin embargo, pueden existir medios que permitan al proveedor SR y a cada usuario SR utilizar los valores de uno o más de estos parámetros CDS.
(El mecanismo relacionado con esta categoría de parámetros se describe en el 7.1.3.2 .)
7.1.2.2
Parámetros CDS del servicio de transmisión de
datos
Esta sección será objeto de ulterior estudio.
7.1.3
Mecanismo relacionado con la CDS
7.1.3.1
Tipos de mecanismos relacionados con parámetros
negociados conexión por conexión
7.1.3.1.1 En la especificación de estos parámetros CDS intervienen tres participantes:
a)el usuario del servicio en el punto de referencia CDS llamante,
b)el proveedor del servicio entre los puntos de referencia CDS,
c)el usuario del servicio en el punto de referencia CDS llamado.
7.1.3.1.2 El usuario del servicio en el punto de referencia llamante iniciará estos parámetros CDS.
7.1.3.1.3 Tanto el proveedor del servicio entre los puntos de referencia como el usuario del servicio en el punto de referencia CDS llamado pueden devaluar estos parámetros CDS de acuerdo con sus capacidades.
7.1.3.1.4 Tras una posible devaluación ulterior, estos parámetros CDS serán retornados al usuario del servicio en el punto de referencia CDS llamante con vista a un ajuste posterior.
7.1.3.1.5 Los parámetros CDS retornados especifican la CDS entre los dos puntos de referencia CDS.
Nota
- La garantía de la CDS durante el tiempo de vida
de la conexión entre los dos puntos de referencia CDS será objeto de ulterior
estudio.
7.1.3.2
Tipos de mecanismos relacionados con parámetros no
negociados conexión por conexión
La determinación del valor de estos tipos de parámetros se efectúa en algún punto dentro del proveedor del servicio pero no requiere que los valores se negocien entre los PRC. Un usuario del servicio, a través del PRC llamante, puede solicitar valores de estos parámetros. También es posible que el proveedor del servicio transmita indicaciones de estos valores al usuario del servicio en el PRC llamante, el PRC llamado, o en ambos. A diferencia de los valores de los parámetros negociados conexión por conexión, los valores de estos otros parámetros no están sujetos al mecanismo de negociación descrito en el 7.1.3.1 .
7.1.3.3
Parámetros CDS mínimo y deseado
7.1.3.3.1 La especificación de parámetros CDS (si existe) contiene siempre un valor CDS deseado (o pretendido). Puede también contener un valor CDS mínimo.
7.1.3.3.2 En el caso de los parámetros negociados conexión por conexión, los valores CDS deseados (o pretendidos) están sujetos a reglas de negociación especificadas en el 7.1.3.1 .
7.1.3.3.3 Los valores CDS mínimos especifican el menor valor que el usuario del servicio en el punto de referencia CDS está dispuesto a aceptar para el establecimiento de una conexión entre los dos puntos de referencia CDS. El valor CDS mínimo puede ser utilizado por el proveedor del servicio entre los puntos de referencia CDS para abortar el establecimiento de la conexión, si el valor CDS deseado ha sido devaluado a un valor inferior al valor CDS mínimo en el caso de parámetros negociados conexión por conexión.
Nota
- Deberá estudiarse con mayor amplitud si el
mecanismo que utiliza parámetros CDS mínimos es un mecanismo general aplicable
a todos los parámetros.
7.1.3.4
Mecanismos específicos relacionados con la CDS
Se han definido ya algunos mecanismos que se relacionan con la calidad de servicio de una llamada (por ejemplo, el mecanismo de negociación de parámetros de control de flujo en las Recomendaciones X.25 y X.75).
Nota
- Se estudiará con mayor amplitud la necesidad de
introducir nuevas facilidades de usuario para solicitar una calidad de servicio
pretendida para una llamada y nuevas utilidades de red para controlar esa
calidad de servicio deseada.
En el cuadro 7-1/X.301 se indican las facilidades facultativas de usuario ya normalizadas para diferentes servicios de transmisión de datos, y que se relacionan con la CDS de la llamada.
7.1.3.4.1
Retardo de tránsito
Para el cálculo y la negociación del retardo de tránsito pueden utilizarse varias facilidades:
-Selección e indicación de retardo de tránsito (SIRT);
-Negociación de retardo de tránsito de extremo a extremo (NRTEE), que comprende tres parámetros:
-Retardo de tránsito acumulativo (RTA),
-Retardo de tránsito deseado (RTD),
-Retardo de tránsito máximo aceptable (RTMA).
Cuadro 7-1/X.301 [T4.301], p.
La utilización de estas facilidades y las relaciones entre las mismas se
describen en las secciones siguientes:
7.1.3.4.1.1
Selección e indicación de retardo de
tránsito
7.1.3.4.1.1.1
Generalidades
La selección e indicación de retardo de tránsito es una facilidad facultativa de usuario que permite la seleción e indicación, llamada por llamada, del retardo de tránsito máximo admisible nominal aplicable a esa llamada virtual.
Un ETD que desea seleccionar un retardo de tránsito máximo admisible nominal para una llamada virtual indica el máximo valor nominal admisible en la fase de petición de llamada.
Durante la fase de petición de llamada, el retardo de tránsito nominal aplicable a la misma se indicará al ETD llamado. Este retardo de tránsito puede ser inferior, igual, o superior al retardo de tránsito máximo admisible nominal solicitado por el ETD llamante en la fase de petición de llamada.
Durante la fase de confirmación de llamada, el retardo de tránsito nominal aplicable a la llamada se enviará también al ETD llamante.
Nota
- Esta facilidad especifica el retardo de
tránsito entre los PRC aplicables al servicio de transmisión de datos (véase
7.1.1.2
). Es posible que para suministrar valores de retardo de
tránsito aplicables al servicio de red ISA (véase
7.1.1.3
) haya que
utilizar un parámetro adicional (véase el
7.1.3.4.1.2
).
Para el tratamiento de estas facilidades en la comunicación interredes se definen dos facilidades:
1)El retardo de tránsito máximo admisible nominal solicitado por el ETD se señaliza entre las redes mediante la utilidad de selección de retardo de tránsito en la fase de petición de llamada.
2)El retardo de tránsito nominal esperado acumulado, hasta el enlace de salida inclusive, se señaliza mediante la utilidad de indicación de retardo de tránsito en la fase de petición de llamada. El retardo de tránsito nominal esparado acumulado se señaliza en retorno mediante la utilidad de indicación de retardo de tránsito en la fase de confirmación de llamada.
7.1.3.4.1.1.2
Definición de retardo de tránsito
Este retardo de tránsito es el retardo de transferencia de paquetes de
datos
definido en el
3.1
de la Recomendación
X.135, medido entre las fronteras
B
2 y
B
n
-1 definidas en la figura 2/X.135 (es decir, excluyendo las líneas de
acceso), con las condiciones enunciadas en el
3.2
de la
Recomendación X.135, y se expresa en forma de un valor medio.
El retardo de tránsito máximo admisible nominal y el retardo de tránsito
nominal esperado se señalizan
provisionalmente
en
milisegundos y expresan el valor que no debe ser rebasado por el 95% de los
paquetes (de 128 octetos de longitud) enviados por el usuario en esa llamada.
Nota 1
- Se estudiará con mayor amplitud si los
valores de retardo de tránsito sólo son aplicables en la condición de la hora
cargada.
Nota 2
- Será objeto de ulterior estudio la gama y el
número de valores razonables del retardo de tránsito máximo admisible nominal y
del retardo de tránsito nominal esperado.
7.1.3.4.1.1.3
Fases de petición de llamada y de
confirmación de llamada
a)En la fase de petición de llamada, una red, cuando esté en condiciones de hacerlo, deberá atribuir recursos y encaminar la llamada virtual de manera que en el retardo de tránsito nominal aplicable a esa llamada no rebase el retardo de tránsito máximo admisible nominal.
1)En la fase de petición de llamada, el ETD llamante indica el retardo de
tránsito máximo admisible nominal en la facilidad de
selección
e
indicación de retardo de
tránsito
;
2)En la fase de petición de llamada o en un enlace entre redes, la red, si
hay encaminamiento en base al retardo de tránsito, deberá tener en cuenta los
dos valores indicados en las utilidades de red de
selección de
retardo de tránsito
e
indicación de retardo de
tránsito
.
b)La red determinará el retardo de tránsito nominal esperado para la parte de red del circuito virtual en cuestión, sobre la base de la definición contenida en 7.1.3.4.1.1.2 .
De acuerdo con la definición
t3c
, este parámetro
incluye el retardo de tránsito nominal esperado para todas las centrales de
conmutación de datos (CCD) y enlaces por los que pasa la llamada, teniendo en
cuenta elementos tales como el tamaño de las CCD, la velocidad de transmisión y
el tipo de enlaces.
No obstante, la determinación de los valores que efectivamente habrán de utilizarse dependerá de cada Administración.
1)En el caso de una llamada entrante a un ETD, el retardo de tránsito nominal esperado se transmitirá al ETD en la facilidad de selección e indicación de retardo de tránsito.
2)En el caso de una petición de llamada en un enlace interredes, el retardo de tránsito nominal esperado se señalizará en la utilidad de selección e indicación de retardo de tránsito. El tiempo de tránsito solicitado inicialmente por ETD se señalizará facultativamente en la utilidad de selección de retardo de tránsito.
c)El retardo de tránsito nominal esperado acumulado, total, se señaliza en retorno mediante la utilidad de indicación de retardo de tránsito en la fase de confirmación de llamada. La red de origen transmite este valor al ETD llamante en la facilidad de selección e indicación de retardo de tránsito en la fase de confirmación de llamada.
Durante la fase de petición de llamada, el retardo de tránsito nominal aplicable a la llamada se indicará al ETD llamado. Este retardo de tránsito puede ser inferior, igual o superior al retardo de tránsito máximo admisible nominal solicitado por el ETD llamante en la fase de petición de llamada.
Durante la fase de confirmación de llamada, el retardo de tránsito nominal aplicable a la llamada se enviará también al ETD llamante.
7.1.3.4.1.2
Negociación del retardo de tránsito de extremo
a extremo
7.1.3.4.1.2.1
Generalidades
La negociación del retardo de tránsito de extremo a extremo es una facilidad facultativa de usuario que permite el transporte llamada por llamada de:
a)@Retardo de tránsito acumulativo (RTA);\
b)@Retardo de tránsito deseado (RTD) (facultativo);\
c)@Retardo de tránsito máximo aceptable (RTMA) (facultativo).\
El RTP corresponde con el parámetro CDS deseado (véase el 7.1.3.3 ) para retardo de tránsito.
El RTMA corresponde con el parámetro CDS mínimo (véase el 7.1.3.3 ) para retardo de tránsito.
El RTA acumula el retardo de tránsito total aplicable a la llamada sumando los distintos retardos de tránsito de las porciones ulteriores de la conexión (que pueden ser presentados por la facilidad de selección e indicación de tiempo de tránsito; véase el 7.1.3.4.1 ).
7.1.3.4.1.2.2
Fases de petición y de confirmación de
llamada
El RTA será transportado del ETD llamante al llamado durante la fase de petición de llamada. Su valor será incrementado por los retardos de tránsito de las distintas porciones de la conexión, que podrán ser presentados por la facilidad de selección e indicación de retardo de tránsito (véase el 7.1.3.4.1 ) o podrán obtenerse por información local. El RTP y el RTMA pueden también ser transportados del ETD llamante al llamado durante la fase de petición de llamada y ser utilizados para comparación con el valor acumulado.
Las redes públicas que intervienen en la llamada no están obligadas a supervisar ni actuar sobre estos parámetros, por ejemplo abortar la llamada, pero algunas redes pueden supervisarlos si lo desean.
El retardo de tránsito acumulado total, una vez aceptado por el ETD llamado, se transporta del ETD llamante al llamado durante la fase de confirmación de llamada mediante el parámetro RTA. Los parámetros RTP y RTMA no son transportados durante la fase de confirmación de llamada.
La figura 7-5/X.301 muestra un ejemplo de utilización de los parámetros de retardo de tránsito.
Figura 7-5/X.301, p.
Las etiquetas (a), (b), (c), (d), (e), (f) y (g) representan los diversos
puntos entre las entidades que intervienen en el escenario indicado más arriba,
donde la información de retardo de tránsito es visible en la información de
control de protocolo.
Facilidad Utilidades NRTEE SIRT SRT IRT RTA RTP RTMA Fase de petición
de la llamada a) t-2d1 (nota 1) N.A. N.A. 2d1 t w b) p1 N.A. N.A. 2d1 t w c)
t-2d1-p1-(g1-g2) N.A. N.A. 2d1+p1+(g1+g2) t w d) N.A. t-2d1-p1-(g1-g2) p2-e
2d1+p1+(g1+g2) t w e) p2-e-p3 N.A. N.A. 2d1+p1+(g1+g2) t w f)
t-(2d1-p1-(g1-g2))-(g3-g4)-(p2-e-p3) N.A. N.A. 2d1+p1+(g1+g2)+(p2+e+p3)+(g3+g4)
t w g) p4 N.A. N.A. 2d1+p1+(g1+g2)+(p2+e+p3)+(g3+g4) t w Facilidad Utilidades
NRTEE SIRT SRT IRT RTA RTP RTMA Fase de confirmación de llamada (nota 2) g)
N.A. N.A. N.A. 2d1+p1+(g1+g2)+(p2+e+p3)+(g3+g4)+p4 N.A. N.A. f) p4 N.A. N.A. -
N.A. N.A. e) N.A. N.A. N.A. - N.A. N.A. d) N.A. N.A. p2-e-p3 - N.A. N.A. c)
p2-e-p3 N.A. N.A. - N.A. N.A. b) N.A. N.A. N.A. - N.A. N.A. a) p1 N.A. N.A. -
N.A. N.A.
Nota 1
- El ETD llamante supone d1 = d2.
Nota 2
- El ETD puede haber aceptado la llamada en base a:
2d1+p1+(g1+g2)+(p2+e+p3)+2(g3+g4)+p4w.
FIGURA 7-5/X.301
Utilización de parámetros de retardo de
tránsito
7.1.3.4.2
Caudal
7.1.3.4.2.1
Negociación de la clase de caudal (véase la
nota)
Nota
-Existen diferentes términos para esta facilidad:
El término utilizado en esta Recomendación es el empleado en las Recomendaciones X.2, X.25 y X.75.
La Recomendación X.213 utiliza el término
`caudal'
.
La Recomendación X.140 utiliza el término
`velocidad de transferencia de
información de usuario'
.
La Recomendación Q.931 utiliza el término
`velocidad de información'
.
7.1.3.4.2.1.1
Generalidades
La negociación de la clase de caudal es una facilidad facultativa de usuario que permite la negociación llamada por llamada de las clases de caudal. Estas se consideran independientemente para cada sentido de transmisión de datos.
El ETD y la Administración acuerdan valores por defecto (véase el 7.1.3.4.2.3 ). Los valores por defecto corresponden a las clases de caudal máximas que pueden asociarse con cualquier llamada virtual en el interfaz ETD/ETCD.
Esta facilidad corresponde con el parámetro de CDS deseada (véase el 7.1.3.3 ) para el caudal.
7.1.3.4.2.1.2
Definición de caudal
El parámetro caudal se define en la Recomendación X.140 (bajo el término velocidad de transferencia de información de usuario).
El caudal se expresa en bits por segundo. Provisionalmente, el valor de caudal negociado para una llamada se obtiene, medido en el periodo de duración de la llamada, en el 95% de todos los casos (llamadas) en condiciones de la hora cargada. Los detalles serán objeto de ulterior estudio.
7.1.3.4.2.1.3
Fases de petición de llamada y de confirmación
de llamada
Cuando el ETD llamante está abonado a la facilidad
negociación de clase de caudal
, puede
solicitar las clases de caudal de la llamada virtual en la fase
petición de llamada
en ambos sentidos de transmisión de
datos. Si no se solicitan expresamente determinadas clases de caudal, el ETCD
supondrá que se han solicitado valores supletorios para ambos sentidos de
transmisión de datos.
Cuando un ETD llamado está abonado a la facilidad
negociación de clase de caudal
, las
clases de caudal a partir de las cuales puede comenzar la negociación entre los
ETD se indicarán al ETD llamado durante la fase de petición de llamada . Estas
clases de caudal son inferiores o iguales a las seleccionadas en el interfaz
ETD/ETCD llamante, ya sea explícitamente, o por defecto si el ETD llamante no
está abonado a la facilidad
negociación de
clase de caudal
o no ha solicitado expresamente valores de
clase de caudal en la fase petición de llamada. Estas clases de caudal
indicadas al ETD llamado tampoco serán superiores a las clases de caudal por
defecto, respectivamente para cada sentido de transmisión de datos, en los
interfaces ETD/ETCD llamante y llamado. Además, pueden estar sujetos a otras
limitaciones internas de la red.
El ETD llamado puede solicitar, con una facilidad en la fase confirmación de llamada, las clases de caudal que finalmente deben aplicarse a la llamada virtual. Las únicas clases de caudal válidas en la fase confirmación de llamada son inferiores o iguales a las indicadas (respectivamente) al ETD llamado en la fase petición de llamada. Si el ETD llamado no hace ninguna petición de facilidad de clase de caudal en la fase de confirmación de llamada, las clases de caudal que finalmente se aplicarán a la llamada virtual serán las indicadas al ETD llamante en la fase petición de llamada.
Si el ETD llamado no está abonado a la facilidad
negociación de clase de caudal
, las
clases de caudal que finalmente se aplicarán a la llamada virtual serán
inferiores o iguales a las seleccionadas en el interfaz ETD/ETCD llamante, e
inferiores o iguales a los valores por defecto definidos en el ETD/ETCD
llamado.
Cuando el ETD llamante está abonado a la facilidad
negociación de clase de caudal
, en la
fase confirmación de llamada de cada llamada se indicará las clases de caudal
que se aplicarán finalmente a la llamada.
Cuando ni el ETD llamante ni el llamado están abonados a la facilidad
negociación de clase de caudal
, las clases de caudal que
se aplicarán a la llamada virtual no serán superiores a las convenidas como
valores por defecto en los interfaces ETD/ETCD llamante y llamado. Además,
pueden estar limitadas por la red a valores inferiores, por ejemplo para el
servicio internacional.
En el caso de llamadas interredes, toda central de conmutación de datos (CCD), incluidas las asociadas a las redes de origen y de destino, pueden reducir, pero no elevar, los valores de la clase de caudal solicitados en la fase de petición de llamada. Así, se indicará a la CCD asociada con la red de destino las clases de caudal a partir de las cuales puede comenzar la negociación con el ETD llamado.
Si no se solicitan explícitamente determinadas clases de caudal, la CCD supondrá que se han solicitado valores de clase de caudal por defecto convenidos entre ambas Administraciones.
Cuando el ETD llamado ha aceptado la llamada, la CCD asociada con la red de destino puede transportar, en la fase de confirmación de llamada, los valores de clase de caudal que serán finalmente aplicables a la llamada después de la negociación con el ETD llamado.
Si no se han confirmado determinadas clases de caudal, se supone que la CCD confirmará los valores de clase de caudal por defecto convenidos entre ambas Administraciones.
Nota
- En el proceso de determinar si se reducirán o
no los valores de clase de caudal por las redes o el usuario, pueden tenerse en
cuenta diferentes criterios, por ejemplo los recursos disponibles. En el caso
de los servicios de transmisión de datos con conmutación de paquetes,
parámetros de control tales como el tamaño de la ventana y de los paquetes
pueden influir en la clase de caudal que puede alcanzarse.
7.1.3.4.2.1.4
Fase de liberación de la llamada
Durante la fase de liberación de la llamada no debe haber presente ninguna indicación de clase de caudal.
7.1.3.4.2.2
Clase de caudal mínima
7.1.3.4.2.2.1
Enunciado general
La clase de caudal mínima es una facilidad facultativa de usuario que permite, llamada por llamada, el transporte de la clase de caudal mínima aceptable. Las clases de caudal mínimas se consideran independientemente para cada sentido de transmisión.
Esta facilidad corresponde con el parámetro de CDS mínima (véase el 7.1.3.3 ) para el caudal.
7.1.3.4.2.2.2
Fases de petición de llamada y de confirmación
de llamada
El parámetro clase de caudal mínima se transportará del ETD llamante al llamado durante la fase de petición de llamada y lo utilizará el ETD llamado para compararlo con el valor negociado del parámetro negociación de clase de caudal.
Las redes públicas que intervienen en la llamada no están obligadas a supervisar ni actuar sobre el parámetro clase de caudal mínima, por ejemplo para abortar la llamada, pero algunas redes pueden supervisar el parámetro si lo desean.
El parámetro clase de caudal mínima no es transportado durante la fase de confirmación de llamada.
7.1.3.4.2.3
Asignación de clases de caudal por defecto
La
asignación de clases de caudal por defecto
^ es una
facilidad facultativa de usuario acordada por cierto periodo de tiempo. El
abono a esta facilidad permite proporcionar la selección de clases de caudal
tomándolas de la lista de clases de caudal admitidas por la Administración.
Algunas redes pueden imponer la limitación de que las clases de caudal por
defecto sean las mismas en ambos sentidos de transmisión de datos. En ausencia
de esta facilidad, las clases de caudal por defecto corresponden con la clase
de servicio de usuario del ETD (Recomendación X.1) pero no serán superiores a
la clase de caudal máximo soportada por la red.
Las clases de caudal por defecto son las clases de caudal máximas que
pueden asociarse con cualquier llamada en el interfaz ETD/ETCD. Pueden
negociarse otros valores distintos de los de las clases de caudal por defecto
por medio de la facilidad
negociación de clase de caudal
(véase el
7.1.3.4.2.1
). Los valores de clase de caudal distintos de
los valores por defecto pueden convenirse durante cierto periodo de tiempo para
cada circuito virtual permanente.
7.2
Facilidades relacionadas con las condiciones de
tarificación aplicables a la llamada
Las facilidades facultativas de usuario que están normalizadas para diferentes servicios de transmisión de datos y se relacionan con las condiciones de tarificación aplicables a la llamada se indican en el cuadro 7-2/X.301.
Cuadro 7-2/X.301 [T5.301], p.
7.2.1
Cobro revertido y aceptación de cobro revertido
7.2.1.1
Generalidades
El
cobro revertido
^ es una facilidad facultativa de
usuario que puede ser solicitada por el usuario llamada por llamada. Permite al
usuario llamante pedir que se cargue la comunicación al usuario llamado.
La aceptación de
cobro revertido
^ es una facilidad
facultativa de usuario asignada al usuario durante un periodo convenido por
contrato. Permite al usuario aceptar llamadas de cobro revertido.
Nota 1
- Las disposiciones de contabilidad
internacional para llamadas de cobro revertido y sus implicaciones en las
capacidades de red aún no se han definido.
Nota 2
- Las especificaciones sobre el interfaz
ETD/ETCD y el intercambio de señalización no abarcan todavía todos los
requisitos de las facilidades
cobro revertido
y
aceptación de cobro revertido
.
7.2.1.2
Procedimiento de establecimiento de la llamada
7.2.1.2.1 Un usuario llamante puede solicitar el cobro revertido mediante una facilidad de petición a través del interfaz ETD/ETCD.
a)Cuando la red de origen permite el cobro revertido, la información de
control de la llamada enviada a la central siguiente incluirá una indicación
petición de cobro revertido
.
b)Cuando la red de origen no permita el cobro revertido, se rechaza la
llamada y se devuelve al usuario llamante una señal de progresión de la llamada
petición de facilidad no válida
.
7.2.1.2.2 Cuando se recibe una llamada que incluye una indicación de petición de cobro revertido, la central de destino actuará como sigue:
a)Cuando el usuario llamado está abonado a la facilidad
aceptación de cobro revertido
, la información de llamada
entrante, incluida la indicación de que se ha pedido el cobro revertido, se
envía al usuario llamado.
b)Cuando el usuario llamado no está abonado a la facilidad
aceptación de cobro revertido
, se rechaza la llamada y se
envía a la central de origen una señal
no abonado a aceptación
de cobro revertido
.
La llamada puede rechazarse también por otros motivos no relacionados con
las facilidades
cobro revertido
o
aceptación de cobro revertido
.
Cuando la información de llamada entrante se envía al usuario llamado, este usuario, si no desea aceptar el cobro revertido para esta llamada en particular, puede rechazar el establecimiento de la llamada mediante la liberación.
Nota
- Las disposiciones de interfaz ETD/ETCD
necesarias en el servicio con conmutación de circuitos de las RPDCC para
permitir que el usuario llamado rechace el establecimiento de una llamada con
cobro revertido, por ejemplo después de la
identificación de la
línea llamante
, aún no se han definido. Probablemente, el procedimiento
elegido afecta a los procedimientos de red para las llamadas con cobro
revertido.
7.2.2
Prevención de tarificación local
La
prevención de tarificación local
^ es una facilidad
facultativa de usuario convenida por un periodo de tiempo. Esta facilidad de
usuario, cuando se está abonado a ella autoriza al ETCD a impedir el
establecimiento de llamadas por las cuales deba pagar el usuario, para lo cual:
a)No se transmiten al ETD llamadas entrantes en que se solicite la facilidad
de
cobro revertido
, y
b)Se asegura que la tarificación se aplica a otra parte (o usuario) cuando el ETD pide una llamada. Esta otra parte (o usuario) puede determinarse realizando cierto número de operaciones de procedimiento y administrativas. Los métodos basados en operaciones de procedimiento incluyen:
-la utilización del cobro revertido,
-la identificación de un tercero mediante la facilidad
identificación de usuario de red
(véase el
7.4.5
).
Cuando no se ha determinado la parte que debe ser tarificada en una petición de llamada, el ETCD aplicará el cobro revertido a esa llamada.
Nota
- Durante un periodo de transición, algunas redes
pueden optar por reaccionar a la prevención de tarificación local por medio de
la liberación de la llamada cuando no se ha determinado la parte que ha de ser
tarificada.
7.2.3
Información de tarificación (o de
tasación)
La información de tarificación
^ es una facilidad
facultativa de usuario que puede ser convenida por cierto periodo de tiempo o
solicitada por el ETD para una determinada llamada.
Si el ETD en cuestión es el ETD a tarificar, podrá solicitar la facilidad
información de tarificación
^ llamada por llamada mediante
una facilidad de petición adecuada en la fase de petición de llamada o de
confirmación de llamada.
Si un ETD está abonado a la facilidad
información de
tarificación
por un periodo acordado por contrato, la facilidad estará en
vigor para ese ETD cuando éste sea el ETD a tarificar, sin que se envíe la
petición de facilidad en la fase de
petición de llamada
o
confirmación de llamada
.
Durante la fase de
liberación de llamada
, el ETCD
enviará al ETD tarificado información sobre la tarificación de esa llamada y/o
las demás informaciones que permitan al usuario determinar el importe de la
comunicación.
El parámetro de información de tarificación puede expresarse en cualquiera de las medidas siguientes: unidad monetaria, distancia, cuenta de segmentos, duración de la comunicación.
7.3
Facilidades relacionadas con las condiciones
específicas de encaminamiento solicitadas por el usuario
de la llamada
Las facilidades facultativas de usuario que están normalizadas para diferentes servicios de transmisión de datos y se relacionan con las condiciones específicas de encaminamiento solicitadas por el usuario de la llamada se indican en el cuadro 7-3/X.301.
Cuadro 7-3/X.301 [T6.301], p.
7.3.1
Redireccionamiento de llamadas
7.3.1.1
Generalidades
El
redireccionamiento de llamadas
es una facilidad
facultativa de usuario asignada al usuario durante un periodo convenido por
contrato.
Esta facilidad permite a un usuario hacer que las llamadas dirigidas a su dirección sean redireccionadas a una dirección predeterminada.
En el caso del servicio con conmutación de circuitos en las RPDCC, esta facilidad se aplicará a todas las llamadas a la dirección en cuestión. En el caso del servicio de transmisión de datos con conmutación de paquetes en la RPDCP y RDSI, la facilidad se aplicará a todas las llamadas que encuentran la condición fuera de servicio u opcionalmente otras condiciones, tales como la de número ocupado.
La provisión de la facilidad y el registro de la dirección a la cual se redireccionarán las llamadas serán controladas por la Administración.
Se estudiará con mayor amplitud si se requiere o no una facilidad para permitir el control por el usuario de la dirección registrada a la cual se redireccionan las llamadas.
Según las posibilidades ofrecidas por la Administración, la activación y desactivación de la facilidad puede hacerse:
a)por el usuario mediante procedimientos de activación y desactivación controlados por éste;
b)por la red en momentos o tiempos predeterminados;
c)por las Administraciones o empresas privadas de explotación reconocidas (EPER) a petición del usuario;
d)por la Administración cuando suministre o cancele la facilidad
redireccionamiento de llamadas
a partir de la dirección.
Pueden proporcionarse también procedimientos controlados por el usuario para indagar el estado de la facilidad (por ejemplo, para saber si la facilidad está activada o desactivada).
En las llamadas internacionales, el redireccionamiento sólo puede efectuarse dentro de la red de destino. Algunas Administraciones pueden autorizar el redireccionamiento entre redes dentro del país de destino. En general, una llamada sólo puede ser redireccionada una vez. Sin embargo, algunas Administraciones pueden proporcionar múltiples redireccionamientos de una llamada en el servicio de transmisión de datos con conmutación de paquetes en las RPDCP y en las RDSI.
El servicio básico está limitado a un solo redireccionamiento de llamada. Además, algunas redes pueden ofrecer cualquiera de las siguientes capacidades (mutuamente exclusivas). Designando por ETD A el ETD llamante, y ETD B el ETD inicialmente llamado:
1)La red del ETD B almacena una lista de ETD alternativos (C1, C2, .^.^.). Se efectúan tentativas consecutivas de redireccionamiento de llamada a cada una de estas direcciones, en el orden de la lista, hasta completar la llamada.
2)Los redireccionamientos de llamada pueden estar concatenados lógicamente; si el ETD C está abonado al redireccionamiento de llamada al ETD D, una llamada redireccionada de ETD B a ETD C puede redireccionarse a ETD D; los redireccionamientos y las desviaciones de llamada también pueden estar concatenadas.
En todo caso, las redes asegurarán que no se produzcan redireccionamientos
circulares y que la fase de
petición de llamada
tenga una
duración limitada, de acuerdo con el límite de tiempo del ETD.
La facilidad
redireccionamiento de llamada
^ no violará
la integridad de la facilidad
grupo cerrado de usuarios
.
En el caso de redes con conmutación de paquetes, cuando se redirecciona la
llamada, la dirección llamada del ETD alternativo y la facilidad
notificación de modificación de la dirección de línea
llamada
, que indica el motivo por el cual la dirección llamada es
diferente de la solicitada inicialmente, se indicarán al ETD llamante durante
la fase de confirmación de llamada o de liberación de llamada (véase el
7.3.5
).
Cuando se redirecciona la llamada, algunas redes pueden indicar al ETD
alternativo el motivo del redireccionamiento y la dirección del ETD
inicialmente llamado, utilizando la facilidad
notificación
de redireccionamiento de llamada
en la fase de
petición de llamada (véase el
7.3.6
).
El orden de procesamiento del establecimiento de la llamada en el ETCD inicialmente llamado así como en el ETCD alternativo se ajustará a la secuencia de señales de pregresión de la llamada indicada en el cuadro 1/X./96. En el caso de redes que proporcionan un redireccionamiento de llamada sistemático previa solicitud del ETD llamado, la petición de redirección de llamada sistemática tendrá la prioridad más elevada en la secuencia de procesamiento de establecimiento de la llamada en el ETCD inicialmente llamado.
Se estudiará con mayor amplitud si se necesita una facilidad facultativa de usuario para que el ETD llamante indique si se permite o no redireccionar llamadas originadas por este ETD.
7.3.1.2
Procedimiento de establecimiento de la llamada para
servicios de transmisión de datos con conmutación de
circuitos en las RPDCC
7.3.1.2.1
Llamadas en que no intervienen otras facilidades
que afectan al procedimiento
La información de que un usuario tiene activada la facilidad
redireccionamiento de llamadas
se almacena, junto con la
dirección de redireccionamiento, en la central a la cual está conectado el
usuario. Cuando se llama a este usuario, la llamada se establece con la
dirección indicada conforme a lo siguiente:
7.3.1.2.1.1
La dirección de redireccionamiento está en la
misma central
En este caso la central de destino conecta la llamada con la dirección de
redireccionamiento y devuelve la señal
llamada
redireccionada
, a menos que se rechace la llamada por uno de los motivos
indicados más abajo. Al recibir la señal
llamada
redireccionada
, la central de origen envía la correspondiente señal de
progresión para informar al usuario llamante que la llamada ha sido
redireccionada.
redirecciona miento de
llamadas
, la central de destino rechaza la llamada y devuelve la señal de
progresión de la llamada
acceso
prohibido
. La llamada puede rechazarse también por otros
motivos (por ejemplo, número ocupado) de acuerdo con los procedimientos
ordinarios.
7.3.1.2.1.2
La dirección de redireccionamiento está en otra
central
7.3.1.2.1.2.1 En este caso, la llamada se establece con la dirección de redireccionamiento de acuerdo con uno de los procedimientos indicados a continuación, según las disposiciones en la red de destino.
7.3.1.2.1.2.2 El siguiente procedimiento se basa en el principio de que la llamada se libera hacia atrás dentro de la red de destino y se establece entonces con la nueva central de destino. En el caso de una llamada internacional, la llamada se libera hacia atrás hasta la central cabeza de línea de llegada. En el caso de una llamada nacional, se libera hacia atrás hasta la señal de origen. Este procedimiento puede basarse en la Recomendación X.61 sobre señalización por canal común. Los medios necesarios para el soporte de este procedimiento no se definen en las Recomendaciones X.70 y X.71.
i)La primera central de destino devuelve la señal
petición de redireccionamiento
con la
dirección de redireccionamiento, a la central directora (es decir, a la central
cabeza de línea de llegada, o a la central de origen).
ii)En el caso de una llamada internacional, la central cabeza de línea de
llegada al recibir la señal
petición de
redireccionamiento
, establece una nueva conexión hacia
delante con la dirección de redireccionamiento. La información de control de la
llamada enviada incluye una indicación
llamada
redireccionada
. Se libera la conexión hacia delante con la primera central
de redireccionamiento.
iii)En el caso de una llamada nacional, la central de origen actúa conforme a ii).
iv)Al recibir la llamada redireccionada, la nueva central de destino conecta
la llamada, o la rechaza, de acuerdo
7.3.1.2.1.1
. La indicación
llamada redireccionada
hacia delante, recibida por la
nueva central de destino, se utiliza para impedir un ulterior
redireccionamiento.
llamada
redireccionada
, después de lo cual envía la señal de progresión de la
llamada
llamada redireccionada
para informar al usuario
llamante que la llamada ha sido redireccionada.
7.3.1.2.1.2.3 El siguiente procedimiento se basa en el principio de que la conexión se extiende, hacia adelante, de la primera central de destino a la nueva central de destino. Este procedimiento puede basarse en la señalización por canal común y en la señalización descentralizada de conformidad con la Recomendación X.61 y las Recomendaciones X.70 y X.71 respectivamente.
i)La primera central de destino establece la conexión hacia delante con la
dirección redireccionada. La información de control de la llamada enviada
incluirá una indicación
llamada redireccionada
.
ii)Al recibir la llamada redireccionada, la nueva central de destino conecta
o rechaza la llamada de acuerdo con el
7.3.1.2.1.1
. La indicación
llamada redireccionada
recibida se utiliza para impedir un
nuevo redireccionamiento.
iii)Cuando la llamada se conecta con la dirección de redireccionamiento, la
central de origen recibirá una señal
llamada
redireccionada
, después de lo cual envía la señal de progresión de la
llamada redireccionada
para informar al usuario llamante
que la llamada ha sido redireccionada.
7.3.1.2.2
Llamadas en que interviene una facilidad de grupo
cerrado de usuarios
Las llamadas redireccionadas están sometidas a las restricciones aplicables a las facilidades de grupo cerrado de usuarios (GCU).
a)Cuando se trata de una llamada GCU, o cuando el usuario inicialmente llamado tiene una facilidad GCU, la llamada se rechaza antes del redireccionamiento, a menos que se cumplan los requisitos de verificación de validación aplicables a la facilidad GCU en cuestión.
b)Cuando se trata de una llamada GCU, o cuando el usuario en la dirección de redireccionamiento dispone de una facilidad GCU, la llamada se rechaza a menos que se cumplan los requisitos de verificación de validación aplicables a la facilidad GCU en cuestión.
c)Cuando:
i)se trata de una llamada GCU, y
ii)la dirección de redireccionamiento está en una central distinta de la primera central de destino, y
iii)el procedimiento para el establecimiento de la llamada a la dirección de
redireccionamiento se ajusta al
7.3.1.2.1.2
(es decir, se libera la
llamada en sentido de retorno), la primera central de destino tiene que
devolver la información GCU recibida (es decir, la indicación de llamada GCU, y
el código de enclavamiento) a la central directora junto con la señal
llamada redireccionada
y la dirección de
redireccionamiento a fin de que la central directora pueda incluir esta
información GCU en la información de control de la llamada que enviará por la
nueva conexión hacia delante.
7.3.1.2.3
El usuario llamante tiene la facilidad de
identificación de la línea llamada
Cuando se redirecciona una llamada procedente de un usuario que tiene la
facilidad
identificación de la línea llamada
, la
identificación de la línea llamada enviada al usuario llamante es el número de
datos de la dirección de redireccionamiento.
7.3.2
Desviación de llamadas
7.3.2.1
Generalidades
La
desviación de llamadas
es una facilidad facultativa
de usuario asignada al usuario durante un periodo convenido por contrato.
Esta facilidad permite al usuario desviar las llamadas entrantes a otra dirección, llamada por llamada, en un servicio de llamada virtual con conmutación de paquetes.
Al recibir una petición de llamada entrante, el ETD inicialmente llamado responde con una petición de liberación que incluye la dirección del ETD al que debe desviarse la llamada (o sea, la fase de transferencia de datos no se realiza nunca entre el ETD llamante y el ETD llamado inicialmente). A continuación, la red inicia una llamada entrante en el interfaz del ETD hacia el que se desvía la llamada.
En las llamadas internacionales, la desviación sólo puede efectuarse dentro de la red de destino. Algunas Administraciones pueden autorizar la desviación entre redes dentro del país de destino. En general, una llamada puede ser desviada una sola vez. Sin embargo, algunas Administraciones pueden proporcionar múltiples desviaciones de una llamada en el servicio de transmisión de datos con conmutación de paquetes en las RPDCP y RDSI.
El servicio básico está limitado a una sola desviación de llamada. Además, las desviaciones de llamada y los redireccionamientos de llamada pueden estar lógicamente concatenados en algunas redes.
En ese caso, las redes asegurarán que no se produzcan desviaciones circulares, y que la fase de petición de llamada tenga una duración limitada, de acuerdo con el límite de tiempo del ETD.
La facilidad
desviación de llamada
no violará la
integridad de la facilidad grupo cerrado de usuarios.
En el caso de redes con conmutación de paquetes, cuando se desvía la
llamada, la dirección llamada del ETD alternativo y la facilidad
notificación de modificación de dirección de línea
llamada
, que indica el motivo por el cual la dirección llamada es
diferente de la solicitada inicialmente, se indicarán al ETD llamante durante
la fase de confirmación de llamada o de liberación de llamada (véase el
7.3.5
).
Cuando se desvía la llamada, algunas redes pueden indicar al ETD
alternativo el motivo de la desviación y la dirección del ETD inicialmente
llamado, utilizando la facilidad
notificación de
redireccionamiento o de desviación
en la fase de
petición de llamada (véase el
7.3.6
).
Se estudiará con mayor detalle si se necesita una facilidad facultativa de usuario que permita al ETD llamante indicar si se permite o no desviar las llamadas originadas por él.
7.3.3
Grupo de búsqueda
7.3.3.1
Generalidades
La facilidad de
grupo de búsqueda
es una facilidad
facultativa de usuario que distribuye las llamadas entrantes provistas de una
dirección de grupo de búsqueda a través de los interfaces ETD/ETCD asociados
con la facilidad.
Una vez que una llamada ha sido asignada a un interfaz ETD/ETCD, se trata como una llamada normal.
Las llamadas originadas en un interfaz ETD/ETCD que pertenece al grupo de búsquda se tratan como llamadas normales.
Nota 1
- Se puede asociar una o más direcciones con la
facilidad. Si se asocia más de una dirección con la facilidad, el procedimiento
de selección se realiza cualquiera que sea la dirección llamada.
Nota 2
- Se puede asignar una dirección específica a
cada interfaz ETD/ETCD asociado con un grupo de búsqueda. Las llamadas hechas
directamente a estas direcciones específicas se tratan normalmente (sin
distribución de llamadas). Si se ha realizado una distribución y se ha asignado
una dirección específica en cada interfaz ETD/ETCD asociado con el grupo de
búsqueda, la dirección debe devolverse al ETD llamante (como identificación de
la línea llamada) junto con un indicador que informe el motivo por el cual la
identificación de línea llamada es diferente de la dirección inicialmente
llamada.
7.3.3.2
Procedimiento de establecimiento de la llamada
Cuando se recibe una llamada entrante que tiene una dirección de grupo de búsqueda, la central de destino realiza la selección del interfaz ETD/ETCD, si hay por lo menos un canal/circuito disponible para llamadas entrantes en cualquiera de los interfaces ETD/ETCD del grupo.
Cuando se hacen llamadas a una dirección del grupo de búsqueda, en el caso de que se han asignado direcciones específicas a los distintos interfaces ETD/ETCD, se transfiere al ETD llamante información que contiene:
1)la dirección llamada del interfaz ETD/ETCD seleccionado, y
2)el motivo por el cual la dirección llamada es diferente de la solicitada inicialmente.
Los detalles precisos de esa disposición serán objeto de ulterior estudio.
En el caso del servicio de llamada virtual con conmutación de paquetes, se
utiliza para esta finalidad la facilidad
notificación de
dirección de línea llamada modificada
.
Algunas redes pueden aplicar facilidades de usuario establecidas en el momento del abono, comunes a todos los interfaces ETD/ETCD en el grupo de búsqueda, imponer un límite al número de interfaces ETD/ETCD en el grupo de búsqueda, y/o limitar la extensión de la zona geográfica que pueda ser servida por un sólo grupo de búsqueda.
7.3.4
Selección de EPER
7.3.4.1
Generalalidades
Esta es una facilidad facultativa de usuario que el ETD puede convenir por un periodo de tiempo o solicitar llamada por llamada para uso en servicios de llamada virtual con conmutación de circuitos o con conmutación de paquetes.
En los países que tienen más de una red de tránsito EPER hay necesidad de una facilidad de usuario que, cuando se solicite, permita al ETD llamante seleccionar una red de tránsito EPER, o una secuencia de EPER, dentro del país de origen. En el caso de las llamadas internacionales, esta facilidad, cuando se solicita, permite al ETD llamante seleccionar una determinada EPER internacional dentro del país de ese ETD llamante.
Nota
- El procedimiento para la selección de varias
EPER aún no se ha especificado en las Recomendaciones sobre el interfaz con
conmutación de circuitos.
7.3.4.2
Procedimiento de establecimiento de la llamada
Un usuario en una red que proporciona la facilidad de selección de EPER puede solicitar la selección de una determinada red de tránsito EPER, o de una secuencia de EPER, dentro del país de origen, bien por un periodo de tiempo convenido, bien llamada por llamada, mediante una petición de facilidad que incluya los IN (véase la Recomendación X.302) que identifican a la red o redes de tránsito EPER seleccionadas.
En el caso de que un usuario llamante solicita la selección de una o más redes de tránsito EPER, la red de origen encaminará la llamada a la central cabeza de línea de la primera red de tránsito EPER seleccionada. Cuando la llamada se encamina vía una o más centrales de tránsito dentro de la red de origen, se incluirá una indicación de petición de selección de EPER y el CIRD o los CIRD que identifican la red o redes de tránsito EPER solicitadas en la información de control de llamada por la red enviada por la central de origen. De forma similar, si el usuario llamante selecciona una secuencia de redes de tránsito, la primera red encaminará la llamada a la central cabeza de línea de la segunda red de tránsito EPER. Además se transmitirá a través del interfaz la secuencia de CIRD que identifican las EPER seleccionadas por el usario. A reserva de ulteriores estudios, la facilidad/utilidad usada para proporcionar esta información está sujeta a acuerdo bilateral entre las redes de tránsito conectantes.
La información de control de la llamada enviada por la red internacional
será como para una llamada ordinaria y no contendrá ninguna información
relacionada con
selección de EPER
.
Cuando la red de tránsito EPER seleccionada no pueda aceptar la llamada,
debido por ejemplo a congestión o fallos en la red, la central cabeza de línea
rechazará la llamada y devolverá una señal
EPER fuera de
servicio
a la central de origen, la cual enviará al usuario llamante la
correspondiente de progresión de la llamada.
7.3.5
Notificación de modificación de la dirección de
la línea llamada
La notificación modificación de la dirección de línea llamada es una facilidad facultativa de usuario utilizada por el ETCD en la fase de confirmación de llamada o de liberación de llamada para informar el ETD llamante sobre el motivo por el cual la dirección llamada en esta fase es diferente de la que dio ETD llamante en la fase de petición de llamada.
Cuando más de una dirección son aplicables al interfaz ETD/ETCD, el ETD respondedor puede utilizar la facilidad de notificación de línea llamada modificada, en la fase de liberación de la llamada (cuando se rechaza la llamada) o en la fase de confirmación de llamada, cuando la dirección llamada presentada por el ETD respondedor es diferente de la indicada al ETD en la fase de petición de llamada. Cuando se recibe esta facilidad del ETD respondedor:
2)Si el redireccionamiento de llamada ha tenido lugar en la RPD o la RDSI,
el ETCD sustituirá el motivo contenido en la facilidad
notificación de modificación de la dirección de
línea llamada
por el motivo que refleje el estado del ETD
inicialmente llamado; en otro caso, se pasa transparentemente el motivo.
Nota
- El ETD debe saber que una modificación de
cualquier parte del campo de dirección del ETD llamado sin una notificación
mediante la facilidad
notificación de
dirección de línea llamada modificada
puede causar la
liberación de la llamada.
Los siguientes motivos pueden indicarse mediante el uso de la facilidad
notificación de dirección de línea llamada modificada
en
la fase de confirmación o de liberación de llamada, y transmitirse al ETD
llamante:
1)Distribución de llamada dentro de un grupo de búsqueda.
2)Redireccionamiento de llamada por estar fuera de servicio el ETD inicialmente llamado.
3)Redireccionamiento de llamada por estar ocupado el ETD inicialmente llamado.
4)Redireccionamiento de llamada porque el ETD inicialmente llamado ha solicitado con prioridad el redireccionamiento sistemático de las llamadas.
5)Originado por el ETD llamado.
6)Desviación de llamada por el ETD de origen.
En la fases de
confirmación
o
liberación
de la llamada, los motivos indicados por el ETD
respondedor junto con el uso de la facilidad
notificación de
dirección de línea llamada modificada
debe ser
`originado por el
ETD'
.
7.3.6
Notificación de redireccionamiento o desviación
de llamada
Notificación de redireccionamiento o desviación de
llamada
es una facilidad facultativa de usuario, utilizada por el ETCD en
la fase de
petición de llamada
para
comunicar al ETD alternativo el motivo por la cual se redirecciona la llamada,
y la dirección del ETD inicialmente llamado.
Los siguientes motivos (o razones) pueden indicarse con la facilidad
notificación de redireccionamiento de llamada
:
1)redireccionamiento de llamada por estar fuera de servicio el ETD inicialmente llamado,
2)redireccionamiento de llamada por estar ocupado el ETD inicialmente llamado,
3)redireccionamiento de llamada porque el ETD inicialmente llamado ha solicitado previamente el redireccionamiento sistemático de las llamadas,
4)desviación de llamada por el ETD inicialmente llamado, o
5)distribución de llamada dentro de un grupo de búsqueda.
7.4
Facilidades relacionadas con el mecanismo de
protección solicitado por el usuario de la
llamada
Las facilidades facultativas de usuario que están normalizadas para diferentes servicios de transmisión de datos y se relacionan con el mecanismo de protección solicitado por el usuario de la llamada se muestran en el cuadro 7-4/X.301.
Cuadro 7-4/X.301 [T7.301], p.
7.4.1
Grupo cerrado de usuarios
7.4.1.1
Generalidades
Las facilidades de grupo cerrado de usuarios (GCU) permiten a los usuarios formar grupos con diferentes combinaciones de restricciones para el acceso desde o hacia usuarios que tienen una o más de estas facilidades. Las facilidades GCU que se indican a continuación son todas ellas facultativas y se asignan al usuario durante un periodo de tiempo convenido por contrato (véase nota 1):
a)
Grupo cerrado de usuarios
. Esta es la facilidad
básica; permite a un usuario que pertenezca a uno o más GCU;
b)
Grupo cerrado de usuarios con acceso de salida
. Esta
es una ampliación de A que permite también al usuario hacer llamadas salientes
a la parte abierta de la red, y a los ETD que tienen la capacidad de acceso de
llegada [véase c)];
c)
Grupo cerrado de usuarios con acceso de llegada
. Esta
es una variante de a) que permite al usuario recibir llamadas entrantes de la
parte abierta de la red, y de los ETD que tienen la capacidad de acceso de
salida [véase b)];
d)
Prohibición de llamadas entrantes dentro del grupo
cerrado de usuarios
. Esta es una facilidad suplementaria a
a), b) y c) que, cuando se utiliza, se aplica GCU por GCU;
e)
Prohibición de llamadas salientes dentro del grupo
cerrado de usuarios
. Esta es una facilidad suplementaria a
a), b) y c) que, cuando se utiliza, se aplica GCU por GCU.
Un usuario puede pertenecer a uno o más GCU. Cuando el usuario pertenece a
un solo GCU, y se ha abonado a la facilidad
grupo cerrado
de usuarios
, este grupo constituye el GCU
preferencial de ese usuario. Cuando el usuario pertenece a más de un GCU, y se
ha abonado a la facilidad de grupo cerrado de usuarios, uno de estos GCU se
designa GCU preferencial de ese usuario.
Cada usuario perteneciente por lo menos a un GCU se ha abonado bien a la
facilidad
grupo cerrado de usuarios
o a una sola de las
dos facilidades siguientes: grupo cerrado de usuarios con acceso de salida o
grupo cerrado de usuarios con acceso de llegada. Cuando el usuario se ha
abonado a la facilidad de grupo cerrado de usuario con acceso de salida y/o
grupo cerrado de usuario con acceso de
llegada
, el ETD puede decidir si tendrá o no GCU preferencial.
Para cada GCU al cual pertenece un usuario podrá ser aplicable, a ese usuario, cada una de las facilidades suplementarias de prohibición de llamadas entrantes dentro del grupo cerrado de usuarios o prohibición de llamadas salientes dentro del grupo cerrado de usuario, o ninguna de ellas. En el caso de diferentes usuarios pertenecientes al mismo GCU pueden aplicarse diferentes combinaciones de facilidades GCU.
La realización de facilidades GCU se efectúa mediante la provisión de códigos de interfuncionamiento y se basa en diferentes verificaciones de validación en la fase de establecimiento de la llamada, por las cuales se determina si se autoriza o no una llamada solicitada hacia, o desde, un usuario que tiene una facilidad GCU. En particular, una verificación de validación se realiza verificando que tanto el usuario llamante como el llamado pertenecen al mismo GCU indicado por los códigos de enclavamiento.
La pertenencia a grupos cerrados de usuarios la controla la Administración o EPER junto con las peticiones de los usuarios. La asignación de códigos de enclavamiento la controla la Administración o EPER, y no puede ser controlada por el usuario.
El código de enclavamiento internacional de un GCU internacional se especifica en el 7.4.1.3 . El código de enclavamiento internacional expresa el número GCU internacional asignado al GCU de acuerdo con las reglas administrativas definidas en la Recomendación X.180.
La utilidad de identificación de red de origen especificada en la Recomendación X.302 puede utilizarse para llamadas GCU internacionales bajo el control de la central cabeza de línea de la red de destino (véase el 7.4.1.2.2 ).
Nota 1
- El acceso de salida y/o el acceso de llegada
se aplican a un usuario individual y no a un grupo cerrado de usuarios
específico.
Nota 2
- Los requisitos indicados en el
7.4.1.2
incluyen casos que no existen necesariamente en un red
determinada, sea porque la Administración (o EPER) ha decidido no ofrecer la
gama completa de combinaciones de facilidades de GCU, o porque algunas
combinaciones no tienen sentido desde el punto de vista del usuario.
Nota 3
- También en el caso de proporcionarse una
facilidad
grupo cerrado de usuarios con
acceso de salida
, una red debe poder servir de soporte a la señalización
necesaria para completar las llamadas entrantes provenientes de usuarios
pertenecientes a otra red que proporciona esa facilidad.
Nota 4
- Las redes privadas, incluidos los diversos
terminales de diferentes tipos, se conectarán a la red pública de datos o la
RDSI. En estas redes privadas, los diferentes terminales pueden pertenecer
internamente a diferentes grupos dentro de estas redes, y pueden también tener
necesidad de comunicar con diferentes GCU en la red pública de datos o la RDSI.
La opción de la red privada de no tener un GCU preferencial en el caso del
abono a la facilidad
grupo cerrado de usuarios con acceso de
salida
y/o la facilidad
grupo cerrado de usuarios con
acceso de llegada
tiene en cuenta una interpretación apropiada de las
facilidades GCU.
Las señales relacionadas con el tratamiento de las llamadas referentes a los GCU se ilustran en la figura 7-6/X.301 y se resumen en los cuadros 7-5, 7-6 y 7-7/X.301.
7.4.1.2
Procedimiento de establecimiento de la llamada
7.4.1.2.1
Central de origen
El protocolo del interfaz ETD/ETCD y las acciones que deben ejecutarse en la central de origen en la fase de establecimiento de una llamada procedente de un usuario perteneciente a un GCU depende de que éste pertenezca a uno o más GCU y de la combinación de facilidades GCU aplicables. Véase también la figura 7-7/X.301.
7.4.1.2.1.1
Selección de GCU
Para cada GCU al que pertenece el usuario, el código de enclavamiento asignado al GCU se almacena y se asocia al usuario en la central local. Cuando un usuario pertenece a más de un GCU, es necesario efectuar, en la fase de establecimiento de la llamada, una selección del GCU preferido y en consecuencia del correspondiente código de enclavamiento. Para esta selección se siguen los siguientes criterios:
Cuando el usuario llamante hace una petición de facilidad que incluye un índice que identifica un determinado GCU, la central de origen selecciona este GCU.
Cuando el usuario llamante pertenece a más de un GCU y tiene un grupo cerrado de usuarios preferencial, no se hace petición sobre la facilidad GCU cuando:
a)el usuario pertenece a un GCU solamente;
b)un usuario que pertenece a más de un GCU con o sin acceso de salida hace una llamada dentro del GCU preferencial; o
c)un usuario que tiene una facilidad de grupo cerrado de usuarios con acceso de salida hace una llamada con acceso de salida, o una llamada dentro del GCU preferencial.
Se necesita siempre una petición de facilidad en el caso de una llamada dentro de un GCU que no sea el preferencial.
Figure 7-6/X.301, p. 18
Figure omitted: 44 Tableau 7-5/X.301 [T8.301]
Tableau 7-5/X.301 [T8.301], p. 19
Tableau 7-6/X.301 [T9.301], p. 20
Figure omitted: 25 blanc
Blanc
Figure omitted: 45 Tableau 7-7/X.301 [T10.301]
Tableau 7-7/X.301 [T10.301], p. 21
Figure omitted: 2 blanc
Blanc
Figure omitted: 47 Figure 7-7/X.301
Figure 7-7/X.301, p. 22
Cuando el usuario llamante pertence a uno o más GCU y no tiene un GCU preferencial, no se hace petición de facilidad concerniente a las facilidades GCU cuando un usuario que tiene una facilidad de grupo cerrado de usuarios con acceso de salida hace una llamada con acceso de salida.
7.4.1.2.1.2
Establecimiento de llamada procedente de un
usuario que tiene la facilidad de GCU o de GCU con acceso
de llegada
El caso del usuario que dispone de las facilidades
grupo
cerrado de usuarios con acceso de llegada
y
grupo cerrado de usuarios con acceso de
salida
se trata conforme al
7.4.1.2.1.3
.
En este caso, la selección de GCU se realiza de acuerdo con el 7.4.1.2.1.1 .
Cuando la facilidad
prohibición de llamadas salientes
dentro del grupo cerrado de usuarios
^ no se aplica al
GCU seleccionado, la llamada se establece en la central de origen. La
información de control de la llamada enviada a la central siguiente incluye
entonces el código de enclavamiento del GCU seleccionado junto con una
indicación de que se trata de una llamada GCU.
Cuando la facilidad
prohibición de llamadas salientes
dentro del grupo cerrado de usuarios
^ se aplica al
GCU seleccionado, se rechaza la llamada y se retorna al usuario llamante la
señal de progresión de la llamada
acceso prohibido
.
7.4.1.2.1.3
Establecimiento de llamada procedente de un
usuario que tiene la facilidad de grupo cerrado de
usuarios con acceso de salida
Cuando el usuario llamante está abonado a la facilidad
grupo cerrado de usuarios con acceso de
salida
, y tiene un GCU preferencial, o un solo GCU, se considera que ésta
es una llamada con acceso de salida y como una llamada dentro del GCU
preferencial, o dentro de un GCU único.
Cuando la facilidad
prohibición de llamadas salientes
dentro del grupo cerrado de usuarios
no es aplicable
al GCU preferencial o al GCU único, la llamada se establece en la central de
origen. La información de control de la llamada enviada a la central siguiente
incluye entonces el código de enclavamiento del GCU preferencial, o del GCU
único, junto con una indicación de que se trata de una llamada GCU para la cual
está autorizado el acceso de salida.
Nota
- Con el procedimiento antes mencionado no es
necesario distinguir en la central de origen entre una llamada dentro de un GCU
y una llamada con acceso de salida.
En aquellos casos en que la facilidad de prohibición de llamadas salientes dentro del grupo cerrado de usuarios es aplicable al GCU preferencial, (o único), se considera que ésta es una llamada con acceso de salida. En este caso, la llamada se establece en la central de origen y no se incluye ningún código de enclavamiento o indicación de llamada GCU en la información de control de la llamada enviada a la central siguiente.
Cuando el usuario llamante se ha abonado a la facilidad de grupo cerrado de usuarios con acceso de salida y no tiene un grupo cerrado de usuarios preferencial, se considera que ésta es una llamada con acceso de salida, a menos que el usuario pida una facilidad que identifique un determinado GCU para la llamada.
7.4.1.2.2
Central de tránsito
Con la posible excepción de algunas centrales cabeza de línea, cada central de tránsito establece una llamada GCU como si se tratase de una llamada ordinaria. La información relacionada con las facilidades GCU recibidas de la central precedente (esto es, un código de enclavamiento, una indicación de llamada GCU y posiblemente una indicación de que el acceso de salida está permitido) se envía a la central siguiente.
En el caso de una llamada GCU internacional, no se requieren funciones especiales en la central de cabecera siempre que el código de enclavamiento asignado al GCU internacional en cuestión se utilice en la red nacional. Sin embargo, cuando en una red nacional se utiliza un código de enclavamiento nacional distinto del código de enclavamiento internacional aplicable, se requiere la conversión del código de enclavamiento en la central de cabecera (o correspondiente).
Cuando una red de destino necesita la identificación de la central de
origen para llamadas GCU, puede emplear la utilidad
identificación de red
de origen especificada en la
Recomendación X.302.
7.4.1.2.3
Central de destino
En la central de destino se efectúa una verificación de validación de la
aceptabilidad de una llamada cuando ora el usuario llamante (señalado por una
indicación de llamada GCU en la información de control recibida), ora el
usuario llamado, pertenece a un GCU. La llamada sólo se conecta cuando la
información recibida esté de acuerdo con la información almacenada en la
central de destino, asociada al usuario llamado, como se especifica más abajo.
En aquellos casos en que se rechaza una lamada en base a información GCU
incompatible, se envía al usuario llamante una señal de progresión de la
llamada
acceso prohibido
.
Las condiciones para la aceptación o rechazo de llamadas con motivo de facilidades GCU se ilustran en la figura 7-8/X.301.
Nota
- Una llamada puede rechazarse por motivos
distintos de los relacionados con las facilidades GCU.
7.4.1.2.3.1
Llamadas a un usuario que tiene la facilidad de
GCU o GCU con acceso de salida
El caso del usuario que tiene la facilidad de GCU
con
acceso de llegada
^ y también la de GCU
con acceso de salida
se trata conforme a lo descrito en el
7.4.1.2.3.2
.
En este caso, una llamada entrante sólo se acepta cuando:
a)es una llamada GCU, incluido el caso en que está autorizado el acceso de salida, y
b)se verifica la correspondencia entre el código de enclavamiento recibido y el código de enclavamiento asociado con el usuario llamado, y
c)la facilidad prohibición de llamadas entrantes dentro del grupo cerrado de usuarios no se aplica al GCU identificado por el código de enclavamiento recibido.
Si no se cumplen todas estas condiciones, se rechaza la llamada.
7.4.1.2.3.2
Llamadas a un usuario que tiene la facilidad de
GCU con acceso de llegada
Una llamada entrante se acepta cuando:
a)es una llamada ordinaria, o
b)es una llamada GCU para la cual está autorizado el acceso de salida, o
c)es una llamada GCU para la cual no está autorizado el acceso de salida pero se cumplen las dos condiciones especificadas en el 7.4.1.2.3.1 b) y c).
En todos los demás casos se rechaza la llamada entrante.
Llamadas GCU a un usuario no perteneciente a
ningún GCU
Cuando la llamada entrante es:
a)una llamada GCU para la cual está autorizado el acceso de salida, se acepta;
b)una llamada para la cual no está autorizado el acceso de salida, se rechaza.
7.4.1.3
Código de enclavamiento
internacional
A cada GCU internacional se asigna un Número GCU Internacional (NGI) único de acuerdo con las reglas administrativas definidas en la Recomendación X.180.
Cada código de enclavamiento internacional contiene:
a)cuatro dígitos decimales codificados en binario que expresan el IPD más un dígito, o CIRD, del país o red de la Administración o empresa privada de explotación reconocida coordinadora, es decir, el número decimal A del número GCU internacional, y
b)un código de l6 bits que expresa en representación binaria pura el valor del número decimal B del número GCU internacional.
Nota 1
- En algunos casos de señalización se
transmiten todos los ceros iniciales, algunos de ellos, o ninguno; véanse las
Recomendaciones X.70 y X.71. El código binario debe en tales casos tener el
mismo significado cualquiera que sea el número de ceros iniciales.
Nota 2
- Deberá estudiarse con mayor amplitud si en el
caso de GCU internacionales que tengan miembros en redes públicas diferentes de
las RPD, por ejemplo las RDSI, se necesitarán o no disposiciones adicionales
para el tratamiento de los códigos de enclavamiento GCU internacionales en las
RPD.
Figura 7-8/X.301, p.
7.4.2
Grupo cerrado de usuarios bilateral
7.4.2.1
Generalidades
El
grupo cerrado de usuarios bilateral
^ y el
grupo cerrado de usuarios con acceso de
salida
^ son facilidades facultativas de usuario asignadas al usuario por
un período convenido por contrato.
La
facilidad grupo cerrado de usuarios bilateral
^
(GCUB) hace posible a pares de usuarios formar relaciones bilaterales que
permiten el acceso de cada uno con todos los demás en tanto que excluyen el
acceso a, o a partir de, otros usuarios con los cuales no se ha formado esa
relación. Un usuario puede pertenecer a más de un GCUB.
La facilidad
grupo cerrado de usuarios bilateral con acceso
de salida
^ (GCUBAS) permite a un usuario formar GCUBs
como el caso de la facilidad
grupo cerrado de usuarios
bilateral
pero al mismo tiempo permite al usuario ganar acceso, mediante
llamadas salientes, a usuarios de la parte abierta de la red que no tienen
facilidades de
grupo cerrado de usuarios bilateral
o
grupo cerrado de usuarios bilateral con acceso de salida
.
Un usuario puede tener simultáneamente la facilidad
grupo
cerrado de usuarios bilateral
^ o
grupo cerrado de usuarios bilateral con acceso de
salida
y una o más facilidades
grupo
cerrado de usuarios
(GCU). En estos casos, una llamada dentro de un GCU se
trata separadamente de la facilidad
grupo cerrado de usuarios
bilateral
, y no se considera como una llamada con acceso de salida en
relación con la facilidad
grupo cerrado de usuarios
bilateral
.
El registro y la cancelación de un GCUB de dos usuarios con respecto a
facilidades de
grupo cerrado de usuarios bilateral
o
grupo cerrado de usuarios bilateral con
acceso de salida
son controlados por los usuarios interesados por medio de
procedimientos automáticos de registro y cancelación.
Las facilidades
grupo cerrado de usuarios bilateral
^ y
grupo cerrado de usuarios bilateral con
acceso de salida
, incluidos los procedimientos automáticos controlados por
el usuario de registro y cancelación, pueden utilizar como soporte la
señalización por canal común (Recomendación X.61) para el servicio de
transmisión de datos con conmutación de circuitos. La señalización
descentralizada para la transmisión de datos con conmutación de circuitos
(Recomendaciones X.70 y X.71) y para el servicio de transmisión de datos con
conmutación de paquetes (Recomendación X.75) no pueden utilizarse como soporte
para estas facilidades.
Los procedimientos para la facilidad
grupo cerrado de
usuarios bilateral
^ se basan en el método del
registro mutuo. Este método utiliza las características de la llamada con
dirección abreviada. Así, un usuario que tiene la facilidad
grupo cerrado de usuarios bilateral
, utiliza un índice
local (esto es, una dirección abreviada) para cada usuario distante con el cual
se forma un GCUB. En la central a que está conectado el usuario está disponible
una tabla asociada al usuario. El índice local utilizado para direccionar un
usuario distante corresponde a una posición en la tabla que contiene el número
(dirección) de datos del usuario distante, el índice local utilizado por el
usuario distante para direccionar al usuario local, y una indicación (bit de
asociación) sobre el estado del GCUB.
7.4.2.2
Procedimientos de registro
7.4.2.2.1 El usuario
A
, cuando solicita el registro
de un GCUB, hace una petición de facilidad que incluye el número de datos
B
del usuario distante y el índice local
x
utilizado para ese usuario. La central de origen
verifica si un número de datos ha sido registrado o no en la posición
correspondiente al índice local
x
recibido, en la tabla
del usuario local
A
.
a)Si no se ha registrado un número de datos en la posición
x
de la tabla del usuario
A
, la
central de origen registra el número de datos
B
en esa
posición. La central de origen envía entonces una petición de registro GCUB a
la central de destino, que incluye un número de datos
B
como dirección de destino, un número de datos
A
como
dirección de fuente (u origen) y el índice local
x
.
b)Cuando ya se ha registrado un número de datos
B
^ para
el usuario distante en la posición
x
^ de la tabla del
usuario
A
, y aún no se ha puesto a 1 su bit de asociación,
lo que indica que el registro aún no se ha completado, la central de origen
envía una petición de registro GCUB a la central de destino, que incluye la
misma información descrita en el apartado a).
c)Cuando el número de datos
B
^ para el usuario distante
ya se ha registrado en una posición
x
^ de la tabla del
usuario
A
y su bit de asociación se ha puesto a 1, la
central de origen envía al usuario
A
la señal de
progresión de la llamada
registro/cancelación confirmado
.
d)Cuando el número de datos registrado en esa posición es diferente del
número de datos
B
^ recibido, la central de origen envía al
usuario
A
la señal de progresión de la llamada
error de procedimiento local
.
7.4.2.2.2 La central de destino, cuando recibe la petición de registro
GCUB, verifica la tabla del usuario
B
direccionado.
a)Si el usuario
B
^ ya ha registrado al usuario
A
^ en una posición
y
, siendo
y
el índice local utilizado por el usuario
B
para el usuario
A
, y su bit de
asociación todavía no se ha puesto a 1, lo que indica que el registro aún no se
ha completado, la centra de destino pone a 1 el bit de asociación y registra el
índice local
x
en esa posición. La central de destino
responde entonces a la central de origen con una señal
registro
completado
, junto con el índice local
y
.
b)Si el usuario
B
^ ya ha registrado al usuario
A
^ en la posición
y
^ y ha puesto ya a
1 su bit de asociación, la central de destino verifica el índice local
registrado en esa posición. Si ese índice local es igual al índice local
recibido, la central de destino responde a la central de origen como se ha
indicado en el apartado a).
c)Si el usuario
B
^ no ha registrado el número de datos
A
^ en ninguna posición, la central de destino responde a
la central de origen con una señal
registro aceptado
.
d)Si el usuario
B
^ no está abonado a la facilidad GCUB,
la central de destino responde a la central de origen con una señal de
progresión de la llamada
acceso prohibido
.
e)Si el usuario
B
^ no es accesible para el usuario
A
^ por cualquier otro motivo, la central de destino
responde a la central de origen con la correspondiente señal de progresión de
la llamada.
7.4.2.2.3 La central de origen, al recibir de la central de destino la respuesta a la petición de registro GCUB, ejecutará unas acciones que dependerán de la señal recibida.
registro completado
, la
central de origen pone a 1 el bit de asociación y registra el índice local
y
en la posición
x
en la tabla del
usuario
A
y envía a este usuario la señal de progresión de
la llamada
registro/cancelación
confirmado
, para confirmar el registro.
b)Si se ha recibido la señal
registro aceptado
, la
central de origen no efectúa un ulterior registro y envía al usuario
A
la señal de progresión de la llamada
registro/cancelación confirmado
.
c)Si se ha recibido una señal indicativa de que la central de destino ha
rechazado el registro GCUB, la central de origen anula toda la información en
la posición
x
de la tabla del usuario
A
y envía la correspondiente señal de progresión de la
llamada al usuario
A
.
7.4.2.2.4 Con los mencionados procedimientos, el registro de un GCUB queda completado cuando los dos usuarios interesados han pedido el registro del otro y han recibido respuestas positivas.
7.4.2.3
Procedimiento de cancelación
7.4.2.3.1 Al pedir la cancelación de un GCUB, el usuario
A
efectúa una petición de facilidad, que incluye el índice
local
x
. La central de origen verifica el estado de la
posición
x
de la tabla del usuario
A
.
a)Cuando se ha registrado un número de datos en la posición
x
, la central de origen envía una petición de cancelación
GCUB con número de datos
B
como dirección y que incluye el
índice local
y
y el número del usuario llamante
A
. Además, la central de origen repone a cero el bit de
asociación, si se había puesto a 1.
b)Cuando no hay número de datos registrado en la posición
x
, la central de origen devuelve al usuario
A
la señal de progresión de la llamada
registro/cancelación confirmado
.
7.4.2.3.2 Al recibir la petición de cancelación GCUB, la central de
destino verifica la tabla del usuario
B
direccionado.
a)Cuando el número de datos en la posición
y
^ de la
tabla de usuario
B
^ es igual al número de datos
A
recibido, la central de destino anula toda la
información en la posición
y
.
b)En todos los demás casos, y en particular cuando el número de datos
almacenado en la posición
y
es diferente del número de
datos
A
recibido, la central de destino no modifica
ninguna información registrada en la tabla del usuario
B
.
En los casos a) y b), la central de destino envía una señal
cancelación completada
^ a la señal de origen.
7.4.2.3.3 Al recibir la señal
cancelación completada
^
en respuesta a una petición de cancelación de GCUB, la central de origen anula
toda la información en la posición
x
de la tabla del
usuario
A
y envía a este usuario la señal de progresión de
la llamada
registro/cancelación
confirmado
.
7.4.2.3.4 Con el procedimiento mencionado, un GCUB queda cancelado cuando
cualquiera de los dos usuarios interesados ha solicitado la cancelación y ha
recibido la señal de progresión de la llamada
registro/cancelación confirmado
.
Nota
- Las posibles implicaciones de condiciones
anormales en la cancelación pueden requerir ulterior estudio.
Supervisión de la temporización en el procedimiento
de registro/cancelación
En la central de origen, en el procedimiento de registro/cancelación de facilidad, es necesario esperar la recepción de la respuesta de la central de destino, después de haberse enviado una petición de registro/cancelación de GCUB. La duración de estos periodos deberán controlarse por temporizaciones apropiadas.
Son necesarias las siguientes temporizaciones:
T1 -Tiempo transcurrrido entre el envío de la petición de registro GCUB y la recepción de una respuesta de acuerdo con el 7.4.2.2 .
T2 -Tiempo transcurrido entre el envío de la petición de cancelación GCUB y
la recepción de una señal
cancelación completada
.
A la expiración de la temporización T1 o T2, la central de origen envía al
usuario
A
^ la señal de progresión de la llamada
congestión de red
para indicarle que el registro o
cancelación solicitado no se ha producido. El usuario
A
tendrá entonces que repetir la petición de registro o cancelación.
El valor de T1 y T2 deberá ser (provisionalmente) de 5-10 segundos.
7.4.2.5
Procedimiento de establecimiento de llamada
7.4.2.5.1
Central de origen
7.4.2.5.1.1 Cuando se hace una llamada dentro de un GCUB, el usuario
llamante
A
utiliza el índice
x
como
dirección para el usuario llamado (de acuerdo con el procedimiento para la
facilidad de llamada con dirección abreviada). La central de origen verifica la
posición correspondiente al índice local
x
registrado en
la tabla del usuario llamante
A
.
a)Si el bit de asociación está puesto a 1, indicando que el GCUB está
registrado para los dos usuarios, el llamante y el llamado, la central de
origen establece la llamada hacia la central de destino utilizando el número de
datos
B
del usuario llamado, registrado en la tabla del
usuario llamante
A
. La información de control enviada por
la central de origen incluye una indicación de que se trata de una llamada
GCUB.
b)Cuando el bit de asociación no está puesto a 1, indicando así que el GCUB
no está completamente registrado, la central de origen rechaza la llamada y
envía al usuario llamante la señal de progresión de la llamada
acceso prohibido
.
7.4.2.5.1.2 Cuando un usuario que tiene la facilidad
grupo
cerrado de usuarios bilateral
hace una llamada con un
número de datos ordinario o con una dirección abreviada no registrada como
GCUB, la central de origen rechaza la llamada y envía al usuario llamante la
señal de progresión de la llamada
acceso prohibido
.
Nota
- Si el usuario pertenece también a un grupo
cerrado de usuarios (GCU), las llamadas dentro de un GCU se tratan
independientemente y no se rechazan por el hecho de existir la facilidad
grupo cerrado de usuarios bilateral
.
7.4.2.5.1.3 Cuando un usuario que tiene la facilidad
grupo
cerrado de usuario bilateral con acceso de salida
^
hace una llamada con un número de datos ordinario o con una dirección abreviada
no registrada como GCUB, la llamada se trata como una llamada con acceso de
salida y la central de origen la establece de acuerdo con el procedimiento
ordinario para el establecimiento de llamadas ordinarias.
7.4.2.5.1.4 La posibilidad de transferencia del índice local
x
^ (en sentido de ida) y del índice
y
^ (en sentido de retorno), así como la posibilidad de
verificaciones adicionales en la central de destino serán objeto de ulterior
estudio.
7.4.2.5.2
Central de tránsito
Una central de tránsito trata una llamada GCUB como una llamada ordinaria.
7.4.2.5.3
Central de destino
7.4.2.5.3.1 La central de destino, cuando recibe una llamada GCUB, puede
aceptarla sin verificar si el usuario llamado tiene la facilidad
grupo cerrado de usuarios bilateral
.
7.4.2.5.3.2 La central de destino, cuando recibe una llamada ordinaria (es
decir, distinta de una llamada GCUB) a un usuario que tiene la facilidad
grupo cerrado de usuarios bilateral
, la rechaza y responde
a la central de origen con la señal de progresión de la llamada de
acceso prohibido
.
7.4.2.5.3.3 La llamada puede rechazarse por otros motivos no relacionados
con la facilidad
grupo cerrado de usuario bilateral
. Las
llamadas de grupo cerrado de usuario pueden aceptarse independientemente de las
condiciones antes mencionadas, siempre que se cumplan los requisitos de esa
facilidad (véase el
2
).
7.4.2.5.4
Combinación de las facilidades GCUB e
identificación de la línea o el terminal
Las posibles disposiciones sobre combinaciones de las facilidades
grupo cerrado de usuario bilateral con acceso de salida
y
de las facilidades
identificación de la línea llamante
y/o
identificación de la línea llamada
, y
la forma de identificación del ETD llamante o llamado en llamadas GCUB serán
objeto de ulterior estudio.
7.4.3
Prohibición de llamadas entrantes
Prohibición de llamadas entrantes
es una facilidad
facultativa de usuario acordada por cierto periodo de tiempo. Esta facilidad se
aplica a todas las llamadas utilizadas en el interfaz ETD/ETCD.
Esta facilidad, cuando se está abonado a ella, impide que se presenten llamadas entrantes al ETD. El ETD puede originar llamadas salientes.
Nota
- Algunas Administraciones pueden proporcionar
una capacidad que permita también que una llamada sólo se presente al ETD en
aquellos casos en que la dirección llamada es la dirección del ETD llamante.
7.4.4
Prohibición de llamadas salientes
Prohibición de llamadas salientes
es una facilidad
facultativa de usuario convenida por cierto período de tiempo. Esta facilidad
se aplica a todas las llamadas utilizadas en el interfaz ETD/ETCD.
Esta facilidad de usuario, cuando se está abonado a ella, impide que el ETCD acepte llamadas salientes provenientes del ETD. El ETD puede recibir llamadas entrantes.
7.4.5
Identificación de red de usuario
Identificación de red de usuario
^ es una facilidad
facultativa de usuario convenida por un período de tiempo. Esta facilidad,
cuando se está abonado a ella, permite al ETD proporcionar a la red, llamada
por llamada, información para fines de facturación, seguridad o gestión de la
red. Esta información puede proporcionarla el ETD llamante en la fase de
petición de llamada o el ETD llamado en la fase de confirmación de llamada.
Puede utilizarse esté o no el ETD abonado a la facilidad
prevención de tarificación local
(véase el
7.2.2
). Si el ETCD determina que el identificador de
usuario de red no es válido o no está presente cuando lo requiere la red,
liberará la llamada.
La identificación de usuario de red nunca se transmite al ETD distante. La dirección del ETD llamante transmitida al ETD distante en el campo de dirección del ETD llamante no debe inferirse de la identificación de usuario de red transmitida por el ETD en la fase de petición de llamada.
El contenido y formato del parámetro identificación de usuario de red (IUR) es un asunto de incumbencia nacional.
La utilización de este elemento entre redes está sujeta a acuerdo bilateral entre Administraciones.
7.4.6
Facilidad permiso para contraordenar la
IUR
La facilidad
permiso para contraordenar la IUR
es una
facilidad facultativa de usuario convenida por un periodo de tiempo. Esta
facilidad, cuando se está abonado a ella, permite a una facilidad IUR,
presentada en la fase de petición de llamada, invocar características
comprendidas en el abono del ETD identificado por esa IUR, y asociadas con la
IUR. Las facilidades asociadas con la IUR contraordenarán las facilidades que
puedan ser aplicables al interfaz. Esta contraordenación no es aplicable a
otras llamadas existentes o posteriores en el interfaz. Sólo produce efecto
durante la llamada específica a que se aplica.
Las facilidades facultativas de usuario obtenidas por abono que pueden asociarse con una IUR son de interés en el plano nacional.
7.5
Facilidades para transportar datos de usuario
además del flujo normal de datos en la fase de
transferencia de datos
Nota
- Existen diferentes términos; en general, en las
Recomendaciones de la serie X se utiliza
`datos de usuario'
, y en las
Recomendaciones de la serie I
`información de usuario a usuario'
.
7.5.1
Generalidades
El transporte de datos de usuario además del flujo normal de datos en la fase de transferencia de datos puede considerarse en las siguientes fases de la llamada:
a)Fase de petición de llamada (del ETD llamante al llamado),
b)Fase de confirmación de llamada (del ETD llamado al llamante),
c)Fase de liberación de llamada (ETD liberante al liberado).
El soporte del transporte de datos de usuario durante estas fases se recapitula en el cuadro 7-8/X.301.
Cuadro 7-8/X.301 [T11.301], p.
Para el interfuncionamiento entre redes que proporcionan un nivel diferente
de soporte a la transferencia de datos de usuario además del flujo normal de
datos en la fase de transferencia de datos, se aplican los siguientes
principios:
a)El objetivo es que, en el futuro, todas las redes puedan transportar hasta 128 octetos de datos de usuario durante las fases de petición, confirmación y liberación de llamada, para la prestación de servicios de transmisión de datos.
b)En aquellos casos en que se solicite el transporte de datos de usuario durante estas fases, pero la red no lo admita, debe utilizarse un mecanismo de protocolo adicional, no operado por la propia red (ejemplo: utilización de procedimientos de paquetes a través de la RTPC).
c)En los casos en que no funciona, o no está previsto lo indicado en la regla b), se abortarán las llamadas de datos; se devolverá un mensaje apropiado de progresión de la llamada al ETD que inicia la fase en cuestión.
7.5.2
Selección rápida
Las facilidades facultativas de usuario que están normalizadas para diferentes servicios de transmisión de datos y se relacionan con la selección rápida se indican en el cuadro 7-9/X.301.
Cuadro 7-9/X.301 [T12.301] p.
Los ETD llamantes pueden solicitar la facilidad
selección rápida
^ llamada por llamada
por medio de una petición de facilidad adecuada en la fase de petición de
llamada.
La facilidad
selección rápida
^ permite transportar
durante la fase de petición de llamada, del ETD llamante al llamado, hasta 128
octetos de datos de usuario.
Si la facilidad
selección rápida
^ indica
`no
restricción en la respuesta'
, permitirá durante la fase de confirmación de
llamada o durante la fase de liberación de llamada, o durante ambas, el
transporte de hasta 128 octetos de datos de usuario del ETD llamado (o ETD
liberante) al ETD llamante (o ETD liberado).
Si la facilidad
selección rápida
^ indica
`restricción en la respuesta'
no se permitirá el transporte durante las
fases de confirmación de llamada y de transferencia de datos. Sin embargo, sí
se permitirá durante la fase de liberación de llamada (si es iniciada por el
ETD llamado) el transporte de hasta 128 octetos del ETD llamado al llamante.
Cuando un ETD llamante solicita una facilidad
selección
rápida
, la llamada entrante sólo deberá entregarse al ETD llamado si este
ETD está abonado a la facilidad
aceptación de selección
rápida
(véase el
7.5.3
).
Cuando un ETD llamante solicita la facilidad
selección
rápida
, y si el ETD está abonado a la facilidad
aceptación
de selección rápida
, la facilidad
selección rápida
se
transportará durante la fase de petición de llamada, del ETD llamante al
llamado, exista o no una
`restricción en la respuesta'
.
Si el ETD llamado no está abonado a la facilidad
aceptación
de selección rápida
, no se le entregará ninguna
llamada que contenga la facilidad
selección rápida
. La red
liberará tales llamadas y devolverá al ETD llamante una señal de progresión de
la llamada
no abonado a aceptación de
selección rápida
.
Nota 1
- Durante un periodo de transición, algunas
redes pueden no permitir que un ETD transmita datos de usuario en la fase de
liberación de la llamada cuando esta fase no haya sido iniciada en respuesta a
la fase de petición de llamada.
Nota 2
- Los datos de usuario transportados además del
flujo normal de datos en la fase de transferencia de datos no se fragmentarán
para la entrega a través del interfaz ETD/ETCD.
Nota 3
- El hecho de que durante la fase de
confirmación de llamada o de la fase de liberación de llamada se transmita la
señal de progresión de la llamada
`originado por el ETD'
como una
reacción directa al hecho de que en la fase de petición de la llamada se ha
utilizado la facilidad
selección
rápida
, significa que el ETD llamado ha recibido los datos
de usuario en la fase de petición de llamada.
7.5.3
Aceptación de selección rápida
La
aceptación de selección rápida
es una facilidad
facultativa de usuario convenida durante un periodo de tiempo. Esta facilidad,
cuando se está abonado a ella, autoriza al ETCD a transmitir al ETD llamado las
llamadas entrantes en que se solicita la facilidad
selección
rápida
. En ausencia de esta facilidad, el ETCD no entregará al ETD llamado
las llamadas entrantes en que se solicite la facilidad
selección rápida
.
7.6
Otras facilidades
Las demás facilidades facultativas de usuario que están normalizadas para diferentes servicios de transmisión de datos se indican en el cuadro 7-10/X.301.
Cuadro 7-10/X.301 [T13.301], p.
7.6.1
Respuesta manual
7.6.1.1
Generalidades
Respuesta manual
^ es un modo de funcionamiento del ETD
permitido por algunas redes para el servicio con conmutación de circuitos en
las RPDCC. Los ETD que funcionan de este modo, cuando son llamados, pueden
demorar la respuesta por medio de la señal
llamada
aceptada
. La central a que está conectado el usuario almacena información
indicativa de que un ETD funciona con
respuesta manual
.
7.6.1.2
Procedimiento de establecimiento de llamada
En el caso de una llamada a un ETD de usuario que funciona con
respuesta manual
, la central de destino envía la señal
terminal llamado
a la central de origen en el momento de
la conexión de la llamada. En la central de origen, esto provoca el envío, al
usuario llamante, de la señal de progresión de la llamada
terminal llamado
. Provoca también la ampliación del valor
de toda temporización aplicable a esta fase de la llamada.
La central de destino completa la llamada como llamada ordinaria cuando
recibe la señal
llamada aceptada
del usuario llamado, y
envía a la central de origen una señal indicativa de que la llamada ha sido
conectada. Si la central de destino no recibe la señal
llamada
aceptada
dentro del periodo aplicable de temporización del ETCD, después
de haber enviado al usuario llamado la señal
llamada
entrante
, liberará la llamada sin enviar en retorno ningún tipo de señal
de progresión de la llamada.
Nota
- Si la red de origen no autoriza la facilidad
llamada manual
, y el usuario llamado
opera con
llamada manual
, podrá cargar al usuario llamante
el tiempo transcurrido a partir de la recepción de la señal
terminal llamado
.
7.6.2
Conexión cuando se libere y espera permitida
7.6.2.1
Generalidades
Conexión cuando se libere
^ y
espera
autorizada
^ son facilidades facultativas de usuario asignadas al usuario
durante un periodo convenido por contrato.
Al usuario abonado a la facilidad
conexión cuando se
libere
^ se asigna cierto número de posiciones de espera en su central
local en las cuales las llamadas entrantes recibidas pueden esperar cuando
estén ocupadas la línea o líneas de acceso al abonado. La facilidad
espera autorizada
permite a un usuario llamar a otro que
esté ocupado y que tenga la facilidad
conexión
cuando se libere
con el fin de esperar a completar la
llamada cuando el usuario llamado se desocupe. Durante la espera, se mantiene
la conexión.
Estas dos facilidades dan oportunidad a los usuarios que tienen ciertas características de tráfico de datos para utilizar la red de una manera más eficaz que de ordinario, cuando se rechazan las llamadas a un abonado ocupado.
La Administración o empresa privada de explotación reconocida controlan el registro de estas facilidades.
7.6.2.2
Procedimiento de establecimiento de llamada
7.6.2.2.1 Cuando se recibe una llamada a un abonado ocupado (es decir,
cuando por lo menos una línea de acceso al usuario llamado está ocupada por una
llamada en curso) que tiene la facilidad
conexión cuando se
libere
, la central de destino verifica las posiciones de espera en el
usuario llamado.
a)Si existe una posición de espera libre, la llamada se sitúa en la cola y
se envía a la central de origen la señal
conexión cuando se
libere
.
b)Si todas las posiciones de espera están ocupadas, se rechaza la llamada y
se envía a la central de origen la señal
número
ocupado
.
La llamada puede rechazarse por otros motivos no relacionados con la
facilidad
conexión cuando se libere
.
7.6.2.2.2 La actuación de la central de origen depende de que el usuario
llamante tenga o no la facilidad de
espera autorizada
, y
de la señal recibida.
a)Si se ha recibido la señal
conexión cuando se libere
^
y el usuario llamante tiene la facilidad
espera
autorizada
, se envía al usuario llamante la señal de progresión de la
llamada
conexión cuando se libere
. El
usuario llamante podrá entonces o bien esperar la completación de la llamada o
liberarla. Si el usuario llamante opta por esperar, se mantiene la conexión,
pero no se efectúa la transconexión. La temporización normal para la
completación de la llamada en la central de origen se desactiva. El usuario
llamante no puede efectuar ni recibir otra llamada por la misma línea de acceso
durante la espera.
b)Cuando se recibe la señal
conexión cuando se libere
^
y el usuario llamante no tiene la facilidad
espera
autorizada
, se le envía la señal de progresión de la llamada
número ocupado
, y se libera la llamada.
c)Cuando se recibe la señal
número ocupado
, se envía al
usuario llamante la señal de progresión de la llamada
número
ocupado
y se libera la llamada. Se procede también de la misma manera
cuando el usuario llamante tiene la facilidad
espera
autorizada
.
7.6.2.2.3 Cuando se desocupa una línea de acceso al usuario llamado, la central de destino conecta la primera llamada en la cola, de forma normal. Se envía a la central de origen una señal indicativa de que la llamada ha sido conectada.
7.6.2.2.4 Cuando la central de origen recibe la señal indicativa de que se ha conectado la llamada, efectúa la transconexión de la llamada en la forma normal.
7.6.2.2.5 El tiempo de espera se tarifica. El usuario llamante puede enviar una petición de liberación en cualquier momento para terminar la espera, lo que produce una liberación normal por la red y la supresión de la llamada en la cola. En ciertas situaciones anormales la espera puede terminarla también la central de destino, como resultado de lo cual se produce una secuencia de liberación hacia el usuario llamante.
Nota
- La posibilidad utilización de una temporización
de red para limitar el tiempo de espera será objeto de ulterior estudio.
Selección de confirmación de recepción
7.6.3.1
Generalidades
La
selección de confirmación de recepción
es una
facilidad facultativa de usuario que permite negociar, llamada por llamada, si
las unidades de datos en recepción en la fase de transferencia de datos serán o
no confirmadas de extremo a extremo.
Nota
- Esta facilidad puede realizarse en las RPDCP y
las RDSI utilizando los procedimientos de bit
D
(véase la
Recomendación X.25).
7.6.3.2
Fases de petición de llamada y de confirmación de
llamada
El ETD llamante puede solicitar, en la fase de petición de llamada, un
acuse de recibo de extremo a extremo de la entrega de unidades de datos que se
transmitirán en la fase de transferencia de datos, para lo cual establecerá el
parámetro selección rápida a
acuse de recibo de extremo
a extremo
. Durante la fase de petición de llamada, toda
red (o parte de la misma) que intervenga en la llamada, así como el ETD
llamado, que no pueda admitir este acuse de recibo de extremo a extremo,
establecerá el parámetro selección de recepción a
`no hay acuse de recibo de
extremo a extremo'
. El valor que finalmente resulte será aplicable a la
llamada y será enviado por el ETD llamado el ETD llamante en la fase de
confirmación de llamada.
7.6.3.3
Fase de transferencia de datos
La entrega de unidades de datos al ETD receptor se confirmará al ETD emisor
si el parámetro confirmación de recepción, transportado en la fase de
confirmación de la llamada, tenía el valor
`acuse de recibo de extremo a
extremo'
.
Nota
- En algunos casos (por ejemplo, en las RPDCP),
podría aplicarse aún una confirmación de recepción de extremo a extremo en esta
fase, independientemente de la presencia de la negociación en la fase de
petición de llamada/confirmación de llamada. No obstante, las definiciones en
la Recomendación X.213 requieren también la negociación.
7.6.3.4
Fase de liberación de llamada
El acuse de recibo de extremo a extremo no es aplicable a esta fase.
7.6.4
Negociación de datos acelerados
7.6.4.1
Generalidades
La negociación de datos acelerados es una facilidad facultativa de usuario que permite negociar llamada por llamada, durante las fases de petición de llamada y de confirmación de llamada, si la transferencia de datos acelerados podrá o no aplicarse durante la fase de transferencia de datos.
7.6.4.2
Fases de petición de llamada y de confirmación de
llamada
El ETD llamante puede solicitar, en la fase de petición de llamada, la
posibilidad de utilizar procedimientos de datos acelerados en la fase de
transferencia de datos, para lo cual establece el parámetro datos acelerados a
`datos acelerados'
. Durante la fase de petición de llamada, la red (o
parte de la misma) que interviene en la llamada, así como el ETD llamado, que
no pueda admitir estos datos acelerados, establecerá el parámetro negociación
de datos acelerados a
`no hay datos acelerados'
. El valor que finalmente
resulte será aplicable a la llamada y será enviado por el ETD llamado al
llamante en la fase de confirmación de llamada.
Las redes públicas que intervienen en la llamada no están obligadas a supervisar ni a actuar sobre este parámetro: no obstante, algunas redes pueden supervisarlo si así lo desean.
7.6.4.3
Fase de transferencia de datos
Durante la fase de transferencia de datos pueden utilizarse procedimientos
de datos acelerados si el parámetro negociación de datos acelerados,
transportado en la fase de confirmación de llamada, tenía el valor
`datos
acelerados'
.
Nota
- Pueden emplearse procedimientos de datos
acelerados en la RPDCP y en la RDSI (con conmutación de paquetes) utilizando
procedimientos de paquetes de interrupción.
MONTAGE :
8
SUR LE RESTE DE CETTE PAGE
(H.T.=OUI)
TAB.???
FICHIER: H.T. =
(86.TA.271.S)
(SANS FORMULE) Tableaux: 19 - Tabulateurs: 3 ICCM: NF02/0
Anexo A
NF02/004 OPM = 03
- NF02/004 OPM = 03
Recomendación Q.701 NF02/007 OPM = 03
- NF02/007 OPM = 03
(cs,1) disque 227 NF01/017 OPM = 02
(cs,2) NF02/012 OPM = 03
(1BT) (BT..)
(86.TE.04.S)
(A1.23s) / [26s]
FOLIOS: 110 - 146
(DO PRC.COSY.2)
MEP {TPS.NON.PHOTO "[PA1]"} : OK= [1]
Saisie 31.01.89 RM/PR
ID + LASER + diskette MAJ 20.02.89 PM
Corr. LASER (1re épreuve) = 3eme 02.03.89 YB
Espaces réservés 06.03.89 PC
AJOUTER (PA1) (CL1,0,0,0) pour MEP
MEP + LASER 15.03.89 GH/PC
Corr. MEP ........ ..
Insertion des tableaux (tabulateurs 3) 15.03.89 PC
BAT 7.04.89 PM
MAJ s/disquettes 1.05.89 CD
MONTAGE: FIN DU
7.6.4.3
EN TêTE DE CETTE PAGE
8 Disposiciones sobre las
señales de progresión de la
llamada
El cuadro 8-1/X.301 indica diferentes redes que utilizan diversos conjuntos de señales de progresión de la llamada.
Cuadro 8-1/X.301 [T14.301], p.
En el caso de terminales conectados a redes públicas por conducto de redes
privadas, las señales de progresión de la llamada originadas en la red privada
se distinguen de las originadas en la red pública de datos. En la RPDCC la
señal de progresión de la llamada
`subdirección llamada'
es enviada por
la red de destino cuando ésta pasa para una llamada que contiene información de
dirección de red privada al interfaz del ETD/ETCD llamado. Toda ulterior señal
de progresión de la llamada habrá sido originada por la red privada. En las
RPDCP, se asigna una gama de codificación específica y distinta para todas las
señales de progresión de la llamada originadas en una red privada.
Las disposiciones interredes descritas en esta sección se relacionan con la transferencia a través de redes de las señales de progresión de la llamada. Pueden considerarse diferentes categorías de interfuncionamiento:
-interfuncionamiento mediante correspondencia de control de la llamada (ICCL),
-interfuncionamiento mediante acceso por puerto (IAP).
El cuadro 8-2/X.301 muestra los diferentes casos de interfuncionamiento con respecto a las señales de progresión de la llamada e indica las secciones pertinentes.
Cuadro 8-2/X.301 [T15.301], p.
8.1
Disposiciones interredes en que intervienen señales
de progresión de la llamada definidas en la Recomendación
X.96 solamente
8.1.1
Interfuncionamiento mediante correspondencia de
control de la llamada
8.1.1.1
Señales de progresión de la llamada durante el
establecimiento de la llamada
8.1.1.1.1
Señales de progresión de la llamada originadas por
el ETD llamante (fase de petición de llamada)
En el momento de la petición de llamada el ETD llamante no transmite ninguna señal de progresión de la llamada.
8.1.1.1.2
Señales de progresión de las llamadas generadas
por la RPD de origen (fase de petición de llamada)
En el momento de la petición de llamada la RPD de origen (incluido el ETCD asociado con el ETD llamante) puede tener que liberar la llamada debido a limitaciones relacionadas con el interfaz ETD/ETCD de ese ETD llamante.
8.1.1.1.2.1
Dirección incorrecta del ETD llamado en una
petición llamada
8.1.1.1.2.1.1 La RPD de origen puede recibir del ETD llamante una petición de llamada con una dirección del ETD llamado que no es correcta. Si la RPD de origen detecta esa dificultad, deberá liberar la llamada con una indicación de NO OBTENIBLE. Un posible motivo es que el IPD o el CIRD sea el asignado a la RPD de origen, pero que los dígitos restantes de la dirección no estén asignados a ningún ETD en esa RPD.
Nota 1
- La transmisión por el ETD llamante de un
prefijo nacional incorrecto (véase
2.5
de la Recomendación X.121)
debe considerarse un error de procedimiento local.
Nota 2
- La reacción de la RPD de origen a una
dirección incorrecta del ETD llamado, recibida del ETD llamante, será objeto de
ulterior estudio.
Facilidad no válida pedida por el ETD llamante
Cuando recibe del ETD llamante una petición de llamada en que se solicita una facilidad facultativa de usuario no ofrecida a ese ETD, la RPD de origen debe liberar la llamada con una indicación PETICIóN DE FACILIDAD NO VáLIDA.
Son posibles motivos:
a)petición de una facilidad a la cual no está abonado el ETD;
b)petición de una facilidad que no está disponible en la RPD de origen;
c)petición de una facilidad no reconocida como válida por la RPD de origen.
Las circunstancias precisas para tal liberación de la llamada por la RPD de origen, con indicación de petición de facilidad no válida, se indican en las Recomendaciones pertinentes de la serie X, es decir, las Recomendaciones sobre el interfaz ETD/ETCD, y las Recomendaciones sobre la señalización interredes.
Error de procedimiento en el ETD llamado,
relacionado con una petición de llamada
8.1.1.1.2.3.1 Cuando recibe una petición de llamada del ETD llamante, la RPD de origen puede detectar un error de procedimiento causado por el ETD. La RPD de origen debe liberar la llamada con una indicación ERROR DE PROCEDIMIENTO LOCAL. Las circunstancias detalladas de esos errores de procedimiento en una petición de llamada se indican en las Recomendaciones pertinentes de la serie X sobre el interfaz ETD/ETCD.
Son posibles circunstancias:
a)petición de llamada en un canal lógico que no se encuentra en el estado preparado (en el caso de un interfaz X.25);
b)referencia incorrecta de un canal lógico para la llamada (en el caso de un interfaz X.25);
c)formato incorrecto durante el establecimiento de la llamada.
Señales de progresión de la llamada generadas por
EICD (fase de petición de llamada)
En la fase de petición de llamada, un equipo internacional de conmutación de datos (EICD) que interviene en un establecimiento de llamada puede tener que liberar la llamada.
8.1.1.1.3.1
Dirección incorrecta del ETD llamado
8.1.1.1.3.1.1 En algunas llamadas, un EICD puede recibir una dirección del ETD llamado que no es compatible con el plan de numeración o no está asignada a ningún ETD en ese momento. El EICD debe liberar la llamada con una indicación NO OBTENIBLE. Son posibles motivos: IPD o CIRD llamado desconocido.
8.1.1.1.3.1.2 Sin embargo, también ha de observarse que un EICD debe, de ser posible, no transmitir al EICD siguiente una petición de llamada con una dirección de ETD llamado que no corresponda a una ruta predeterminada. Si un EICD recibe una dirección de ETD llamado que no corresponde a una ruta predeterminada, puede liberar la llamada con una indicación ACCESO PROHIBIDO.
8.1.1.1.3.2
Fallo interno de la red o congestión
8.1.1.1.3.2.1 Cuando un EICD detecta que todas las rutas adecuadas posibles, del ETD llamante al ETD llamado, a través de este EICD, están temporalmente indisponibles, el EICD liberará la llamada con una indicación CONGESTIóN EN LA RED.
8.1.1.1.3.3
Fallo interno de la red en la ruta o rutas de
tránsito
Un fallo temporal de la red puede forzar a un EICD a liberar la petición de llamada que pasa a través del mismo, con una indicación CONGESTIóN EN LA RED.
8.1.1.1.3.4
Facilidad no disponible en la ruta o rutas de
tránsito
Cuando un EICD detecta una petición de facilidad que intencionalmente no está disponible en la ruta o rutas de tránsito, liberará la llamada con una indicación DESTINO INCOMPATIBLE, o con una indicación CONGESTIóN EN LA RED en el caso de la RPDCC.
8.1.1.1.3.5
Facilidad de tarificación no disponible en la
ruta o rutas de tránsito
Cuando un EICD detecta que se piden facilidades de tarificación que intencionalmente no están disponibles en la ruta o rutas de tránsito, liberará la llamada con una indicación DESTINO INCOMPATIBLE, o con una indicación CONGESTIóN EN LA RED en el caso de la RPDCC.
8.1.1.1.3.6
Facilidad de protección de acceso no disponible
en la ruta o rutas de tránsito
Cuando un EICD detecta que se solicitan facilidades de protección de acceso que intencionalmente no están disponibles en la ruta o rutas de acceso, liberará la llamada con una indicación ACCESO PROHIBIDO.
8.1.1.1.4
Señales de progresión de la llamada generadas por
la RPD de destino (fase de petición de llamada)
En la fase de petición de llamada, la RPD de destino (incluido el ETCD asociado con el ETD llamado) puede tener que liberar la llamada debido a limitaciones relacionadas con el interfaz (ETD/ETCD de ese ETD llamado).
8.1.1.1.4.1
Interfaz ETD/ETCD no operacional
El interfaz ETD/ETCD del ETD llamado puede estar fuera de servicio. Con posibles motivos:
a)ETD no preparado no controlado,
b)Interrumpida la alimentación del ETCD,
c)Avería de la red en el bucle local,
d)El nivel 1 no funciona (X.25 solamente),
e)El nivel 2 no está en servicio (X.25 solamente).
8.1.1.1.4.1.1 Si el interfaz del ETD llamado no está funcionando, y por esa razón no se le puede transmitir una llamada entrante, la RPD de destino debe liberar la llamada con la indicación FUERA DE SERVICIO, o la RPDCC con la indicación NO PREPARADO NO CONTROLADO, INTERRUMPIDA LA ALIMENTACIóN DEL ETCD o AVERíA DE LA RED EN EL BUCLE LOCAL.
Nota
- Podrían aplicarse condiciones especiales si el
ETD llamado no está abonado a la facilidad de redireccionamiento de llamada.
8.1.1.1.4.2
Interfaz ETD/ETCD ocupado
8.1.1.1.4.2.1 Cuando la RPD de destino detecta que el ETD llamado está ocupado en otra u otras llamadas, y por tanto no puede aceptar una nueva llamada entrante, deberá liberar la llamada con la indicación NúMERO OCUPADO. Al ETD llamado no se le transmite la llamada entrante.
Nota 1
- En el caso de un interfaz X.25, algunos
canales lógicos pueden estar reservados (por ejemplo para llamadas salientes) y
no estar disponibles para llamadas entrantes (véase también el anexo B de la
Recomendación X.25). La condición de número ocupado descrita en esta sección se
aplica si al menos un canal lógico sirve de soporte a llamadas entrantes.
Nota 2
- Pueden aplicarse condiciones especiales si el
abonado llamado está abonado a la facilidad de redireccionamiento de llamada.
Nota 3
- Cuando el ETD llamado está abonado a la
facilidad de grupo de búsqueda, la condición de ocupado se da cuando todos los
canales/circuitos disponibles están ocupados en todos los interfaces ETE/ETCD
del grupo de búsqueda.
8.1.1.1.4.3
No aceptación de una facilidad por el ETD
llamado
8.1.1.1.4.3.1 Excepto en los casos especificados en los 8.1.1.1.4.3.2, 8.1.1.1.4.4 y 8.1.1.1.4.5, cuando el interfaz del ETD llamado no admite una función o facilidad solicitada en la llamada entrante, la RPD de destino deberá liberar la llamada con la indicación DESTINO INCOMPATIBLE (para la RPDCP). La llamada entrante no se transmite al ETD llamado. La señal de progresión de la llamada utilizada en la RPDCC será objeto de ulterior estudio.
Las circunstancias precisas para esa liberación de la llamada por la RPD de destino se describen detalladamente en las Recomendaciones pertinentes de la serie X sobre el interfaz ETD/ETCD.
8.1.1.1.4.4
Facilidad de tarificación específica solicitada
por el ETD llamado
8.1.1.1.4.4.1 Cuando el ETD llamado no se ha abonado a la facilidad de aceptación de cobro revertido, y si en una llamada entrante se solicita el cobro revertido, la RPD de destino deberá liberar la llamada con la indicación NO ABONADO A ACEPTACIóN DE COBRO REVERTIDO. La llamada entrante no se transmite al ETD llamado.
8.1.1.1.4.5
Condiciones específicas de protección de
acceso requeridas por el ETD llamado
8.1.1.1.4.5.1 Si hay una llamada entrante destinada a un ETD que está
abonado a la facilidad
prohibición de llamadas entrantes
,
la RPD de destino deberá liberar la llamada con la indicación ACCESO PROHIBIDO.
La llamada entrante no se transmite al ETD llamado.
a)grupo cerrado de usuarios incompatible;
b)acceso no autorizado del ETD llamante al ETD llamado. Las circunstancias precisas de estas restricciones serán objeto de ulterior estudio.
Nota
- El hecho de que no se permita al ETD llamante
la conexión con el ETD llamado puede haberse detectado antes en la parte
internacional de la ruta, en la cual se liberaría entonces la llamada. En este
caso, la RPD de destino no tiene conocimiento de la llamada entrante.
8.1.1.1.5
Señales de progresión de la llamada generadas por
el ETD llamado (fases de petición de llamada y
confirmación de llamada)
El ETD llamado puede decidir rechazar la llamada entrante. En tal situación liberará la llamada con la indicación ORIGINADO EN EL ETD (en la RPDCP). En la RPDCC, la RPD de destino puede señalizar SUBDIRECCIóN LLAMADA, después de lo cual se puede indicar una señal de progresión de la llamada en una señal de liberación procedente del ETD. Las señales de progresión de la llamada generadas por el ETD llamado se transfieren al ETD llamante.
8.1.1.1.6
Señales de progresión de la llamada generadas por
la RPD de destino (fase de confirmación de llamada)
8.1.1.1.6.1
Error de procedimiento en el ETD llamado,
relacionado con una aceptación de llamada
8.1.1.1.6.1.1 Cuando la RPD de destino está esperando una indicación LLAMADA ACEPTADA del ETD llamado, podrá detectar un error de procedimiento causado por este ETD. La red de destino deberá entonces liberar la llamada, con la indicación ERROR DE PROCEDIMIENTO LOCAL al ETD llamado, y ERROR DE PROCEDIMIENTO EN EL OTRO EXTREMO al ETD llamante. Las circunstancias precisas de estos errores de procedimiento en una indicación de llamada aceptada se describen en las Recomendaciones pertinentes de la serie X sobre el interfaz ETD/ETCD. Entre las posibles circunstancias está el formato incorrecto de la indicación LLAMADA ACEPTADA.
8.1.1.1.7
Señales de progresión de la llamada generadas por
un EICD (fase de confirmación de llamada)
Para ulterior estudio.
8.1.1.1.8
Señales de progresión de la llamada generadas por
la RPD de origen (fase de confirmación de llamada)
Para ulterior estudio.
8.1.1.1.9
Señales de progresión de la llamada resultantes de
abortar una llamada (fases de petición de llamada y de
confirmación de llamada)
Para ulterior estudio.
8.1.1.2
Señales de progresión de la llamada de liberación
durante la fase de transferencia de datos
8.1.1.2.1
Señales de progresión de la llamada de
liberación generadas por un ETD (fase de transferencia de
datos)
8.1.1.2.1.1 Cuando una liberación de llamada procede de un ETD X.25, se aplican las siguientes reglas:
8.1.1.2.1.1.1 La causa de liberación debe ser ORIGINADO POR EL ETD.
8.1.1.2.1.1.2 El ETD puede transmitir un código de diagnóstico de un octeto, que pasa sin modificación del ETD liberante al otro ETD.
8.1.1.2.1.1.2 En la RPDCC no se genera ninguna señal de progresión de la llamada cuando se inicia la liberación durante la fase de transferencia de datos.
8.1.1.2.2
Señales de progresión de la llamada de
liberación generadas por una RPD de terminación (fase de
transferencia de datos)
Después del establecimiento de la llamada, cualquiera de las RPD de terminación puede tener que liberar la llamada debido a sucesos que ocurren en el correspondiente interfaz ETD/ETCD.
8.1.1.2.2.1
Interfaz ETD/ETCD no operacional
8.1.1.2.2.1.1 Cuando un interfaz ETD/ETCD de una RPDCP deja de estar en condiciones de funcionamiento (o de ser operacional), y por tanto no puede transportar más señales para una llamada ya establecida a través de ese interfaz, la RPD de terminación puede liberar la llamada con la indicación FUERA DE SERVICIO. Son posibles dos motivos:
a)capa 1 no funcional;
b)capa 2 fuera de servicio.
Nota 1
- Las circunstancias precisas por las cuales
una RPD de terminación tendría que liberar la llamada virtual al darse la
condición fuera de servicio del interfaz ETD/ETCD serán objeto de ulterior
estudio.
Nota 2
- En el caso de los servicios con conmutación
de paquetes, la indicación básica de fuera de servicio se transmite en ambas
condiciones a) o b), pero el diagnóstico puede ser más detallado.
Nota 3
- Cuando la red está preparada para reanudar el
funcionamiento normal tras un fallo temporal o una congestión, la RPD de
terminación puede informar al ETD con una indicación RED OPERACIONAL. En el
caso de un interfaz X.25, esta información se pasa en el paquete de indicación
de rearranque.
8.1.1.2.2.2
Error de procedimiento en el interfaz
ETD/ETCD
8.1.1.2.2.2.1 Cuando se detecta un error de procedimiento causado por el ETD, en una RPDCP, que requiere la liberación de la llamada, la RPD de terminación debe liberar la llamada con la indicación ERROR DE PROCEDIMIENTO LOCAL al ETD local, y con la indicación ERROR DE PROCEDIMIENTO EN EL OTRO EXTREMO al ETD distante. Las circunstancias detalladas de esos errores de procedimiento se indican en las Recomendaciones pertinentes de la serie X sobre el interfaz ETD/ETCD (por ejemplo, formato incorrecto, expiración de una temporización).
8.1.1.2.3
Señales de progresión de la llamada generadas por
un EICD (fase de transferencia de datos)
Tras el establecimiento de la llamada, un equipo internacional de conmutación de datos (EICD) puede tener que liberar una llamada debido a algunas limitaciones en la parte de tránsito internacional de la ruta.
8.1.1.2.3.1
Fallo interno de la red o congestión
Un fallo temporal de la red o una congestión pueden obligar a un EICD a liberar la llamada que pasa a través del mismo, con una indicación CONGESTIóN EN LA RED (RPDCP solamente).
8.1.1.2.3.2
Facilidad no disponible en la ruta o rutas de
tránsito
Cuando un EICD detecta que no es posible ofrecer una facilidad en un determinado instante, libera la llamada que pasa a través del mismo, con la indicación CONGESTIóN EN LA RED (RPDCP solamente).
8.1.1.2.4
Posibles colisiones entre señales de progresión de
la llamada de liberación (fase de transferencia de
datos)
Para ulterior estudio.
8.1.1.3
Señales de colisión de la llamada de reiniciación
durante la fase de transferencia de datos
Esta sección sólo se aplica a los servicios con conmutación de paquetes, en los cuales se puede reiniciar una llamada virtual o un circuito virtual permanente.
8.1.1.3.1
Señales de progresión de la llamada de
reiniciación generadas por un ETD (fase de transferencia
de datos)
8.1.1.3.1.1 Cuando la reiniciación procede de un ETD X.25, se aplican las reglas siguientes:
8.1.1.3.1.1.1 La causa de reiniciación debe ser ORIGINADO POR EL ETD.
8.1.1.3.1.1.2 El ETD puede transmitir un diagnóstico de un octeto, que pasa sin modificación del ETD reiniciante al otro ETD.
8.1.1.3.2
Señales de progresión de la llamada de
reiniciación generadas por una RPD de terminación (fase de
transferencia de datos)
8.1.1.3.2.1 Cuando se produce un fallo en un terminal ETD/ETDC X.25, sin que sea necesaria la liberación de la llamada, la RPD de terminación puede reiniciar la llamada virtual con la indicación FUERA DE SERVICIO.
Nota
- Las circunstancias precisas, en las cuales la
RPD de terminación tendría que reiniciar la llamada virtual debido a la
condición de fuera de servicio en el interfaz ETD/ETCD, serán objeto de
ulterior estudio.
8.1.1.3.2.2 En un interfaz X.25, ciertos errores de procedimiento causados por el ETD pueden no necesitar la liberación de la llamada. La RPD de terminación debe entonces reiniciar la llamada virtual con la indicación ERROR DE PROCEDIMIENTO LOCAL al ETD local y con la indicación ERROR DE PROCEDIMIENTO EN EL OTRO EXTREMO al ETD distante. Las circunstancias detalladas de tales errores de procedimiento se indican en la Recomendación X.25.
8.1.1.3.2.3 Cuando un interfaz X.25 está preparado para reanudar la transferencia normal de datos en un circuito virtual permanente después de una condición de fallo o de fuera de servicio (por ejemplo un rearranque), la RPD terminal debe reiniciar el circuito virtual permanente con la indicación ETD DISTANTE OPERACIONAL.
8.1.1.3.3
Señales de progresión de la llamada de
reiniciación generadas por un EICD (fase de transferencia
de datos)
8.1.1.3.3.1
Fallo interno de la red o congestión
En un circuito virtual permanente, un fallo de red o una congestión pueden obligar a un EICD a enviar un paquete de reiniciación con la indicación RED FUERA DE SERVICIO a los dos terminales que intervienen.
8.1.1.3.4
Posibles colisiones entre señales de progresión de
la llamada de reiniciación (fase de transferencia de
datos)
Para ulterior estudio.
8.1.2
Interfuncionamiento mediante acceso por puerto
Para ulterior estudio.
8.2
Disposiciones interredes en que intervienen señales
de progresión de la llamada definidas en la Recomendación
Q.931 solamente
8.2.1
Interfuncionamiento mediante correspondencia del
control de la llamada
Para ulterior estudio.
8.3
Disposiciones interredes en que intervienen señales
de progresión de la llamada definidas en la Recomendación
X.699 solamente
8.3.1
Interfuncionamiento mediante correspondencia del
control de la llamada
Para ulterior estudio.
8.3.2
Interfuncionamiento mediante acceso por puerto
Para ulterior estudio.
8.4
Disposiciones interredes en que intervienen señales
de progresión de la llamada definidas en las
Recomendaciones X.96 y Q.931
8.4.1
Interfuncionamiento mediante correspondencia del
control de la llamada
Para ulterior estudio.
8.4.2
Interfuncionamiento mediante acceso por puerto
Para ulterior estudio.
8.5
Disposiciones interredes en que intervienen señales
de progresión de la llamada definidas en las
Recomendaciones X.96 y Q.699
8.5.1
Interfuncionamiento mediante correspondencia del
control de la llamada
Para ulterior estudio.
8.5.2
Interfuncionamiento mediante acceso por puerto
Para ulterior estudio.
8.6
Disposiciones interredes en que intervienen señales
de progresión de la llamada definidas en las
Recomendaciones Q.931 y Q.699
8.6.1
Interfuncionamiento mediante correspondencia del
control de la llamada
Véase la Recomendación Q.699.
APéNDICE I (a la Recomendación X.301)
Elementos de protocolos
de diferentes redes utilizados para las facilidades y
disposiciones descritas en esta Recomendación
Este apéndice describe los
elementos de protocolo de diferentes redes utilizados para las facilidades y
disposiciones descritas en esta Recomendación.
Se consideran los siguientes protocolos de acceso o combinaciones de protocolos:
I.1
Servicios de transmisión de datos con conmutación de
circuitos
RPDCCX.20, X.20^
bis
, X.21,
X.21^
bis
, X.22
RDSII.420, I.421
I.2
Servicios de transmisión de datos con conmutación de
paquetes:
RPDCPX.25, X.32 RDSIX.31 Sistemas de datos móvilesX.350/X.352
El siguiente cuadro I-1/X.301 muestra los elementos de protocolo, en cada una de las combinaciones de protocolos, utilizados en las fases de petición de llamada, confirmación de llamada y liberación de llamada que pueden utilizarse para transportar los parámetros destinados a las facilidades y disposiciones descritas en esta Recomendación.
Los siguientes cuadros recapitulan la aplicación de las disposiciones y facilidades descritas en esta Recomendación a las fases de petición, confirmación y liberación de llamada.
Convenios utilizados en los cuadros I-2/X.301 a
I-7/301:
*El parámetro de disposición o facilidad (si se solicita) será transportado (mediante elementos de protocolo indicados en el cuadro I-1/X.301).
BEl parámetro de disposición o facilidad (si se solicita) será transportado y tiene un valor booleano.
(=)El parámetro transportado tiene un valor idéntico al del parámetro suministrado por el ETD distante que inicia esta fase de la llamada.
()El parámetro transportado tiene un valor superior o igual al del parámetro suministrado por el ETD distante que inicia esta fase de la llamada.
()El parámetro transportado tiene un valor menor o igual al del parámetro
suministrado por el ETD distante que inicia esta fase de la llamada. Cuando se
trata de un valor booleano, el valor del parámetro transportado puede haber
cambiado de
verdadero
a
falso
con
respecto al valor suministrado por el ETD distante que inicia esta fase de la
llamada.
Table I-1/X.301 (plus notes) [T16.301], p.
Tableau I-2/X.301 (plus notes) [T17.301], p. 4
Tableau I-3/X.301 [T18.301], p. 5
Tableau I-4/X.301 [T19.301], p. 6
Tableau I-5/X.301 [T20.301], p. 7
Tableau I-6/X.301 [T21.301], p. 8
Tableau I-7/X.301 [T22.301], p. 9
Tableau I-8/X.301 [T23.301], p. 10
APéNDICE II (a la Recomendación X.301)
Disposiciones para el
soporte del servicio de red ISA
Este apéndice enumera las disposiciones y
facilidades descritas en la presente Recomendación que pueden utilizarse para
la prestación del servicio de red ISA normalizado en la Recomendación X.213.
(Será objeto de ulterior estudio.)
DESCRIPCIóN DE LAS DISPOSICIONES GENERALES PARA LAS
UTILIDADES DE RED INTERNAS A UNA SUBRED Y LAS UTILIDADES
INTERMEDIAS ENTRE SUBREDES PARA LA PRESTACIóN DE SERVICIOS
DE TRANSMISIóN DE DATOS
(antes, parte del proyecto de Recomendación X.300,
Málaga-Torremolinos, 1984, modificada en Melbourne, 1988)
El CCITT,
considerando
(a)que la Recomendación X.300 define los principios generales para el interfuncionamiento entre redes públicas de datos y entre éstas y otras redes para la prestación de servicios de transmisión de datos;
(b)que la Recomendación X.301 define las disposiciones generales para el control de la llamada dentro de una subred y entre subredes para la prestación de servicios de transmisión de datos;
(c)que debe considerarse el interfuncionamiento con la red de señalización por canal común (RSCC) con vista de las exigencias de la transferencia de información de explotación entre Administraciones;
(d)la necesidad de que las subredes interconectadas puedan comunicar las utilidades internas necesarias relacionadas con la prestación de los servicios de transmisión de datos;
(e)que las Recomendaciones X.61, X.70, X.71 y X.75 ya especifican los procedimientos detallados aplicables al control de la llamada entre dos RPD del mismo tipo;
(f)la necesidad de disposiciones para el interfuncionamiento entre subredes;
(g)la necesidad, en particular, de ciertas utilidades interredes definidas entre sistemas de conmutación internacional para la prestación de servicios de transmisión de datos;
(h)la necesidad de compatibilidad y uniformidad de principio para la realización de utilidades de red internas a una subred y entre subredes para la prestación de servicios de transmisión de datos,
recomienda por unanimidad
que las disposiciones sobre las utilidades internas a una subred y entre subredes para la prestación de servicios de transmisión de datos, y los elementos necesarios para la realización de esas utilidades internas de red sean conformes a los principios y disposiciones especificados en esta Recomendación.
íNDICE
0
Introducción
1
Objeto y campo de aplicación
2
Referencias
3
Definiciones
4
Abreviaturas
5
Aspectos generales del control de la llamada
6
Disposiciones sobre utilidades internas de red
6.1Identificación de red
6.1.1Generalidades 6.1.2Identificación de la red de origen 6.1.3Identificación de la red de destino 6.1.4Identificación de red de tránsito 6.1.5Identificación de la red liberante
6.2Identificador de llamada
6.3Parámetros de calidad de servicio deseada
6.4Tarifas
6.5Identificación del usuario de la red
0 Introducción
Esta Recomendación forma parte de un conjunto de Recomendaciones elaboradas
para facilitar la consideración del interfuncionamiento entre redes. Se
relaciona con la Recomendación X.300, que define los principios generales para
el interfuncionamiento entre redes públicas de datos y entre éstas y otras
redes para la prestación de servicios de transmisión de datos. La Recomendación
X.300 indica en particular combinaciones de equipo físico que pueden
representarse como
`subredes'
para la consideración de situaciones de
interfuncionamiento.
Esta Recomendación describe utilidades que pueden emplearse dentro de una subred y entre subredes para la prestación de servicios de transmisión de datos. Sólo se describen las utilidades que se necesitan para la operación interna o entre redes, y que no son visibles por los usuarios de extremo de la llamada. Las facilidades que son (también) visibles por los usuarios de extremo de la llamada se especifican en otras Recomendaciones (por ejemplo, las disposiciones descritas en la Recomendación X.301).
1 Objeto y campo de aplicación
Esta Recomendación tiene por objeto describir disposiciones generales sobre utilidades internas de red aplicables al interfuncionamiento en la capa de red. Estas disposiciones no son visibles por los usuarios de la conexión de capa de red y se aplican dentro de una subred y entre subredes.
Estas disposiciones no son aplicables al interfuncionamiento que comprende las capacidad de comunicación descrita en el 7 de la Recomendación X.300.
2
Referencias
X.61Sistema de señalización N.o 7 - Parte Usuario de Datos.
X.70Sistema de señalización de control terminal y de tránsito para servicios arrítmicos en circuitos internacionales entre redes anisócronas de datos.
X.71Sistema de señalización descentralizada de control terminal y de tránsito para circuitos internacionales entre redes síncronas de datos.
X.75Sistemas de señalización con conmutación de paquetes entre redes públicas que prestan servicios de transmisión de datos.
X.121Plan de numeración internacional para redes públicas de datos.
X.300Principios generales de interfuncionamiento entre redes públicas y entre éstas y otras redes para la prestación de servicios de transmisión de datos.
X.301Descripción de las disposiciones generales para el control de la llamada dentro de una subred y entre subredes para la prestación de servicios de transmisión de datos.
3
Definiciones
Esta Recomendación utiliza los siguientes términos definidos en la Recomendación X.300:
a)capacidad de transmisión;
b)capacidad de comunicación;
c)servicios de transmisión de datos.
Esta Recomendación utiliza los siguientes términos definidos en la Recomendación X.301:
a)fase de petición de la llamada;
b)fase de confirmación de llamada;
c)fase de transferencia de datos;
d)fase de liberación de llamada.
4
Abreviaturas
@CICDCentral (o centro) internacional de conmutación de datos\
@CIRDCódigo de identificación de red de datos\
@CIRICódigo de identificación de red RDSI\
@CIRLCódigo de identificación de la red liberante\
@ETCDEquipo de terminación del circuito de datos\
@ETDEquipo terminal de datos\
@IPDIndicativo de país para datos\
@IRIdentificador de red\
@IURIdentificación de usuario de red\
@RDSIRed digital de servicios integrados\
@RPDRed pública de datos\
@RPDCCRed pública de datos con conmutación de circuitos\
@RPDCPRed pública de datos con conmutación de paquetes\
@RSCCRed de señalización por canal común.\
5 Aspectos generales
Las utilidades de red descritas en esta Recomendación pueden aplicarse para el funcionamiento interno de la red y para disposiciones entre redes, y no se transmiten a través del interfaz ETD/ETCD.
Los principios generales sobre las señales interredes se definen en la Recomendación X.301, en particular las fases relacionadas con la llamada.
-fase de petición de llamada y de confirmación de llamada,
-fase de transferencia de datos,
-fase de liberación de llamada.
El modelo correspondiente aplicable a las disposiciones entre redes se reproduce en las figuras 5-1/X.302 y 5-2/X.302.
Figura 5-1/X.302, p.
Figura 5-2/X.302, p.
6 Disposiciones sobre utilidades de red
internas
6.1
Identificación de red
6.1.1
Generalidades
Las utilidades
identificación de red
^ internacionales
proporcionan información sobre la red o redes desde, vía, o a las cuales se
encamina una llamada internacional. En el caso general, el término
identificador de red (IR) es el nombre del número que identifica a una red.
Según el tipo de red y la ubicación geográfica de la misma, el formato de IR
puede variar.
Una RPD (véase la nota) se identifica por cuatro dígitos (o cifras) decimales que indican:
a)en el caso de la red de un país que utiliza el formato IPD del plan de numeración internacional de datos (véase la Recomendación X.121), el IPD aplicable más un dígito de acuerdo con el plan de numeración;
b)en el caso de una red que utiliza el formato CIRD del plan de numeración internacional de datos (véase la Recomendación X.121), el CIRD aplicable.
A corto plazo, una RDSI se identifica por un CIRI de cuatro cifras (código de identificación de red RDSI), que ha sido designado para que no coincida con un valor de RPD de CIRD válido (véase la Recomendación X.75).
Nota
- La solución a largo plazo para la
identificación de la red (IR) requiere ulterior estudio.
6.1.2
Identificación de la red de origen
La utilidad
identificación de la red de origen
^
identifica la red de origen de una llamada.
En el servicio de transmisión de datos con conmutación de paquetes en las
RPDCP, la identidad de la red de origen (CIRD) se transfiere en la fase de
petición de llamada a la red de destino como parte del número de datos
internacional (véase la Recomendación X.75). Para realizar la función de la
utilidad
identificación de la red de origen
, este CIRD,
que forma parte del número de datos internacional, siempre es insertado o
comprobado por la red de origen.
La provisión de
identificación de la red de origen
^
como una utilidad facultativa de red a petición de una red de tránsito o de
destino, llamada por llamada, es obligatoria en el servicio de transmisión de
datos con conmutación de circuitos.
En el caso de la señalización por canal común (véase la Recomendación
X.61), una red que necesita la identificación de la red de origen solicita
dicha identificación devolviendo una indicación de petición
identificación de la red de origen
. Al recibir esta
petición la red de origen responde enviando:
a)la identidad de la línea llamante, completa, de acuerdo con el
6.2.4
de la Recomendación X.301 cuando la red de origen proporciona
la facilidad
identificación de la línea llamante
y se ha
pedido también tal identificación;
b)la identidad de la red de origen cuando no se proporciona, o no se pide,
identificación de la línea llamante
.
En el caso de la señalización descentralizada (véase las Recomendaciones
X.70 y X.71), una red que necesita la identificación de la red de origen
solicita tal identificación devolviendo una identificación de petición de
identificación de la línea llamante
. Al recibir esta
petición, la red de origen responde con la identidad de la línea llamante o con
la identidad de la red de origen, lo que dependerá de que la red de origen
proporcione o no la facilidad
identificación de la línea
llamante
(véase el
6.2.4
de la Recomendación X.301).
6.1.3
Identificación de la red de
destino
La utilidad
identificación de la red de destino
^
identifica la red de destino de una llamada.
En el servicio de transmisión de datos con conmutación de circuitos en las
RPDCC, la
identificación de la red de destino
para todas
las llamadas internacionales es una utilidad de red obligatoria. Así, para cada
llamada internacional, la identidad de la red de destino se devuelve de acuerdo
con los procedimientos de señalización aplicables (véanse las Recomendaciones
X.61, X.70 y X.71).
En el servicio de transmisión de datos con conmutación de paquetes, la identidad de la red de destino (CIRD) puede transferirse en la fase de confirmación de llamada a la red de origen como parte del número de datos internacional (véase la Recomendación X.75). Una vez transferido, este CIRD debe ser insertado o comprobado por la red de destino.
6.1.4
Identificación de red de tránsito
La utilidad
identificación de red de tránsito
^
identifica la red o redes de tránsito a través de las cuales se ha establecido
la llamada, y se transporta durante la fase de petición de llamada.
En el servicio de transmisión de datos con conmutación de paquetes en las
RPDCP y las RDSI, la
identificación de red de tránsito
,
tanto en sentido de ida como de retorno, es una utilidad de red obligatoria en
las llamadas internacionales (véase la Recomendación X.75).
En el servicio de transmisión de datos con conmutación de circuitos en las RPDCC, la identificación de red de tránsito en ambos sentidos es una utilidad de red obligatoria en las llamadas internacionales (véanse las Recomendaciones X.61, X.70 y X.71).
Cuando se identifica más de una red de tránsito, las identidades se indican en el orden en que las redes de tránsito son atrevesadas por la llamada siguiendo el trayecto establecido desde el usuario llamante hasta el usuario llamado.
6.1.5
Identificación de la red liberante
La utilidad
código de identificación de la red
liberante
^ (CIRL) identifica la red que ha liberado la llamada y sólo se
utiliza cuando una red ha iniciado la fase de liberación de la llamada durante
la fase de transferencia de datos.
En el servicio de transmisión de datos con conmutación de paquetes en las RPDCP y las RDSI, el CIRL es una utilidad facultativa de red, sujeta a acuerdos bilaterales entre las Administraciones (véanse las Recomendaciones X.75).
La red que inicia la fase de liberación de la llamada es identificada en las RPD y las RDSI por el IR (véanse las Recomendaciones X.75 y X.121). Una CICD que recibe un CIRL pasará este código sin modificación siempre que sea aplicable.
6.2
Identificador de llamada
La utilidad identificador de llamada proporciona la identificación de una llamada. Cuando esta utilidad se emplea junto con la dirección del ETD llamante, identifica inéquivocamente la llamada durante un período de tiempo cuya duración será objeto de ulterior estudio. Esta utilidad está normalizada para el servicio de transmisión de datos con conmutación de paquetes en las RPDCP y las RDSI (véase la Recomendación X.75).
Se puede o no crear un identificador de llamada significativo para una determinada llamada (véase también la nota 2). Esto es responsabilidad de la red de origen. Cada red de tránsito transferirá siempre sin modificación un identificador de llamada significativo. La definición del contenido del identificador de llamada, así como una definición más precisa del mecanismo de señalización asociado, requieren ulterior estudio.
Nota 1
- Sin embargo, se estudiará con mayor amplitud
si una red puede crear un identificador de llamada significativo cuando haya
recibido un identificador de llamada que no sea significativo.
Nota 2
- En los enlaces diseñados de conformidad con
la Recomendación X.75, hay siempre una utilidad de identificador de llamada de
4 octetos presente en el paquete de petición de llamada. El valor del parámetro
de identificador de llamada de 3 octetos puede o no ser significativo.
En el servicio de circuito vital permanente, el identificador de llamada puede necesitarse sistemáticamente. Sin embargo, esto ha quedado para ulterior estudio.
6.3
Parámetros de calidad de servicio
deseada
Se ha dejado para ulterior estudio si se requiere o no una utilidad de red para señalizar información relacionada con la obtención de los parámetros de la calidad de servicio deseada (por ejemplo, el retardo de tránsito deseado), para fines de red fuera del control de un usuario (véase también el 7.1 de la Recomendación X.301).
6.4
Tarifas
La utilidad
tarifas
^ es una utilidad facultativa,
normalizada para las RPDCP y RDSI. El soporte de esta utilidad para un interfaz
entre redes dado está sujeto a un acuerdo bilateral entre las Administraciones.
Esta utilidad se emplea para transmitir información de una red a otra u otras redes participantes en la llamada con el propósito de aplicar los acuerdos de facturación, contabilidad o tarifas que puedan existir entre las respectivas Administraciones.
La utilidad
tarifas
^ puede aparecer en las fases de
petición de llamada, confirmación de llamada y petición de liberación de
llamada. Si esta utilidad aparece en las fases de confirmación de llamada o de
petición de liberación, la información que contiene se relaciona con el
interfaz de destino final de la red. La utilidad puede aparecer en la fase de
petición de liberación, únicamente si dicha fase la inicia el ETD o el ETCD de
destino como respuesta directa a la fase de petición de llamada.
El contenido de esta utilidad está determinado por la red de origen o de destino y no depende de la información transmitida a la red por el ETD.
Incluso si esta utilidad es soportada en el interfaz entre redes, puede no estar presente en una fase de una llamada dada, si no es necesario intercambiar información relativa a la tarifa en dicha fase.
6.5
Identificación de usuario de la red
(IUR)
La utilidad
identificación de usuario de la red
^ es
una utilidad facultativa de la red normalizada para las RPDCP y las RDSI. El
uso de esta utilidad está sujeto a acuerdos bilaterales entre las
Administraciones.
Esta utilidad puede estar presente en la fase de petición de llamada. Su uso en la fase de confirmación de llamada será objeto de ulterior estudio.
Según acuerden las Administraciones interconectadas, el campo de parámetro de esta utilidad que aparece en la fase de petición de llamada puede contener:
a)la totalidad, parte o nada del campo de parámetro de la facilidad de selección de IUR transmitida a la red por el ETD en la fase de petición de llamada, y/o
b)un código de identificación/verificación/seguridad adecuado, generado por la red, y relacionado con el correspondiente usuario de extremo.
FUNCIONALIDADES DE SUBRED RELACIONADAS CON EL SOPORTE
DEL SERVICIO DE RED ISA EN EL MODO CON CONEXIóN
(Melbourne, 1988)
El CCITT,
considerando
(a)que la Recomendación X.200 define el modelo de referencia de la interconexión de sistemas abiertos para aplicaciones del CCITT;
(b)que la Recomendación X.213 es la definición del servicio de red para la interconexión de sistemas abiertos para aplicaciones del CCITT;
(c)que la Recomendación X.300 define los principios generales para el interfuncionamiento entre redes públicas, y entre éstas y otras redes para el suministro de servicios de transmisión de datos, y que la Recomendación X.300 indica en particular la forma en que los distintos equipos reales de una red pueden representarse como subredes;
(d)que es necesario considerar diferentes tipos de subredes, todos los cuales suministran el servicio de red con conexión ISA en diferentes grados, y que es necesario describir las diversas formas en las cuales los diferentes tipos de subredes suministran el servicio de red con conexión de la ISA,
recomienda por unanimidad
(1)que la descripción de las funcionalidades de una subred que se relacionan con la fase de establecimiento de la conexión del servicio de red con conexión ISA sea la indicada en el 6 ;
(2)que la descripción de las funcionalidades de una subred que se relacionan con la fase de liberación de la conexión del servicio de red con conexión ISA sea la indicada en el 7 ;
(3)que la descripción de las funcionalidades de una subred que se relacionan con la fase de transferencia de datos del servicio de red con conexión ISA sea la indicada en la 8 .
íNDICE
0
Introducción
1
Objeto y campo de aplicación
2
Referencias
3
Definiciones
4
Abreviaturas
5
Visión de conjunto y características generales
6
Fase de establecimiento de la conexión
7
Fase de liberación de la conexión
8
Fase de transferencia de datos
Anexo A
-Funcionalidad relacionada con la fase de
transferencia de datos del servicio de red con conexión de la ISA en los
diferentes tipos de subredes.
Anexo B
-Conjuntos de protocolos para el suministro del
servicio de red con conexión ISA a través de diferentes ejemplos de subredes.
0 Introducción
Esta Recomendación forma parte de un conjunto de Recomendaciones elaboradas
para facilitar la consideración del interfuncionamiento entre redes. Está
relacionada con la Recomendación X.300, que define los principios generales del
interfuncionamiento entre redes públicas de datos, y entre éstas y otras redes
para la provisión de servicios de transmisión de datos. La Recomendación X.300
indica en particular cómo las colecciones de equipos físicos pueden
representarse como
`subredes'
para el estudio de situaciones de
interfuncionamiento.
Esta Recomendación describe las funcionalidades de subredes que se relacionan con el suministro del servicio de red con conexión ISA.
La presente Recomendación no describe las funcionalidades de subredes que no se relacionan con el suministro del servicio de red con conexión ISA (por ejemplo, las disposiciones de la Recomendación X.301 que no se relacionan con el suministro del servicio de red con conexión ISA).
1 Objeto y campo de aplicación
Esta Recomendación define las funcionalidades de subredes que se relacionan con el servicio de red con conexión ISA en base a:
a)las acciones y sucesos que se producen en el interfaz con una subred;
b)los parámetros asociados con cada acción y suceso, y la forma que adoptan;
c)las relaciones entre estas acciones y sucesos, así como la secuencia válida de los mismos, para una determinada conexión;
d)las relaciones entre diferentes conexiones establecidas a través de la misma subred.
Esta Recomendación define también las formas en que diferentes tipos de subredes suministran el servicio de red con conexión ISA, incluyendo en la subred una parte o la totalidad de las funcionalidades de subredes que se relacionan con el servicio de red con conexión ISA.
El objetivo principal de esta Recomendación consiste en proporcionar orientaciones para el examen del interfuncionamiento entre subredes, en relación con el suministro del servicio de red con conexión ISA.
Esta Recomendación no especifica productos ni realizaciones de esas funcionalidades en equipos de red reales, ni restringe la distribución de esas funcionalidades entre los distintos equipos de red considerados en una determinada subred (por ejemplo, redes públicas de datos, unidades de interfuncionamiento, RDSI, etc.).
2
Referencias
Recomendación I.430-Interfaz usuario-red básico - Especificación de la capa 1
Recomendación I.431-Interfaz usuario-red a velocidad primaria - Especificación de la capa 1
Recomendación T.70-Servicio de transporte básico independiente, de la red para los servicios telemáticos
Recomendación Q.701-Descripción funcional del sistema de señalización (parte de transferencia de mensajes)
Recomendación Q.702-Enlace de datos de señalización
Recomendación Q.703-Enlace de señalización
Recomendación Q.704-Funciones y mensajes en la red de señalización
Recomendación Q.705-Estructura de la red de señalización
Recomendación Q.706-Calidad de señalización de la parte de transferencia de mensajes
Recomendación Q.707-Pruebas y mantenimiento
Recomendación Q.711-Descripción funcional de la parte control de la conexión del sistema de señalización N.o 7
Recomendación Q.712-Definición y funciones de los mensajes de la parte control de la conexión de señalizacion
Recomendación Q.713-Formatos y códigos de la parte control de la conexión de señalización (PCCS)
Recomendación Q.714-Procedimientos de la parte control de la conexión de señalización
Recomendación Q.921-Especificación de la capa de enlace de datos del interfaz usuario-red de la RDSI
Recomendación Q.931-Especificación de la capa 3 del interfaz usuario-red de la RDSI
Recomendación X.21-Interfaz entre el equipo terminal de datos (ETD) y el equipo de terminación del circuito de datos (ETCD) para funcionamiento síncrono en redes públicas de datos
Recomendación X.25-Interfaz entre el equipo terminal de datos (ETD) y el equipo de terminación del circuito de datos (ETCD) para equipos terminales que funcionan en el modo paquete y conectados a redes públicas de datos por circuitos especializados
Recomendación X.75-Sistema de señalización con conmutación de paquetes entre redes públicas que prestan servicios de transmisión de datos
Recomendación X.200-Modelo de referencia de interconexión de sistemas abiertos para aplicaciones del CCITT
Recomendación X.213-Definición del servicio de red para la interconexión de sistemas abiertos para aplicaciones del CCITT
Recomendación X.223-Utilización de la Recomendación X.25 para el suministro del servicio de red con conexión ISA
Recomendación X.300-Principios generales de interfuncionamiento entre redes públicas de datos, y entre éstas y otras redes para la prestación de servicios de transmisión de datos
Recomendación X.301-Descripción de las disposiciones generales para el control de la llamada dentro de una subred y entre subredes para la prestación de servicios de transmisión de datos.
3
Definiciones
3.1 Esta Recomendación utiliza los siguientes términos definidos en la Recomendación X.200:
a)conexión de red;
b)capa de red;
c)servicio de red;
d)subred.
3.2 Esta Recomendación utiliza también los siguientes términos definidos en la Recomendación X.213:
a)usuario de servicio de red llamante;
b)usuario de servicio de red llamado.
3.3 Esta Recomendación utiliza también los siguientes términos definidos en la Recomendación X.300:
a)subred de tipo I;
b)subred de tipo II;
c)subred de tipo III;
d)subred de tipo IV.
3.4
Convenios
Las flechas utilizadas en las figuras de los 6 a 8 indican de una manera genérica el intercambio de información en el interfaz de la subred. Su propósito no es representar las primitivas de SR transportadas a través del interfaz horizontal abstracto entre la capa de red y la capa de transporte.
4
Abreviaturas
@CARCapa de red\
@CCConmutación de circuitos\
@CDSCalidad de servicio\
@CPConmutación de paquetes\
@CRConexión de red\
@ETDEquipo terminal de datos\
@FIFFunción de interfuncionamiento\
@ISAInterconexión de sistemas abiertos\
@LAPBProcedimiento de acceso al enlace equilibrado\
@MTPParte transferencia de mensajes\
@PCCSParte control de la conexión de señalización\
@PCPProtocolo de la capa paquete\
@PSRParte servicio de red\
@RDCPRed de datos con conmutación de paquetes\
@RDSIRed digital de servicios integrados\
RPDCCRed pública de datos con conmutación de circuitos
RPDCPRed pública de datos con conmutación de paquetes
RSCCRed de señalización por canal común
RTPCRed telefónica pública conmutada
SRServicio de red
SMSSistemas del servicio móvil por satélite
SRCCServicio de red con conexión.
5 Descripción de conjunto y
características generales
5.1 Las funcionalidades de una subred incluyen la provisión de la transferencia transparente de datos entre dos interfaces con la subred, por una conexión de red (CR). Puede existir más de una CR entre un mismo par de interfaces.
Nota 1
- La medida en que una subred puede soportar
más de una conexión (CR) entre el mismo par de interfaces puede depender de los
tipos de subredes; asimismo, la medida en que una subred puede soportar
conexiones (CR) simultáneas entre un determinado interfaz con una subred y
otros interfaces distintos puede depender de los tipos de subredes (véase
también la figura 5-1/X.305).
Figura 5-1/X.305, p.
Nota 2
- Además, los interfaces con la subred pueden
utilizar bien el mismo protocolo, bien protocolos diferentes, según la
naturaleza del sistema asociado a ese interfaz (por ejemplo; X.25 si se trata
de un ETD, X.75 si se trata de otra subred).
5.2 Dentro de una subred, el soporte del servicio de red con conexión ISA puede comprender las funcionalidades de esa subred realizadas:
-en las capas 1, 2 y 3; o
-en las capas 1 y 2; o
-en la capa 1 solamente.
Esto puede depender del tipo de subred considerado.
Puede depender también de la fase en que se encuentre la conexión de red (es decir, establecimiento de la conexión, liberación de la conexión, transferencia de datos), así como del elemento del servicio de red con conexión considerado en esa fase.
Figura 5-2/X.305, p.
6
Fase de establecimiento de la
conexión
6.1 Las funcionalidades de una subred que se relacionan con la fase de establecimiento de la conexión del servicio de capa de red ISA corresponden a las siguientes acciones y sucesos en los interfaces con la subred:
a)
Petición de conexión
, con los siguientes parámetros:
-Dirección llamada,
-Dirección llamante,
-Selección de confirmación de recepción (véase la nota 1),
-Selección de datos acelerados (véase la nota 1),
-Conjunto de parámetros de CDS (véase la nota 2),
-Datos de usuario de SR (véase la nota 3).
b)
Indicación de conexión
, con los siguientes
parámetros:
-Dirección llamada,
-Dirección llamante,
-Selección de confirmación de recepción (véase la nota 1),
-Selección de datos acelerados (véase la nota 1),
-Conjunto de parámetros de CDS (véase la nota 2),
-Datos de usuario de SR (véase la nota 3).
c)
Respuesta de conexión
, con los siguientes parámetros:
-Dirección respondedora,
-Selección de confirmación de recepción (véase la nota 1),
-Selección de datos acelerados (véase la nota 1),
-Conjunto de parámetros de CDS (véase la nota 2),
-Datos de usuario de SR (véase la nota 3).
d)
Confirmación de conexión
, con los siguientes
parámetros:
-Dirección respondedora,
-Selección de confirmación de recepción (véase la nota 1),
-Selección de datos acelerados (véase la nota 1),
-Conjunto de parámetros de CDS (véase la nota 2),
-Datos de usuario del SR (véase la nota 3).
Nota 1
- Opción del proveedor del SR.
Nota 2
- La utilización de la negociación del retardo
de tránsito requiere un estudio ulterior con urgencia, con el objeto de tener
una realización armonizada en los diferentes tipos de subredes. Debe prestarse
especial atención a las consecuencias para el encaminamiento y la tasación.
Nota 3
- El objetivo es hacer que éste sea un
parámetro obligatorio admitido por todas las redes en el futuro. Sin embargo,
cierto número de redes existentes no pueden admitirlo en ese momento. Durante
el periodo de transición, mientras existan estas redes y no hayan sido
modificadas para que lo proporcionen, este parámetro se considerará una opción
del proveedor. No se necesita un mecanismo de negociación en el servicio de red
con conexión. La limitación, en algunas redes, de la longtiud de los datos de
usuario SR que ha de proporcionarse, a un valor inferior a 128 octetos (por
ejemplo de 16 a 32 octetos) durante cierto periodo de transición implicaría
menos cambios en los interfaces y sistemas de señalización existentes y
simplificaría la introducción de ese servicio en las subredes existentes.
6.2 En relación con la prestación del servicio de red con conexión ISA, se espera que las diversas acciones y sucesos en los interfaces con la subredes, que se describen en el 6.1 , se producirán en la secuencia descrita en el 11 de la Recomendación X.213. En particular, se espera que un establecimiento de conexión correcto sea conforme a la figura 6-1/X.305:
Figura 6-1/X.305 p.
6.3 En relación con el suministro del servicio de red con conexión ISA, se
espera que los parámetros enumerados en el
6.1
se traten de la
manera descrita en el
12
de la Recomendación X.213.
6.4 Los elementos de una fase de establecimiento de la conexión del servicio de red con conexión ISA son suministrados por los diferentes tipos de subredes de la manera siguiente:
a)
Subredes de tipo I y de tipo II
Las funcionalidades de las subredes de tipo I y de tipo II incluyen todos los elementos descritos en los 6.1 a 6.3.
b)
Subredes de tipo III
Las funcionalidades de las subredes de tipo III no incluyen todos los elementos descritos en los 6.1 a 6.3.
Nota
- En algunos casos (por ejemplo, subredes de tipo
III), la inclusión de algunos elementos descritos en los
6.1
a 6.3
en las funcionalidades de la subred requiere ulterior estudio.
c)
Subredes de tipo IV
Las funcionalidades de las subredes del tipo IV incluyen, bien todos los elementos descritos en los 6.1 a 6.3, bien un subconjunto de esos elementos solamente.
7 Fase de liberación de la conexión
7.1 Las funcionalidades de una subred que se relacionan con la fase de liberación de la conexión del servicio de red con conexión ISA corresponden a las siguientes acciones y sucesos en los interfaces con la subred:
a)
Petición de desconexión
, con los siguientes
parámetros:
-Motivo,
-Datos de usuario SR (véase la nota),
-Dirección respondedora.
b)
Indicación de desconexión
, con los siguientes
parámetros:
-Originador,
-Motivo,
-Datos de usuario RS (véase la nota),
-Dirección respondedora.
Nota
- El objetivo es hacer que éste sea un parámetro
obligatorio, admitido por todas las subredes en el futuro. Sin embargo, cierto
número de subredes existentes no pueden proporcionarlo en estos momentos.
Durante el periodo de transición, mientras estas subredes existan y no se hayan
modificado para proporcionarlo, este parámetro se considera una opción del
proveedor. No se necesita un mecanismo de negociación en el servicio de red con
conexión.
7.2 En relación con la prestación del servicio de red con conexión ISA, se espera que las diversas acciones y sucesos en los interfaces con la subred, que se describren en el 7.1 , se produzcan en la secuencia descrita en el 11 de la Recomendación X.213. En particular, se espera que una liberación de conexión iniciada por un usuario SR se ajuste a la figura 7-1/X.305:
Figura 7-1/X.305 p.
7.3 En relación con el suministro del servicio de red con conexión ISA, se
espera que los parámetros enumerados en el
7.1
sean operados como se
describe en el
13
de la Recomendación X.213.
7.4 Los diferentes tipos de subredes apoyan los elementos de una fase de liberación de conexión del servicio de red con conexión ISA, de la manera siguiente:
a)
Subredes de tipo I y de tipo II
Las funcionalidades en las subredes de tipo I y de tipo II incluyen todos los elementos descritos en los 7.1 a 7.3.
b)
Subredes de tipo III
Las funcionalidades en las subredes de tipo III no incluyen todos los elementos descritos en los 7.1 a 7.3.
Nota
- En algunos casos (por ejemplo, el tipo III), la
inclusión de algunos elementos descritos en los
7.1
a 7.3 en las
funcionalidades de la subred requiere ulterior estudio.
c)
Subredes de tipo IV
Las funcionalidades en las subredes de tipo IV incluyen, bien todos los elementos descritos en los 7.1 a 7.3, bien un subconjunto de esos elementos solamente.
8
Fase de transferencia de
datos
8.1 Las funcionalidades de una subred que se relacionan con la fase de transferencia de datos del servicio de capa de red ISA corresponden a las siguientes acciones y sucesos en los interfaces con la subred:
a)
Petición de DATOS
, con los siguientes parámetros:
-datos de usuarios SR,
-petición de confirmación (véase la nota).
b)
Indicación de DATOS
, con los siguientes parámetros:
-datos usuario de red,
-petición de confirmación (véase la nota).
c)
Petición de REINICIACIóN
, con los siguientes
parámetros:
-Motivo.
d)
Indicación de REINICIACIóN
, con los siguientes
parámetros:
-Originador,
-Motivo.
e)
Respuesta de REINICIACIóN
, sin ningún parámetro.
f)
Confirmación de REINICIACIóN
, sin ningún parámetro.
g)
Petición de DATOS ACELERADOS
(véase la nota).
h)
Indicación de DATOS ACELERADOS
(véase la nota).
Nota
- Las opciones del proveedor SR, cuando se
proporcionan en una subred, conducirían a acciones y sucesos adicionales.
8.2 En relación con el suministro del servicio de red con conexión ISA, se espera que las diversas acciones y sucesos de los interfaces con la subred, que se describen en el 8.1 , se produzcan en la secuencia conforme a los 11 y 14 de la Recomendación X.213
8.3 Además, se espera que los parámetros enumerados en 8.1 se traten como se indica en el 14 de la Recomendación X.213.
8.4 Se espera que las condiciones de control de flujo aplicables a una conexión sean las descritas en el 9.2 de la Recomendación X.213 (modelo de una conexión de red).
Figura 8-1/X.305 p.
Figura 8-2/X.305 p.
Figura 8-3/X.305 p.
8.5 Los diferentes tipos de subredes apoyan los elementos de una fase de
transferencia de datos del servicio de red ISA de la manera siguiente:
a)
Subredes de tipo I
Las funcionalidades de las subredes de tipo I incluyen todos los elementos descritos en los 8.1 a 8.4 (véase también el anexo A).
Las funciones y protocolos requeridos para completar el soporte de los SRCC ISA residen entonces en una subred, y en los sistemas asociados a la subred.
b)
Subredes de tipo II o III
Las funcionalidades de las subredes de tipo II o III incluyen algunos elementos descritos en los 8.1 a 8.4 (véase también el anexo A).
Esos elementos corresponden al suministro de una conexión física.
Las funciones y protocolos requeridos para completar el soporte del SRCC ISA residen entonces en sistemas asociados a la subred, y no son operados dentro de ésta.
c)
Subredes de tipo IV
Las funcionalidades de las subredes de tipo IV incluyen algunos de los elementos descritos en los 8.1 a 8.4 (véase también el anexo A).
Esta subred puede efectuar cierto tipo de paquetización o entramado, sin proporcionar todos los elementos obligatorios requeridos para el soporte del SRCC ISA.
Las funciones y protocolos requeridos para completar el soporte del SRCC ISA residen entonces en sistemas asociados a la subred, y no son operados dentro de ésta.
ANEXO A (a la Recomendación X.305)
Funcionalidad relacionada
con la fase de transferencia de datos del servicio de red
con conexión en los diferentes tipos de subredes
Cuadro A-1/X.305 [T1.305] p.
ANEXO B (a la Recomendación X.305)
Conjuntos de
protocolos para el suministro del servicio de red con
conexión ISA a través de diferentes ejemplos de subredes
Generalidades
El anexo B presenta algunos ejemplos de subredes (de tipo I, tipo II y tipo III) indicando posibles conjuntos de protocolos de las capas 1 a 3 para el suministro del servicio de red con conexión ISA (SRCC ISA) a través de esos ejemplos de subredes (véase el cuadro B-1/X.305).
Cuadro B-1/X.305 [T2.305] p.
B.2
RSCC
La figura B-1/X.305 muestra la representación de subred para el examen de posibles conjuntos de protocolos destinados a proporcionar el SRCC ISA en el caso de una RSCC.
Figura B-1/X.305, p.
El posible conjunto de protocolos para proporcionar el SRCC ISA relacionado
con esta representación se muestra en la figura B-2/X.305.
Figura B-2/X.305 [T3.305], p.
B.3
RPDCC
Las partes a) y b) de la figura B-3/X.305 muestran la representación de subred para el examen de posibles conjuntos de protocolos para el suministro del SRCC ISA en el caso de una RPDCC.
Figures B-3/X.305, p.
Las partes a) y b) de la figura B-4/X.305 muestran los posibles conjuntos de
protocolos para proporcionar el servicio de capa de red ISA relacionado con
esta representación.
Figura B-4/X.305 [T4.305], p.
B.4
RDSI (se solicita un portador CC)
La figura B-5/X.305 muestra la representación de subred para el examen de posibles conjuntos de protocolos para proporcionar el SRCC ISA en el caso de una RDSI cuando se solicita un portador con conmutación de circuitos (CC).
Figure B-5/X.305 p.
La figura B-6/X.305 muestra un posible conjunto de protocolos para
proporcionar el SRCC ISA relacionadado con esta representación.
Nota
- Serán objeto de ulterior estudio otros posibles
conjuntos de protocolos para proporcionar el SRCC ISA.
Figure B-6/X.305 [T5.305], p.
B.5
RDSI (se solicita un portador CP)
La figura B-7/X.305 muestra la representación de subred para el examen de posibles conjuntos de protocolos para proporcionar el SRCC ISA en el caso de una RDSI cuando se solicita un portador con conmutación de paquetes (CP).
Figura B-7/X.305 p.
Las partes a) y b) de la figura B-8/X.305 muestran los posibles conjuntos de
protocolos para proporcionar el SRCC ISA relativo a esta representación.
Figures B-8/X.305 [T6.305], p.
B.6
Sistemas de datos móviles
Las partes a) y b) de la figura B-9/X.305 muestran la representación de subred para el examen de posibles conjuntos de protocolos para proporcionar el SRCC ISA en el caso de sistemas de datos móviles.
Figures B-9/X.305 p.
Las partes a) y b) de la figura B-10/X.305 muestran los posibles conjuntos de
protocolos para proporcionar el SRCC ISA relacionado con esta representación.
Figures B-10/X.305 [T7.305], p.
B.7
Redes privadas
La representación de la subred para el examen de los posibles conjuntos de protocolos para proporcionar el SRCC ISA en el caso de redes privadas depende del tipo de red privada que se utilice. Para el caso de las RDCP privadas (véase el Î B.8). Para el caso de las RDSI privadas (véanse los Î B.4 y B.5).
B.8
RPDCP
La figura B-11/X.305 muestra la representación de subred para el examen de posibles conjuntos de protocolos para proporcionar el SRCC ISA en el caso de una RPDCP.
Figura B-11/X.305 p.
La figura B-12/X.305 muestra el posible conjunto de protocolos para
proporcionar el SRCC ISA relacionado con esta representación.
Figura B-12/X.305 [T8.305], p.
B.9
RTPC
La figura B-13/X.305 muestra la representación de subred para el examen de posibles conjuntos de protocolos para proporcionar el SRCC ISA en el caso de una RTPC.
Figura B-13/X.305 p.
La figura B-14/X.305 muestra el posible conjunto de protocolos para
proporcionar el SRCC ISA relacionado con esta representación.
Figura B-14/X.305 [T9.305], p.
(H.T.=OUI)
TAB.???
FICHIER: H.T. =
(86.TA.272.S)
(SANS FORMULE) Tableaux: 10 Tabulateurs: 1 - (a)
(1BT) (BT..)
(86.TE.05.S)
(A1.23s) / [26s]
FOLIOS: 146 - 188 (AS)
(DO PRC.COSY.2)
MEP {TPS.NON.PHOTO "[PA1]"} : OK= [1]
Saisie 06.02.89 RM
ID + LASER + diskette MAJ 17.02.89 BM
Corr. LASER (1re épreuve) = 3eme ........ ..
Espaces réservés 6.03.89 PC
AJOUTER (PA1) (CL1,0,0,0) pour MEP
MEP + LASER 15.03.89 GH/PC
Corr. MEP ........ ..
Insertion des tableaux (tabulateurs 1) 15.03.89 PC
BAT 14.04.89 PM
MAJ s/disquettes 1.05.89 CD
Recomendación X.320
DISPOSICIONES GENERALES PARA EL INTERFUNCIONAMIENTO
ENTRE REDES DIGITALES DE SERVICIOS INTEGRADOS (RDSI)
PARA LA PRESTACIóN DE SERVICIOS DE TRANSMISIóN DE
DATOS
(Melbourne, 1988)
El CCITT,
considerando
(a) que la Recomendación X.300 define los principios generales para el interfuncionamiento entre redes públicas, y entre éstas y otras redes para la prestación de servicios de transmisión de datos;
(b) que la Recomendación X.301 define las disposiciones generales para el control de la llamada dentro de una subred y entre subredes para la prestación de servicios de transmisión de datos;
(d) que la Recomendación X.75 ya especifica procedimientos detallados aplicables al control de la llamada entre redes públicas que prestan servicios de transmisión de datos;
(e) que la Recomendación X.10 describe categorías de acceso a las RDSI para la prestación de servicios de transmisión de datos;
(f) que la Recomendación X.213 especifica la definición del servicio de red para la interconexión de sistemas abiertos para aplicaciones del CCITT;
(g) que la Recomendación X.305 describe funcionalidades de subredes relacionadas con el soporte del servicio de red ISA;
(h) que la Recomendación I.520 describe los requisitos del interfuncionamiento RDSI-RDSI en el caso de servicios de transmisión de datos y de servicios que no son de transmisión de datos,
(i) la necesidad de disposiciones en el caso del interfuncionamiento entre RDSI para la prestación de servicios de transmisión de datos;
recomienda por unanimidad
que las disposiciones para el interfuncionamiento entre RDSI para la prestación de servicios de transmisión de datos estén de acuerdo con los principios y las disposiciones especificadas en esta Recomendación.
Introducción
1
Objeto y campo de aplicación
2
Referencias
3
Definiciones
4
Abreviaturas
5
Aspectos generales
6
Disposiciones específicas de interfuncionamiento
0 Introducción
Esta Recomendación forma parte de un conjunto de Recomendaciones elaboradas
para facilitar el análisis del interfuncionamiento de las redes. Se basa en la
Recomendación X.300, que define los principios generales del
interfuncionamiento entre redes públicas y entre éstas y otras redes para la
prestación de servicios de transmisión de datos. La Recomendación X.300 indica
en particular cómo colecciones de equipo físico pueden representarse como
`subredes'
para su consideración en situaciones de interfuncionamiento.
Esta Recomendación describe las disposiciones de interfuncionamiento entre redes digitales de servicios integrados para la prestación de servicios de transmisión de datos.
1 Objeto y campo de aplicación
Esta Recomendación tiene por objeto describir las disposiciones generales para el interfuncionamiento entre redes digitales de servicios integrados (RDSI) para la prestación de servicios de transmisión de datos. Estas disposiciones sólo son aplicables al interfuncionamiento que implica capacidades de transmisión, y no al interfuncionamiento que implica capacidades de comunicación, descritas en la Recomendación X.300.
Nota
- La tipificación de subredes en esta
Recomendación se basa en el soporte del servicio de red en modo conexión de ISA
y, por lo tanto, sólamente es válida en este contexto.
2
Referencias
[1]Recomendación X.300
[2]Recomendación X.301
[3]Recomendación X.302
[4]Recomendación X.305
[5]Recomendación X.31
[6]Recomendación X.75
[7]Recomendación X.1
[8]Recomendación X.2
[9]Recomendación X.10
[10]Recomendaciones de la serie I.230 Recomendaciones de la serie I.250
[11]Recomendación I.500
[12]Recomendación X.121
[13]Recomendación X.122
[14]Recomendación E.164
[15]Recomendación E.166
3
Definiciones
Esta Recomendación utiliza los siguentes términos definidos en la Recomendación X.300:
a)capacidad de transmisión,
b)capacidad de comunicación,
c)funcionalidad de subred,
d)servicio de transmisión de datos,
e)interfuncionamiento por control de la llamada,
f)interfuncionamiento mediante acceso por puerto.
Esta Recomendación utiliza los siguientes términos definidos en las Recomendaciones de la serie I.230:
a)servicio portador con conmutación de circuitos,
b)servicio portador de circuito virtual con conmutación de paquetes.
4
Abreviaturas
@ATAdaptador de terminal\
@CIRLCódigo de identificación de la red liberante\
@CIRTCódigo de identificación de red de tránsito\
@ETEquipo terminal\
@ETDEquipo terminal de datos\
@FIFFunción de interfuncionamiento\
@GCUGrupo cerrado de usuarios\
@GCU/AS o GCUASGrupo cerrado de usuarios con acceso de salida\
@RDSIRed digital de servicios integrados\
@RPDCPRed pública de datos con conmutación de paquetes\
@SMSSistema del servicio móvil por satélite\
@SS N.o 7Sistema de señalización N.o 7\
5 Aspectos generales
Esta Recomendación, al describir las disposiciones de interfuncionamiento entre dos subredes para la prestación de servicios de transmisión de datos, se inspira en los principios generales de la Recomendación X.300. Los entornos de estas dos subredes se describen en las secciones que siguen.
5.1
RDSI
La RDSI puede proporcionar servicios de transmisión de datos con conmutación de circuitos y/o con conmutación de paquetes/servicios portadores como se indica en las Recomendaciones X.1, las de la serie I.230 y X.2.
Nota
- En las Recomendaciones de la serie I.250 se
describen servicios suplementarios/facilidades facultativas de usuario para el
funcionamiento en modo circuito por la RDSI. La Recomendación X.2 se aplica
solamente a los servicios de transmisión de datos con conmutación de paquetes
por la RDSI/servicios portadores.
Para la prestación de servicios de transmisión de datos, los ETD/ET pueden ganar acceso a la RDSI por las categorías de acceso S, T, U definidas en la Recomendación X.10 y/o los métodos de acceso definidos en las Recomendaciones de la serie I.230. Además, se puede ganar acceso a la RDSI a través de otras redes tales como la RTPC (Recomendación I.530), RPDCC (Recomendación X.10 categoría B, y X.321), RPDCP (Recomendación X.325 y X.10 categorías C, D), SMS (Recomendación X.324) o RDSI (SS N.o 7, Recomendación X.75, X.10 categoría Y, esta Recomendación).
Nota
- En el contexto de esta Recomendación, y con
vista a la prestación de servicios de transmisión de datos solamente, se
consideran las siguientes categorías de servicios portadores definidos en las
Recomendaciones de la serie I.230. (Otras serán objeto de ulterior estudio.):
a)64 kbit/s, modo circuito, sin restricciones, estructurado a 8 kHz;
b)64 kbit/s, modo circuito, estructurado a 8 kHz, utilizable para transferencia de información de conversación;
c)64 kbit/s, modo circuito, estructurado a 8 kHz, utilizable para transferencia de información audio de 3,1 kHz;
d)llamada virtual y circuito virtual permanente.
5.2
Control de la llamada entre RDSI y
RDSI
Las disposiciones generales para el control de la llamada y las RDSI se definen en la Recomendación X.301. Las utilidades de red invisibles por el usuario utilizadas entre RPDCP y la RDSI se definen en la Recomendación X.302. En las Recomendaciones de la serie I.250 se especifican servicios suplementarios/facilidades facultativas de usuario para el funcionamiento en modo circuito de la RDSI.
5.3
Funcionalidades de la RDSI
Las funcionalidades de diferentes tipos de subredes se describen en la Recomendación X.305. Cuando se utiliza una RDSI para proporcionar un servicio/servicio portador de transmisión de datos con conmutación de circuitos y otra RDSI para proporcionar un servicio/servicio portador de transmisión de datos con conmutación de paquetes, la funcionalidad de las dos RDSI es diferente. En consecuencia, para hacer posible el interfuncionamiento deberán aplicarse procedimientos a través del servicio portador con conmutación de circuitos, para conseguir la compatibilidad funcional. Cuando las dos RDSI se utilizan para proporcionar un servicio/servicio portador de transmisión de datos con conmutación de paquetes, o cuando ambas redes se utilizan para proporcionar un servicio/servicio portador de transmisión de datos con conmutación de circuitos, las RDSI son funcionalmente compatibles.
Cuadro 1/X.320 [T1.320], p.
6
Disposiciones específicas de
interfuncionamiento
De acuerdo con la descripción de la Recomendación X.300, se deben distinguir las siguientes clases de interfuncionamiento:
a)Interfuncionamiento entre RDSI cuando cada una de ellas utiliza un portador con conmutación de paquetes.
b)Interfuncionamiento entre RDSI cuando cada una de ellas utiliza un portador con conmutación de circuitos.
c)Interfuncionamiento entre RDSIs cuando cada una de ellas utiliza un portador con conmutación de paquetes y la otra un portador con conmutación de circuitos:
1)Interfuncionamiento por relación de correspondencia para el control de la llamada.
2)Interfuncionamiento mediante acceso por puerto.
6.1
Interfuncionamiento entre RDSI cuando en cada una
de ellas se solicita un portador con conmutación de
paquetes
Los procedimientos detallados para el interfuncionamiento por relación de correspondencia para el control de la llamada se definen en la Recomendación X.75 (véase la figura 1/X.320). La utilización de otras Recomendaciones será objeto de ulterior estudio. En particular se aplica lo siguiente:
Figura 1/X.320, p.
6.1.1
Transferencia de información de direccionamiento
La RDSI utiliza típicamente el plan de numeración E.164. Las consideraciones sobre la transferencia de información de direccionamiento E.164 en X.75 se indican en la Recomendación X.301.
6.1.2
Disposiciones sobre facilidades relacionadas con la
CDS de la llamada
Estas disposiciones son las descritas en la Recomendación X.301.
6.1.3
Disposiciones sobre facilidades relacionadas con las
condiciones de tarificación aplicables a la llamada
Estas disposiciones se describen en la Recomendación X.301.
6.1.4
Disposiciones sobre facilidades relacionadas con
las condiciones específicas de encaminamiento solicitadas
por el usuario de la llamada
Estas disposiciones se describen en la Recomendación X.301.
6.1.5
Disposiciones sobre facilidades relacionadas con el
mecanismo de protección solicitado por el usuario de la
llamada
Estas disposiciones son las descritas en la Recomendación X.301. En particular, para las facilidades de GCU y de GCU/AS debe aplicarse el mecanismo de código de enclavamiento descrito en la Recomendación X.180.
6.1.6
Disposiciones sobre facilidades destinadas a
transportar datos de usuario además del flujo de datos
normales en la fase de transferencia de datos
Estas disposiciones se describen en la Recomendación X.301.
6.1.7
Disposiciones sobre otras facilidades
Estas disposiciones se describen en la Recomendación X.301.
6.1.8
Disposiciones sobre las utilidades internas de red
(invisibles por los usuarios)
Estas disposiciones se describen en la Recomendación X.302. En particular se aplican los siguientes mecanismos para la identificación de las redes:
-la RDSI se identifica por el método de la Recomendación X.302.
6.2
Interfuncionamiento entre RDSI cuando cada una de
ellas solicita un portador con conmutación de
circuitos
Los procedimientos detallados para el interfuncionamiento se definen en la parte usuario RDSI del Sistema de señalización N.o 7 (véase la figura 2/X.320). En particular se aplica lo siguiente:
Figura 2/X.320, p.
6.2.1
Transferencia de información de direccionamiento
Las RDSI utilizan típicamente el plan de numeración E.164. Las consideraciones sobre la transferencia de información de direccionamiento se exponen en la Recomendación X.301.
6.2.2
Disposiciones sobre aplicaciones relacionadas con la
CDS de la llamada
Estas disposiciones se describen en la Recomendación X.301.
6.2.3
Disposiciones sobre facilidades relacionadas con las
condiciones de tarificación aplicables a la llamada
Estas disposiciones se describen en la Recomendación X.301.
6.2.4
Disposiciones sobre facilidades relacionadas con
condiciones específicas de encaminamiento solicitadas por
el usuario de la llamada
Estas disposiciones se describen en la Recomendación X.301.
6.2.5
Disposiciones sobre facilidades relacionadas con
mecanismos de protección solicitados por el usuario de la
llamada
Estas disposiciones se describen en la Recomendación X.301.
6.2.6
Disposiciones sobre facilidades destinadas a
transportar datos de usuario además del flujo de datos
normales en la fase de transferencia de datos
Estas disposiciones se describen en la Recomendación X.301.
6.2.7
Disposiciones sobre otras facilidades
Estas disposiciones se describen en la Recomendación X.301.
6.2.8
Disposiciones sobre utilidades internas de red
Estas disposiciones se describen en la Recomendación X.302.
6.3
Interfuncionamiento entre RDSI cuando una de
ellas utiliza un portador con conmutación de paquetes y la
otra un portador con conmutación de circuitos
6.3.1
Interfuncionamiento por relación de correspondencia
para el control de la llamada
Figura 3/X.320, p.
A fin de hacer posible el interfuncionamiento, los procedimientos deben ser
operados a través del portador con conmutación de circuitos RDSI para asegurar
la capacidad funcional. Sin embargo, estos procedimientos han quedado para
ulterior estudio. En general, se aplica lo siguiente:
-Las dispopsiciones de control de la llamada en el caso de la RDSI con conmutación de circuitos (es decir, I.420, o el protocolo SS N.o 7 funcionalmente idéntico, o un protocolo interno de red funcionalmente idéntico) debe hacerse corresponder, en la FIF, con las disposiciones de control de la llamada en el caso de la RDSI con conmutación de paquetes (es decir X.75 o un protocolo interno de red funcionalmente idéntico). Esta relación de correspondencia queda para ulterior estudio.
-Las disposiciones de transferencia de datos en el caso de la RDSI con conmutación de paquetes (es decir X.75 o un protocolo interno de red funcionalemnte idéntico) debe hacerse corresponder, en la FIF, con los procedimientos operados a través del portador con conmutación de circuitos entre la FIF y el ET/ETD. Esta relación de correspondencia ha quedado para ulterior estudio.
6.3.2
Interfuncionamiento mediante acceso por
puerto
Figura 4/X.320, p.
A fin de hacer posible el interfuncionamiento, los procedimientos tienen que
ser operados a través del portador con conmutación de circuitos RDSI, para
asegurar la compatibilidad funcional. Estos procedimientos son conformes a la
Recomendación X.25 (véanse las Recomendaciones X.31 y X.10 categoría Y). Son
aplicables ciertos aspectos de la X.32, como se indica en la X.31.
En general, se aplica lo siguiente:
-X.75, o un protocolo interno de red funcionalmente idéntico, es operado entre la RDSI con conmutación de paquetes y la FIF.
-I.420, o PU-RDSI, o un protocolo interno de red funcionalmente idéntico es operado entre la RDSI con conmutación de circuitos y la FIF, y utilizado para controlar el portador con conmutación de circuitos.
-X.25 es operado entre la FIF y el ETD/ET a través del portador con conmutación de circuitos RDSI.
Consideraciones sobre la
`marcación de salida'
:
Se establecerá un portador con conmutación de circuitos a través de la RDSI al recibirse un paquete de petición de llamada X.75; se procede de la manera siguiente:
-El número de la parte llamada Q.931 (y la subdirección, si se ha suministrado) se obtiene a partir del paquete de petición de llamada X.75.
-La capacidad portadora Q.931 se codifica como modo circuito.
-Después de establecido el portador con conmutación de circuitos se establece una conexión de enlace y la FIF hace corresponder el paquete de petición de llamada X.75 con un paquete de llamada entrante X.25.
-Los procedimientos restantes se describen detalladamente en la Recomendación X.31.
Consideraciones sobre la
`marcación de llegada'
:
Se establecerá un portador con conmutación de circuitos a través de la RDSI; se procede de la manera siguiente:
-El número de la parte llamada Q.931 es la dirección de la FIF (dirección de un puerto).
-La capacidad portadora Q.931 se codifica como modo circuito.
-Después de establecido el portador con conmutación de circuitos, se establece una conexión de enlace.
-La FIF hace corresponder un paquete de petición de llamada X.25 con un paquete de petición de llamada X.75.
-Se aplican entonces los procedimientos descritos en la Recomendación X.31.
DISPOSICIONES GENERALES SOBRE EL INTERFUNCIONAMIENTO
ENTRE REDES PúBLICAS DE DATOS CON CONMUTACIóN DE
CIRCUITOS (RPDCC) Y REDES DIGITALES DE
SERVICIOS INTEGRADOS (RDSI) PARA LA PRESTACIóN
DE SERVICIOS DE TRANSMISIóN DE DATOS
(Melbourne, 1988)
El CCITT,
considerando
(a) que la Recomendación X.300 define los principios generales para el interfuncionamiento entre redes públicas, y entre éstas y otras redes para la prestación de servicios de transmisión de datos;
(b) que la Recomendación X.301 define las disposiciones generales para el control de la llamada dentro de una subred y entre subredes para la prestación de servicios de transmisión de datos;
(c) que la Recomendación X.302 define las disposiciones generales sobre las utilidades internas de red, en una subred y entre subredes para la prestación de servicios de transmisión de datos;
(d) que la Recomendación X.75 ya especifica procedimientos detallados aplicables al control de la llamada entre redes públicas que proporcionan servicios de transmisión de datos;
(e) que la Recomendación X.10 describe categorías de acceso a las RDSI para la prestación de servicios de transmisión de datos;
(f) que la Recomendación X.213 describe la definición del servicio de red para la interconexión de sistemas abiertos para aplicaciones del CCITT;
(g) que la Recomendación X.305 describe funcionalidades de subredes relacionadas con el soporte del servicio de red ISA;
(h) la necesidad de disposiciones en el caso del interfuncionamiento entre RDSI y RPDCC para la prestación de servicios de transmisión de datos,
recomienda por unanimidad
que las disposiciones sobre el interfuncionamiento entre RPDCC y RDSI para la prestación de servicios de transmisión de datos sean conformes a los principios y disposiciones específicas en esta Recomendación.
íNDICE
0
Introducción
1
Objeto y campo de aplicación
2
Referencias
3
Definiciones
4
Abreviaturas
5
Aspectos generales
6
Disposiciones específicas de interfuncionamiento
0 Introducción
Esta Recomendación forma parte de un conjunto de Recomendaciones elaboradas
para facilitar el análisis del interfuncionamiento de las redes. Se basa en la
Recomendación X.300, que define los principios generales del
interfuncionamiento entre redes públicas y entre éstas y otras redes para la
prestación de servicios de transmisión de datos. La Recomendación X.300 indica
en particular cómo colecciones de equipo físico pueden representarse como
`subredes'
para su consideración en situaciones de interfuncionamiento.
Esta Recomendación describe las disposiciones de interfuncionamiento entre redes digitales de servicios integrados para la prestación de servicios de transmisión de datos.
1 Objeto y campo de aplicación
Esta Recomendación tiene por objeto describir las disposiciones generales para el interfuncionamiento entre redes digitales de servicios integrados (RDSI) para la prestación de srevicios de transmisión de datos. Estas disposiciones sólo son aplicables al interfuncionamiento que implica capacidades de transmisión, y no al interfuncionamiento que implica capacidades de conmutación, descritas en la Recomendación X.300.
Nota
- La tipificación de subredes en esta
Recomendación se basa en la prestación del servicio de red en modo conexión de
ISA y, por lo tanto, solamente es válida en este contexto.
2
Referencias
[1]Recomendación X.300
[2]Recomendación X.301
[3]Recomendación X.302
[4]Recomendación X.305
[5]Recomendación X.31
[6]Recomendación X.75
[7]Recomendación X.1
[8]Recomendación X.2
[9]Recomendación X.10
[10]Recomendaciones de la serie I.230 Recomendaciones de la serie I.250
[11]Recomendación I.500
[12]Recomendación X.121
[13]Recomendación X.122
[14]Recomendación E.164
[15]Recomendación E.166
3
Definiciones
Esta Recomendación utiliza los siguientes términos definidos en la Recomendación X.300:
a)capacidad de transmisión,
b)capacidad de comunicación,
c)funcionalidad de subred,
d)servicio de transmisión de datos.
Esta Recomendación utiliza los siguientes términos definidos en la Recomendación I.211:
a)circuito portador con conmutación de circuitos,
b)servicio portador de circuito virtual con conmutación de paquetes.
4
Abreviaturas
ATAdaptador de terminal
CIRLCódigo de identificación de la red liberante
CIRTCódigo de identificación de red de tránsito
ETEquipo terminal
ETDEquipo terminal de datos
FIFFunción de interfuncionamiento
GCUGrupo cerrado de usuarios
GCU/AS (o GCUAS)Grupo cerrado de usuarios con acceso de salida
RDSIRed digital de servicios integrados
RPDCPRed pública de datos con conmutación de paquetes
SMSSistema del servicio móvil por satélite
SS N.o 7Sistema de señalización N.o 7
5 Aspectos generales
Esta Recomendación, al describir las disposiciones de interfuncionamiento entre dos subredes para la prestación de servicios de transmisión de datos, se inspira en los principios generales de la Recomendación X.300. Los entornos de estas dos subredes se describen en las secciones que siguen. Véase también el cuadro 1/X.321.
5.1
RPDCC
La RPDCC proporciona servicios de transmisión de datos con conmutación de circuitos como se prescribe en las Recomendaciones X.1 y X.2 para la prestación de servicios de transmisión de datos; los ETD pueden ganar acceso a la RPDCC mediante la categoría de acceso B definida en la Recomendación X.10. Se puede ganar acceso a la RDSI también por otras redes como la RPDCP (X.10 categorías C, D y X.75), SMS (Recomendación X.75), y RDSI (esta Recomendación). El acceso de las redes privadas a la RPDCC será objeto de ulterior estudio (véase la Recomendación X.300).
5.2
RDSI
La RDSI puede proporcionar servicios de transmisión de datos con conmutación de circuitos y/o con conmutación de paquetes/servicios portadores como se indica en las Recomendaciones X.1, las de la serie I.230 y X.2.
Nota
- En las Recomendaciones de la serie I.250 se
describen servicios suplementarios/facilidades facultativas de usuario para el
funcionamiento en modo circuito por la RDSI. La Recomendación X.2 se aplica
solamente a los servicios de transmisión de datos con conmutación de paquetes
por la RDSI/servicios portadores.
Para la prestación de servicios de transmisión de datos, los ETD/ET pueden ganar acceso a la RDSI por las categorías de acceso S, T, U definidas en la Recomendación X.10 y/o los métodos de acceso definidos en las Recomendaciones de la serie I.230. Además, se puede ganar acceso a la RDSI a través de otras redes tales como la RTPC (Recomendación I.530), RPDCC (Recomendación X.10 categoría B, y esta Recomendación), RPDCP (Recomendación X.325 y X.10 categorías C, D), SMS (Recomendación X.324) o RDSI (SS N.o 7, Recomendación X.75 y X.10 categoría Y).
Nota
- En el contexto de esta Recomendación, y con
vista a la prestación de servicios de transmisión de datos solamente, se
consideran las siguientes categorías de servicios portadores definidos en las
Recomendaciones de la serie I.230. (Otras serán objeto de ulterior estudio):
a)64 kbit/s, modo circuito, sin restricciones, estructurado a 8 kHz;
b)64 kbit/s, modo circuito, estructurado a 8 kHz, utilizable para transferencia de información de conversación;
c)64 kbit/s, modo circuito, estructurado a 8 kHz, utilizable para transferencia de información audio de 3,1 kHz;
d)llamada virtual y circuito virtual permanente.
5.3
Control de la llamada entre RPDCC y RDSI
Las disposiciones generales para el control de la llamada entre la RPDCC y la RDSI se definen en la Recomendación X.301. Las utilidades de red invisibles por el usuario utilizadas entre RPDCC y la RDSI se definen en la Recomendación X.302. En las Recomendaciones de la serie I.250 se especifican servicios suplementarios/facilidades facultativas de usuario para el funcionamiento en modo circuito de la RDSI.
5.4
Funcionalidades de la RDSI
Las funcionalidades de diferentes tipos de subredes se describen en la Recomendación X.305. Cuando se utiliza la RDSI para proporcionar un servicio/servicio portador de transmisión de datos con conmutación de paquetes, la funcionalidad de la RPDCC y la de la RDSI pueden ser diferentes. En consecuencia, para hacer posible el interfuncionamiento deberán aplicarse procedimientos a través del servicio portador con conmutación de circuitos en la RPDCC para conseguir la compatibilidad funcional. Cuando se utiliza la RDSI para proporcionar un servicio/servicio portador de transmisión de datos con conmutación de circuitos, la RPDCC y la RDSI son funcionalmente compatibles.
Cuadro 1/X.321 [T26], p.
6
Disposiciones específicas de
interfuncionamiento
Como se indica en la Recomendación X.300, deben distinguirse los siguientes casos de interfuncionamiento:
a)Interfuncionamiento entre la RPDCC y la RDSI cuando se utiliza un portador con conmutación de paquetes.
b)Interfuncionamiento entre la RPDCC y la RDSI cuando se utiliza un portador con conmutación de circuitos.
6.1
Interfuncionamiento entre la RPDCC y la RDSI
cuando se solicita un portador con conmutación de
paquetes
Los procedimientos detallados para el interfuncionamiento se definen en la Recomendación X.75. Véase la figura 1/X.321. En particular se aplica lo siguiente:
6.1.1
Transferencia de información de direccionamiento
La RDSI y la RPDCC utilizan típicamente planes de numeración diferentes (esto es, E.164 y X.121 respectivamente). Son aplicables las consideraciones contenidas en la Recomendación X.301 sobre la transferencia de informaciones de direccionamiento de los dos tipos diferentes. Otros aspectos específicos del interfuncionamiento entre los dos planes de numeración en cuestión se describen detalladamente en las Recomendaciones E.166 y X.122.
Figura 1/X.321, p.
6.1.2
Disposiciones sobre facilidades relacionadas con la CDS
de la llamada
Estas disposiciones se describen en la Recomendación X.301. Sin embargo, en cuanto a la facilidad de caudal, la RDSI y la RPDCC admiten diferentes clases de caudal (64 kit/s). Cuando se solicita de la RDSI una clase de caudal superior a 48 kbit/s, la solicitud debe negociarse, en orden descendente, hasta la clase más baja soportada por la RPDCC.
6.1.3
Disposiciones sobre facilidades relacionadas con las
condiciones de tarificación aplicables a la llamada
Para ulterior estudio.
6.1.4
Disposiciones sobre facilidades relacionadas con
condiciones específicas de encaminamiento solicitadas por
el usuario
Para ulterior estudio.
6.1.5
Disposiciones sobre facilidades relacionadas con el
mecanismo de protección solicitado por el usuario de la
llamada
Estas disposiciones se describen en la Recomendación X.301. En particular, en lo que respecta a las facilidades GCU y GCU/AS, se aplicará el mecanismo de código de enclavamiento descrito en la Recomendación X.180.
6.1.6
Disposiciones sobre facilidades destinadas a
transportar datos de usuario además del flujo de datos
normales en la fase de transferencia de datos
Para ulterior estudio.
6.1.7
Disposiciones sobre otras facilidades
Para ulterior estudio.
6.1.8
Disposiciones sobre las utilidades internas de red
(invisibles por los usuarios)
Estas disposiciones se describen en la Recomendación X.302. En particular se aplican los siguientes mecanismos para la identificación de las redes:
-la RPDCC se identifica por el método del CIRD/IPD;
-la RDSI se identifica por el método de la Recomendación X.302.
Estas identificaciones de red se aplican entonces en las utilidades CIRT y CIRL de la Recomendación X.75.
6.2
Interfuncionamiento entre una RPDCC y una RDSI
cuando se solicita un portador con conmutación de
circuitos
Los procedimientos detallados para interfuncionamiento se definen en la Recomendación X.81 (véase la figura 2/X.321). En particular se aplica lo siguiente:
6.2.1
Transferencia de información de direccionamiento
Las RDSI y las RPDCC utilizan típicamente planes de numeración diferentes (esto es, el E.164 y el X.121 respectivamente). Son aplicables las consideraciones contenidas en la Recomendación X.301 sobre la transferencia de información de direccionamiento de los dos tipos diferentes. Otros aspectos del interfuncionamiento entre los dos planes de numeración en cuestión se describen detalladamente en las Recomendaciones E.166 y X.122.
Figura 2/X.321, p.
6.2.2
Disposiciones relacionadas con la CDS de la llamada
Estas disposiciones para la RPDCC se describen en la Recomendación X.301. Las disposiciones sobre la RDSI (CC) serán objeto de ulterior estudio.
Disposiciones sobre facilidades relacionadas con las
condiciones de tarificación solicitadas por el usuario de
la llamada
Para ulterior estudio.
6.2.4
Disposiciones sobre facilidades relacionadas con
condiciones específicas de encaminamiento solicitadas por
el usuario de la llamada
Para ulterior estudio.
6.2.5
Disposiciones sobre facilidades relacionadas con el
mecanismo de protección solicitado por el usuario de la
llamada
Estas disposiciones para la RPDCC se describen en la Recomendación X.301. Las disposiciones para la RDSI (CC) serán objeto de ulterior estudio.
6.2.6
Disposiciones sobre facilidades para transportar datos
de usuario además del flujo de datos normales en la fase
de transferencia de datos
Para ulterior estudio.
6.2.7
Disposiciones sobre otras facilidades
Para ulterior estudio.
6.2.8
Disposiciones sobre la red interna
Estas disposiciones para la RPDCC se describen en la Recomendación X.302. Las disposiciones para la RDSI (CC) serán objeto de ulterior estudio.
DISPOSICIONES GENERALES SOBRE EL INTERFUNCIONAMIENTO
ENTRE REDES PúBLICAS DE DATOS CON CONMUTACIóN DE PAQUETES
(RPDCP) Y REDES PúBLICAS DE DATOS CON CONMUTACIóN DE
CIRCUITOS (RPDCC) PARA LA PRESTACIóN DE SERVICIOS DE
TRANSMISIóN DE DATOS
(Melbourne, 1988)
El CCITT,
considerando
(a) que la Recomendación X.300 define los principios generales para el interfuncionamiento entre redes públicas y entre éstas y otras redes para la prestación de servicios de transmisión de datos;
(b) que la Recomendación X.301 define las disposiciones generales sobre el control de la llamada dentro de una subred y entre subredes para la prestación de servicios de transmisión de datos;
(c) que la Recomendación X.302 define las disposiciones generales sobre las utilidades internas de red entre una subred y entre subredes para la prestación de servicios de transmisión de datos;
(d) que la Recomendación X.75 define procedimientos para el interfuncionamiento RPDCP/RPDCP y que las Recomendaciones X.61 y X.71 definen procedimientos para el interfuncionamiento RPDCC/RPDCC;
(e) que la Recomendación X.10 describe categorías de acceso a las RPD y las RDSI para prestación de servicios de transmisión de datos;
(f) que la Recomendación X.213 especifica la definición del servicio de red para la interconexión de sistemas abiertos para aplicaciones del CCITT;
(g) que la Recomendación X.305 describe funcionalidades de subredes relacionadas con la prestación del servicio de red de ISA;
(h) la conveniencia de mantener la compatibilidad en los procedimientos utilizados en las capas 1, 2 y 3, en la RPDCP, de los terminales telemáticos actuales y futuros, y de los terminales para aplicaciones no telemáticas;
(i) que la Recomendación X.223 define la utilización de X.25 para proporcionar el servicio de red con conexión de ISA;
(j) que la Recomendación T.70 define el servicio de transporte básico independiente de la red para los servicios telemáticos;
(k) que la Recomendación X.32 define el interfaz entre ETD y ETCD para terminales que funcionan en el modo paquete y ganan acceso a la RPDCP a través de una RTPC, una RDSI o una RPDCC;
(l) que la Recomendación X.82 define disposiciones detalladas para el interfuncionamiento entre las RPDCC y las RPDCP basadas en la Recomendación T.70.
(m) la necesidad de disposiciones sobre el interfuncionamiento entre las RPDCP y las RPDCC para la prestación de servicios de transmisión de datos,
recomienda por unanimidad
que las disposiciones para el interfuncionamiento entre las RPDCP y las RPDCC para la prestación de servicios de transmisión de datos sean conformes con los principios y disposiciones especificadas en esta Recomendación.
íNDICE
0
Introducción
1
Objeto y campo de aplicación
2
Referencias
3
Definiciones
4
Abreviaturas
5
Aspectos generales
6
Disposiciones específicas de interfuncionamiento
0 Introducción
Esta Recomendación forma parte de un conjunto de Recomendaciones elaboradas
para facilitar el análisis del interfuncionamiento de las redes. Se basa en la
Recomendación X.300, que define los principios generales del
interfuncionamiento entre redes públicas y entre éstas y otras redes para la
prestación de servicios de transmisión de datos. La Recomendación X.300 indica
en particular cómo colecciones de equipo físico pueden representarse como
`subredes'
para su consideración en situaciones de interfuncionamiento.
Esta Recomendación describe las disposiciones de interfuncionamiento entre RPDCC y RPDCP para la prestación de servicios de transmisión de datos.
1 Objeto y campo de aplicación
Esta Recomendación tiene por objeto describir las disposiciones generales para el interfuncionamiento entre RPDCP y RPDCC para la prestación de servicios de transmisión de datos (véase la nota 1). Estas disposiciones sólo son aplicables al interfuncionamiento que implica capacidades de transmisión, y no al interfuncionamiento que implica capacidad de comunicación, descritas en la Recomendación X.300.
Nota 1
- Estas disposiciones también pueden utilizarse
para prestar servicios de telemática.
Nota 2
- En esta Recomendación, la tipificación de las
subredes se basa en el servicio de red en modo conexión de ISA, y por
consiguiente sólo es válida en este contexto.
Los demás tipos de subredes para otros servicios y aplicaciones se estudiarán ulteriormente.
2
Referencias
X.300Principios generales de interfuncionamiento entre redes públicas de datos, y entre éstas y otras redes para la prestación de servicios de transmisión de datos
X.301Descripción de las disposiciones generales para el control de la llamada dentro de una subred y entre subredes para la prestación de servicios de transmisión de datos
X.302Descripción de las disposiciones generales para las utilidades de red internas a una subred y las utilidades intermedias entre subredes para la prestación de servicios de transmisión de datos
X.305Funcionalidades de subredes relacionadas con el suministro del servicio de red ISA en el modo con conexión
X.1Clases de servicio internacional de usuario en redes públicas de datos y en redes digitales de servicios integrados (RDSI)
X.2Servicios de transmisión de datos y facilidades facultativas de usuario internacionales en redes públicas de datos
X.10Categorías de acceso para el equipo terminal de datos (ETD) a los servicios públicos de transmisión de datos proporcionados por redes públicas de datos (RPD) y/o por las redes digitales de servicios integrados (RDSI) mediante adaptadores de terminal
X.71Sistema de señalización descentralizada de control terminal y de tránsito para circuitos internacionales entre redes síncronas de datos
X.75Sistema de señalización con conmutación de paquetes entre redes públicas que proporcionan servicios de transmisión de datos
X.82Disposiciones detalladas sobre el interfuncionamiento entre RPDCC y RPDCP basadas en la Recomendación T.70
X.121Plan de numeración internacional para redes públicas de datos
X.223Utilización de la Recomendación X.25 para proporcionar el servicio de red en el modo de conexión de la ISA para aplicaciones del CCITT
X.70Servicio de transporte básico independiente de la red para los servicios telemáticos
3
Definiciones
Esta Recomendación utiliza los siguientes términos definidos en la Recomendación X.300:
a)capacidad de transmisión,
b)capacidad de comunicación,
c)funcionalidad de subred,
d)servicio de transmisión de datos,
e)red^*,
f)interfuncionamiento mediante la correspondencia del control de la llamada,
g)interfuncionamiento mediante acceso por puerto.
4
Abreviaturas
CDSCalidad de servicio
CIRTCódigo de identificación de red de tránsito
ETDEquipo terminal de datos
FIFFunción de interfuncionamiento
PBX@Centralita privada\
RAL@Red de área local\
RDSIRed digital de servicios integrados
RPDCCRed pública de datos con conmutación de circuitos
RPDCPRed pública de datos con conmutación de paquetes
RTPCRed telefónica pública conmutada
SMSServicio marítimo por satélite
5 Aspectos generales
Esta Recomendación, al describir las disposiciones de interfuncionamiento entre dos subredes para la prestación de servicios de transmisión de datos, se inspira en los principios generales de la Recomendación X.300. Los entornos de estas dos subredes se describen en las secciones que siguen.
5.1
RPDCP
La RPDCP proporciona servicios de transmisión de datos con conmutación de paquetes como se prescribe en las Recomendaciones X.1 y X.2 para la prestación de servicios de transmisión de datos; los ETD pueden ganar acceso a la RPDCP mediante las categoría de acceso C y D definidas en la Recomendación X.10. Se puede ganar acceso a la RPDCP también por otras redes como la RTPC (X.10 categorías L y P), RPDCC (X.10 categorías K y O y esta Recomendación), RPDCP (Recomendación X.75), SMS (Recomendación X.75), o RDSI (Recomendación X.325). El acceso de las redes privadas a la RPDCP tiene lugar vía X.10 categoría de acceso D.
5.2
RPDCC
La RPDCC proporciona servicios de transmisión de datos con conmutación de circuitos descritos en las Recomendaciones X.1 y X.2. Para la prestación de servicios de transmisión de datos, pueden tener acceso a la RPDCC los ETD mediante la categoría B definida en la Recomendación X.10. También se puede ganar acceso a esta red a través de otras redes, a saber, RPDCP (esta Recomendación), RPDCC (Recomendación X.71), o RDSI (Recomendación X.321). El acceso de las redes privadas y los sistemas móviles a la RPDCC será objeto de ulterior estudio (véase la Recomendación X.300).
5.3
Control de la llamada entre la RPDCP y la RPDCC
Las disposiciones generales para el control de la llamada entre la RPDCP y la RPDCC se definen en la Recomendación X.301. Entre la RPDCP y la RPDCC se emplean utilidades de red (invisibles por los usuarios), definidas en la Recomendación X.302.
5.4
Funcionalidades de la RPDCP y la RPDCC
Las funcionalidades de diferentes tipos de subredes se describen en la Recomendación X.300. Las funcionalidades de la RPDCP son diferentes de las de la RPDCC. En consecuencia, para hacer posible el interfuncionamiento, los procedimientos deben ser operados a través de la RPDCC para asegurar la compatibilidad funcional.
Para este fin se utilizan dos conjuntos diferentes de procedimientos:
a)procedimientos basados en la Recomendación T.70 para ofrecer procedimientos telemáticos; véase el 6.1 ;
b)procedimientos basados en la Recomendación X.25 (véase la X.32); véase el 6.2 .
Sin embargo, los procedimientos basados en la Recomendación T.70 no proporcionan una compatibilidad funcional completa; la FIF no puede hacer corresponder algunos elementos del protocolo de la RPDCP (véase la Recomendación X.82).
Cuadro 1/X.322 [T1.322] p.
5.5
Encaminamiento
5.5.1
Consideraciones de encaminamiento relacionadas con
la utilización de T.70
a)Cuando ha de pasarse de una red pública con conmutación de paquetes a una red pública con conmutación de circuitos, el paso de la primera a la segunda red debe producirse lo más lejos posible del origen:
FIGURE 1/X.322, p.
es decir, para pasar de A a D, es preferible hacerlo por (3).
b)La solución basada en T.70 ( 3.3.3 ) no debe utilizarse en aquellos casos en que la RPDCC funcione como red de tránsito, donde es necesario mantener en la mayor medida posible la compatibilidad funcional.
c)Deberá estudiarse con mayor amplitud si más alla del interfaz de abonado X.21, las redes privadas pueden, típicamente, esperar encontrar redes distintas de las del tipo de central privada (con conmutación de circuitos) (por ejemplo, redes que no sean de área local). Este supuesto es de particular importancia para el tratamiento de los parámetros de CDS en la FIF.
5.5.2
Selección de la FIF
Cuando es necesario pasar de la RPDCP a la RPDCC, habrá que elegir la FIF apropiada, es decir, la FIF basada en X.75, o la basada en T.70. (Aun en el caso en que las FIF estén instaladas físicamente en el mismo lugar, habrá que elegir los procedimientos apropiados). Esta selección podrá hacerse en base a la dirección del ETD llamado.
6
Disposiciones específicas de
interfuncionamiento
6.1
Interfuncionamiento por correspondencia del control de
llamada
La disposición de interfuncionamiento se ilustra en la figura 2/X.322.
FIGURE 2/X.322, p.
En esta disposición de interfuncionamiento:
a)la disposición internacional entre las dos subredes (por ejemplo, en las figuras, entre las funciones de interfuncionamiento y la RPDCP) se basa en la Recomendación X.75;
b)la función de interfuncionamiento (FIF) efectúa la conversión entre el sistema de señalización de la Recomendación X.71 o de la Recomendación X.61 y los procedimientos de la Recomendación X.75. Durante la fase de transferencia de datos, y para los terminales telemáticos mencionados en la Recomendación T.70, los protocolos definidos en los 3.3.2 y 3.3.3 de la Recomendación T.70 se utilizan en la RPDCC en las capas 2 y 3; para los demás terminales de la RPDCC, es posible aplicar esos u otros protocolos.
Nota 1
- Al establecer los principios de la
contabilidad internacional en relación con esta disposición de
interfuncionamiento, debería tenerse en cuenta la distribución de los elementos
funcionales que intervienen en ella (por ejemplo, coste/ingresos de la FIF).
Nota 2
- En cualquiera de los casos del
6.1
, las Administraciones interesadas pueden acordar, a título
excepcional, que la función de interfuncionamiento o el punto de paso entre la
RPDCC y la RPDCP esté en un país distinto del de la RPDCC.
Los procedimientos detallados de interfuncionamiento se definen en la Recomendación X.82 (que todavía no abarca el caso de la Recomendación X.61). En particular, es aplicable lo siguiente:
6.1.1
Transferencia de información de direccionamiento
Para ulterior estudio.
6.1.2
Disposiciones sobre facilidades relacionadas con la
CDS de la llamada
Para ulterior estudio.
6.1.3
Disposiciones sobre facilidades relacionadas con las
condiciones de tarificación aplicables a la llamada
Para ulterior estudio.
6.1.4
Disposiciones sobre facilidades relacionadas con
condiciones específicas de encaminamiento aplicables a la
llamada
Para ulterior estudio.
6.1.5
Disposiciones sobre facilidades relacionadas con el
mecanismo de protección solicitado por el usuario de la
llamada
Para ulterior estudio.
6.1.6
Disposiciones sobre facilidades destinadas a
transportar datos de usuario además del flujo de datos
normales en la fase de transferencia de datos
Para ulterior estudio.
6.1.7
Disposiciones sobre otras facilidades
Para ulterior estudio.
6.1.8
Disposiciones sobre utilidades internas de red
(invisibles por los usuarios)
Estas disposiciones se describen en la Recomendación X.302.
6.2
Interfuncionamiento mediante acceso por puerto
La disposición de interfuncionamiento se ilustra en la figura 3/X.322.
FIGURE 3/X.322 + Notas, p.
Los procedimientos detallados para el interfuncionamiento se definen en la
Recomendación X.32. En particular es aplicable lo siguiente:
6.2.1
Transferencia de información de direccionamiento
Esta se describe en la Recomendación X.301.
6.2.2
Disposiciones sobre facilidades relacionadas con la
DCS de la llamada
Estas disposiciones se describen en la Recomendación X.301.
6.2.3
Disposiciones sobre facilidades relacionadas con
las condiciones de tarificación aplicables a la
llamada
Estas disposiciones se describen en la Recomendación X.301.
6.2.4
Disposiciones sobre facilidades relacionadas con
condicions especificadas de encaminamiento aplicables a la
llamada
Estas disposiciones se describen en la Recomendación X.301.
6.2.5
Disposiciones sobre facilidades relacionadas con el
mecanismo de protección solicitado por el usuario de la
llamada
Estas disposiciones se describen en la Recomendación X.301.
6.2.6
Disposiciones sobre facilidades destinadas a
transportar datos de usuario además del flujo de datos
normales en la fase de transferencia de datos
Estas disposiciones se describen en la Recomendación X.301.
6.2.7
Disposiciones sobre otras facilidades
Estas disposiciones se describen en la Recomendación X.301.
6.2.8
Disposiciones sobre utilidades de red internas
(invisibles por los usuarios)
Estas disposiciones se describen en la Recomendación X.302.
DISPOSICIONES GENERALES SOBRE EL INTERFUNCIONAMIENTO ENTRE
REDES PúBLICAS DE DATOS CON CONMUTACIóN DE PAQUETES
(RPDCP)
(Melbourne, 1988)
El CCITT,
considerando
(a) que la Recomendación X.300 define los principios generales para el interfuncionamiento entre redes públicas de datos y entre éstas y otras redes para la prestación de servicios de transmisión de datos;
(b) que la Recomendación X.301 define las disposiciones generales para el control de la llamada dentro de una subred y entre subredes para la prestación de servicios de transmisión de datos;
(c) que la Recomendación X.302 define las disposiciones generales para las utilidades de red internas a una subred y entre subredes para la prestación de servicios de transmisión de datos;
(d) que la Recomendación X.75 especifica el sistema de señalización con conmutación de paquetes entre redes públicas que proporcionan servicios de transmisión de datos;
(e) que la Recomendación X.10 describe categorías de acceso a las RDSI para la prestación de servicios de transmisión de datos;
(f) que la Recomendación X.213 especifica la definición del servicio de red para la interconexión de sistemas abiertos para aplicaciones del CCITT;
(g) que la Recomendación X.305 describe funcionalidades de subredes relacionadas con el suministro del servicio de red ISA;
(h) la necesidad, en el caso del interfuncionamiento entre RDSI y RPDCP, de disposiciones sobre la prestación de servicios de transmisión de datos,
recomienda por unanimidad
que las disposiciones sobre el interfuncionamiento entre RPDCP para la prestación de servicios de transmisión de datos sean conformes con los principios y disposiciones especificados en esta Recomendación.
íNDICE
0
Introducción
1
Objeto y campo de aplicación
2
Referencias
3
Definiciones
4
Abreviaturas
5
Aspectos generales
6
Disposiciones específicas de interfuncionamiento
0 Introducción
Esta Recomendación forma parte de un conjunto de Recomendaciones elaboradas
para facilitar el análisis del interfuncionamiento entre redes. Se basa en la
Recomendación X.300, que define los principios generales para el
interfuncionamiento entre redes públicas de datos y entre éstas y otras redes.
La Recomendación X.300 indica en particular cómo colecciones de equipos físicos
pueden representarse como
`subredes'
para su consideración en
situaciones de interfuncionamiento.
Esta Recomendación describe las disposiciones de interfuncionamiento entre RPDCP para la prestación de servicios de transmisión de datos. Estas disposiciones de interfuncionamiento deben incluir todas las capacidades requeridas para proporcionar el servicio de red para la interconexión de sistemas abiertos para aplicaciones del CCITT, descritas en la Recomendación X.213.
1 Objeto y campo de aplicación
Esta Recomendación tiene por objeto describir las disposiciones generales sobre el interfuncionamiento entre RPDCP para la prestación de servicios de transmisión de datos. Estas disposiciones sólo son aplicables al interfuncionamiento en que intervienen capacidades de transmisión, y no al interfuncionamiento en que intervienen capacidades de comunicación, descritas en la Recomendación X.300.
2
Referencias
[1]Recomendación X.300
[2]Recomendación X.301
[3]Recomendación X.302
[4]Recomendación X.305
[5]Recomendación X.31
[6]Recomendación X.75
[7]Recomendación X.1
[8]Recomendación X.2
[9]Recomendación X.10
[10]Recomendación I.211
[11]Recomendación I.500
[12]Recomendación X.121
[13]Recomendación E.164
3
Definiciones
Esta Recomendación utiliza los siguientes términos definidos en la Recomendación X.300:
a)capacidad de transmisión,
b)capacidad de comunicación,
c)funcionalidad de subred,
d)servicio de transmisión de datos.
4
Abreviaturas
CIRLCódigo de identificación de la red liberante
CIRTCódigo de identificación de red de tránsito
ETDEquipo terminal de datos
FIFFunción de interfuncionamiento
GCUGrupo cerrado de usuarios
GCU/ASGrupo cerrado de usuarios con acceso de salida
RPDCPRed pública de datos con conmutación de paquetes
5 Aspectos generales
La Recomendación, al describir las disposiciones de interfuncionamiento entre dos subredes para la prestación de servicios de transmisión de datos, se inspira en los principios generales de la Recomendación X.300. Los entornos de estas dos subredes se describen en las secciones siguientes.
5.1
RPDCP
La RPDCP proporciona servicios de transmisión de datos con conmutación de paquetes definidos en las Recomendaciones X.1 y X.2 para la prestación de servicios de transmisión de datos. Los ETD tienen acceso a las RPDCP por medio de las categorías de acceso C y D definidas en la Recomendación X.10.
5.2
Control de las llamadas entre las RPDCP
Las disposiciones generales para el control de las llamadas entre las RPDCP se definen en la Recomendación X.301. Las utilidades de red usadas entre las RPDCP se definen en la Recomendación X.302 (no visibles por los usuarios).
6
Disposiciones específicas de
interfuncionamiento
6.1
Interfuncionamiento entre RPDCP
Los procedimientos detallados para el interfuncionamiento se definen en la Recomendación X.75. En particular, se aplica lo siguiente:
6.1.1
Transferencia de información de direccionamiento
Las consideraciones sobre la transferencia de información de direccionamiento se describen en la Recomendación X.301.
6.1.2
Disposiciones sobre las facilidades relacionadas con
la CDS de la llamada
Estas disposiciones se describen en la Recomendación X.301.
6.1.3
Disposiciones sobre facilidades relacionadas con el
mecanismo de protección solicitado por el usuario de la
llamada
Estas disposiciones se describen en la Recomendación X.301.
6.1.4
Disposiciones sobre las utilidades internas de
red
(no visibles por los usuarios)
Estas disposiciones se describen en la Recomendación X.302.
DISPOSICIONES GENERALES SOBRE EL INTERFUNCIONAMIENTO
ENTRE REDES PúBLICAS DE DATOS CON CONMUTACIóN DE PAQUETES
(RPDCP) Y SISTEMAS MóVILES PúBLICOS PARA LA PRESTACIóN DE
SERVICIOS DE TRANSMISIóN DE DATOS
(Melbourne, 1988)
El CCITT,
considerando
(a) que la Recomendación X.300 define los principios generales para el interfuncionamiento entre redes públicas de datos y entre éstas y otras redes para la prestación de los servicios de transmisión de datos;
(b) que la Recomendación X.301 define las disposiciones generales sobre control de las llamadas dentro de una subred y entre subredes para la prestación de servicios de transmisión de datos;
(c) que la Recomendación X.302 define las disposiciones generales sobre las utilidades de red internas a una subred y entre subredes para la prestación de servicios de transmisión de datos;
(d) que la Recomendación X.75 ya especifica procedimientos detallados aplicables al control de las llamadas entre dos redes públicas que prestan servicios de transmisión de datos;
(e) que la Recomendación X.10 describe categorías de acceso a las RPDCP para la prestación de servicios de transmisión de datos;
(f) que la Recomendación X.213 especifica la definición del servicio de red para la interconexión de sistemas abiertos para aplicaciones del CCITT;
(g) que la Recomendación X.305 describe funcionalidades de subredes relacionadas con el soporte del servicio de red ISA;
(h) que la serie de Recomendaciones Q.1000 definen las redes móviles terrestres públicas (RMTP);
(i) que la Organización Internacional de Satélites Marítimos (INMARSAT) opera actualmente un sistema de satélite marítimo designado por norma A que proporciona servicios de voz, télex y transmisión de datos;
(j) que entrarán en servicio nuevas normas INMARSAT, designadas por norma B (reemplazo digital; potenciada con respecto a la norma A), norma C (sistema de mensajería a baja velocidad de datos) y Aeronáutica (sistemas digitales de transmisión de la voz y datos para aeronaves);
(k) la necesidad de disposiciones para el interfuncionamiento entre sistemas móviles y RPDCP para la prestación de servicios de transmisión de datos,
recomienda por unanimidad
que las disposiciones sobre el interfuncionamiento entre RPDCP y sistemas móviles para la prestación de servicios de transmisión de datos sean conformes con los principios y disposiciones especificados en esta Recomendación.
íNDICE
0
Introducción
1
Objeto y campo de aplicación
2
Referencias
3
Definiciones
4
Abreviaturas
5
Aspectos generales
6
Disposiciones específicas de interfuncionamiento
7
Interfuncionamiento internacional
0 Introducción
Esta Recomendación forma parte de un conjunto de Recomendaciones elaboradas
para facilitar el análisis del interfuncionamiento entre redes. Se basa en la
Recomendación X.300, que define los principios generales para el
interfuncionamiento entre redes públicas de datos y entre éstas y otras redes.
La Recomendación X.300 indica en particular cómo colecciones de equipo físico
pueden representarse como
`subredes'
para su consideración en
situaciones de interfuncionamiento.
1 Objeto y campo de aplicación
Esta Recomendación tiene por objeto describir las disposiciones generales sobre el interfuncionamiento entre RPDCP y sistemas móviles para la prestación de servicios de transmisión de datos. Estas disposiciones solamente son aplicables al interfuncionamiento en que intervienen capacidades de transmisión, y no al interfuncionamiento en que intervienen capacidades de comunicación, descritas en la Recomendación X.300.
2
Referencias
[1]Recomendación X.300
[2]Recomendación X.301
[3]Recomendación X.302
[4]Recomendación X.305
[5]Recomendación X.325
[6]Recomendación X.1
[7]Recomendación X.2
[8]Recomendación X.10
[9]Recomendación X.121
3
Definiciones
En esta Recomendación se utilizan los siguientes términos definidos en la Recomendación X.300:
a)capacidad de transmisión,
b)capacidad de comunicación,
c)funcionalidad de subred,
d)servicio de transmisión de datos.
4
Abreviaturas
ETDEquipo terminal de datos
RDSIRed digital de servicios integrados
RMTPRed móvil terrestre pública
RPDRed pública de datos
RPDCCRed pública de datos con conmutación de circuitos
RPDCPRed pública de datos con conmutación de paquetes
RTPCRed telefónica pública conmutada
5 Aspectos generales
Esta Recomendación, al describir las disposiciones de interfuncionamiento entre dos subredes para la prestación de servicios de transmisión de datos, se inspira en los principios generales de la Recomendación X.300. Los entornos de estas dos subredes se describen a continuación.
5.1
RPDCP
La RPDCP proporciona servicios de transmisión de datos con conmutación de paquetes definidos en las Recomendaciones X.1 y X.2 para prestación de servicios de transmisión de datos. Pueden conectarse a la RPDCP los ETD con las categorías de acceso C y D definidas en la Recomendación X.10. Además, se puede obtener la conexión con la RPDCP a través de otras redes como la RTPC (X.10 categorías de acceso L, P), la RPDCC (X.10 categorías de acceso K, O), la RPDCP (Recomendación X.75), la RDSI (Recomendación, X.325) o sistemas móviles (esta Recomendación). Las redes privadas pueden conectarse a la RPDCP mediante la categoría de acceso D de la Recomendación X.10.
5.2
Sistema móvil público
El sistema móvil público puede ser bien una red móvil terrestre pública (RMTP) definida en la Recomendación Q.1001 o un sistema móvil por satélite (SMS), como el operado por la Organización Internacional de Satélites Marítimos (INMARSAT).
El sistema móvil puede proporcionar servicios de transmisión de datos con conmutación de paquetes definidos en las Recomendaciones X.1 y X.2.
En el contexto de la presente Recomendación, los ETD pueden conectarse al sistema móvil por las categorías de acceso C y D definidas en la Recomendación X.10.
5.3
Aspectos específicos de los sistemas móviles
públicos
Además de las funciones básicas de red que comparten con otros tipos de redes, los sistemas móviles públicos tienen funciones específicas inherentes a la movilidad de sus usuarios que ganan acceso al sistema a través de estaciones móviles.
a)estableciendo un pequeño número de zonas, y exigiendo que el usuario llamante indique una de ellas como la ubicación del usuario móvil;
b)manteniendo una base de datos en la cual está registrada la ubicación actual de cada estación móvil (esta base de datos se denomina registro de posiciones en la Recomendación Q.1001), y tomando las disposiciones pertinentes para que la red o redes fijas interconectadas encaminen las llamadas a un punto de acceso apropiado para el sistema móvil público. Con tal mecanismo, un usuario que desea llamar a otro no necesita saber dónde se encuentra éste, en ese momento.
El primer método (denominado método de encaminamiento de las llamadas a los usuarios móviles con designación) se utiliza en el sistema móvil marítimo por satélite público, donde la estación móvil puede encontrarse en una de tres regiones de satélite. El segundo método (denominado método de encaminamiento de las llamadas a usuarios móviles sin designación) es el adoptado por los sistemas conformes a las Recomendaciones de la serie Q.1000.
5.4
Organización de las Recomendaciones de la serie X
relacionadas con el interfuncionamiento entre RPDCP y los
sistemas móviles públicos
Al haber dos categorías de sistemas móviles, como se ha indicado en el 5.3 , se necesitan dos conjuntos de Recomendaciones para describir las correspondientes disposiciones de interfuncionamiento. En la figura 1/X.324 se indican las estructuras actual y prevista de dichas Recomendaciones.
Figure 1/X.324, p.
6 Disposiciones específicas de
interfuncionamiento
Para ulterior estudio.
Véanse también las Recomendaciones X.351, X.352 sobre los sistemas móviles por satélite públicos.
7 Interfuncionamiento internacional
Para ulterior estudio.
DISPOSICIONES GENERALES SOBRE EL INTERFUNCIONAMIENTO
ENTRE REDES PúBLICAS DE DATOS CON CONMUTACIóN DE
PAQUETES (RPDCP) Y REDES DIGITALES DE SERVICIOS
INTEGRADOS (RDSI) PARA LA PRESTACIóN DE SERVICIOS
DE TRANSMISIóN DE DATOS
(Melbourne, 1988)
El CCITT,
considerando
(a) que la Recomendación X.300 define los principios generales para el interfuncionamiento entre redes públicas, y entre éstas y otras redes para la prestación de servicios de transmisión de datos;
(b) que la Recomendación X.301 define las disposiciones generales para el control de la llamada dentro de una subred y entre subredes para la prestación de servicios de transmisión de datos;
(c) que la Recomendación X.302 define las disposiciones generales sobre las utilidades internas de red en una subred y entre subredes para la prestación de servicios de transmisión de datos;
(d) que la Recomendación X.75 ya especifica procedimientos detallados aplicables al control de la llamada entre redes públicas que proporcionan servicios de transmisión de datos;
(e) que la Recomendación X.10 describe categorías de acceso a las RDSI para la prestación de servicios de transmisión de datos;
(f) que la Recomendación X.213 describe la definición del servicio de red para la interconexión de sistemas abiertos para aplicaciones del CCITT;
(g) que la Recomendación X.305 describe funcionalidades de subredes relacionadas con el soporte del servicio de red ISA;
(h) la necesidad de disposiciones en el caso del interfuncionamiento entre RDSI y RPDCP para la prestación de servicios de transmisión de datos,
recomienda por unanimidad
que las disposiciones sobre el interfuncionamiento entre RPDCP y RDSI para la prestación de servicios de transmisión de datos sean conformes a los principios y disposiciones especificadas en esta Recomendación.
íNDICE
0
Introducción
1
Objeto y campo de aplicación
2
Referencias
3
Definiciones
4
Abreviaturas
5
Aspectos generales
6
Disposiciones específicas de interfuncionamiento
0 Introducción
Esta Recomendación forma parte de un conjunto de Recomendaciones elaboradas
para facilitar el análisis del interfuncionamiento de las redes. Se basa en la
Recomendación X.300, que define los principios generales del
interfuncionamiento entre redes públicas y entre éstas y otras redes para el
suministro de los servicios de transmisión de datos. La Recomendación X.300
indica en particular cómo colecciones de equipo físico pueden representarse
como
`subredes'
para su consideración en situaciones de
interfuncionamiento.
Esta Recomendación describe las disposiciones de interfuncionamiento entre RDSI y RPDCP para la prestación de servicios de transmisión de datos.
1 Objeto y campo de aplicación
Esta Recomendación tiene por objeto describir las disposiciones generales para el interfuncionamiento entre RPDCP y RDSI para la prestación de servicios de transmisión de datos. Estas disposiciones sólo son aplicables al interfuncionamiento que implica capacidades de transmisión, y no al interfuncionamiento que implica capacidades de comunicación, descritas en la Recomendación X.300.
Nota
- La tipificación de subredes en la presente
Recomendación se basa en el soporte del servicio de red en modo conexión, por
lo que sólo es válida en este contexto.
2
Referencias
[1]Recomendación X.300
[2]Recomendación X.301
[3]Recomendación X.302
[4]Recomendación X.305
[5]Recomendación X.31
[6]Recomendación X.75
[7]Recomendación X.1
[8]Recomendación X.2
[9]Recomendación X.10
[10]Recomendaciones de la serie I.230 Recomendaciones de la serie I.250
[11]Recomendación I.500
[12]Recomendación X.121
[13]Recomendación X.122
[14]Recomendación E.164
[15]Recomendación E.166
3
Definiciones
Esta Recomendación utiliza los siguientes términos definidos en la Recomendación X.300:
a)capacidad de transmisión,
b)capacidad de comunicación,
c)funcionalidad de subred,
d)servicio de transmisión de datos,
e)interfuncionamiento por correspondencia del control de la llamada,
f)interfuncionamiento mediante acceso por puerto.
Esta Recomendación utiliza los siguientes términos definidos en las Recomendaciones de la serie I.230:
a)servicio portador con conmutación de circuitos,
b)servicio portador de circuito virtual con conmutación de paquetes.
4
Abreviaturas
ATAdaptador de terminal
CIRLCódigo de identificación de la red liberante
CIRTCódigo de identificación de red de tránsito
ETEquipo terminal
ETDEquipo terminal de datos
FIFFunción de interfuncionamiento
GCUGrupo cerrado de usuarios
GCU/AS (o GCUAS)Grupo cerrado de usuarios con acceso de salida
RDSIRed digital de servicios integrados
RPDCPRed pública de datos con conmutación de paquetes
SMSSistema del servicio móvil por satélite
SS No. 7Sistema de señalización N.o 7
5 Aspectos generales
Esta Recomendación, al describir las disposiciones de interfuncionamiento entre dos subredes para la prestación de servicios de transmisión de datos, se inspira en los principios generales de la Recomendación X.300. Los entornos de estas dos subredes se decriben en las secciones que siguen. Véase también el cuadro 1/X.325.
5.1
RPDCP
La RPDCP proporciona servicios de transmisión de datos con conmutación de paquetes como los definidos en las Recomendaciones X.1 y X.2 para la prestación de servicios de transmisión de datos; los ETD pueden ganar acceso a la RPDCP mediante las categorías de acceso C y D definidas en la Recomendación X.10. Además, se puede ganar acceso a la RPDCP a través de otras redes como son la RTPC (X.10 categorías L, P), RPDCC (X.10 categorías K, O), RPDCP (Recomendación X.75), SMS (Recomendación X.75), y RDSI (esta Recomendación y X.10 categoría Q). Las redes privadas tienen acceso a la RPDCP vía X.10 categoría D.
5.2
RDSI
La RDSI puede proporcionar servicios de transmisión de datos con conmutación de circuitos y/o con conmutación de paquetes/servicios portadores como se indica en las Recomendaciones X.1, las de la serie I.230 y X.2.
Nota
- En la Recomendación I.250 se describen
servicios suplementarios/facilidades facultativas de usuario para el
funcionamiento en modo circuito por la RDSI. La Recomendación X.2 se aplica a
los servicios de transmisión de datos con conmutación de paquetes por la
RDSI/servicios portadores.
Para la prestación de servicios de transmisión de datos, los ETD/ET pueden ganar acceso a la RDSI por las categorías de acceso S, T, U definidas en la Recomendación X.10 y/o los métodos de acceso definidos en las Recomendaciones de la serie I.230. Además, se puede ganar acceso a la RDSI a través de otras redes tales como la RTPC (Recomendación I.530), RPDCC (Recomendación X.10 categoría B, y la Recomendación X.321), RPDCP (esta Recomendación), SMS (Recomendación X.324) o RDSI (SS N.o 7, Recomendación X.75, X.10 categoría Y).
Nota
- En el contexto de esta Recomendación, y con
vista a la prestación de servicios de transmisión de datos solamente, se
consideran las siguientes categorías de servicios portadores definidos en las
Recomendaciones de la serie I.230. (Otras serán objeto de ulterior estudio):
a)64 kbit/s, modo circuito, sin restricciones, estructurado a 8 kHz;
b)64 kbit/s, modo circuito, estructurado a 8 kHz, utilizable para transferencia de información de conversación;
c)64 kbit/s, modo circuito, estructurado a 8 kHz, utilizable para transferencia de información audio de 3,1 kHz;
d)llamada virtual y circuito virtual permanente.
5.3
Control de la llamada entre RPDCP y RDSI
Las disposiciones generales para el control de la llamada entre la RPDCP y la RDSI se definen en la Recomendación X.301. Las utilidades de red (invisibles por el usuario) utilizadas entre RPDCC y la RDSI se definen en la Recomendación X.302. En las Recomendaciones de la serie I.250 se especifican servicios suplementarios/facilidades facultativas de usuario para el funcionamiento en modo circuito de la RDSI.
5.4
Funcionalidades de la RPDCP y la RDSI
Las funcionalidades de diferentes tipos de subredes se describen en la Recomendación X.305. Cuando se utiliza la RDSI para proporcionar un servicio/servicio portador de transmisión de datos con conmutación de circuitos, la funcionalidad de la RPDCP y la de la RDSI pueden ser diferentes. En consecuencia, para hacer posible el interfuncionamiento deberán aplicarse procedimientos a través del servicio portador con conmutación de circuitos para conseguir la compatibilidad funcional. Cuando se utiliza la RDSI para proporcionar un servicio/servicio portador de transmisión de datos con conmutación de paquetes, la RPDCP y la RDSI son funcionalmente compatibles.
6
Disposiciones específicas de
interfuncionamiento
Como se indica en la Recomendación X.300, deben distinguirse los siguientes casos de interfuncionamiento.
a)Interfuncionamiento entre la RPDCP y la RDSI cuando se utiliza un portador con conmutación de paquetes.
b)Interfuncionamiento entre la RPDCP y la RDSI cuando se utiliza un portador con conmutación de circuitos:
1)interfuncionamiento por relación de correspondencia para el control de la llamada;
2)interfuncionamiento mediante acceso por puerto.
Cuadro 1/X.325 [T1.325], p.
6.1
Interfuncionamiento entre la RPDCP y la RDSI cuando se
solicita un portador con conmutación de paquetes
Los procedimientos detallados para el interfuncionamiento por relación de correspondencia para el control de la llamada se definen en la Recomendación X.75 (véase la figura 1/X.325). En particular, se aplica lo siguiente:
Figura 1/X.325, p.
6.1.1
Transferencia de información de direccionamiento
La RDSI y las RPDCP utilizan típicamente planes de numeración diferentes (esto es, E.164 y X.121 respectivamente). Son aplicables las consideraciones contenidas en la Recomendación X.301 sobre la transferencia de informaciones de direccionamiento de los dos tipos diferentes. Otros aspectos específicos del interfuncionamiento entre los dos planes de numeración en cuestión se describen detalladamente en las Recomendaciones E.166 y X.122.
6.1.2
Disposiciones sobre facilidades relacionadas con la
CDS de la llamada
Estas disposiciones se describen en la Recomendación X.301. Sin embargo, en cuanto a la facilidad de caudal, la RDSI y la RPDCP admiten diferentes clases de caudal (64 kbit/s). Cuando se solicita de la RDSI una clase de caudal superior a 48 kbit/s, la solicitud debe negociarse, en orden descendente, hasta la clase más baja admitida por la RPDCP.
6.1.3
Disposiciones sobre facilidades relacionadas con las
condiciones de tarificación aplicables a la llamada
Estas disposiciones se describen en la Recomendación X.301.
6.1.4
Disposiciones sobre facilidades relacionadas con
condiciones específicas de encaminamiento solicitadas por
el usuario
Estas disposiciones se describen en la Recomendación X.301.
6.1.5
Disposiciones sobre facilidades relacionadas con el
mecanismo de protección solicitado por el usuario de la
llamada
Estas disposiciones se describen en la Recomendación X.301. En particular, en lo que respecta a las facilidades GCU y GCU/AS, se aplicará el mecanismo de código de enclavamiento descrito en la Recomendación X.180.
6.1.6
Disposiciones sobre facilidades destinadas a
transportar datos de usuario además del flujo de datos
normales en la fase de transferencia de datos
Estas disposiciones se describen en la Recomendación X.301.
6.1.7
Disposiciones sobre otras facilidades
Estas disposiciones se describen en la Recomendación X.301.
6.1.8
Disposiciones sobre las utilidades internas de red
(invisibles por los usuarios)
Estas disposiciones se describen en la Recomendación X.302. En particular se aplican los siguientes mecanismos para la identificación de las redes:
-la RPDCP se identifica por el método del CIRD/IPD.
-la RDSI se identifica por el método de la Recomendación X.302.
Estas identificaciones de red se aplican entonces en las utilidades CIRT y CIRL de la Recomendación X.75.
6.2
Interfuncionamiento entre la RPDCP y la RDSI
cuando se solicita un portador con conmutación de
circuitos
6.2.1
Interfuncionamiento por relación de correspondencia
para el control de la llamada
Figura 2/X.325, p.
Este caso de interfuncionamiento por relación de correspondencia para el
control de la llamada no lo trata la Recomendación X.31. Para permitir el
interfuncionamiento los procedimientos deben ser operados por conducto del
portador con conmutación de circuitos RDSI para asegurar la compatibilidad
funcional. Sin embargo, estos procedimientos serán objeto de ulterior estudio.
En general se aplica lo siguiente:
-Las disposiciones de control de la llamada en la RDSI (es decir, I.420 o el protocolo SS N.o 7 funcionalmente idéntico, o un protocolo interno de red funcionalmente idéntico) debe hacerse corresponder en la FIF con las disposiciones de control de la llamada en la RPDCP (esto es, X.75, o un protocolo interno de la red funcionalmente idéntico). Esta relación de correspondencia será objeto de ulterior estudio.
-Las disposiciones de transferencia de datos en la RPDCP (es decir, X.75, o un protocolo interno de red funcionalmente idéntico) debe hacerse corresponder en la FIF con los procedimientos operados a través del portador con conmutación de circuitos entre FIF y ET/ETD. La relación de correspondencia será objeto de ulterior estudio.
6.2.2
Interfuncionamiento mediante acceso por puerto
A fin de hacer posible el interfuncionamiento, los procedimientos tienen que ser operados a través del portador con conmutación de circuitos RDSI, para asegurar la compatibilidad funcional. Estos procedimientos son conformes a la Recomendación X.25 (véanse las Recomendaciones X.31 y X.10 categoría Y). Son aplicables ciertos aspectos de la X.32, como se indica en la X.31.
En general, se aplica lo siguiente:
-X.75, o un protocolo interno de red funcionalmente idéntico, es operado entre la RDSI con conmutación de paquetes y la FIF.
-I.420, o PU-RDSI, o un protocolo interno de red funcionalmente idéntico es operado entre la RDSI con conmutación de circuitos y la FIF, y utilizado para controlar el portador con conmutador de circuitos.
-X.25 es operado entre la FIF y el ETD/ET a través del portador con conmutación de circuitos RDSI.
Consideraciones sobre la
`marcación de salida'
:
Se establecerá un portador con conmutación de circuitos a través de RDSI al recibirse un paquete de petición de llamada X.75; se procede de la manera siguiente:
-El número de la parte llamada Q.931 (y la subdirección, si se ha suministrado) se obtiene a partir del paquete de petición de llamada X.75.
-La capacidad portadora Q.931 se codifica como modo circuito.
-Después de establecido el portador con conmutación de circuitos se establece una conexión de enlace y la FIF hace corresponder el paquete de petición de llamada X.75 con un paquete de llamada entrante X.25.
-Los procedimientos restantes se describen detalladamente en la Recomendación X.31.
Consideraciones sobre la
`marcación de llegada'
.
Se establecerá un portador con conmutación de circuitos a través de la RDSI; se procede de la manera siguiente:
-El número de la parte llamada Q.931 es la dirección de la FIF (dirección de un puerto).
-La capacidad portadora Q.931 se codifica como modo circuito.
-Después de establecido el portador con conmutación de circuitos, se establece una conexión de enlace.
-La FIF hace corresponder un paquete de petición de llamada X.25 con un paquete de petición de llamada X.75.
-Se aplican entonces los procedimientos descritos en la Recomendación X.31.
Figura 3/X.325, p.
DISPOSICIONES GENERALES SOBRE EL INTERFUNCIONAMIENTO
ENTRE LAS REDES PúBLICAS DE DATOS CON CONMUTACIóN DE
PAQUETES (RPDCP) Y LA RED DE SEñALIZACIóN POR CANAL COMúN
(RSCC)
(Melbourne, 1988)
El CCITT,
considerando
(a) que la Recomendación X.300 define los principios generales para el interfuncionamiento entre redes públicas, y entre redes públicas de datos y otras redes para la prestación de servicios de transmisión de datos;
(b) que la Recomendación X.301 define las disposiciones generales para el control de las llamadas dentro de una subred y entre subredes para la prestación de servicios de transmisión de datos;
(c) que la Recomendación X.302 define las disposiciones generales para las utilidades de red internas a una subred y entre subredes para la prestación de servicios de transmisión de datos;
(d) que la Recomendación X.75 ya especifíca procedimientos detallados aplicables al control de las llamadas entre redes públicas que proporcionan servicios de transmisión de datos;
(e) que la Recomendación X.10 describe categorías de acceso a las RDSI para la prestación de servicios de transmisión de datos;
(f) que la Recomendación X.213 contiene la definición del servicio de red para la interconexión de sistemas abiertos para aplicaciones del CCITT;
(g) que la Recomendación X.305 describe funcionalidades de subredes relacionadas con la prestación del servicio de red con conexión de la ISA;
(h) que las Recomendaciones Q.711 a 716 describen la parte control de la conexión de señalización (PCCS) para la señalización por canal común;
(i) la necesidad de efectuar aplicaciones de operaciones, administración y mantenimiento (OA y M) a través de una diversidad de redes, incluidas la RSCC y las RPDCP, y en consecuencia la necesidad de que estas redes puedan interfuncionar,
recomienda por unanimidad
que las disposiciones sobre el interfuncionamiento entre las RPDCP y la RSCC sean conformes con los principios y disposiciones especificados en la presente Recomendación.
íNDICE
0
Introducción
1
Objeto y campo de aplicación
2
Referencias
3
Definiciones
4
Abreviaturas
5
Aspectos generales del interfuncionamiento entre la RSCC y
la RPDCP
6
Fase de establecimiento de la conexión
7
Fase de liberación de la conexión
8
Fase de transferencia de datos
0 Introducción
Esta Recomendación forma parte de un conjunto de Recomendaciones elaboradas
para facilitar el análisis del interfuncionamiento entre las redes. Se basa en
la Recomendación X.300, que define los principios generales para el
interfuncionamiento entre las redes públicas, y entre éstas y otras redes. La
Recomendación X.300 indica en particular cómo colecciones de equipo físico
pueden representarse como
`subredes'
para su consideración en
situaciones de interfuncionamiento.
Esta Recomendación describe las disposiciones de interfuncionamiento entre RPDCP y RSCC. Estas disposiciones de interfuncionamiento deben incluir todas las capacidades requeridas para proporcionar el servicio de red para la interconexión de sistemas abiertos para aplicaciones del CCITT. Las aplicaciones se describen en la Recomendación X.213.
1 Objeto y campo de aplicación
1.1 Las aplicaciones de operaciones, administración y mantenimiento (OA y M) de las redes deben poder efectuarse a través de una diversidad de redes, incluidas las redes públicas de datos.
1.2 Esta Recomendación describe el interfuncionamiento entre la red de señalización por canal común (RSCC) y las redes públicas de datos con conmutación de paquetes (RPDCP), que puede necesitarse para la transmisión de información de explotación entre Administraciones como un medio de transmisión de datos entre centros de explotación y/o terminales de esas Administraciones. Esta situación se ilustra en la siguiente figura 1/X.326.
Figura 1/X.326, p.
1.3 Debe observarse que, cuando se trata de protocolos OA y M, puede haber una
gran confusión entre:
-la red que se utiliza para transportar la información OA y M (por ejemplo, la RSCC o la RPD en la figura 1/X.326);
-la red que es controlada por la RSCC, con el soporte de las aplicaciones OA y M.
Además, puede suceder que la red controlada interfuncione con una RPD, como se ilustra en la siguiente figura 2/X.326. Esto se considera un interfuncionamiento entre la RSCC y la RPD, y por tanto no se describe en la presente Recomendación.
Figure 2/X.326, p.
2
Referencias
[1]Recomendación X.200 - Modelo de referencia de interconexión de sistemas abiertos para aplicaciones del CCITT
[2]Recomendación X.213 - Definición del servicio de red para la interconexión de sistemas abiertos (ISA) para aplicaciones del CCITT
[3]Recomendación X.300 - Principios generales sobre interfuncionamiento entre redes públicas y entre éstas y otras redes para la prestación de servicios de transmisión de datos
[4]Recomendación X.305 - Funcionalidades de subredes relacionadas con el suministro del servicio de capa de red con conexión ISA
[5]Recomendación Q.711 - Descripción funcional de la PCCS
[6]Recomendación Q.712 - Definiciones y funciones de los mensajes de la PCCS
[7]Recomendación Q.713 - Formatos y códigos de la PCCS
[8]Recomendación Q.714 - Procedimientos de la PCCS
[9]Recomendación Q.716 - Características de funcionamiento de la PCCS
3
Definiciones
3.1 En esta Recomendación se utilizan los siguientes términos definidos en las Recomendaciones X.300 y X.305:
a)subred de tipo I,
b)subred,
c)función de interfuncionamiento (FIF),
d)conexión de red (ISA),
e)capa de red (ISA),
f)servicio de capa de red (ISA).
3.2 Se utilizan también los siguientes términos definidos en las Recomendaciones Q.711, Q.712, Q.713 y Q.714:
a)mensaje (PCCS) (véase la nota),
b)tipo de mensaje,
c)referencia local.
Nota
- El uso del término
`mensaje'
en esta
Recomendación no debe confundirse con otros usos del mismo término
`mensaje'
en otras materias (por ejemplo en el contexto del sistema de
tratamiento de mensajes - STM - especificado en las Recomendaciones de la serie
X.400).
4
Abreviaciones
CaRCapa de red
CDSCalidad de servicio
CRConexión de red
ETDEquipo terminal de datos
FIFFunción de interfuncionamiento
ISAInterconexión de sistemas abiertos
@OA y MOperaciones, administración y mantenimiento\
@PCCSParte control de la conexión de señalización\
RPDRed pública de datos
RPDCPRed pública de datos con conmutación de paquetes
RSCCRed de señalización por canal común
SCRServicio de capa de red
5
Aspectos generales del
interfuncionamiento RSCC/RPDCP
5.1 El interfuncionamiento entre RSCC y RPDCP, que se requiere para la transmisión de información de explotación entre las Administraciones, debe proporcionar a los sistemas de extremo el servcio de capa de red con conexión definido en el contexto de la interconexión de sistemas abiertos (ISA).
5.2 Para este interfuncionamiento, la RPDCP debe ofrecer la plena capacidad del servicio de capa de red ISA, y podría considerarse globalmente un sistema de relevo ISA, abstracto (o una subred de tipo I, descrita en la Recomendación X.300).
5.3 Para el interfuncionamiento con la RPDCP, la RSCC debe, en asociación
con la función de interfuncionamiento apropiada cuando sea necesario, ofrecer
la plena capacidad del servicio de capa de red con conexión ISA. En el contexto
de la ISA, la RSCC y la función de interfuncionamiento (FIF) asociada podrían
considerarse globalmente un sistema de relevo ISA abstracto (o una
`subred
de tipo I'
descrita en la Recomendación X.300). Son aplicables los
protocolos de clase 3 de la PCCS.
5.4 En consecuencia, el interfuncionamiento entre RSCC y RPDCP debe considerarse en el contexto de la ISA como un interfuncionamiento entre dos subredes, cada una de las cuales es plenamente capaz de proporcionar el servicio de capa de red con conexión ISA. La siguiente figura 3/X.326 ilustra una representación del interfuncionamiento según el modelo ISA.
Figura 3/X.326, p.
5.5 Las disposiciones en el interfaz entre las dos
`Subredes de tipo I'
deben basarse en la Recomendación X.75.
5.6 En ese interfaz hay que establecer una relación de correspondencia entre los mensajes PCCS utilizados en el lado RSCC, y los paquetes X.25/X.75 utilizados en el lado RPDCP. En los 6 a 8 se describe detalladamente esta correspondencia, para cada fase de la conección: establecimiento de la conexión, liberación de la conexión, transferencia de datos. Esta relación de correspondencia está ligada a las correspondientes primitivas del servicio de capa de red ISA.
5.7 A cada tipo de primitiva del servicio de capa de red ISA corresponde:
-un tipo de mensaje PCCS, en el lado RSCC;
-un tipo de paquete, en el lado RPDCP.
Cada tipo se reconoce por:
-el parámetro
`tipo de mensaje'
, en el lado RSCC (PCCS);
-el parámetro
`tipo de paquete'
, en el lado RPDCP.
5.8 Cada conexión se identifica por:
-el número de referencia local de origen, en el lado RSCC (PCCS);
-un número de canal lógico, en el lado RPDCP.
Nota
- En el lado RPDCP, el número de canal lógico por
lo general, es local a un interfaz X.25 o X.75. En una misma conexión, por lo
general presenta valores diferentes en dos interfaces distintos.
6
Fase de establecimiento de la
conexión
6.1 Los siguientes cuadros 1 y 2/X.326 muestran las relaciones entre las primitivas utilizadas durante el establecimiento de la conexión de red ISA a través de la RSCC (PCCS) y la RPDCP interconectadas, y los mensajes PCCS y paquetes X.25/X.75 asociados con ese establecimiento de la conexión.
6.2 Las acciones y sucesos en los interfaces con la RSCC o la RPDCP que corresponden a estas primitivas se describen también en la Recomendación X.305.
6.3 En el contexto del interfuncionamiento entre RSCC (PCCS) y RPDCP, los cuadros 1 y 2/X.326 describen la correspondencia que hay que establecer entre mensajes PCCS y paquetes X.25/X.75 en relación con el servicio de capa de red ISA.
6.4 Puesto que se aplica al interfuncionamiento la clase de protocolo 3 de
la PCCS, todo mensaje PCCS de petición de conexión enviado o recibido por la
Función de Interfuncionamiento (FIF) debe contener una
`clase de protocolo
propuesto'
fijada a 3. La acción que deberá ejecutar la FIF si recibe un
mensaje PCCS de petición de conexión que propone una clase de protocolo
diferente de 3 será objeto de ulterior estudio.
Todo mensaje (PCCS) de confirmación de conexión debe contener una
`clase
de protocolo seleccionado'
fijada a 3. La acción que deberá ejecutar la
función de interfuncionamiento (FIF) cuando reciba un mensaje PCCS de
confirmación de conexión que seleccione una clase de protocolo inferior a 3
será objeto de ulterior estudio.
6.5 Todo mensaje PCCS de petición de conexión enviado o recibido por la FIF debe contener las direcciones de capa de red ISA que se necesiten para identificar las partes llamada y llamante que intervienen en la conexión.
Nota 1
- La medida en que será necesario dar soporte
una parte o a la totalidad de las direcciones de capa de red ISA se estudiará
con mayor amplitud en lo que respecta al interfuncionamiento entre la RSCC y
las RPDCP.
Nota 2
- Se estudiará con mayor amplitud la
correspondencia exacta de las direcciones de la capa de red ISA utilizadas en
el interfuncionamiento entre la RSCC y las RPDCP, con mensajes PCCS en un lado,
y con paquetes X.25/X.75 en el otro lado.
6.6 Dado que pueden requerirse varias conexiones simultáneas, es necesario identificar cada una de ellas en el interfuncionamiento entre RSCC y RPDCP (véase también el 5.8 ). A fin de hacer corresponder los planes de numeración de los canales lógicos en ambos lados, la FIF deberá conectar un circuito lógico en un lado con un circuito lógico del otro lado, como se ilustra en la figura 4/X.326:
Figure 4/X.326, p.
6.7 Durante el establecimiento de una conexión se utilizan parámetros de
calidad de servicio (CDS) para ajustar la calidad de la conexión.
Nota
- La correspondencia exacta entre los mecanismos
utilizados para ajustar la CDS, en la PCCS por un lado, y en X.25/X.75 por otro
lado, será objeto de ulterior estudio.
7
Fase de liberación de la
conexión
7.1 Los cuadros 1/X.326 a 3/X.326 muestran las relaciones entre las primitivas utilizadas durante la liberación de una conexión de red ISA a través de la RSCC (PCCS) y la RPDCP interconectadas, y los mensajes PCCS y los paquetes X.25/X.75 asociados con esa liberación de la conexión.
7.2 Las acciones y sucesos en los interfaces con la RSCC o RPDCP que corresponden a esas primitivas se describen también en el 7 de la Recomendación X.305.
7.3 En el contexto del interfuncionamiento entre RSCP (PCCS) y RPDCP, el cuadro 3/X.326 describe la correspondencia que hay que establecer entre los mensajes PCCS y los paquetes X.25/X.75 en relación con el servicio de capa de red ISA.
Nota
- La correspondencia exacta de los originadores
de las desconexiones de la ISA, y de los motivos por los cuales tuvieron lugar
en el interfuncionamiento entre la RSCC y las RPDCP, con mensajes PCCS por un
lado, y con paquetes X.25/X.75 por otro lado, será objeto de ulterior estudio.
Cuadro 1/X.326 [T1.326], p.
Cuadro 2/X.326 [T2.326], p.
Cuadro 3/X.326 [T3.326], p.
8
Fase de transferencia de
datos
8.1 Los cuadros 4/X.326 a 6/X.326 muestran las relaciones entre las primitivas utilizadas para la transferencia de datos en una conexión de red ISA a través de la RSCC (PCCS) y la RPDCP interconectadas, y los mensajes PCCS y paquetes X.25/X.75 asociados con esa transferencia de datos.
8.2 Las acciones y los sucesos en el interfaz con la RSCC o la RPDCP que corresponden a esas primitivas se describen también en el 8 de la Recomendación X.305.
8.3 En el contexto del interfuncionamiento entre RSCC (PCCS) y RPDCP, los cuadros 4/X.326 a 6/X.326 describen la correspondencia que hay que establecer entre mensajes PCCS y paquetes X.25/X.75 en relación con el servicio de capa de red ISA.
Cuadro 4/X.326 [T4.326], p.
Cuadro 5/X.326 [T5.326], p.
Cuadro 6/X.326 [T6.326], p.
8.4 En una conexión de capa de red ISA establecida mediante el
interfuncionamiento entre RSCC y RPDCPs, puede ser necesario transportar
unidades de datos del servicio de red (UDSR). Por tanto, se necesita la
segmentación y reensamblado.
Para efectuar la segmentación y el reensamblado se utiliza un mecanismo constituido por:
-el bit más datos (bit M) en el lado RPDCP;
-el indicador más datos (bit M) en el lado RSCC (PCCS).
8.5 En una conexión de capa de red ISA establecida mediante el interfuncionamiento entre RSCC y RPDCP se efectúa un control del flujo de datos.
Nota
- La correspondencia exacta entre el mecanismo de
control de flujo utilizado en la clase 3 de protocolo PCCS en un lado, y
X.25/X.75 en otro lado, deberá ser objeto de ulterior estudio.
8.6 Pueden producirse reiniciaciones durante la fase de transferencia de datos de un conexión.
Nota
- La correspondencia exacta de los originadores
de las reiniciaciones de la ISA, y de los motivos por los cuales tuvieron
lugar, en el interfuncionamiento entre la RSCC y las RPDCP, con mensajes PCCS
por un lado, y con paquetes X.25/X.75 por el otro lado, será objeto de ulterior
estudio.
MONTAGE : RECOMMANDATION X.327 SUR LE RESTE DE CETTE PAGE
@RDpriv D.1 NF01/010 (OPM = NF01) a) D.3 NF01/008 (OPM = NF04) (cs,) - (cs,)
(1BT) (BT..)
(86.TE.06.S)
(A1.23s) / [26s]
FOLIOS: 189 - 235 (DO
PRC.COSY.2)
MEP {TPS.NON.PHOTO "[PA1]"} : OK= [1]
Saisie 31.01.89 PR/GG/RM
ID + LASER + diskette MAJ 21.02.89 CJ
Corr. LASER (1re épreuve) = 3eme 02.03.89 IR
Espaces réservés 9.03.89 PC
AJOUTER (PA1) (CL1,0,0,0) pour MEP
MEP + LASER 17.03.89 ZR
Corr. DIGISET 11.04.89 CW
Corr. DIGISET 25.04.89 CW
Corr. MEP ........ ..
Insertion des tableaux (tabulateurs...) ........ ..
BAT ........ ..
MAJ s/disquettes 1.05.89 CD
MONTAGE:
Fin de la Rec. X.370 en tête de cette page 189
Recomendación X.327
DISPOSICIONES GENERALES SOBRE EL INTERFUNCIONAMIENTO
ENTRE REDES PúBLICAS DE DATOS PARA LA PRESTACIóN
DE SERVICIOS DE TRANSMISIóN DE DATOS
(Melbourne, 1988)
El CCITT,
considerando
(a) que la Recomendación X.300 define los principios generales para el interfuncionamiento entre redes públicas, y entre redes públicas y otras redes para la prestación de servicios de transmisión de datos;
(b) que la Recomendación X.301 define las disposiciones generales sobre control de la llamada dentro de una subred y entre subredes para la prestación de servicios de transmisión de datos;
(c) que la Recomendación X.302 define las disposiciones generales sobre utilidades internas de red dentro de una subred y entre subredes para la prestación de servicios de transmisión de datos;
(d) que la Recomendación X.75 ya especifica procedimientos detallados aplicables al control de la llamada entre las RPDCP;
(e) que la Recomendación X.10 describe categorías de acceso a las RPDCP para la prestación de servicios de transmisión de datos;
(f) que la Recomendación X.213 especifica la definición del servicio de red para la interconexión de sistemas abiertos para aplicaciones del CCITT;
(g) que la Recomendación X.223 describe una relación de correspondencia entre el protocolo X.213 y el protocolo del nivel de paquetes de la Recomendación X.25;
(h) que la Recomendación X.305 describe funcionalidades de subredes relacionadas con el suministro del servicio de red ISA;
(i) la necesidad de disposiciones para el caso del interfuncionamiento entre las RPDCP y redes privadas para la prestación de servicios de transmisión de datos,
recomienda (por unanimidad)
que las disposiciones sobre el interfuncionamiento entre RPDCPs y redes privadas para la prestación de servicios de transmisión de datos sean conformes con los principios y disposiciones especificados en esta Recomendación.
íNDICE
0
Introducción
1
Objeto y campo de aplicación
2
Referencias
3
Definiciones
4
Abreviaturas
5
Aspectos generales
6
Disposiciones específicas de interfuncionamiento
0 Introducción
Esta Recomendación forma parte de un conjunto de Recomendaciones elaboradas
para facilitar el examen del interfuncionamiento entre redes. Se basa en la
Recomendación X.300, que define los principios generales para el
interfuncionameinto entre redes públicas y entre redes públicas y otras redes
para la prestación de servicios de transmisión de datos. La Recomendación X.300
indica en particular cómo colecciones de equipos físicos pueden representarse
como
`subredes'
para su consideración en situaciones de
interfuncionamiento.
Esta Recomendación describe las disposiciones de interfuncionamiento entre RPDCP y redes de datos privadas para la prestación de servicios de transmisión de datos. Estas disposiciones de interfuncionamiento deben incluir todas las capacidades requeridas para suministrar el servicio de red para interconexión de sistemas abiertos para aplicaciones del CCITT, descrito en la Recomendación X.213.
1 Objeto y campo de aplicación
Esta Recomendación tiene por objeto describir las disposiciones generales sobre el interfuncionamiento entre RPDCPs para la prestación de servicios de transmisión de datos. Estas disposiciones son aplicables solamente al interfuncionamiento en que intervienen capacidades de transmisión y no al interfuncionamiento en que intervienen capacidades de comunicación, descritas en la Recomendación X.300.
2
Referencias
[1]Recomendación X.300
[2]Recomendación X.301
[3]Recomendación X.302
[4]Recomendación X.305
[5]Recomendación X.1
[6]Recomendación X.2
[7]Recomendación X.10
[8]Recomendación X.121
[9]Recomendación X.223
3
Definiciones
Esta Recomendación utiliza los siguientes términos definidos en la Recomendación X.300:
a)capacidad de transmisión
b)subred
c)servicio de transmisión de datos.
4
Abreviaturas
ETDEquipo terminal de datos
FIFFunción de interfuncionamiento
@RDprivRed de datos privada\ (o redes privadas de datos)
RDSIRed digital de servicios integrados
RPDCCRed pública de datos con conmutación de circuitos
RPDCPRed pública de datos con conmutación de paquetes
RTPCRed telefónica pública conmutada
@SRCCServicio de red con conexión\
5 Aspectos generales
Esta Recomendación, al describir las disposiciones sobre el interfuncionamiento entre dos subredes (una RPDCP y una RDpriv) para la prestación de servicios de transmisión de datos, se inspira en los principios generales de la Recomendación X.300. Los entornos de estas dos subredes se describen en las secciones siguientes. El interfuncionamiento debe proporcionar el servicio de capa de red con conexión, definido en la Recomendación X.213.
5.1
RPDCP
La RPDCP proporciona servicios de transmisión de datos con conmutación de paquetes definidos en las Recomendaciones X.1 y X.2 para la prestación de servicios de transmisión de datos. Los ETD tienen acceso a las RPDCP a través de las categorías de acceso C y D definidas en la Recomendación X.10.
Además, se puede también tener acceso a la RPDCP a través de otras redes como son la RTPC (X.10 categorías L, P), RPDCC (X.10 categorías K, O), RPDCP (Recomendación X.75), sistemas móviles (Recomendación X.324), RDSI (Recomendación X.325), o redes de datos privadas (esta Recomendación).
La RPDCP podría considerarse globalmente como un sistema de relevo ISA
abstracto (o una
`subred de tipo I'
, como la descrita en la
Recomendación X.300).
5.2
Redes de tipo privadas
La red de datos privada proporciona servicios de transmisión de datos. En el contexto de esta Recomendación, una red de datos privada puede ser una de las siguientes:
a)una subred que proporciona servicios de transmisión de datos con conmutación de paquetes, definidos en las Recomendaciones X.1 y X.2. para la prestación de servicios de transmisión de datos. Los ETD pueden ganar acceso a la red de datos privada a través de la categoría de acceso D definida en la Recomendación X.10;
b)una subred que proporciona servicios de transmisión de datos con conmutación de circuitos, definidos en las Recomendaciones X.1 y X.2, para la prestación de servicios de transmisión de datos. Los ETD pueden ganar acceso a las redes de datos privadas a través de la categoría de acceso B definida en la Recomendación X.10;
c)una red de punto a punto que proporcione servicios de transmisión de datos por circuito arrendado, definidos en la Recomendación X.1;
d)una subred conforme a ISO 8802.
Por otra parte, en el contexto de esta Recomendación, los ETD que ganan acceso a la red de datos privada utilizan en la capa de red el protocolo definido en ISA 8208.
En el contexto de la Interconexión de Sistemas Abiertos (ISA), la red de
datos privada y la FIF asociada podrían considerarse un sistema de relevo ISA
abstracto (o una
`subred de tipo I'
, descrita en la Recomendación
X.300).
Figura 1/X.327, p.
5.3
Disposiciones
generales
de interfuncionamiento
Las disposiciones en el interfaz entre las dos
`subredes de tipo I'
deben basarse en la Recomendación X.25.
En el interfaz hay que establecer una relación de correspondencia entre los paquetes X.25 utilizados a cada lado de la FIF. En el 6 se dan detalles sobre esta correspondencia, para cada fase de la conexión: establecimiento de la conexión, liberación de la conexión, transferencia de datos. Esta relación de correspondencia está a su vez ligada a las correspondientes primitivas del servicio de capa de red ISA.
En general, cada tipo de primitiva del servicio de capa de red corresponde
a un tipo de paquete en el lado RPDCP o en el lado RDpriv. Cada tipo se
reconoce por el parámetro
`tipo de paquete'
.
Cada conexión se identifica por:
-un número de canal lógico, en la RDpriv;
-un número de canal lógico, en el lado RPDCP.
Nota
- El número de canal lógico generalmente es local
a un interfaz X.25. En una misma conexión, es usual que su valor cambie entre
dos interfaces.
6 Disposiciones específicas de
interfuncionamiento
6.1
Fase de establecimiento de la conexión
6.1.1El cuadro 1/X.327 muestra las relaciones entre las primitivas utilizadas durante el establecimiento de una conexión de red ISA a través de una RDpriv y una RPDCP interconectadas, y los paquetes X.25 asociados con ese establecimiento de conexión (véase también la Recomendación X.223).
6.1.2 Las acciones y sucesos en el interfaz con la RDpriv o la RPDCP que corresponden a esas primitivas se describen también en el 6 de la Recomendación X.305.
6.1.3 En el contexto del interfuncionamiento entre RDpriv y RPDCP, el cuadro 1/X.327 describe una correspondencia que ha de establecerse entre los paquetes X.25 a cada lado del interfaz, en relación con el servicio de capa de red ISA. En particular, se da la siguiente correspondencia:
a)la recepción de un paquete de llamada entrante da lugar a la emisión de un paquete de petición de llamada; y
b)la recepción de un paquete de llamada aceptada da lugar a la emisión de un paquete de llamada conectada.
6.1.4 Todo paquete de establecimiento de la llamada enviado o recibido por la FIF debe contener las direcciones de capa de red ISA que se necesiten para identificar las partes llamada y llamante que intervienen en la conexión.
6.1.5 Dado que se pueden requerir varias conexiones simultáneas, es necesario identificar cada una de estas conexiones en el interfuncionamiento entre RDpriv y RPDCP (véase también el 5.3 ). A fin de establecer la correspondencia de los planes de numeración de los canales lógicos en ambos lados, la función de interfuncionamiento (FIF) debe conectar un canal lógico de un lado con un canal lógico del otro lado, como se muestra en la figura 2/X.327:
Figura 2/X.327, p.
6.1.6 Durante el establecimiento de una conexión, se utilizan parámetros de
calidad de servicio (CDS) para ajustar la calidad de la conexión.
6.2
Fase de liberación de la conexión
6.2.1El siguiente cuadro 2/X.327 muestra las relaciones entre las primitivas utilizadas durante la liberación de una conexión de red ISA a través de una RDpriv y una RPDCP interconectadas, y los paquetes X.25 asociados a esa liberación de la conexión (véase también la Recomendación X.223).
6.2.2 Las acciones y sucesos en el interfaz con la RDpriv o la RPDCP que corresponden a esas primitivas se describen también en el 7 de la Recomendación X.305.
6.2.3 En el contexto del inerfuncionamiento entre RDpriv y RPDCP, el cuadro 2/X.327 describe una correspondencia que ha de establecerse en cada interfaz entre los protocolos del nivel paquete X.25 y el servicio de capa de red ISA. En particular se da la siguiente correspondencia:
La recepción de un paquete de indicación de liberación provoca el envío de un paquete de petición de liberación (véase también el 6.4.1 ) y la confirmación del paquete de indicación de liberación.
6.3
Fase de transferencia de datos
6.3.1 Los siguientes cuadros 3/X.327 a 5/X.327 muestran las relaciones entre las primitivas utilizadas para la transferencia de datos en una conexión de red ISA a través de una RDpriv y una RPDCP interconectadas y los paquetes X.25 asociados con esa transferencia de datos (véase también la Recomendación X.223).
6.3.2 Las acciones y sucesos en los interfaces de la RDpriv o la RPDCP que corresponden a esas primitivas se describen también en el 8 de la Recomendación X.305.
6.3.3 En el contexto del interfuncionamiento entre una RDpriv y una RPDCP, los cuadros 3/X.327 a 5/X.327 describen una correspondencia que ha de establecerse entre paquetes X.25 y el servicio de capa de red ISA. En particular, se da la siguiente correspondencia:
a)la recepción de un paquete de datos provoca el envío de un paquete de datos (véase el 6.4.2 );
b)la recepción de un paquete de interrupción provoca el envío de un paquete de interrupción;
c)la recepción de un paquete de confirmación de interrupción provoca el envío de un paquete de confirmación de interrupción;
d)la recepción de un paquete de indicación de reiniciación provoca el envío de un paquete de petición de reiniciación y la confirmación del paquete de indicación de reiniciación.
6.3.4 Pueden producirse reiniciaciones durante la fase de transferencia de datos de una conexión.
6.4
Consideraciones adicionales
6.4.1
Rearranque
En el contexto del interfuncionamiento entre una RDpriv y una RPDCP, la recepción de un paquete de indicación de rearranque en un interfaz:
a)es confirmada por un paquete de confirmación de rearranque en ese interfaz, y
b)da lugar a la liberación de cada llamada virtual en el otro interfaz.
6.4.2
Tamaños de paquete y tamaños de
ventana
No se exige que los tamaños de paquete y los tamaños de ventana utilizados en un interfaz sean iguales a los utilizados en el otro interfaz. Sin embargo, la integridad de las secuencias completas de paquetes debe mantenerse dándole valores adecuados al bit M y al bit D.
6.4.3
Control de flujo
No se exige, en general, que los procedimientos de control de flujo en los dos interfaces estén acoplados. Sin embargo, la recepción de un paquete de datos con el bit D puesto a 1 no deberá provocar una rotación de la ventana en un interfaz hasta que se haya efectuado la rotación de la ventana en el otro interfaz para todos los datos de usuario en los paquetes de datos recibidos inicialmente.
Tableau 1/X.327 [T1.327], p. 3
Tableau 2/X.327 [T2.327], p. 4
Tableau 3/X.327 [T3.327], p. 5
Tableau 4/X.327 [T4.327], p. 6
Tableau 5/X.327 [T5.327], p. 7
MONTAGE: PAGE 198 = PAGE BLANCHE
SISTEMAS DE TRANSMISIóN DE DATOS MóVILES
Recomendación X.350
REQUISITOS GENERALES DE INTERFUNCIONAMIENTO PARA^ LA
TRANSMISIóN DE DATOS EN LOS SISTEMAS MóVILES PúBLICOS
INTERNACIONALES POR SATéLITE
(Málaga-Torremolinos 1984; modificada en Melbourne, 1988)
El CCITT,
considerando
(a) que la Organización Internacional de Satélites Marítimos (INMARSAT) explota ya un servicio marítimo por satélite;
(b) que los servicios de transmisión de datos establecidos en el sistema INMARSAT deben satisfacer las condiciones estipuladas para la transmisión de datos en general;
(c) que los equipos terminales de datos (ETD) móviles pueden conectarse con las redes públicas de datos (RPD) sobre la base de llamadas individuales;
(d) que los ETD móviles deben tener la posibilidad de comunicar con redes públicas de datos a través de todas las estaciones terrenas terrestres aun si éstas se hallan situadas en países diferentes y están conectadas a diferentes redes públicas de datos,
recomienda por unanimidad
que se apliquen las disposiciones generales siguientes a la transmisión de datos en sistemas móviles públicos internacionales por satélite.
1
Definiciones
Se definen seguidamente los términos utilizados en relación con la transmisión de datos en sistemas móviles públicos internacionales por satélite.
Nota
- En la Recomendación M.1100 aparece un conjunto
similar de definiciones para el interfuncionamiento del servicio telefónico.
1.1 Un @
sistema de transmisión de datos móvil por
satélite
@ es \un medio de establecer conexiones temporales entre una
central de conmutación de datos (CCD) de una red pública de datos (RPD) y un
ETD móvil. El sistema de transmisión de datos móvil por satélite comprende un
circuito móvil por satélite
, un
circuito
móvil local
, una
central de conmutación de datos del
servicio móvil por satélite (CCDMS)
y un
circuito móvil
terrenal
. La configuración de los sistemas móviles marítimos por satélite
se muestra en la figura 1/X.350.\ No se ha definido aún la transmisión de datos
por sistemas móviles aeronáuticos y móviles terrestres internacionales por
satélite.
1.2 Un @
circuito móvil local
@ es \un circuito entre la
estación terrena móvil
^y un ETD móvil.\
1.3 Un @
circuito móvil por satélite
@ \es un circuito
entre una
estación terrena móvil
^y la
estación terrena terrestre
. Comprende todos los elementos
necesarios para establecer, mantener y liberar el circuito móvil por satélite,
incluida la
estación de coordinación de la
red
.\
Figure 1/X.350, p.
1.4 Un @
circuito móvil terrenal
@ es \un circuito entre la
estación terrena terrestre
^y la
central
de conmutación de datos del servicio móvil por
satélite
.\
1.5 La @
definición de estación terrena móvil
@ \aparece
en el artículo 1,
4.9
, del Reglamento de Radiocomunicaciones (UIT,
Ginebra, 1982).\
1.6 La @
definición de estación terrena costera
@ \figura
en el artículo 1,
4.14
, del Reglamento de Radiocomunicaciones (UIT,
Ginebra, 1982).\
La @
definición de estación terrena aeronáutica
@ \figura
en el artículo 1,
4.20
, del Reglamento de Radiocomunicaciones (UIT,
Ginebra, 1982).\
La @
definición de estación terrena terrestre
@ \figura en
el artículo 1,
4.10
A, del Reglamento de Radiocomunicaciones,
modificado por la CAMR MOB-1987.\
La @
definición de estación terrena de base
@ \figura en
el artículo 1,
4.11
A, del Reglamento de Radiocomunicaciones,
modificado por la CAMR MOB-1987.\
1.7 Una @
central de conmutación de datos del servicio móvil
por satélite (CCDMS)
@ \es el interfaz funcional entre el
sistema de transmisión de datos móvil
público por satélite
y una red pública de datos.\
La CCDMS proporciona las siguientes funciones:
-interfuncionamiento entre los sistemas de señalización utilizados en el
sistema de transmisión de datos móvil
público por satélite
y la RPD;
-encaminamiento y control de las llamadas con destino y origen en estaciones terrenas móviles;
-tarificación.
1.8 Una @
estación de coordinación de la red
@ es \una
estación del sistema móvil público por satélite capaz de coordinar, supervisar
y controlar la asignación y utilización de los circuitos móviles por satélite
dentro de la zona de cobertura de un satélite. La estación de coordinación de
la red es designada y operada por el operador del sistema por satélite.\
Nota
- El resto de esta Recomendación se aplica a los
sistemas de transmisión de datos móviles públicos por satélite. Deberá
estudiarse ulteriormente su aplicabilidad a los sistemas móviles públicos por
satélite aeronáuticos y terrestres.
2
Elección del interfaz entre un ETD
móvil y la CCDMS
2.1 Para las velocidades de señalización de datos de 600 bit/s y superiores se han definido dos modos de funcionamiento del terminal (Recomendación X.1):
i)terminales que funcionan en el modo síncrono para las clases de servicio
de usuario 3 a 7 conectados a RPD con conmutación de circuitos por interfaces
definidos en las Recomendaciones X.21, X.21^
bis
y X.22;
ii)terminales que funcionan en el modo paquete para las clases de servicio de usuario 8 a 12 conectados a RPD con conmutación de paquetes por el interfaz definido en la Recomendación X.25.
2.2 El funcionamiento en el modo paquete ofrece varias ventajas en comparación con el modo síncrono, a saber:
i)permite interconectar los ETD que funcionan en clases de servicio de usuario diferentes;
ii)el interfaz comprende las capas 1, 2 y 3 del protocolo de interconexión de sistemas abiertos (ISA), lo que permite establecer las capas superiores directamente encima del interfaz definido en la Recomendación X.25;
iii)el protocolo de capa de enlace (capa 2) ofrece protección contra errores enlace por enlace utilizando técnicas de repetición automática de retransmisión (técnicas ARQ).
Nota
- Esta protección contra errores es adicional a, e
independiente de, cualquier sistema de corrección de errores sin canal de
retorno aplicado en el contexto de la capa 1;
iv)el suministro de facilidades del EDD permitirá también interconectar un ETD móvil en modo paquete con abonados de datos de la red telefónica pública conmutada y con abonados de RPD con conmutación de circuitos; puede utilizarse también el EDD para la interconexión con circuitos arrendados;
v)sería posible operar con velocidades de señalización de datos diferentes en los dos sentidos de transmisión del enlace por satélite.
2.3 De las anteriores consideraciones se desprende que el acceso desde sistemas móviles marítimos públicos por satélite a las RPD debiera establecerse en el modo paquete.
Con carácter facultativo se podrá ofrecer la interconexión con RPD con conmutación de circuitos.
2.4 Los procedimientos de interfuncionamiento entre redes de datos con conmutación de paquetes y el sistema de transmisión de datos móvil marítimo público por satélite se describen en la Recomendación X.352.
3
Número de datos internacional de
un ETD móvil
El formato del número de datos internacional que debe utilizar un ETD móvil se define en la Recomendación X.121, y tiene el siguiente formato:
Cuadro [T1.350], p.
4
Prefijos que han de utilizarse para
la transmisión de datos
Los prefijos que ha de utilizar un ETD móvil para llamar a un ETD de una RPD o a una terminación especial situada en la central de conmutación de datos del servicio móvil marítimo público por satélite (CCDMS) o en una RPD se indican en el anexo A.
5
Transferencia de la señal de
dirección entre la CCDMS y un ETD móvil
5.1
Llamadas originadas en una red pública de
datos
5.1.1 En el caso de una llamada entrante a un ETD móvil, la parte de la dirección del ETD llamado que comprende el CIRD y el número INMARSAT móvil no necesita transferirse a través del interfaz ETCD/ETD pues la estación terrena costera identifica la estación terrena móvil llamada por procedimientos basados en el trayecto radio. Si está presente la cifra adicional que identifica un ETD móvil específico, debe transferirse, de forma transparente, a la estación terrena móvil [véase también la Recomendación X.352, 2.3 ^ii)].
5.1.2 La dirección del ETD llamante transferida a través del interfaz ETCD/ETD debe tener el siguiente formato:
Cuadro [T2.350], p.
5.2
Llamadas originadas en una estación terrena
móvil
5.2.1 En el caso de un ETD móvil llamante, la dirección del ETD llamado que se transfiere por el interfaz ETD/ETCD debe tener el siguiente formato, cualquiera que sea la ubicación del ETD llamado:
Cuadro [T3.350], p.
5.2.2 La dirección del ETD llamante, que comprende el número INMARSAT móvil
seguido facultativamente por la cifra que identifica el ETD en cuestión, debe
transferirse por el interfaz ETD/ETCD [véase también la Recomendación X.352,
2.4
^i)].
Nota
- Tal como lo prescribe la Recomendación X.300,
la dirección del ETD llamante, si está presente, debe ser verificada por la
CCDMS antes de transmitir el paquete de petición de llamada a una RPD. El CIRD
de la zona oceánica en que se encuentra la estación terrena móvil llamante
deberá ser insertado por la CCDMS. Si no está presente la dirección del ETD
llamante, la CCDMS deberá insertarla. La dirección insertada deberá comprender
el CIRD seguido de la identidad del número de la estación terrena móvil.
5.3
Llamadas dirigidas a terminaciones
especiales
Cuando un ETD móvil llame a una terminación especial definida por uno de los prefijos (diferentes de cero) indicados en el anexo A, la dirección del ETD llamado que se transfiere por el interfaz ETD/ETCD debe tener el siguiente formato:
Cuadro [T4.350], p.
5.4
Subdireccionamiento
El empleo del método de dirección compartida para identificar un ETD móvil específico se describe en el 3 precedente.
Para identificar un ETD móvil específico utilizando el método de dirección ampliada en el campo de facilidad, véase la Recomendación X.25.
6 Servicios y facilidades de usuario
6.1 Deben ofrecerse servicios y facilidades de usuario de acuerdo con la Recomendación X.2.
6.2 La realización de las facilidades de usuario se indica en la Recomendación X.300.
6.3 Los valores por defecto para facilidades y parámetros pueden ser fijados independientemente para cada CCDMS.
Los métodos para la negociación de facilidades y parámetros llamada por llamada deberán ser objeto de ulterior estudio.
Véase también la Recomendación X.32.
7
Encaminamiento
Los principios generales del encaminamiento entre redes públicas de datos se definen en la Recomendación X.110. Los requisitos especiales en materia de encaminamiento vinculados con el servicio móvil por satélite se definen en la Recomendación X.353.
8 Señales de progresión de la llamada y
códigos de diagnóstico
8.1 Un abonado a una RPD que llama a un ETD móvil puede recibir señales de progresión de la llamada y códigos de diagnóstico de conformidad con la Recomendación X.96 y con el anexo E a la Recomendación X.25, respectivamente. Cuando la señal de progresión de la llamada (y el código de diagnóstico) son devueltos desde la CCDMS en caso de fracaso del establecimiento de la llamada por el circuito móvil por satélite, en la Recomendación X.352 se da una información más precisa en cuanto a la causa.
9
Grupos cerrados de
usuarios
9.1 De conformidad con la Recomendación X.2 la facilidad de grupo cerrado de usuarios se considera esencial y debe por tanto ofrecerse también para uso por las estaciones terrenas móviles.
9.2 Como quiera que las estaciones terrenas móviles pueden establecer y recibir llamadas de datos a través de cualquier CCDMS, una estación terrena móvil que forme parte de un grupo cerrado de usuarios debe ser conocida como tal por todas las CCDMS del servicio móvil por satélite.
9.3 Los principios y procedimientos para el establecimiento de grupos cerrados de usuarios se estipulan en la Recomendación X.300.
10
Interfaz con facilidades de
EDD
10.1 Un ETD móvil en el modo paquete deberá ganar acceso a las facilidades EDD de una RPD utilizando los procedimientos definidos en la Recomendación X.29.
10.2 Un ETD móvil que funcione en el modo arrítmico deberá ganar cceso a las facilidades EDD utilizando los procedimientos definidos en la Recomendación X.351.
11
Transferencia de la información
por los conductores C e I
Cuando sea necesario, deben tomarse disposiciones para que el circuito móvil por satélite permita transferir la información de los conductores C e I (Recomendación X.21) entre el interfaz ETD móvil/estación terrena móvil y el interfaz estación terrena costera/CCDMS. Si con tal fin se emplea una estructura de envolvente, deberá garantizarse que no llegue a la RPD ninguna envolvente no normalizada.
12
Tratamiento de las llamadas a grupo
(servicio de difusión)
12.1 El sistema móvil marítimo público internacional por satélite ofrece un servicio de comunicación (llamadas marítimas a grupo) en virtud del cual el ETD que llama desde una RPD puede enviar mensajes simultáneamente a un determinado grupo de barcos. No existe un enlace de retorno desde los barcos (es decir, el servicio es símplex), y en consecuencia no se dará ningún acuse de que el mensaje ha sido recibido por un determinado barco del grupo llamado.
Estas llamadas a grupo marítimas se identifican por medio del siguiente número de datos internacional (véase la Recomendación E.215/F.125):
Cuadro [T5.350], p.
en el cual la primera cifra del número de la estación terrena móvil tiene el
valor fijo 0. Las demás cifras del número INMARSAT móvil determinan el grupo de
barcos al que se dirige la llamada.
Las llamadas a grupo en otros sistemas móviles públicos por satélite se definen también en la Recomendación E.215.
12.2 Si deben efectuarse llamadas marítimas a grupo a través de una RPD, dichas llamadas deben hacerse pasar por un sistema de tratamiento de mensajes (STM) en la CCDMS. Los procedimientos que se utilicen entre un ETD de una RPD y el STM deben ajustarse a las reglas definidas por el CCITT.
EL STM (o la CCDMS) debe cerciorarse de que el ETD llamante está autorizado para efectuar llamadas a grupo marítimas, por ejemplo utilizando la facilidad de identificación de la línea llamante o la facilidad de grupo cerrado de usuarios. Serán prohibidas las llamadas procedentes de ETD no autorizados.
12.3 Las llamadas con una dirección de grupo (excepto las transmitidas por el STM) deberán ser prohibidas por la CCDMS o por la estación terrena costera.
ANEXO A (a la Recomendación X.350)
Atribución de
prefijos telefónicos, códigos de acceso télex y prefijos de
transmisión de datos
La Secretaría del CCITT sería responsable de coordinar la atribución de nuevos prefijos y códigos de acceso con las Comisiones de Estudio competentes. Esto debiera hacerse de manera que quedase asegurado que servicios equivalentes vehiculados por circuitos telefónicos, télex o de datos reciban el mismo prefijo.
Los prefijos y códigos de acceso que han de utilizarse para llamadas automáticas debieran ser los siguientes:
Telefonía:
Para las llamadas internacionales, el
prefijo debiera ser 00 seguido del número telefónico internacional del abonado
llamado. Como una opción, para las llamadas nacionales, podría utilizarse el
prefijo 0 seguido del número nacional (significativo) del abonado llamado.
Nota
- En el servicio marítimo por satélite se prefiere
el formato internacional solamente.
Télex:
Para las llamadas internacionales, el código de
acceso debiera ser 00 seguido del número télex internacional del abonado
llamado. Como una opción, para las llamadas nacionales, podría utilizarse el
código de acceso 0 seguido del número télex nacional del abonado llamado.
Nota
- En el servicio marítimo por satélite se prefiere
el formato internacional solamente.
Transmisión de datos:
Para las llamadas de datos por
conducto de una red pública de datos, el formato debiera consistir siempre en
el prefijo 0 seguido del número de datos internacional del abonado llamado
(véase el
5.2.1
de la Recomendación X.350).
A.2 El cuadro A1/X.350 contiene una lista de los prefijos y códigos de acceso atribuidos hasta la fecha para el acceso a destinos, servicios o facilidades especiales.
A.3 Las facilidades se definen en el anexo B de la Recomendación E.216.
Tableau A-1/X.350 [1T6.350], p. 14
Tableau A-1/X.350 (suite) [2T6.350], p. 15
REQUISITOS ESPECIALES QUE DEBEN SATISFACER LAS
FACILIDADES DE EMPAQUETADO/DESEMPAQUETADO DE DATOS (EDD)
SITUADAS EN ESTACIONES TERRENAS COSTERAS, O EN ASOCIACIóN
CON ELLAS, EN EL SERVICIO MARíTIMO POR SATéLITE
(Málaga-Torremolinos, 1984; modificada en Melbourne, 1988)
El CCITT,
considerando
(a) que en la Recomendación X.3 se definen los EDD;
(b) que en la Recomendación X.28 se define el interfaz ETD/ETCD para un ETD arrítmico que accede a un EDD;
(c) que en la Recomendación X.29 se definen los procedimientos para el intercambio de información de control y datos de usuario entre un EDD y un ETD de paquetes;
(d) que en la Recomendación X.350 se exponen los requisitos generales que debe satisfacer la transmisión de datos en el servicio marítimo por satélite;
(e) que en el servicio marítimo por satélite se utilizan ETD arrítmicos;
(f) que es conveniente que se ofrezca a tales ETD el acceso hacia y desde redes públicas de datos con conmutación de paquetes a través de EDD situados en, o en asociación con, estaciones terrenas costeras o centrales de conmutación de datos del servicio marítimo por satélite (CCDMS);
(g) que es conveniente emplear los mismos procedimientos de
Nota 1
- El término
EDD marítimo
^se utiliza para designar a los EDD situados en estaciones terrenas costeras, o
en asociación con ellas, en el servicio marítimo por satélite, de acuerdo con
esta Recomendación.
Nota 2
- Esta Recomendación no especifica EDD
utilizados a bordo de barcos,
recomienda por unanimidad
(1) que los EDD del servicio marítimo por satélite (EDD marítimos) satisfagan las exigencias de esta Recomendación para garantizar una compatibilidad total entre EDD asociados con diferentes estaciones terrenas costeras o @centrales de conmutación de datos del servicio marítimo por satélite (CCDMS)\ (véase en la Recomendación X.350 la definición de CCDMS). Las especificaciones generales de los EDD aparecen en las Recomendaciones X.3, X.28, y X.29;
(3) que los EDD marítimos ofrezcan el perfil normalizado inicial especificado en el cuadro 3/X.351;
(4) que los EDD marítimos ofrezcan además otros perfiles normalizados que se definen en la Recomendación X.28;
(5) que se recomiende a los usuarios a bordo de barcos, que efectúen la llamada a través del EDD marítimo más próximo al abonado llamado, para evitar rutas terrestres largas;
(6) que el protocolo permita el acceso hacia y desde ETD arrítmicos no atendidos situados a bordo de barcos y garantice una desconexión eficaz del trayecto de información de acceso al finalizar una llamada virtual para evitar una ocupación indebida del circuito del satélite;
(8) que se ubiquen los EDD marítimos como se indica en el anexo B.
1
Procedimientos para establecer el
trayecto de información de acceso para llamadas originadas en
barcos
1.1
Interfaz ETD/ETCD
El trayecto de información de acceso se establecerá mediante modems normalizados para su uso en la red telefónica conmutada.
i)A la velocidad de 300 bit/s para funcionamiento dúplex de acuerdo con la Recomendación V.21. El canal N.o 1 se utilizará en el sentido del barco al EDD, y el canal N.o 2 en el sentido opuesto. La inhabilitación de los supresores de eco se efectuará por tonos.
iii)A la velocidad de 75/1200 bit/s de acuerdo con la Recomendación V.23. La velocidad de 75 bit/s se utilizará para el sentido del ETD de a bordo al EDD, y la velocidad de 1200 bit/s se utilizará para el sentido opuesto. La inhabilitación de los supresores de eco se efectuará por tonos.
Nota 1
- Se prefiere la alternativa que aparece en el
apartado ii).
Nota 2
- Las Administraciones pueden ofrecer a los EDD
marítimos velocidades de datos adicionales.
Los circuitos de intercambio particulares que se provean, y su funcionamiento, estarán de acuerdo con la Recomendación V.24 y la fijación del circuito 104 se realizará de acuerdo con la Recomendación V.24, 4.3 .
1.2
Procedimientos para que el ETD establezca el trayecto
de información de acceso
1.2.1
Establecimiento del enlace de satélite
El enlace de satélite se establece mediante los procedimientos definidos en el sistema INMARSAT.
1.2.2
Procedimientos de marcación
Los procedimientos de marcación para establecer circuitos telefónicos en el
sistema
Cuadro 1/X.351 [T1.351], p.
En el cuadro 2/X.351 aparecen las secuencias de marcación para las otras
velocidades de señalización de datos de la Recomendación X.3 que se pueden
apoyar en el sistema INMARSAT existente. Estas velocidades de señalización de
datos se pueden ofrecer con carácter facultativo.
Cuadro 2/X.351 [T2.351], p.
Las secuencias de marcación 2050 a 2099 están asignadas para uso nacional, es
decir, acceso a los EDD para servicios especiales, tales como el videotex.
Para el acceso a EDD diferentes de los EDD marítimos se deben utilizar procedimientos de acceso y números de acceso nacionales. La numeración y los procedimientos de marcación serán como los definidos para llamar a un abonado telefónico de la red terrenal (véase el 2.3.1 de la Recomendación E.211).
Encaminamiento y conversión de cifras en las
estaciones terrenas costeras
El encaminamiento de llamadas desde la estación terrena del barco al EDD marítimo se realiza tal como se muestra en el anexo B.
Puede haber un puerto de entrada diferente al EDD marítimo para cada velocidad de datos, o bien se pueden aceptar velocidades de datos diferentes en el mismo puerto. La estación terrena costera encaminará la llamada automáticamente hacia el puerto adecuado del EDD.
Si el EDD marítimo está conectado de forma remota a la estación terrena
costera a través de la red telefónica pública con conmutación [lo
1.2.4
Inhabilitación de supresores de
eco
Normalmente, se disponen supresores de eco en ambos extremos de la conexión por satélite. Aunque en algunos casos los supresores de eco pueden ser inhabilitados por medio de señalización, es conveniente que los modems envíen el tono de inhabilitación siempre que se establece el trayecto de información de acceso.
2 Procedimientos para establecer el
trayecto de información de acceso para llamadas originadas en una RPD
Este punto debe ser objeto de estudios ulteriores.
3
Procedimientos para desconectar el
trayecto de información de acceso
En los 1.1.3.2 y 1.1.3.4 de la Recomendación X.28 se describen los procedimientos para desconectar el trayecto de información de acceso, es decir, el circuito telefónico marítimo por satélite.
Nota 1
- Puesto que para acceder al EDD marítimo se
utiliza un circuito telefónico marítimo por satélite, la tasación de la
comunicación puede tener lugar hasta que el circuito sea liberado hacia
adelante (véanse las Recomendaciones de la serie Q.1100 para las condiciones
pertinentes). Para establecimiento de comunicaciones desde el ETD a bordo, la
desconexión realizada por el EDD marítimo corresponde con la liberación hacia
atrás del circuito telefónico del servicio marítimo por satélite. Los
procedimientos de liberación relativos a la liberación hacia atrás de circuitos
telefónicos del servicio marítimo por satélite se definen en las
Recomendaciones de la serie Q.1100.
Nota 2
- Los EDD marítimos pueden estar dotados de
mecanismos de control para desconectar el trayecto de información de acceso
durante condiciones de fallo; por ejemplo, cuando no se ha transmitido
información entre el ETD y el EDD durante un periodo de tiempo determinado.
Nota 3
- Cuando el EDD marítimo detecta que se ha
producido una condición de liberación de capa 3 en el interfaz con la RPD, y
tras haber enviado o recibido del ETD las necesarias señales de control (por
ejemplo, la señal de servicio de EDD indicación de liberación), el EDD deberá
desconectar el trayecto de información de acceso.
4
Formato de los caracteres utilizados
en el intercambio de información de control
Los ETD arrítmicos generarán y podrán recibir caracteres del Alfabeto Internacional N.o 5, especificados en la Recomendación V.3. La estructura general de los caracteres estará de acuerdo con la Recomendación X.4.
Se aplicarán las siguientes condiciones específicas. El EDD transmitirá y
esperará recibir caracteres de 8 bits, cuyo octavo bit (es decir, el último
bit, anterior al elemento de parada) será el bit de paridad. El EDD marítimo
detectará la paridad de la señal
petición de servicio
.
Si se selecciona el modo transparente en el curso de la llamada (véase el 5.2 siguiente), el EDD ignorará el bit de paridad, y transmitirá los octetos de forma transparente entre ambos ETD interconectados.
En el perfil normalizado inicial del cuadro 3/X.351 se supone que se
utiliza paridad par. Sin embargo, los EDD marítimos soportarán también los
valores facultativos 1, 2 y 3 del parámetro 21 (véase la Recomendación X.3). Si
el ETD arrítmico a bordo requiere la utilización de un valor
instrucción de EDD asignación
(o
instrucción de EDD asignación y
lectura
), por ejemplo, SET 21^:^3, la cual se enviará tan
pronto como se reciba la señal de
servicio de EDD
identificación de EDD
[véase el
5.2.1
^ii)].
Debe ser objeto de estudios ulteriores si se deben incluir en el cuadro 3/X.351 perfiles normalizados específicos para aplicaciones marítimas, con objeto de proporcionar otros tratamientos de la paridad además de los suministrados con el perfil normalizado inicial.
5
Procedimientos para llamadas
originadas en barcos
5.1
Generalidades
5.1.1
Perfil normalizado inicial para EDD
marítimos
El perfil normalizado inicial para aplicaciones marítimas por satélite, que se ofrecerá a todos los EDD marítimos, aparece en el cuadro 3/X.351.
Los parámetros N.os 1 a 12 y el parámetro N.o 21 se preverán en todos los EDD marítimos. Los parámetros restantes pueden ofrecerse a nivel nacional.
Table 3/X.351 [T3.351], p.
5.1.2
Codificación de las señales de instrucción de EDD y de
las señales de servicio de EDD
La codificación de las señales
instrucción de EDD
^y
de las señales
servicio de EDD
^aparece en la
Recomendación X.28.
5.2
Procedimientos
5.2.1 En la figura 1/X.351 aparece la secuencia de sucesos para el establecimiento y la liberación de las llamadas originadas en barcos.
Figura 1/X.351, p.
En EDD marítimos se apoyarán los siguientes procedimientos para llamadas
virtuales establecidas por el ETD arrítmico de barco. Estos procedimientos se
basan en los que aparecen en la Recomendación X.28; sin embargo, en los casos
en que los procedimientos descritos a continuación difieren de los
especificados en la Recomendación X.28, o en los casos en que la Recomendación
X.28 describe varios procedimientos posibles, prevalecerán los que se describen
a continuación.
i)El procedimiento será iniciado por el ETD arrítmico de barco, el cual
enviará al EDD una señal
petición de
servicio
formada por los caracteres <2/14(.) 0/13(CR)>.
ii)El EDD responderá dentro de 10 segundos con la señal de
servicio de EDD identificación de EDD
, con el formato
siguiente:
&lab;identificación de EDD y/o puerto> <(CR) (LF)>
(La señal <(CR) (LF)> es el determinante de formato.)
Al recibir esta señal, el ETD arrítmico enviará o bien:
-la señal
instrucción de EDD selección
, o
-una
instrucción de EDD asignación
^(o
instrucción de EDD asignación y
lectura
) para establecer parámetros de EDD específicos seguida de la señal
de
instrucción de EDD selección
, o
-una señal
instrucción de EDD selección de perfil
normalizado
^seguida de la señal
instrucción de EDD selección
.
El formato de la señal
instrucción de EDD selección
^aparece en el anexo A.
petición de facilidad IUR
^contenida en la señal
instrucción de EDD selección
,
transmitirá la señal de
servicio de EDD indicación de
liberación
&lab;CLR NA> y desconectará el trayecto de
información de acceso.
Si el EDD no ha recibido el primer carácter de la señal
instrucción de EDD selección
dentro de 60 segundos, o el
último carácter dentro de 120 segundos, transmitirá la señal de
servicio de EDD error
, y desconectará el trayecto de
información de acceso.
iii)El EDD acusará el recibo de la señal
instrucción de
EDD selección
^dentro de 10 segundos, con la señal de
servicio de EDD acuse de recibo
compuesta por los
caracteres <0/13 (CR) 0/10 (LF)>.
iv)Cuando la llamada virtual se ha llevado al ETD llamado, el EDD devolverá
la señal de servicio de EDD &lab;COM> al ETD arrítmico. El interfaz se
encontrará entonces en el estado transferencia de datos, en el cual se pueden
transferir
Si el ETD arrítmico necesita que los datos se tranfieran en forma
transparente a través del EDD, deberá enviar, bien la señal
instrucción de EDD selección de perfil normalizado
&lab;PROF91>, o la señal
instrucción de EDD asignación
&lab;SET 1:0, 3:0, 4:20, 6:0, 12:0> tan pronto como se reciba la señal de
servicio de EDD
&lab;COM>.
La selección de otros valores de parámetro de EDD se realizará siguiendo el procedimiento descrito en la Recomendación X.28.
Nota
- Cuando se selecciona el perfil transparente, el
ETD arrítmico no podrá salir del estado transferencia de datos y, puesto que no
se dará ninguna señal servicio de EDD, será necesario que exista un
procedimiento de control de llamada entre los dos ETD que comunican. Los ETD de
paquetes, necesitarían para ello un protocolo de una capa superior a la 3.
a)Cuando el parámetro 6 no está puesto a 0, el EDD devolverá la señal de
servicio de EDD confirmación de
liberación
dentro de los 10 segundos que siguen a la
recepción de una señal
instrucción de EDD petición de
liberación
procedente del ETD en el barco, sin esperar un
paquete de confirmación de liberación procedente del ETD de paquetes. Será
responsabilidad del ETD arrítmico la desconexión del trayecto de información de
acceso. Sin embargo, si el ETD arrítmico no desconecta el trayecto de
información de acceso o no envía el primer carácter de una nueva señal
instrucción de EDD
dentro de 20 segundos, el EDD
desconectará el trayecto de información de acceso.
b)Si el parámetro 6 no está puesto 0, el EDD enviará una señal de
servicio de EDD indicación de liberación
al ETD arrítmico
cuando reciba un paquete indicación de liberación procedente de la RPD. El EDD
debe ser capaz de desconectar el
-el ETD arrítmico a bordo no haya desconectado el trayecto de información de acceso,
-no se haya recibido una nueva señal
instrucción de EDD
^procedente del ETD a bordo, o
-no se haya recibido un paquete de llamada entrante al mismo barco procedente de la RPD dentro de este periodo de temporización.
c)Si el parámetro 6 se ha puesto a 0, el ETD a bordo desconectará el trayecto de información de acceso al finalizar la llamada virtual. Si se recibe un paquete indicación de liberación procedente de la RPD, y el ETD a bordo no ha desconectado el trayecto, el EDD deberá poder desconectar el trayecto de información de acceso.
5.2.3 Los EDD marítimos pueden ofrecer, en el plano nacional, perfiles iniciales y procedimientos adicionales a los que se describen en esta Recomendación.
6 Procedimientos para llamadas originadas en la
red pública de datos (RPD)
Estos procedimientos deben ser objeto de estudios ulteriores.
7 Procedimientos para el
intercambio de datos de usuario
7.1
Generalidades
Se deben utilizar los procedimientos que aparecen en la Recomendación X.28, 4 .
7.2
Condiciones especiales para el servicio marítimo por
satélite
Las condiciones siguientes se refieren al largo tiempo de transmisión de ida y retorno en el circuito por satélite (aproximadamente 0,6 segundos).
i)El EDD debe ser capaz de almacenar más de un paquete antes de enviar una señal de control de flujo al ETD arrítmico.
ii)El parámetro M en la Recomendación X.28, 4.6 , debe respetar los valores mínimos indicados en el cuadro 4/X.351.
Cuadro 4/X.351 [T4.351], p.
ANEXO A (a la Recomendación X.351)
Formato de la señal
de instrucción de EDD selección para aplicaciones marítimas
por satélite
Formato general
El formato general de la señal
instrucción de EDD
selección
^se especifica en la Recomendación X.28, y su composición es la
siguiente:
Figura, p.
Se utiliza el carácter 2/12 (,) como un separador entre señales petición de
facilidad, y el carácter 2/13 (-) como separador entre el bloque de petición de
facilidad y la señal dirección de ETD llamado. La señal
instrucción de EDD selección
finaliza con un carácter 0/13
(CR) o 2/11 (+).
Si el EDD recibe una señal
instrucción de EDD
selección
^con un carácter separador 2/12 (,) seguida de un campo de
petición de facilidad vacío, la señal se aceptará siempre que los otros campos
de esta señal se acepten.
La inclusión de datos de usuario en las señales
instrucción
de EDD selección
^debe ser objeto de estudios
ulteriores.
A.2
Señal petición de facilidad de IUR
A.2.1
Formato de la señal petición de facilidad IUR
La señal petición de facilidad IUR tendrá el formato y se enviará en el orden que se muestra a continuación.
Figura, p.
N es el carácter 4/14 (N) del Alfabeto Internacional N.o 5. El código nemónico
de la señal petición de facilidad IUR puede estar formado por 1 a 4 caracteres
de las columnas 2 a 7 del Alfabeto Internacional N.o 5, con la excepción de 2/0
(SP), 7/15 (DEL), 2/13 (-), 2/12 (,) y 2/11 (+).
Validación de la señal petición de facilidad IUR
La estación terrena costera comprobará la autorización general del barco llamante para el acceso al sistema INMARSAT. Por consiguiente, la validación de la señal petición de facilidad IUR puede estar limitada al código mnemónico. Sin embargo, la posibilidad de llamadas fraudulentas se reduciría si en la validación se incluyera también el número móvil INMARSAT.
El número móvil INMARSAT puede utilizarse también para identificar al barco llamante con fines de tasación y para la inserción del campo de dirección de ETD llamante del paquete petición de llamada.
A.3
Composición de la señal dirección de ETD llamado
A.3.1
Llamadas a un ETD de una RPD
La señal dirección de ETD llamado estará formada por el prefijo 0 seguido del número internacional completo del ETD llamado. Esto es aplicable también cuando el ETD llamado está situado en el mismo país que el EDD marítimo.
Llamadas a destinos especiales
En el anexo A de la Recomendación X.350 se definen prefijos de dos dígitos para el acceso a destinos especiales. Para llamadas a tales destinos la dirección de ETD llamado estará formada por el prefijo de dos dígitos, seguido facultativamente de dígitos adicionales.
A.4
Facilidades facultativas
Las facilidades que se deben ofrecer en un EDD marítimo es un asunto que debe determinar la Administración afectada.
El ETD situado a bordo del barco puede solicitar las facilidades disponibles de acuerdo con los procedimientos descritos en la Recomendación X.28.
Posibles ubicaciones de
los EDD en el servicio marítimo por^ satélite
Se puede ubicar a los EDD
del servicio marítimo por satélite
a)El EDD está conectado a una CCD del país en el cual está situada la estación terrena costera. En este caso, una llamada procedente del ETD arrítmico situado a bordo del barco, se encamina desde el sistema telefónico marítimo por satélite a través de la red telefónica hacia el EDD. A los fines de la tarificación, se debe utilizar una señal de identificación de usuario de red (IUR) para la identificación del barco llamante.
Esta solución se puede aplicar independientemente de las facultades de conmutación telefónica de la estación terrena costera. Es la única solución posible cuando la estación terrena costera no incorpora conmutación telefónica.
b)El EDD se encuentra situado en la estación terrena costera, y está conectado al sistema telefónico marítimo por satélite en la estación terrena costera, y a la CCDMS mediante el interfaz definido en la Recomendación X.25. También en este caso se requerirá la señal IUR.
c)El EDD está integrado en la CCDMS, y se utilizan los procedimientos de interfuncionamiento definidos en la Recomendación X.352 para transferir la identificación de línea llamante desde la estación terrena costera hasta la CCDMS. En este caso, no será necesaria la utilización de la señal IUR con propósitos de identificación.
Figure B-1/X.351, p. 23
INTERFUNCIONAMIENTO ENTRE REDES
PúBLICAS DE^ DATOS CON CONMUTACIóN DE PAQUETES Y EL SISTEMA
DE TRANSMISIóN DE DATOS DEL SERVICIO MóVIL MARíTIMO PúBLICO
POR SATéLITE
(Málaga-Torremolinos, 1984; modificada en Melbourne, 1988)
El CCITT,
considerando
(a) que la International Maritime Satellite Organization (Organización Internacional de Telecomunicaciones Marítimas por Satélite) (INMARSAT) explota actualmente un servicio marítimo por satélite;
(b) que es necesario el interfuncionamiento entre el servicio marítimo por satélite y redes públicas de datos;
(c) que la Recomendación X.350 especifica los requisitos generales de interfuncionamiento para la transmisión de datos en sistemas móviles públicos por satélite y la Recomendación X.353 expone los principios de encaminamiento para la interconexión de sistemas móviles públicos por satélite con redes públicas de datos;
(d) que la Recomendación X.25 especifica el interfaz entre terminales de datos y equipos de terminación del circuito de datos para terminales que funcionen en el modo paquetes en redes públicas de datos, y que la Recomendación X.75 especifica procedimientos detallados aplicables al control de llamadas entre redes públicas que proporcionan servicios de transmisión de datos;
(e) que el enlace físico entre una estación terrena móvil y una central de conmutación de datos (CCD) sólo existirá temporalmente, es decir, mientras exista una llamada virtual entre el barco y la CCD;
(f) que la Recomendación X.141 facilita directrices relativas a los principios generales para la detección y correción de errores en las redes públicas de datos,
recomienda por unanimidad
que deben aplicarse los siguientes principios de interfuncionamiento y condiciones de interfaz a las operaciones en la capa de red en el modo paquete entre un ETD móvil y una red pública de datos.
1
Definiciones
Las definiciones de los términos empleados en relación con la transmisión de datos en sistemas móviles públicos por satélite pueden verse en la Recomendación X.350.
Para los fines de esta Recomendación, se define la @
central
de conmutación de datos del servicio móvil por satélite
(CCDMS)
@ como \el interfaz funcional entre el sistema de transmisión de
datos móvil público por satélite y una red pública de datos con conmutación de
paquetes (RPDCP).\
La CCDMS realiza las siguientes funciones:
-interfuncionamiento entre los sistemas de señalización utilizados en el sistema de transmisión de datos móvil público por satélite y la RPDCP;
-encaminamiento y control de las llamadas destinadas a, y procedentes de, estaciones terrenas móviles;
-tarificación.
La composición del sistema de transmisión de datos móvil marítimo público por satélite para la interconexión con una RPD con conmutación de paquetes se muestra en la figura 1/X.352.
La \unidad de acceso de datos con conmutación de paquetes (UADCP)\ proporciona un medio para interconectar un ETD móvil con la red terrestre pública de datos con conmutación de paquetes, a través de una estación terrena móvil y una estación terrena costera equipada con una facilidad de datos con conmutación de paquetes.
Figura 1/X.352, p.
Figura 2/X.352, p.
2
Condiciones de interfaz
Hay que especificar los siguientes interfaces para fines de interfuncionamiento y control de la llamada:
-el interfaz entre el ETD móvil y la UADCP (circuito móvil local);
-el interfaz entre la UADCP y la estación terrena móvil (circuito móvil local);
-el interfaz entre la estación terrena móvil y la estación terrena costera, incluido el interfaz con la estación de coordinación de la red (circuito móvil por satélite);
-el interfaz entre la estación terrena costera y la CCDMS (circuito móvil terrenal).
-el interfaz entre la CCDMS y la RPD con conmutación de paquetes.
En la figura 2/X.352 se muestran los interfaces para las capas 1, 2 y 3.
2.1
Interfaz entre el ETD móvil y la unidad de acceso
de datos con conmutación de paquetes (UADCP)
2.1.1 La
capa 1
^ (capa física) entre el ETD móvil y la
UADCP puede realizarse utilizando los interfaces definidos en:
-la Recomendación X.21,
-la Recomendación X.21^
bis
,
-las Recomendaciones V.24 y V.25.
El interfaz de la Recomendación X.21 debe incluirse en el diseño de las
nuevas UADCP. El interfaz de la Recomendación X.21^
bis
(o
el de la Recomendación V.24) se puede utilizar para los diseños existentes.
Las características básicas del interfaz de capa 1 son:
i)Para llamadas originadas en el ETD móvil, el interfaz debe proporcionar las siguientes funciones:
-debe permitir que el ETD proporcione a la estación terrena móvil la dirección de la estación terrena costera a través de la cual se ha de establecer la comunicación, y el código de petición de acceso del servicio de datos con conmutación de paquetes;
Nota 1
- La dirección del ETD llamado se suministra
dentro del procedimiento del nivel 3.
Nota 2
- La UADCP debe proporcionar una indicación de
progresión de la llamada.
a)visualmente, para uso por un operador; y/o
b)como señales de progresión de la llamada al ETD cuando fracasa la tentativa de establecer el circuito móvil por satélite. Las señales de progresión de la llamada que han de utilizarse se indican en el 6.1 . Puede que tales señales de progresión de la llamada no siempre sean posibles, por ejemplo, cuando el ETD está interconectado con la UADCP a través de un interfaz conforme a la Recomendación V.24.
ii)Para llamadas originadas en la RPD, el interfaz debe permitir la conexión automática del ETD móvil con el circuito.
Para responder a estas exigencias se proporcionarán circuitos de intercambio (denominados también circuitos de enlace). Los circuitos de intercambio necesarios se definen en las Recomendaciones aplicables al interfaz utilizado. Estos circuitos de intercambio se controlarán de tal modo que se garantice el debido establecimiento y liberación del circuito móvil por satélite. Conviene observar también que, como el circuito móvil por satélite se establece llamada por llamada, hay que cerciorarse de que el ETD móvil se ha sincronizado con la temporización de los elementos de la señal de la RPD antes de que se establezca el procedimiento completo en la capa 2. El ETD deberá enviar bits sucesivos de valor 1, hasta obtener el sincronismo.
Véase también la Recomendación X.32.
2.1.2 La
capa 2
^debe cumplir el
2
de la
Recomendación X.25. El campo de control ampliado (módulo 128) puede utilizarse,
si es necesario.
Nota
- Por los motivos indicados en la Recomendación
X.141, puede ser ventajoso utilizar la instrucción de rechazo selectivo (SREJ).
El ETD móvil debe iniciar el envío de la secuencia de bandera tan pronto como se haya establecido el sincronismo con la CCDMS.
2.1.3 La
capa 3
^debe cumplir los
3
a 7 de
la Recomendación X.25.
Los valores por defecto para parámetros de la capa de red tales como el número de conexiones virtuales, uso de la numeración secuencial ampliada de los paquetes, tamaño de ventana, tamaño de paquete y caudal pueden ser definidos por el proveedor del servicio.
La composición del campo de dirección del paquete
petición
de llamada
^se describe en el
4
de esta
Recomendación.
2.2
Interfaz entre la UADCP y la estación terrena
móvil
El interfaz ha de definirse bajo la responsabilidad del proveedor del servicio.
2.3
Interfaz entre la estación terrena móvil y la estación
terrena costera
^(circuito móvil por satélite)
Los procedimientos de establecimiento y liberación del circuito móvil por satélite deberán ser definidos por el proveedor del servicio de acuerdo con los procedimientos de interfuncionamiento definidos en los 2.1 y 2.4.
La estación terrena móvil y la estación terrena costera deben ser transparentes para las capas 2 y 3 de la Recomendación X.25.
Nota
- En el circuito móvil por satélite puede
emplearse la corrección de errores sin canal de retorno para mejorar la
característica de errores de bit. Véase la Recomendación X.141.
2.4
Interfaz entre la estación terrena costera y la
CCDMS
^(circuito móvil terrenal)
El circuito móvil terrenal debe ser transparente para las capas 2 y 3 de la Recomendación X.25.
El interfuncionamiento entre la estación terrena costera y el circuito internacional que interconecta la CCDMS con una RPD debe producirse como sigue:
i)Para llamadas originadas en estaciones móviles, la estación terrena
costera debe proporcionar a la CCDMS el número móvil INMARSAT (véase la
Recomendación E.215/F.125) de la estación terrena móvil llamante para su
inserción en el campo de dirección del ETD llamante del paquete de
petición de llamada
. Esta información se suministrará a la
estación terrena costera como parte del procedimiento de señalización para el
establecimiento del circuito móvil por satélite, y estará disponible antes de
que se haya establecido la capa 3 entre el ETD móvil y la CCDMS.
Nota
- Si no resulta práctico aplicar este
procedimiento, se puede obtener el número móvil INMARSAT mediante la dirección
del ETD llamante en el paquete de
petición de llamada
.
La estación terrena costera, debe también dar una indicación a la CCDMS de que se ha completado el establecimiento del circuito móvil por satélite para que puedan establecerse las capas 2 y 3 del protocolo.
ii)Para llamadas procedentes de una RPD, la CCDMS debe transferir el número
móvil INMARSAT contenido en el paquete de
petición de
llamada
a la estación terrena costera a fin de establecer el circuito
móvil por satélite. Cuando se ha establecido el circuito móvil por satélite, la
estación terrena costera debe proporcionar a la CCDMS una señal que indique que
puede comenzar el establecimiento de las capas 2 y 3.
En el caso de fracaso del establecimiento de la llamada en el circuito móvil
por satélite, la estación terrena costera debe indicar a la CCDMS el motivo del
fracaso del establecimiento de la llamada de forma que la CCDMS pueda devolver
la apropiada señal de progresión de la llamada (y código de diagnóstico) en el
paquete de
petición de liberación
. Las señales de
progresión de la llamada que han de utilizarse se indican en el
6.2
.
iii)La CCDMS debe iniciar el envío de la secuencia de bandera tan pronto como la estación terrena costera haya indicado que ha establecido e interconectado el circuito móvil por satélite.
Si no se ha recibido la secuencia de bandera procedente del ETD móvil dentro de un periodo de temporización dado (o de 6 segundos), la CCDMS deberá iniciar la liberación del circuito de satélite.
A fin de garantizar también un completo control de las llamadas por la CCDMS en el caso de las llamadas originadas en estaciones móviles, la CCDMS puede inicializar la capa 2 enviando la instrucción SABM tan pronto como haya detectado la secuencia de bandera.
iv)Si el circuito móvil por satélite es interrumpido (véase el
7.2
) o liberado de una manera anómala (por ejemplo, postergación por
razones de prioridad) debe darse una indicación a la CCDMS a fin de que se
pueda liberar la parte terrenal del circuito virtual mediante una señal de
progresión de llamada
apropiada.
La CCDMS debe poder en todo momento recibir una indicación de la estación terrena costera de que el circuito por satélite ha sido liberado o interrumpido.
v)La CCDMS debe también poder indicar a la estación terrena costera que puede liberarse el circuito móvil por satélite.
2.5
Interfaz entre la CCDMS y una RDP con conmutación de
paquetes
Este interfaz debe ajustarse a la Recomendación X.75.
3 Procedimientos detallados de
establecimiento y liberación de la llamada
En el anexo A se incluyen ejemplos de procedimientos de establecimiento y liberación de la llamada y el interfuncionamiento entre diversos elementos del sistema.
4
Composición del paquete de
petición de llamada en el ETD móvil
4.1 El formato general del paquete de
petición de
llamada
debe ser el definido en la Recomendación X.25.
4.2 La dirección del ETD llamado deberá componerse como sigue para llamadas destinadas a abonados de una red RPD:
-prefijo 0;
-el número de datos internacional del ETD llamado conforme con la Recomendación X.121.
4.3 La dirección del ETD llamante, compuesto en la forma definida en la
Recomendación X.350, deberá siempre insertarse en el paquete de
petición de llamada
.
4.4 En el servicio móvil marítimo, la dirección del ETD llamante que la CCDMS deberá insertar en el paquete de petición de llamada comprenderá el CIRD (111S) asociado con la zona oceánica en la cual se encuentra el barco y la correspondiente cifra T, seguida del número móvil INMARSAT y, de estar presente, la cifra facultativa que identifica un ETD móvil específico.
4.5 Algunas CCDMS pueden ofrecer acceso a terminaciones especiales mediante el empleo de direcciones abreviadas. La dirección del ETD llamado consistirá en tales casos en la dirección abreviada solamente (véase la Recomendación X.350). Todas estas direcciones abreviadas tendrán una primera cifra diferente de 0 a fin de distinguirlas de las de las llamadas dirigidas a un número de datos internacional. Si la terminación requerida se encuentra en una RPD, la CCDMS debe realizar la necesaria conversión de las cifras al número de datos internacional asociado con la terminación requerida antes de que se pase la llamada a una RPD.
5
Liberación del circuito móvil por
satélite
Si existe más de una llamada virtual, la CCDMS no deberá iniciar la liberación del circuito móvil por satélite al detectar una condición de liberación para una de las llamadas virtuales.
Si existe una sola llamada virtual al recibirse un paquete de petición de liberación de una de las dos partes, la CCDMS iniciará la liberación del enlace HDLC LAPB de la siguiente manera:
i)Si la liberación ha sido iniciada por la RPD, la liberación del enlace HDLC LAPB debe comenzar cuando se cumple una de las dos condiciones siguientes:
-se ha recibido del ETD móvil una
confirmación
de liberación por el ETD
o un paquete de
petición de liberación
;
-ha expirado el temporizador T13 (véase el anexo D a la Recomendación X.25).
Nota 1
- Antes de liberar el enlace HDLC, la CCDMS
puede emitir un paquete de indicación de liberación con el código de
diagnóstico N.o 50 (expiración del temporizador para la indicación de
liberación).
Nota 2
- Es conveniente tener un valor inferior a 60
segundos en el temporizador T13 para las aplicaciones del servicio móvil por
satélite a fin de reducir la carga de tráfico en los circuitos de satélite. El
valor mínimo queda pendiente de estudio adicional.
ii)Si la liberación ha sido iniciada por el ETD móvil, la CCDMS debe enviar
el paquete de
petición de liberación
a la RTD y devolver
inmediatamente un paquete de
confirmación de liberación por el
ETCD
al ETD móvil sin esperar el retorno de ningún paquete de
confirmación de liberación
de la RPD.
Tan pronto como se envía al ETD móvil el paquete de
confirmación de liberación
debe comenzar la liberación del
enlace HDLC.
Nota
- A fin de permitir que el ETD haga una nueva
llamada inmediatamente después de la liberación de la última llamada virtual
existente, la liberación del enlace HDLC puede ser retardada por un breve
periodo de temporización. Si la liberación se inicia desde la RPD, el
temporizador se pondrá en marcha cuando se reciba el paquete de
confirmación de liberación por el ETD
procedente del ETD
móvil. Si la liberación es iniciada por el ETD móvil, el temporizador se pondrá
en marcha cuando el paquete de
confirmación de liberación por
el ETCD
se haya enviado al ETD móvil. Si se recibe un nuevo paquete de
petición
de llamada
de cualquiera de las dos partes,
durante este periodo de temporización, no debe liberarse el circuito de
satélite. La temporización será breve a fin de evitar una ocupación indebida
del circuito de satélite en aquellos casos en que no vaya a efectuarse una
nueva llamada.
Tan pronto como la CCDMS entre en la fase de desconexión, debe darse a la estación terrena costera una indicación de que se puede liberar el enlace físico. La liberación propiamente dicha del circuito móvil por satélite la efectuaría entonces la estación terrena costera.
Nota
- Con los anteriores procedimientos, la
liberación de las capas 1 y 2 la inicia siempre la CCDMS y no se requiere
ningún interfuncionamiento entre capas diferentes en el ETD móvil. Los
procedimientos para el tratamiento de los fallos de la liberación asociados al
circuito móvil por satélite deben ser definidos por el proveedor del servicio.
6
Relación entre señales de
progresión de la llamada, códigos de diagnóstico y sucesos que provocan el
fracaso de la llamada en el circuito móvil por satélite
6.1
Llamadas originadas en estaciones móviles
Cuando proceda, de acuerdo con las capacidades de capa 1 del interfaz con la UADCP, la UADCP deberá proporcionar señales de progresión de la llamada al ETD móvil, de conformidad con el cuadro 1/X.352.
Cuadro 1/X.352 [T1.352], p.
6.2
Llamada entrante desde una RPD
La estación terrena costera deberá indicar a la CCDMS el motivo del fracaso del establecimiento de la llamada por el circuito móvil por satélite. La señal de progresión de la llamada y el código de diagnóstico que debe devolver la CCDMS a la RPD se indican en el cuadro 2/X.352.
La codificación del campo de causa de liberación puede verse en la Recomendación X.25.
7
Supervisión de la interrupción de
un circuito por satélite
7.1
Consideraciones generales
El circuito por satélite puede interrumpirse por varias causas, por ejemplo, bloqueo de la antena en la estación terrena móvil, la estación terrena móvil ya no está dentro de la cobertura del satélite, la estación terrena móvil está defectuosa. La condición de interrupción debe definirla el proveedor del servicio.
La supervisión de la interrupción deben realizarla la estación terrena móvil y la estación terrena costera (o la CCDMS). La supervisión de la interrupción debe asociarse con cada enlace físico.
Tableau 2/X.352 [T2.352], p. 27
7.2
Acciones que debe efectuar la CCDMS
Al detectar una interrupción del circuito móvil por satélite, la CCDMS
deberá enviar a la RPD, por cada circuito virtual afectado, paquetes de
petición de liberación
con la causa de liberación
`congestión en la red'
. El paquete de
indicación de
liberación
deberá enviarse al ETD móvil para facilitar la liberación si la
interrupción sólo existe en un sentido de transmisión. Sin embargo, la CCDMS no
deberá esperar un paquete de
confirmación de liberación por el
ETD
procedente del ETD móvil.
Como la CCDMS no dispone de medios para continuar la supervisión de la
estación terrena móvil (y la condición de interrupción), toda llamada ulterior
a ese ETD móvil deberá tratarse de manera normal. Si la estación terrena móvil
no responde a la llamada, la indicación de causa de liberación deberá ser
`barco ausente'
(véase el cuadro 2/X.352).
Nota
- Por los motivos expuestos, no se aplica el
procedimiento de rearranque de la Recomendación X.25.
7.3
Acciones que debe efectuar el ETD móvil
Para ulterior estudio.
ANEXO A (a la Recomendación X.352)
Procedimientos de
establecimiento y liberación de la llamada para canales de
tipo telefónico
Introducción
En este anexo se describen los procedimientos que es posible aplicar para la liberación de las capas 1, 2 y 3 entre un ETD móvil que funciona en modo paquete y una CCDMS cuando se utilizan canales de tipo telefónico entre la UAPCP y la estación terrena costera. Es importante definir los procedimientos aplicables en este caso pues ello permitirá ofrecer servicios de transmisión de datos de conmutación de paquetes con las estaciones terrenas móviles de los modelos existentes en la actualidad introduciendo sólo una UAPCP.
Como quiera que el enlace físico (capa 1) está subdividido en tres partes
(véase la figura 1/X.352), es preciso transmitir también por el circuito móvil
por satélite una información equivalente a la de los conductores C e I (o los
correspondientes conductores del interfaz definido en la Recomendación
X.21^
bis
) a fin de que la estación terrena costera pueda
controlar totalmente el establecimiento y la liberación de dicho circuito. Ello
puede hacerse en el sistema INMARSAT de norma A utilizando las señales de
continuidad y de liberación dentro de banda especificadas para la telefonía
(ambas son tonos de una sola frecuencia, de 2600 Hz).
Aunque los procedimientos definidos a continuación se basan en la señalización telefónica, serían aplicables unos procedimientos similares para la transmisión de datos por canales de datos especializados (o por canales digitales combinados para conversación y datos). La información de los conductores C e I podría presentarse en tal caso en forma de bits de estado multiplexados junto con los datos digitales en los circuitos T y R (véase también la Recomendación X.51). Se podría establecer entonces la continuidad del circuito marítimo por satélite antes de efectuar la prolongación de la capa 1 hasta el ETD y la CCDMS. Además, la liberación de la capa 1 podría efectuarse con independencia de las capas más altas, lo que permitiría que la estación terrena costera y la estación terrena de barco controlasen totalmente el establecimiento y la liberación del circuito marítimo por satélite.
A.2
Llamada originada en un ETD móvil, en el sistema
INMARSAT de norma A
La figura A-1/X.352 muestra los procedimientos completos de establecimiento y liberación de la llamada para todas las capas del protocolo de control de la llamada y de transferencia de datos entre la CCDMS y un ETD móvil para una llamada originada en ETD móvil, en el sistema INMARSAT de norma A.
Se intercambian las señales siguientes entre la estación terrena costera, la estación terrena móvil y la estación de coordinación de la red utilizando el sistema de señalización por canal común definido por INMARSAT:
-
mensaje de petición
^(enviado por la estación terrena
móvil a la estación terrena costera llamada);
-
petición de asignación
^(enviada por la estación
terrena costera llamada a la estación de coordinación de la red);
-
mensaje de asignación
^(enviado por la estación de
coordinación de la red a la estación terrena móvil y a la estación terrena
costera para indicar el circuito móvil por satélite por el que debe
establecerse la llamada).
Nota
- La estación terrena costera y la estación de
coordinación de la red pueden enviar otros mensajes a fin de indicar el fracaso
del establecimiento de la llamada (por ejemplo, acceso prohibido, congestión).
Para verificar el circuito móvil por satélite, la estación terrena costera inicia una prueba de continuidad del circuito asignado. El circuito móvil terrenal no deberá establecerse antes de que termine la prueba de continuidad. Si la prueba de continuidad falla, la estación terrena costera liberará el circuito.
Para el procedimiento entre la estación terrena costera y la CCDMS, sólo se muestran las señales necesarias para la transferencia de información de interfuncionamiento.
A.3
Llamada procedente de una red pública de datos destinada
a una estación terrena móvil en el sistema INMARSAT de
norma A
La figura A-2/X.352 muestra los procedimientos de establecimiento y liberación de una llamada entrante, procedente de una RPD.
Figure A-1/X.352, p. 28
La dirección (es decir, el número de la estación terrena móvil llamada)
contenido en el paquete de
petición de llamada
se
transfiere a la estación terrena costera. El circuito móvil por satélite se
establece por el método definido en el sistema INMARSAT de norma A similar a
los descritos en el Î A.2. En la estación terrena móvil se desactiva la señal
de continuidad cuando la UADCP retorna la señal
`colgado'
, de modo que
se puede señalizar llamada conectada a la CCDMS.
El paquete de
llamada conectada
^se devuelve a la RPD
cuando se recibe del ETD móvil el paquete de
llamada
aceptada
.
El fracaso de una llamada puede ser detectado por la estación terrena costera en varias etapas durante la fase de establecimiento:
-a partir de indicaciones dadas por la estación de coordinación de la red (por ejemplo, estación móvil ocupada, congestión);
-fallo de la prueba de continuidad del circuito móvil por satélite (por ejemplo, no hay respuesta del barco).
La estación terrena costera debe en tales casos proporcionar una indicación
apropiada a la CCDMS de forma que pueda devolverse a la RPD un paquete de
petición de liberación
.
PRINCIPIOS DE ENCAMINAMIENTO PARA LA
INTERCONEXIóN DE SISTEMAS DE TRANSMISIóN DE DATOS MóVILES
MARíTIMOS PúBLICOS POR SATéLITE CON REDES PúBLICAS DE
DATOS
(Málaga-Torremolinos, 1984; modificada en Melbourne, 1988)
El CCITT,
considerando
(a) que la International Maritime Satellite Organization (Organización Internacional de Satélites Marítimos) (INMARSAT) explota actualmente un servicio móvil marítimo público por satélite;
(b) que los abonados móviles pueden tener acceso al servicio a través de un número de estaciones terrenas costeras situadas en diferentes países;
(c) que se requiere el interfuncionamiento entre el sistema de transmisión de datos móvil por satélite y redes públicas de datos;
(d) que la Recomendación X.110 especifica los principios de encaminamiento para los servicios públicos internacionales de datos, la Recomendación X.121 especifica el plan de numeración internacional para redes públicas de datos, y la Recomendación E.215/F.125. proporciona una identificación de estación terrena móvil única en el plano internacional;
(e)que se están definiendo nuevos sistemas móviles para aplicaciones marítimas y aeronáuticas,
recomienda por unanimidad
que los siguientes principios de encaminamiento se apliquen para el establecimiento de llamadas (o comunicaciones) entre abonados de las redes públicas de datos y usuarios de sistemas de transmisión de datos móviles marítimos públicos internacionales por satélite.
1
Generalidades
1.1
Definiciones
La figura 1/X.353 muestra la composición de los sistemas en el servicio móvil marítimo público por satélite. Para la definición de los diversos elementos, véase la Recomendación X.350.
La @central de conmutación de datos del servicio móvil marítimo por satélite (CCDMS)\ se define en el 1.7 de la Recomendación X.350.
1.2
Cometido de la CCDMS
Una CCDMS actuará al mismo tiempo como cabecera internacional y como interfaz con las estaciones terrenas móviles. Dentro de una zona oceánica, una estación terrena móvil marítima pública puede establecer o recibir llamadas (comunicaciones) de datos desde cualquier CCDMS en esa región. Cada zona oceánica puede tener varias CCDMS.
Una CCDMS puede tener acceso a más de un satélite y por tanto servir a más de una zona oceánica.
Una CCDMS puede servir a uno o más sistemas móviles marítimos públicos.
La CCDMS puede estar conectada a más de una @central (o centro) internacional de conmutación de datos (CICD)\ en una red pública de datos (RPD). La CCDMS puede también estar conectada a más de una CICD en diferentes RPD.
En esta Recomendación se parte del supuesto de que una RPD no conecta con más de una CCDMS que sirve a la misma zona oceánica y sistema móvil marítimo público por satélite (como INMARSAT normas A, B y C).
2
Encaminamiento
de llamadas originadas en estaciones terrenas móviles marítimas
públicas
2.1
Una estación terrena móvil marítima pública llama
a un abonado de la red terrestre
La estación terrena móvil selecciona una CCDMS en la zona oceánica mediante procedimientos de señalización definidos en el servicio móvil por satélite. Se debe aconsejar al usuario móvil que haga la llamada a través de la CCDMS que se encuentre más cerca del abonado llamado, a fin de evitar rutas terrenales largas.
El abonado de la estación terrena móvil marítima pública proporciona a la CCDMS el número de datos internacional del abonado llamado y esta central encaminará la llamada a través la CICD a que está asociada (o a través de la CICD más conveniente, si la CCDMS estuviese conectada a más de una CICD).
FIGURA 1/X.353, p.
2.2
Una estación terrena móvil marítima pública llama a
otra estación terrena móvil
Si dos estaciones terrenas móviles marítimas públicas están en la misma zona oceánica o se encuentran en dos zonas oceánicas diferentes pero servidas por la misma CCDMS, esta central establece la llamada directamente a la estación terrena móvil marítima pública solicitada, y es la única CCDMS que interviene en la llamada.
Nota
- Si la CCDMS no tiene una plena capacidad de
conmutación, la llamada se encaminará primeramente a la CICD asociada y después
retornará a la CCDMS.
Si las dos estaciones terrenas móviles marítimas públicas se encuentran en zonas oceánicas diferentes que no son servidas por la misma CCDMS, la CCDMS llamante encaminará la llamada de acuerdo con lo estipulado en el 2.1 .
2.3
Encaminamiento de peticiones de servicios
especiales
Se puede ganar acceso a ciertos servicios (por ejemplo, a bases de datos que proporcionan avisos para la navegación, partes meteorológicos, etc.) utilizando códigos numéricos abreviados especiales, definidos dentro de los sistemas móviles marítimos públicos por satélite. Estos códigos abreviados deben ser convertidos en el número de datos internacional completo para que la llamada pueda enviarse de la CCDMS a una RPD.
2.4
Información proporcionada a las estaciones
terrenas móviles
Las administraciones que operan las CCDMS deben preparar y mantener actualizada la información, destinada a las estaciones terrenas móviles, relativa a las posibilidades de encaminamiento hacia los diversos destinos.
3
Encaminamiento de llamadas de
tierra a estaciones terrenas móviles marítimas públicas
3.1
Principios de encaminamiento
De acuerdo con la Recomendación X.121, se asigna un CIRD a cada zona oceánica. Estos CIRD tienen la forma 111S, siendo S la zona oceánica. Los valores asignados se indican en la Recomendación X.121.
Además, la primera cifra del siguiente número de terminal de red (NTR) en
el sistema móvil marítimo público por satélite es la cifra
`T'
, definida
en la Recomendación E.215/F.125, que se utiliza para distinguir entre
diferentes sistemas móviles marítimos públicos por satélite.
Un usuario llamante sólo puede indicar la zona oceánica y el tipo de sistema móvil marítimo público por satélite (como INMARSAT normas A, B y C) al que se dirige la llamada, y no puede seleccionar una CCDMS específica. En consecuencia, cada red de origen y/o de destino tiene normalmente que encaminar las llamadas de datos con uno de los CIRD de sistema móvil marítimo público a una CCDMS predeterminada que sirve a la zona oceánica y al tipo de sistema indicado por el CIRD y la cifra T de acuerdo con un convenio bilateral entre la administración de origen y la administración que opera la CCDMS. Por tanto, se requiere el análisis de cinco cifras del número llamado para fines de encaminamiento.
Deberán celebrarse acuerdos similares con las Amdministraciones que operan redes de tránsito que participarán en el establecimiento de la conexión.
Pueden presentarse situaciones en que dos Administraciones estén utilizando la misma red de tránsito para el encaminamiento de sus llamadas a dos CCDMS diferentes dentro de la misma zona oceánica, es decir, dos CCDMS con el mismo CIRD y cifra T. Esto se solucionará encaminando la llamada de acuerdo con el CIRD de la administración de origen.
3.2
Encaminamiento en base a la información del campo de
facilidad
Si la CCDMS (o la red de tránsito asociada) no proporciona una facilidad determinada, cuando se pide una llamada en que se solicita esa facilidad, la administración, en lugar de prohibir la llamada, puede optar por establecerla a través de una CCDMS o una red de tránsito distinta de la utilizada normalmente por dicha administración.
3.3
Reencaminamiento de llamadas en la CCDMS
Las CCDMS que tienen acceso a dos satélites pueden tener la facultad de reencaminar llamadas entre las zonas de cobertura de esos dos satélites. En el reencaminamiento de llamadas por las CCDMS se permite al usuario de la red terrestre pedir el reencaminamiento de llamadas a otro número de datos (pero a la misma estación terrena móvil marítima pública) que difiera solamente en el código de zona oceánica, cuando una estación terrena móvil está ausente de la zona oceánica indicada por el número de datos original. El reencaminamiento de una llamada entre las dos zonas oceánicas cubiertas por la CCDMS podrá efectuarse una sola vez.
La condición para que el reencaminamiento sea posible es que la estación terrena móvil marítima pública esté incluida en la lista de estaciones terrenas móviles y no tenga prohibido el acceso de llegada.
El CIRD que ha de devolverse como parte de la identificación de la línea llamada, o la necesidad de devolver en tales casos una identificación de la línea llamada, deberán ser objeto de ulterior estudio.
El reencaminamiento general de llamadas en base a la información contenida en un registro de posiciones del servicio móvil por satélite es conveniente. Esto puede exigir modificaciones de Recomendaciones existentes de la serie X y de las especificaciones del sistema móvil marítimo público por satélite y por lo tanto, debe ser objeto de ulterior estudio.
Nota
- Véase también el
3.1
.
4
Llamadas a grupos
En general, deben prohibirse las llamadas con una dirección de grupo (definidas en la Recomendación E.215/F.125). Estas direcciones son números de estación terrena móvil marítima pública con una cifra T de valor 0. La llamada debe bloquearse preferiblemente en la red de origen. Sin embargo, la CCDMS tendrá en todo caso la posibilidad de prohibir esas llamadas (véase también la Recomendación X.350).
5 Utilización de
enlaces por satélite
El enlace entre la estación terrena costera y una estación terrena móvil marítima pública es siempre por satélite.
A fin de proporcionar una calidad de servicio aceptable, el número de enlaces por satélite permitidos en una conexión de datos debe estar limitado. (Véase el anexo B a la Recomendación X.110.)
En consecuencia, en el caso de una llamada destinada a una estación terrena móvil marítima pública, todas las centrales de tránsito deben saber, en base al CIRD de destino 111S, que el tramo final es un enlace por satélite, y efectuar el encaminamiento de manera que no se rebase el tiempo de transferencia máximo permitido del usuario llamante al llamado.
Nota
- El mecanismo en virtud del cual una red de
tránsito determina el retardo de tránsito ya transcurrido en el establecimiento
de una llamada será objeto de ulterior estudio.
GESTIóN DE INTERFUNCIONAMIENTO
Recomendación X.370
DISPOSICIONES PARA LA TRANSFERENCIA DE INFORMACIóN
DE GESTIóN INTERREDES
(Melbourne, 1988)
El CCITT,
considerando
(a) que la Recomendación X.1 define las clases de servicio internacionales de usuario en redes públicas de datos y en la RDSI;
(b) que la Recomendación X.2 define los servicios y facilidades internacionales de usuario en RPD y en la RDSI;
(c) que la Recomendación X.10 define las diversas categorías de acceso de equipos terminales de datos (ETD) a los diferentes servicios de transmisión de datos proporcionados por redes públicas de datos (RPD) y la RDSI;
(d) que la Recomendación X.96 define las señales de progresión de la llamada, incluidas las que se utilizan conjuntamente con facilidades internacionales de usuario;
(e) que las Recomendaciones X.20, X.20^
bis
, X.21,
X.21^
bis
, X.25, X.28 y X.29 ya especifican los
procedimientos detallados aplicables a los diferentes tipos de interfaces
ETD/ETCD en las RPD;
(f) que las Recomendaciones X.61, X.70, X.71 y X.75 ya especifican los procedimientos detallados aplicables al control de las comunicaciones entre dos RPD del mismo tipo;
(g) que las RPD se pueden utilizar para soportar servicios recomendados por el CCITT (en particular, servicios telemáticos);
(h) que la Recomendación X.200 especifica el modelo de referencia de interconexión de sistemas abiertos para aplicaciones del CCITT;
(i) que la Recomendación X.213 define el servicio de capa de red de interconexión de sistemas abiertos para las aplicaciones del CCITT;
(j) la necesidad de considerar el interfuncionamiento con la red de señalización por canal común (RSCC), teniendo en cuenta las condiciones para la transferencia de información operacional entre las Administraciones;
(k) la necesidad de que los ETD puedan comunicar a través de redes diferentes, y en diferentes condiciones de interfuncionamiento entre redes;
(l) la necesidad de establecer principios y disposiciones generales para el interfuncionamiento entre redes públicas de datos, y entre éstas y otras redes públicas;
(m) la necesidad, en particular:
-de ciertas facilidades de usuario y utilidades de red para la comunicación, a través de redes nacionales, entre los protocolos de interfaz de equipo terminal de datos definidos en el plano internacional y los procedimientos de control y señalización internacionales entre centrales,
-de ciertas utilidades de red definidas en el plano internacional para la operación internacional de redes públicas de datos,
-de que los principios relativos a la realización de facilidades de usuario y de utilidades de red internacionales, en redes públicas de datos, sean compatibles y uniformes,
recomienda por unanimidad
que los principios y disposiciones generales para el interfuncionamiento entre redes públicas de datos, y entre éstas y otras redes públicas, y que los elementos necesarios:
-para las disposiciones para la transferencia de información de gestión interredes, concuerden con los principios y procedimientos especificados en esta Recomendación.
íNDICE
1
Condiciones generales para la transferencia de información
de gestión interredes
2
Disposiciones detalladas en la capa de red para la
transferencia de información de gestión interredes
3
Disposiciones detalladas en la capa de transporte para
la transferencia de información de gestión interredes
4
Disposiciones detalladas en la capa de sesión
5
Disposiciones detalladas en la capa de presentación
6
Disposiciones detalladas en la capa de aplicación
1 Condiciones generales para la
transferencia de información de gestión interredes
La transferencia de información de gestión interredes de redes públicas de datos se efectuará de conformidad con el modelo de referencia para aplicaciones ISA definido por el CCITT, como se ilustra en las figuras 1 y 2/X.370:
Figura 1/X.370, p.
Figura 2/X.370, p.
2 Disposiciones detalladas en la capa de la
red para transferencia de información de gestión interredes
Los servicios ISA considerados en la capa de red se ajustarán a la Recomendación X.213.
Para ganar acceso a estos servicios ISA, los protocolos en las capas física, de enlace y de red serán función de las redes que participen en la transferencia de información de gestión. Los protocolos precisos que se utilizarán se especifican en secciones anteriores de esta Recomendación.
3 Disposiciones detalladas en la capa de
transporte para la transferencia de información de gestión interredes
Los servicios ISA considerados en la capa de transporte se ajustarán a la Recomendación X.214.
El protocolo a utilizar en la capa de transporte se ajustará a la Recomendación X.224.
Las características precisas del protocolo de la capa de transporte (a saber, la clase de protocolo de transporte, etc.) aplicable a la transferencia de información de gestión deberán ser objeto de ulterior estudio.
4 Disposiciones detalladas en la capa de
sesión
(Para ulterior estudio.)
Los servicios ISA considerados en la capa de sesión se ajustarán a la Recomendación X.215.
El protocolo a utilizar en la capa de sesión se ajustará a la Recomendación X.225.
Las características precisas de los servicios y el protocolo en la capa de sesión, aplicables a la transferencia de información de gestión, deberán ser objeto de ulterior estudio.
5 Disposiciones detalladas en la capa de
presentación
(Para ulterior estudio.)
6 Disposiciones detalladas en la capa de
aplicación
(Para ulterior estudio.)
Extraction et codification 3.11.89 PC
MEP 17.11.89 PC
Corr. MEP ........ ..
Corr. DIGISET 7.12.89 PC
MAJ disquettes ........ ..
íNDICE DEL FASCíCULO VIII.7 DEL LIBRO AZUL
Recomendaciones X.400 a X.420
Redes de comunicación de datos: Sistemas de
tratamiento de mensajes
Rec. N.o Página X.400Sistema de tratamiento de mensajes: visión de conjunto del
sistema y del servicio 3
X.402 Sistemas de tratamiento de mensajes: arquitectura global 75
X.403 Sistemas de tratamiento de mensajes: pruebas de conformidad 147
X.407 Sistemas de tratamiento de mensajes: convenios para la definición del
servicio abstracto 200
X.408 Sistemas de tratamiento de mensajes: reglas de conversión de tipos de
información codificada 228
X.411 Sistemas de tratamiento de mensajes: sistema de transferencia de
mensajes: definición del servicio abstracto y procedimientos 272
2 En este fascículo, la expresión
`Administración'
se utiliza para
designar, en forma abreviada, tanto una Administración de telecomunicaciones
como una empresa privada de explotación de telecomunicaciones reconocida.
3 Los términos anexo y apéndice a las Recomendaciones de la serie X deberán interpretarse como sigue (salvo que se especifique lo contrario):
- el
anexo
a una Recomendación forma parte
integrante de la misma;
- el
apéndice
a una Recomendación no forma
parte integrante de la misma y tiene solamente por objeto
proporcionar explicaciones o informaciones complementarias
específicas a dicha Recomendación.
4 Algunas de las Recomendaciones de la serie X contenidas en este fascículo se desarrollaron conjuntamente y en colaboración con la ISO/CEI. En el cuadro que sigue se facilitan las referencias mutuas entre esas Recomendaciones y las normas ISO/CEI correspondientes.
Recomendación del CCITT Norma ISO/CEI X.400 ISO 10021-1, Information processing systems - Text communication - Message oriented text interchange system - Part 1: System and service overview^a). X.402 ISO 10021-2, Information processing systems - Text communication - Message oriented text interchange system - Part 2: Overall architecture^a). X.407 ISO 10021-3, Information processing systems - Text communication - Message oriented text interchange system - Part 3: Abstract service definition co nventions^a). X.411 ISO 10021-4, Information processing systems - Text communication - Message oriented text interchange system - Part 4: Message transfer system: Abstract service definition and procedures^a). X.413 ISO 10021-5, Information processing systems - Text communication - Message oriented text interchange system - Part 5: Message store: Abstract service definition.^a) X.419 ISO 10021-6, Information processing systems - Text communication - Message oriented text interchange system - Part 6: Protocol specifications^a). X.420 ISO 10021-7, Information processing systems - Text communication - Message oriented text interchange system - Part 7: Interpersonal messaging system^a). a)Actualmente a nivel de proyecto de norma internacional (PNI).
Anexo D DISK. 2 NF01/008 OPM = 02 - DISK. 2 NF01/008 OPM = 02 Recomendación U.204 DISK. 2 NF01/011 OPM = 02 UATLXP DISK. 2 NF01/017 OPM = 02 DISK. 2 NF01/017 OPM = 02 (cs,)
(1BT) (BT..)
(87.TE.01.S)
(A1.23s) / [26s]
FOLIOS: 1 - 41
(DO PRC.COSY.2)
MEP {TPS.NON.PHOTO "[PA1]"} : OK= [1]
Saisie 23.10.89 UT
ID + LASER REPRIS DU VOL. VI 23.10.89 AF
MAJ diskette ........ ..
Corr. LASER (1re épreuve) = 3eme 31.10.89 UT
Espaces réservés ........ ..
AJOUTER (PA1) (CL1,0,0,0) pour MEP
MEP + LASER ........ ..
Corr. MEP ........ ..
Insertion des tableaux (tabulateurs...) ........ ..
BAT du 13/11/89 16.11.89 PV
MAJ s/disquettes 6.12.89 CD
FASCíCULO VIII.7
Recomendaciones X.400 a X.420
REDES DE COMUNICACIóN DE DATOS: SISTEMAS DE
TRATAMIENTO DE MENSAJES
MONTAGE:
page 2 = page blanche.
Recomendación X.400
La Recomendación F.400 es idéntica a la
Recomendación X.400.
SISTEMA DE TRATAMIENTO DE MENSAJES:
VISIóN DE CONJUNTO DEL SISTEMA Y DEL SERVICIO
El CCITT,
considerando
(a) la necesidad de sistemas de tratamiento de mensajes;
(b) la necesidad de transferir y almacenar mensajes de diferentes tipos;
(c) que la Recomendación X.200 define el modelo de referencia de interconexión de sistemas abiertos para aplicaciones del CCITT;
(d) que las Recomendaciones X.208, X.217, X.218 y X.219 sirven de base para las aplicaciones del CCITT;
(e) que las Recomendaciones de la serie X.500 definen los sistemas de guía;
(f)que los sistemas de tratamiento de mensajes se definen en la serie de Recomendaciones X.400, X.402, X.403, X.407, X.408, X.411, X.413 y X.419;
(g) que la mensajería interpersonal se define en las Recomendaciones X.420 y T.330;
(h) que varias Recomendaciones de la serie F describen los servicios públicos de tratamiento de mensajes: F.400, F.401, F.410 y F.420;
(i) que varias Recomendaciones de la serie F describen la intercomunicación entre los servicios públicos de tratamiento de mensajes y otros servicios: F.421, F.415 y F.422,
recomienda por unanimidad
que la visión de conjunto del sistema y del servicio de tratamiento de mensajes sea la definida en la presente Recomendación.
íNDICE
PARTE 1 -
Introducción
0
Introducción
1
Objeto
2
Referencias
3
Definiciones
4
Abreviaturas
5
Convenios
PARTE 2 -
Descripción general de STM
6
Finalidad
7
Modelo funcional del STM
7.1Descripción del modelo STM
7.2Estructura de los mensajes
7.3Aplicación del modelo STM
7.4Memoria de mensajes
8
Servicio de transferencia de mensajes
8.1Depósito y entrega
8.2Transferencia
8.3Notificaciones
8.4Agente de usuario
8.5Memoria de mensajes
8.6Unidad de acceso
8.7Empleo del STRM en la prestación de servicios públicos
9
Servicios de mensajería interpersonal (MIP)
9.1Modelo funcional del servicio de mensajería interpersonal (MIP)
9.2Estructura de los mensajes IP
9.3Notificaciones IP
10
Intercomunicación con los servicios de entrega
física
10.1Introducción
10.2Configuraciones de organización
11
Acceso especializado
11.1Introducción
11.2Acceso teletex
11.3Acceso télex
PARTE 3 -
Capacidades del STM
12
Denominación y direccionamiento
12.1Introducción
12.2Nombre de guía
12.3Nombres O/D
12.4Direcciones O/D
13
Utilización de la guía por el STM
13.1Introducción
13.2Modelo funcional
13.3Configuraciones físicas
14
Listas de distribución en el STM
14.1Introducción
14.2Propiedades de una LD
14.3Depósito
14.4Utilización de una guía por la LD
14.5Expansión de la LD
14.6Jerarquización
14.7Control de repetición
14.8Entrega
14.9Control del bucle de encaminamiento
14.10Notificaciones
14.11Política de tratamiento de LD
15
Capacidades de seguridad del STM
15.1Introducción
15.2Riesgos que afectan a la seguridad al STM
15.3Modelo de seguridad
15.4Características de seguridad del STM
15.5Gestión de la seguridad
16
Conversión en el STM
17
Utilización del STM en la prestación de servicios
públicos
PARTE 4 -
Elementos de servicio
18
Finalidad
19
Clasificación
19.1Finalidad de la clasificación
19.2Servicio de transferencia de mensajes básico
19.3Facilidades facultativas de usuario del servicio TRM
19.4Intercomunicación de los servicios TM/EF de base
19.5Facilidades facultativas de usuario para la intercomunicación de los servicios TM/EF
19.6Memoria de mensajes de base
19.7Facilidades facultativas de usuario de la MM
19.8Servicio de mensajería interpersonal básico
19.9Facilidades facultativas de usuario del servicio MIP
Anexo A
-Glosario de términos
Anexo B
-Definiciones de los elementos de servicio
Anexo C
-Cambios de los elementos de servicio a partir
de 1984
Anexo D
-Diferencias entre la Recomendación F.400 del
CCITT y la norma ISO 10021-1
PARTE 1 - INTRODUCCIóN
0 Introducción
La presente Recomendación forma parte de una serie de Recomendaciones sobre el tratamiento de mensajes. Esta serie proporciona una especificación completa de los sistemas de tratamiento de mensajes compuestos por cualquier número de sistemas abiertos cooperantes.
Los sistemas y servicios de tratamiento de mensajes permiten a los usuarios intercambiar mensajes empleando medios de almacenamiento y retransmisión. Un mensaje depositado por un usuario, el originador, es transmitido por el sistema de transferencia de mensajes (STRM), componente principal de un sistema más amplio de tratamiento de mensajes (STM), y entregado a continuación a uno o más usuarios destinatarios del mensaje.
El STM se compone de diversas entidades funcionales interconectadas. Los agentes de transferencia de mensajes (STM) cooperan en la ejecución de la función de transferencia de mensajes con almacenamiento y retransmisión. Los dispositivos de almacenamiento de mensajes (AM) constituyen el medio de almacenamiento de los mensajes y permiten el depósito, la extracción y gestión de éstos. Los agentes de usuario (AU) ayudan a los usuarios a obtener acceso al STM. Las unidades de acceso (UA) proporcionan enlaces con otros sistemas y servicios de comunicación de diversa naturaleza (por ejemplo, otros servicios telemáticos, servicios postales).
Esta Recomendación describe globalmente el sistema y el servicio correspondientes a las capacidades de tratamiento de mensajes.
1
Objeto
La presente Recomendación define globalmente el sistema y el servicio de un STM, y proporciona una descripción general de éste.
En otras Recomendaciones, se definen otros aspectos de los sistemas y servicios de tratamiento de mensajes. La distribución de las Recomendaciones que definen el sistema y los servicios de tratamiento de mensajes se muestra en el cuadro 1/X.400. Los servicios públicos construidos sobre un STM, así como el acceso a y desde el STM para servicios públicos se definen en las Recomendaciones de la serie F.400.
Los aspectos técnicos del STM se definen en las Recomendaciones de la serie X.400. La arquitectura global del STM se define en la Recomendación X.402.
Tableau 1/X.400 [T1.400], p. 1
2
Referencias
En esta Recomendación se citan los siguientes documentos:
Recomendación F.60Disposiciones relativas a la explotación del servicio télex internacional
Recomendación F.69Plan de códigos télex de destino
Recomendación F.72Almacenamiento y retransmisión télex internacional - Principios generales y aspectos operacionales
Recomendación F.160Disposiciones generales relativas a la explotación de los servicios facsímil públicos internacionales
Recomendación F.200Servicio teletex
Recomendación F.300Servicio videotex
Recomendación F.400Sistema de tratamiento de mensajes: Visión de conjunto del sistema y del servicio (véase también ISO 10021-1)
Recomendación F.401Servicios de tratamiento de mensajes: Denominación y direccionamiento para los servicios públicos de tratamiento de mensajes
Recomendación F.410Servicios de tratamiento de mensajes: Servicio público de transferencia de mensajes
Recomendación F.415Servicios de tratamiento de mensajes: Intercomunicación con los servicios públicos de entrega física
Recomendación F.420Servicios de tratamiento de mensajes: Servicio público de mensajería interpersonal
Recomendación F.421Servicios de tratamiento de mensajes: Intercomunicación entre el servicio MIP y el servicio télex
Recomendación F.422Servicios de tratamiento de mensajes: Intercomunicación entre el servicio MIP y el servicio teletex
Recomendación T.61Repertorio de caracteres y juegos de caracteres codificados para el servicio teletex internacional
Recomendación T.330Acceso telemático al servicio de mensajería interpersonal
Recomendación U.80Almacenamiento y retransmisión télex internacional - Acceso desde el télex
Recomendación U.204Interfuncionamiento entre el servicio télex y el servicio público de mensajería interpersonal
Recomendación X.200Modelo de referencia de interconexión de sistemas abiertos para aplicaciones del CCITT (véase también ISO 7498)
Recomendación X.208Especificación de la notación de sintaxis abstracta uno (NSA.1) (véase también ISO 8824)
Recomendación X.209Especificación de las reglas básicas de codificación para la notación de sintaxis abstracta uno (NSA.1) (véase también ISO 8825)
Recomendación X.217Definición del servicio de control de asociación para la interconexión de sistemas abiertos para aplicaciones del CCITT (véase también ISO 8649)
Recomendación X.218Transferencia fiable: Modelo y definición del sistema (véase también ISO/CEI 9066-1)
Recomendación X.219Operaciones a distancia: Modelo, notación y definición del servicio (véase también ISO/CEI 9072-1).
Recomendación X.400Sistema de tratamiento de mensajes: Visión de conjunto del sistema y del servicio (véase también ISO/CEI 10021-1)
Recomendación X.402Sistemas de tratamiento de mensajes: Arquitectura global (véase también ISO/CEI 10021-2)
Recomendación X.403Sistemas de tratamiento de mensajes: Pruebas de conformidad
Recomendación X.407Sistemas de tratamiento de mensajes: Convenios para la definición del servicio abstracto (véase también ISO/CEI 10021-3)
Recomendación X.408Sistemas de tratamiento de mensajes: Reglas de conversión de los tipos de información codificada
Recomendación X.411Sistemas de tratamiento de mensajes: Sistema de transferencia de mensajes: definición del servicio abstracto y procedimientos (véase también ISO/CEI 10021-4)
Recomendación X.413Sistemas de tratamiento de mensajes: Definición del servicio abstracto de almacenamiento de mensajes (véase también ISO/CEI 10021-5)
Recomendación X.419Sistemas de tratamiento de mensajes: Especificaciones de protocolo (véase también ISO/CEI 10021-6)
Recomendación X.420Sistemas de tratamiento de mensajes: Sistema de mensajería interpersonal (véase también ISO/CEI 10021-7)
Recomendación X.500La Guía - Visión de conjunto de conceptos, modelos y servicios (véase también ISO/CEI 9594-1)
Recomendación X.501La Guía - Modelos (véase también ISO/CEI 9594-2)
Recomendación X.509La Guía - Marco de autenticación (véase también ISO/CEI 9594-8)
Recomendación X.511La Guía - Definición del servicio abstracto (véase también ISO/CEI 9594-3)
Recomendación X.518La Guía - Procedimientos para operación distribuida (véase también ISO/CEI 9594-4)
Recomendación X.519La Guía - Especificaciones de protocolos (véase también ISO/CEI 9594-5)
Recomendación X.520La Guía - Tipos de atributo seleccionados (véase también ISO/CEI 9594-6)
Recomendación X.521La Guía - Clases de objeto seleccionadas (véase también ISO/CEI 9594-7)
3
Definiciones
Esta Recomendación utiliza los términos relacionados a continuación, así como los definidos en el anexo A.
Las definiciones de los elementos de servicio aplicables al STM se encuentran en el anexo B.
3.1
Interconexión de sistemas abiertos
Esta Recomendación utiliza los siguientes términos, definidos en la Recomendación X.200:
a)capa de aplicación,
b)proceso de aplicación,
c)interconexión de sistemas abiertos,
d)modelo de referencia ISA.
3.2
Sistemas de Guía
Esta Recomendación utiliza los siguientes términos, definidos en la Recomendación X.500:
a)inscripción de guía,
b)agente del sistema de guía,
c)sistema de guía,
d)agente de usuario de guía.
Esta Recomendación utiliza los siguientes términos, definidos en la Recomendación X.501:
e)atributo,
f)grupo,
g)miembro,
h)nombre.
4
Abreviaturas
@AAdicional \
@DGADDominio de gestión de administración \
@AUUnidad de acceso \
@ACAcuerdo contractual \
@LDLista de distribución \
@ASGAgente de sistema de guía \
@AUGAgente de usuario de la guía \
@EEsencial \
@TICTipo de información codificada \
@E/SEntrada/salida \
@IPInterpersonal \
@MIPMensajería interpersonal \
@SMIPSistema de mensajería interpersonal \
@DGDominio de gestión \
@TMTratamiento de mensajes \
@STMSistema de tratamiento de mensajes \
@MMMemoria de mensajes; almacenador de mensajes (AM) \
@TRMTransferencia de mensajes \
@ATMAgente de transferencia de mensajes \
@STRMSistema de transferencia de mensajes \
@N/ANo aplicable \
@O/DOriginador/destinatario \
@ISAInterconexión de sistemas abiertos \
@EFEntrega física \
@UAEFUnidad de acceso de entrega física \
@SEFSistema de entrega física \
@PMPor mensaje \
@PDPor destinatario \
@DGPRDominio de gestión privado \
@UATLXPUnidad de acceso de télex público \
@ATLMAgente telemático \
@UATLXUnidad de acceso al télex \
@TTXTeletex \
@AUAgente de usuario \
5
Convenios
En esta Recomendación, la expresión
`Administración'
se utiliza como
forma abreviada para indicar una Administración de telecomunicaciones, una
empresa privada de explotación reconocida y, en el caso de intercomunicación
con el servicio de entrega física, una Administración postal.
Nota
- Esta Recomendación es idéntica a la
Recomendación F.400. Debido a la armonización deseada con la ISO, se han
adoptado convenios de las normas de la ISO para la estructura de este texto.
Dichos convenios difieren del estilo del CCITT. Las demás Recomendaciones de la
serie X.400 son conformes a los convenios del CCITT.
6
Finalidad
La presente Recomendación forma parte de una serie de Recomendaciones y describe el modelo del sistema de tratamiento de mensajes y los elementos del servicio de tratamiento de mensajes (STM). En ella se pasa revista a las capacidades de un STM que utilizan las Administraciones para proporcionar servicios TM públicos que permiten a los abonados intercambiar mensajes con almacenamiento y retransmisión.
El sistema de tratamiento de mensajes está diseñado de acuerdo con los principios del modelo de referencia de interconexión de sistemas abiertos (modelo de referencia ISA) para aplicaciones del CCITT (Recomendación X.200) y utiliza los servicios de capa de presentación y servicio ofrecidos por otros elementos de servicio de aplicación más generales. Un STM puede construirse utilizando cualquier red que se adapte al objeto de la ISA. El servicio de transferencia de mensajes proporcionado por el STRM es independiente de la aplicación. Un ejemplo de aplicación normalizada es el servicio MIP. Los sistemas de extremo pueden utilizar el servicio de TRM para aplicaciones específicas que se definen en forma bilateral.
Los servicios de tratamiento de mensajes proporcionados por las Administraciones pertenecen al grupo de servicios telemáticos definidos en las Recomendaciones de la serie F.
Otros servicios telemáticos, el télex (Recomendaciones F.60, F.160, F.200, F.300, etc.), los servicios de transmisión de datos (X.1) o los servicios de entrega física (F.415) ganan acceso al servicio MIP y se intercomunican con él o entre sí mediante unidades de acceso.
Los elementos de servicio son las características de servicio suministradas
a través de entidades de aplicación. Se considera que estos elementos de
servicio son componentes de los servicios suministrados a los usuarios, y son
elementos de un servicio básico, o bien
facilidades de
usuario facultativas
, clasificadas en
facilidades de usuario facultativas
esenciales
, o
facilidades de usuario
facultativas adicionales
.
7
Modelo funcional del
STM
El modelo funcional del STM sirve de instrumento para formular Recomendaciones sobre el STM y describir los conceptos básicos que pueden ser representados gráficamente. Comprende varios componentes funcionales diferentes que actúan conjuntamente para proporcionar servicios TM. El modelo puede aplicarse a diversas configuraciones físicas y organizaciones diferentes.
7.1
Descripción del modelo STM
En la figura 1/X.400 se da una visión de conjunto de las funciones del modelo STM. En este modelo, un usuario es una persona o un proceso de computador. Los usuarios pueden ser usuarios directos (es decir, efectuar el tratamiento de mensajes utilizando el STM directamente) o usuarios indirectos [es decir, efectuar el tratamiento de mensajes a través de otro sistema de comunicación (por ejemplo, un sistema de entrega física), que esté vinculado al STM]. Un usuario es un originador (cuando envía un mensaje), o un destinatario (cuando recibe un mensaje). Los elementos de servicio del tratamiento de mensajes definen el conjunto de tipos de mensajes y las capacidades que permiten a un originador transferir mensajes de estos tipos a uno o más destinatarios.
Un originador prepara los mensajes con la ayuda de su agente de usuario. Un agente de usuario (AU) es un proceso de aplicación que interactúa con el sistema de transferencia de mensajes (STRM) o con una memoria de mensajes (MM) para depositar mensajes en nombre de un solo usuario. Los mensajes que el STRM recibe en depósito, los entrega a uno o más AU receptores, unidades de acceso (UA) o MM pudiendo devolver notificaciones al originador. Las funciones realizadas únicamente por el AU y no normalizadas como parte de los elementos de servicio del tratamiento de mensajes se denominan funciones locales. Un AU puede aceptar la entrega de mensajes directamente del STRM o bien puede utilizar la capacidad de la MM para recibir mensajes entregados, para su posterior extracción por el AU.
El STRM comprende varios agentes de transferencia de mensajes (ATM). Operando juntos, en forma de almacenamiento y retransmisión el STRM transfiere mensajes y los entrega a los correspondientes destinatarios.
El acceso de usuarios indirectos del STM se efectúa por medio de los UA. La entrega a usuarios indirectos del STM se efectúa por medio de los UA, al igual que la entrega física, por medio de la unidad de acceso de entrega física (UAEF).
La memoria de mensajes (MM) es una capacidad facultativa de propósito general del STM que actúa como intermediario entre el AU y el ATM. La MM se describe en el modelo funcional del STM que se muestra en la figura 1/X.400. La MM es una entidad funcional cuya finalidad primaria es efectuar el almacenamiento y permitir la extracción de los mensajes entregados. La MM también permite el depósito desde el AU y la alerta al mismo.
La colección de UA, MM, AU y ATM se denomina sistema de tratamiento de mensajes (STM).
Figure 1/X.400, p. 2
7.2
Estructura de los mensajes
En la figura 2/X.400, se muestra la estructura básica de los mensajes transmitidos por el STRM. Un mensaje se compone de un sobre y un contenido. El sobre lleva la información que utiliza el STRM al transferir el mensaje dentro del STRM. El contenido es la información que el AU originador desea entregar a uno o más AU destinatarios. El STRM no modifica ni examina el contenido, salvo para su conversión (véase el 16 ).
Figure 2/X.400, p. 3
7.3
Aplicación del modelo STM
7.3.1
Correspondencia física
Los usuarios acceden a los AU con fines de procesamiento de mensajes, por ejemplo, para crear, presentar o archivar mensajes. Un usuario puede interactuar con su AU a través de un dispositivo o proceso de entrada/salida (por ejemplo, teclado, unidad de visualización, impresora, etc.). Un AU puede realizarse como un (conjunto de) proceso(s) de computador en un terminal inteligente.
Un AU y un ATM pueden estar ubicados en el mismo sistema, o un AU/MM pueden estar realizados en sistemas físicamente separados. En el primer caso, el AU tiene acceso a los elementos de servicio TRM interactuando directamente con el ATM en el mismo sistema. En el segundo caso, el AU debe comunicarse con el ATM a través de protocolos normalizados especificados para el STM. Es posible también que un ATM se realice en un sistema AU o sin MM.
Las figuras 3/X.400 y 4/X.400 se muestran algunas configuraciones físicas posibles. Los diferentes sistemas físicos pueden estar conectados por medio de conexiones directas o de red conmutada.
Figure 3/X.400, p. 4
Figure 4/X.400, p. 5
7.3.2
Relación de correspondencia orgánica
Una Administración u organización puede desempeñar diversos papeles al proporcionar servicios de tratamiento de mensajes. En este contexto, una organización puede ser una empresa o una organización no comercial.
La colección de menos un ATM, cero o más AU, cero o más MM y cero o más UA explotados por una Administración u organización constituye un dominio de gestión (DG). Un DG manejado por una Administración se denomina dominio de gestión de Administración (DGAD). Un DG manejado por una organización, que no sea una Administración, se denomina dominio de gestión privado (DGPR). Un DG proporciona servicios de tratamiento de mensajes según la clasificación de elementos de servicios descrita en el 19 . La figura 5/X.400 muestra las relaciones entre los dominios de gestión.
Figura 5/X.400, p.
Nota 1
- Debe reconocerse que la provisión de soporte de
sistemas privados de mensajería por miembros del CCITT cae dentro del marco de
los reglamentos nacionales. Así, las posibilidades mencionadas en este punto
pueden o no ser ofrecidas por una Administración que proporcione servicios de
tratamiento de mensajes. Además, los AU descritos en la figura 5/X.400 no
implican que el AU que pertenece a un DG debe encontrarse exclusivamente en el
mismo país que su DG.
Nota 2
- Las interacciones directas entre los DGPR y
las interacciones internas dentro de un DG están fuera del ámbito de esta
Recomendación.
Nota 3
- Se considera que, en el contexto del CCITT
una Administración que maneja un DGAD es un miembro de la UIT o una empresa
privada de explotación reconocida (EPER) registrada por un país en la UIT.
7.3.3
Dominio de gestión de
administración
En un país pueden existir uno o más DGAD. Un DGAD se caracteriza porque proporciona funciones de relevo entre otros dominios de gestión y la provisión del servicio de transferencia de mensajes para las aplicaciones proporcionadas dentro del DGAD.
Una Administración puede proporcionar a sus usuarios acceso al DGAD en una o más de las siguientes formas:
-usuario a AU proporcionado por la Administración,
-AU privado a ATM de la Administración,
-AU privado a MM de la Administración,
-ATM privado a ATM de la Administración,
-usuario a UA proporcionada por la Administración.
Véanse también los ejemplos de configuraciones de las figuras 3/X.400 y 4/X.400.
Los AU proporcionados por la Administración pueden existir como parte de un terminal inteligente que el usuario puede utilizar para acceder al STM. También pueden existir como parte del equipo residente de la Administración que forma parte del STM, en cuyo caso el usuario obtiene acceso al AU por medio de un dispositivo de entrada/salida (E/S).
En el caso de un AU privado, el usuario tiene un AU privado autónomo que interactúa con el ATM o la MM proporcionado por la Administración, utilizando las funciones de depósito, entrega y recuperación. Un AU privado autónomo puede asociarse con una o más MM, siempre que se respeten los convenios de denominación necesarios.
Un ATM privado como parte de un DGPR puede acceder a uno o más DGAD en un país, de acuerdo a los reglamentos nacionales.
El acceso se puede también dar por medio de las AU proporcionadas por la Administración, tal como se indica en los 10 y 11.
7.3.4
Dominio de gestión privado
Una organización que no sea una Administración puede tener uno o más ATM, cero o más AU, UA y MM que forman un DGPR que puede interactuar con un DGAD, de DG a DG (ATM a ATM). Un DGPR se caracteriza porque proporciona funciones de mensajería dentro de ese dominio de gestión.
Se considera que un DGPR existe completamente dentro de un país. Dentro de ese país, el DGPR puede acceder a uno o más DGAD como se muestra en la figura 5/X.400. Sin embargo, en el caso de una interacción específica entre DGPR y DGAD (como cuando se transfiere un mensaje entre DG), se considera que el DGPR está asociado únicamente con dicho DGAD. Un DGPR no actuará como relevo entre dos DGAD.
En la interacción entre un DGPR y un DGAD, el DGAD asume la responsabilidad de las acciones del DGPR que están relacionadas con la interacción. Además, de garantizar que el DGPR proporciona debidamente el servicio de transferencia de mensajes, el DGAD debe asegurar que se realicen correctamente las funciones de contabilidad, registro cronológico, calidad de servicio, exclusividad de nombres y operaciones conexas del DGPR. Como asunto nacional, el nombre de un DGPR puede ser único a nivel nacional o relativo al DGAD asociado. Si un DGPR está asociado con más de un DGAD, puede tener más de un nombre.
7.4
Memoria de mensajes
Como los AU pueden realizarse con una gran variedad de equipos, incluyendo computadores personales, la MM puede completar un AU realizado, por ejemplo, en un computador personal, proporcionando un mecanismo de almacenamiento disponible en forma continua, más seguro, para aceptar la entrega de mensajes por cuenta del agente del usuario. La capacidad de recuperación de la MM proporciona, a los usuarios que se abonan a una MM, la capacidad básica de recuperación de mensajes aplicable potencialmente a todos los tipos de mensajes. La figura 6/X.400 muestra la entrega y posterior recuperación de mensajes que son entregados a una MM y el depósito indirecto de mensajes por medio de la MM.
Figura 6/X.400, p.
Una AM actúa por cuenta de un solo usuario (una dirección O/D), es decir no
proporciona a varios usuarios una capacidad MM común o compartida. Véase
también DGPR3 de la figura 5/X.400.
Cuando existe el abono a una MM, todos los mensajes destinados al AU son
entregados únicamente a la MM. El AU, si funciona
`en línea'
, puede
recibir alertas cuando ciertos mensajes son entregados a la MM. Los mensajes
entregados a una MM se consideran, desde la perspectiva del STRM, como
entregados.
Cuando un AU deposita un mensaje por medio de la MM, la MM en general es transparente y lo deposita en el ATM antes de confirmar al AU el éxito del depósito. Sin embargo, la MM puede ampliar el mensaje, si el AU solicita el reenvío de mensajes existentes en la MM.
Los usuarios también cuentan con la capacidad de solicitar a la MM que reenvíe automáticamente ciertos mensajes inmediatamente después de entregados.
Los elementos de servicio describen las características de una MM se definen en el anexo B y se clasifican en el 19 . Los usuarios disponen de una posibilidad, sobre la base de diversos criterios, de obtener cuentas y listas de mensajes, de capturar mensajes y de borrar mensajes, contenidos en ese momento en la MM.
7.4.1
Configuraciones físicas
La MM puede encontrarse situada físicamente, respecto al ATM, de diversas maneras. La MM puede estar ubicado junto al AU, junto al ATM, o ser autónomo. Desde un punto de vista exterior, un AU y una MM coubicados no pueden diferenciarse de un AU autónomo. La coubicación de la MM con el ATM ofrece ventajas significativas que probablemente lo conviertan en la configuración predominante.
7.4.2
Configuraciones de organización
Los DGAD o los DGPR pueden operar MM. En el caso de una MM suministrada por una Administración, el abonado puede proporcionar su propio AU o hacer uso de un AU proporcionado por la Administración por medio de un dispositivo de entrada/salida. En ambos casos, todos los mensajes de abonados son entregados a la MM para su ulterior recuperación.
Las configuraciones físicas y de organización descritas anteriormente son únicamente ejemplos y pueden existir otros casos igualmente válidos.
8
Servicio
de
transferencia de mensajes
El STRM proporciona el servicio de transferencia de mensajes general, con almacenamiento y retransmisión, independientemente de la aplicación. Los elementos de servicio que configuran las características del servicio TRM se definen en el anexo B y se clasifican en el 19 . El servicio público de transferencia de mensajes proporcionado por las Administraciones se describe en la Recomendación F.410.
8.1
Depósito y entrega
El STRM proporciona los medios que permiten a los AU intercambiar mensajes. Hay dos interacciones básicas entre los ATM y los AU y/o MM.
1)La interacción de depósito es el medio por el cual un AU o MM de origen transfiere a un ATM el contenido de un mensaje y el sobre de depósito. El sobre de depósito contiene la información que necesita el STRM para proporcionar los elementos de servicio solicitados.
2)La interacción de entrega es el medio por el cual el ATM transfiere a un AU o MM destinatario el contenido de un mensaje más el sobre de entrega. El sobre de entrega contiene información relativa a la entrega del mensaje.
En las interacciones de depósito y de entrega, la responsabilidad del mensaje se transfiere entre el STRM y el AU o la MM.
8.2
Transferencia
Comenzando en el ATM del originador, cada ATM transfiere el mensaje a otro ATM hasta que el mensaje alcanza al ATM de destino, el cual lo entrega entonces al AU o la MM de destino utilizando la interacción de entrega.
La interacción de transferencia es el medio por el cual un ATM transfiere a otro ATM el contenido de un mensaje más el sobre de transferencia. El sobre de transferencia contiene información relativa a la operación del STRM más la información que el STRM necesita para proporcionar los elementos de servicio solicitados por el AU de origen.
Los ATM transfieren mensajes que contienen muchos tipos de información codificada en binario. Los ATM no interpretan ni modifican el contenido de los mensajes a menos que realicen una conversión.
8.3
Notificaciones
Las notificaciones en el servicio de TRM pueden ser de entrega y de no entrega. Cuando un mensaje o sonda no puede ser entregado por el STRM, se genera una notificación de no entrega que se devuelve al originador en un informe que así lo indica. Además, un originador puede, al hacer el depósito, solicitar específicamente el acuse de la entrega correcta por medio del elemento de servicio de notificación de entrega.
8.4
Agente de usuario
El AU utiliza el servicio TRM proporcionado por el STRM. Un AU es una entidad funcional mediante la cual un usuario directo único efectúa un tratamiento de mensajes.
Los AU se agrupan en clases basadas en el tipo del contenido de los mensajes que pueden tratar. El STRM proporciona a los AU la posibilidad de identificar su clase al enviar mensajes a otros AU. Los AU de una misma clase se denominan AU cooperantes, puesto que cooperan entre sí para mejorar la comunicación entre sus respectivos usuarios.
Nota
- Un AU puede admitir más de un tipo de contenido
de mensajes y por lo tanto pertenecer a varias clases de AU.
8.5
Memoria de mensajes
La memoria de mensajes (MM) utiliza el servicio TRM proporcionado por el STRM. Una MM es una entidad funcional asociada con un AU de usuario. El usuario puede utilizarlo para entregar mensajes y para extraer mensajes que hayan sido entregados a la MM.
8.6
Unidad de acceso
Una unidad de acceso (UA) emplea el servicio TRM proporcionado por el STRM. Un UA es una entidad funcional asociada con un ATM para proporcionar la intercomunicación entre el STM y otro sistema o servicio.
8.7
Empleo del STRM en la prestación de diversos
servicios
El STRM es utilizado por servicios específicos a una aplicación para proporcionar servicios de tratamiento de mensajes de diversos tipos. El servicio de mensajería interpersonal, descrito en el 9 es un ejemplo de lo anterior. Sobre la base del STRM, pueden establecerse otros servicios, ya sea con Recomendaciones correspondientes o como aplicaciones privadas.
9
Servicio de mensajería
interpersonal (MIP)
El servicio de mensajería interpersonal (MIP) proporciona a un usuario los elementos que lo ayudarán a comunicar con otros usuarios del servicio MIP. El servicio MIP utiliza las capacidades del servicio TRM para enviar y recibir mensajes interpersonales. Los elementos de servicio que describen las características del servicio MIP se definen en el anexo B, y se clasifican en el 19 . La prestación del servicio público de mensajería interpersonal por las Administraciones se describe en la Recomendación F.420.
9.1
Modelo funcional del servicio de mensajería
interpersonal (MIP)
La figura 7/X.400 muestra el modelo funcional del servicio MIP. Los AU utilizados en el servicio MIP (AU de MIP) comprenden una clase específica de AU cooperantes. Las unidades de acceso opcionales que se muestran (ATLM, UATLXP) permiten a los usuarios teletex y télex intercomunicar con el servicio MIP. La unidad de acceso opcional (ATLM) también permite a los usuarios teletex participar en el servicio MIP (véase también el 11 ). La unidad de acceso de entrega física (UAEF) opcional permite a los usuarios de MIP enviar mensajes a usuarios fuera del servicio MIP que no tienen acceso al STM. El almacén de mensajes puede ser utilizado opcionalmente por los usuarios MIP para recibir la entrega de mensajes en su nombre.
9.2
Estructura de los mensajes IP
La clase MIP de AU crea mensajes que tienen un contenido específico para el MIP. El contenido específico que se envía de un AU de MIP a otro es el resultado de la composición y envío por un originador de un mensaje denominado mensaje IP. En la figura 8/X.400 se muestra la estructura de un mensaje IP y su relación con la estructura básica del mensaje STM. Cuando se transfiere a través del STRM el mensaje IP se transmite con un sobre.
En la figura 9/X.400 se muestra una analogía entre un memorándum de oficina típico y la estructura del mensaje IP correspondiente. El mensaje IP contiene información (por ejemplo, a:, cc:, asunto,) que es proporcionada por el usuario y transformada por el AU de MIP en el encabezamiento de mensaje IP. La información principal que el usuario desea comunicar (el cuerpo del memorándum) está contenida dentro del cuerpo del mensaje IP. En este ejemplo, el cuerpo contiene dos tipos de información codificada: texto y facsímil, que conforman lo que se denomina partes del cuerpo. En general, un cuerpo de mensaje IP puede consistir en varias partes del cuerpo, cada una de las cuales puede ser un tipo de información codificada diferente, tal como voz, texto, facsímil y gráficos.
Figure 7/X.400, p. 8
Figure 8/X.400, p. 9
Figure 9/X.400, p. 10
9.3
Notificaciones IP
En el servicio MIP, un usuario puede solicitar la notificación de la recepción o de la no recepción de un mensaje por un destinatario. Estas notificaciones son solicitadas por un originador y se generan como resultado de alguna acción (como la lectura o no lectura del mensaje) del destinatario. En ciertos casos la notificación de no recepción la genera automáticamente el AU del destinatario.
10
Intercomunicación con los
servicios de entrega física
10.1
Introducción
El valor de los sistemas de tratamiento de mensajes puede aumentar conectándolos a sistemas de entrega física (EF), como el servicio postal tradicional. Esto permitirá la entrega física (por ejemplo en copia impresa) de mensajes originados dentro del STM a destinatarios ajenos al STM y en algunos casos permitirá devolver notificaciones del servicio EF a un originador STM. La capacidad de originar mensajes en el servicio EF para su depósito en el STM por medio de la UAEF requiere ulterior estudio. La capacidad de intercomunicación entre los servicios EF y TM es una capacidad facultativa del STM y se puede emplear para cualquier aplicación como la MIP. Todos los usuarios del STM tendrán la posibilidad de generar mensajes para su ulterior entrega física. La figura 10/X.400 muestra el modelo funcional de este interfuncionamiento. La provisión de intercomunicación entre los servicios públicos de tratamiento de mensajes ofrecidos por las Administraciones y los servicios de EF se describe en la Recomendación F.415. Los elementos de servicio que describen las características de esta intercomunicación se definen en el anexo B y se clasifican en el 19 .
Figura 10/X.400, p.
Un sistema de entrega física es un sistema, explotado por un dominio de
gestión, que transporta y entrega mensajes físicos. Un mensaje físico es un
objeto físico que comprende un sobre de remisión y su contenido. Un ejemplo de
un SEF lo constituye el servicio postal. Un ejemplo de un mensaje físico es una
carta escrita en papel y su correspondiente sobre de papel.
Una unidad de acceso de entrega física (UAEF) convierte un mensaje de usuario TM a una forma física, proceso que se denomina transformación física. Un ejemplo de este proceso es la impresión de un mensaje y su colocación automática en un sobre de papel. La UAEF transfiere el mensaje que ha sufrido la transformación física a un SEF, para que éste lo siga transmitiendo y, finalmente, efectúe la entrega física.
Una UAEF puede considerarse como un conjunto de AU, cada uno de los cuales está identificado por una dirección postal. Para cumplir sus funciones, una UAEF debe admitir las interacciones de depósito (notificaciones) y de entrega con el STRM, y también cooperar con otros AU. De esta manera se proporciona la intercomunicación entre el STM y el SEF, como parte del servicio de transferencia de mensajes.
Para que los usuarios TM puedan dirigir mensajes que habrán de ser entregados físicamente por un SEF existe una forma de dirección adecuada, que se describe en el 12 .
10.2
Configuraciones de organización
En la figura 11/X.400 se muestran posibles correspondencias de organización
del modelo funcional descrito anteriormente. En cada modelo (A y B), el término
`dominio de EF'
designa el dominio de responsabilidad de una
organización que proporciona un servicio EF. En el caso A, el dominio del SEF
comprende un STM y un SEF. El límite entre el dominio de EF y el resto del STM
es un límite entre dominios de gestión (DG). En el caso B, el dominio de EF
comprende sólo el SEF; la UAEF no forma parte del dominio de EF. El límite
entre el dominio de EF y el STM se encuentra en el punto en el que la UAEF
transfiere mensajes físicos al SEF.
11 Acceso especializado
11.1
Introducción
El modelo funcional del STM (figura 1/X.400) contiene unidades de acceso (UA) que permiten el acceso entre el STM y otros sistemas y servicios de comunicación. El modelo muestra una unidad de acceso genérica entre el STM y los servicios telemáticos.
También se muestra una unidad de acceso de entrega física (UAEF) que permite la entrega física de mensajes STM a los destinatarios sin necesidad de un terminal para el acceso al STM. El acceso a los servicios de entrega física está disponible para cualquier aplicación que emplee el STRM, a través de una UAEF que se describe en el 10 .
A continuación se describen otras formas de acceso.
Figure 11/X.400, p. 12
11.2
Acceso teletex
11.2.1
Acceso registrado al servicio MIP
La unidad de acceso especializada definida para el acceso telemático, el agente telemático (ATLM), se destina específicamente a los terminales teletex (TTX). Este ATLM proporciona un acceso teletex al servicio MIP, como se muestra en la figura 7/X.400. Las disposiciones técnicas de este acceso se definen en la Recomendación T.330. El ATLM permite a los usuarios de terminales teletex la plena participación en el servicio MIP.
11.2.2
Acceso (público) no registrado al servicio MIP
La unidad de acceso especializada definida para el acceso telemático, agente telemático (ATLM), también proporciona acceso público al servicio MIP para usuarios TTX que no son usuarios registrados del servicio MIP. Esto se muestra en la figura 7/X.400. Las disposiciones técnicas de este acceso se definen en la Recomendación T.330. La intercomunicación entre el servicio MIP y el servicio teletex se define en la Recomendación F.422.
11.3
Acceso télex
11.3.1
Acceso registrado al servicio MIP
En las Recomendaciones técnicas se define una unidad de acceso al télex (UATLX) para permitir la intercomunicación entre los usuarios MIP y los usuarios télex. La prestación de un servicio con este tipo de UA es asunto nacional.
11.3.2
Acceso (público) no registrado al servicio MIP
Se define una unidad de acceso especializada para permitir la intercomunicación entre los usuarios MIP y los usuarios télex. Esta unidad de acceso (UA) proporciona acceso público al servicio MIP para usuarios télex que no son usuarios registrados del servicio MIP y se denomina unidad de acceso télex pública (UATLXP). Se muestra en la figura 7/X.400. Los usuarios télex no son abonados del servicio MIP, pero utilizan algunas de las prestaciones del servicio MIP para transmitir mensajes a los usuarios del MIP. Los usuarios MIP también pueden enviar mensajes a usuarios télex por medio de esta UA. La intercomunicación entre el servicio MIP y el servicio télex se define en la Recomendación F.421.
Nota
- Otros tipos de unidades de acceso requieren
ulterior estudio (por ejemplo para facsímil, videotex, etc.).
PARTE 3 -
12
Denominación y
direccionamiento
12.1
Introducción
En un STM, la entidad principal que hay que denominar es el usuario (originador y destinatario de los mensajes). Además, las listas de distribución (LD) tienen nombres que se emplean en el STM. Los usuarios del STM y las LD se identifican mediante nombres O/D. Los nombres O/D están compuestos por nombres de guía y/o direcciones O/D, cuyas descripciones se ofrecen en este apartado.
12.2
Nombres de guía
Los usuarios del servicio TM y las LD pueden identificarse mediante un nombre, denominado nombre de guía. Un nombre de guía debe ser buscado en una guía para encontrar la dirección O/D correspondiente. La estructura y los componentes de los nombres de guía se describen en las Recomendaciones de la serie X.500.
Un usuario puede lograr acceso directo a un sistema de guía para encontrar la dirección O/D de un usuario, o las direcciones O/D de los miembros de una LD (ambas acciones se encuentran fuera del ámbito de estas Recomendaciones). Como alternativa, un usuario puede utilizar el nombre de guía y hacer que el STM consulte la guía para encontrar automáticamente la dirección (o direcciones) O/D correspondientes, como se describe en el 14 .
No es necesairo que un usuario STM o una LD tengan un nombre de guía, a menos que figuren en una guía. A medida que las guías se utilicen cada vez más, se prevé que los nombres de guía serán el método preferido para que los usuarios STM se identifiquen entre sí.
12.3
Nombres O/D
Cada usuario TM o LD tendrá uno o más nombres O/D. Un nombre O/D se compone de un nombre de guía, una dirección O/D, o ambos.
Para depositar un mensaje se puede utilizar uno o ambos componentes de un nombre O/D. Si sólo se suministra el nombre de guía, el STM tendrá acceso a una guía para intentar determinar la dirección O/D, que utilizará después para encaminar el mensaje y entregarlo. Si no se indica el nombre de guía, utilizará la dirección O/D dada. Cuando se indiquen ambos elementos al efectuar el depósito, el STM utilizará la dirección O/D, pero cursará el nombre de la guía, y presentará ambos al destinatario. Si la dirección O/D no es válida, intentará utilizar el nombre de guía como se indica anteriormente.
12.4
Direcciones O/D
Una dirección O/D contiene información que pemite al STM identificar
unívocamente a un usuario a fin de entregarle un mensaje o devolverle una
notificación. (El prefijo
`O/D'
reconoce el hecho de que el usuario
puede actuar como originador o como destinatario del mensaje o de la
notificación de que se trata.)
Una dirección O/D es una colección de informaciones denominadas atributos. La Recomendación X.402 especifica una serie de atributos normalizados a partir de los cuales pueden construirse direcciones O/D. El que los atributos sean normalizados significa que su sintaxis y su semántica son los que se definen en la Recomendación X.402. Además, de los atributos normalizados, y para satisfacer las necesidades de los sistemas de mensajería existentes, hay atributos definidos según el dominio, cuya sintaxis y semántica son definidas por los dominios de gestión.
Se han definido varias formas de direcciones O/D, cada una con su propia finalidad. Esas formas y finalidades son las siguientes:
-
Dirección O/D nemotécnica:
proporciona al usuario un
medio práctico de identificar a otros usuarios cuando no existe una guía. Se
utiliza también para identificar una lista de distribución.
-
Dirección O/D de terminal:
proporciona un medio de
identificar a los usuarios con terminales que pertenecen a diversas redes.
-
Dirección O/D numérica:
proporciona un medio para
identificar a los usuarios mediante teclados numéricos.
-
Dirección O/D postal:
proporciona un medio para
identificar a los originadores y destinatarios de mensajes físicos.
13 Utilización de la guía por el STM
13.1
Introducción
La guía definida en las Recomendaciones de la serie X.500 proporciona capacidades útiles para el empleo y el suministro de diversos servicios de telecomunicación. Este apartado describe cómo se puede utilizar la guía en el tratamiento de mensajes; en otras Recomendaciones de la serie X.400 se pueden encontrar más detalles.
Las capacidades de la guía utilizadas en el tratamiento de mensajes se agrupan en las siguientes cuatro categorías:
a)
Nombres cómodos para el usuario:
el originador o
destinatario de un mensaje puede ser identificado mediante su nombre de guía,
en lugar de su dirección O/D, orientada a la máquina. En todo momento el STM
puede obtener la dirección a partir del nombre consultando la guía.
b)
Listas de distribución (LD):
un grupo cuyos miembros
estén registrados en la guía puede ser utilizado como una lista de
distribución. El originador simplemente proporciona el nombre de la lista. En
el punto de expansión de la LD, el STM puede obtener, consultando la guía, los
nombres de guía (y a continuación, las direcciones O/D) de los destinatarios
individuales.
c)
Capacidades de AU del destinatario:
las capacidades
STM de un destinatario (u originador) pueden registrarse en su inscripción de
la guía. En todo momento, el STM puede informarse de esas capacidades
consultando la guía (y actuar en consecuencia).
d)
Autenticación:
antes de que dos entidades funcionales
STM (dos ATM, o un AU y un ATM) se comuniquen entre sí, cada una establecerá la
identidad de la otra. Esto puede efectuarse utilizando las capacidades de
autenticación del STM sobre la base de la información almacenada en la guía.
Además, un usuario puede tener acceso directo a la guía, por ejemplo, para determinar la dirección O/D o las capacidades STM de otro usuario. Se suministra el nombre del usuario a la guía, la cual responde con la información solicitada.
13.2
Modelo funcional
Tanto los AU como los ATM pueden utilizar la guía. Un AU puede presentar a la guía el nombre de guía del destinatario deseado, y obtener de la guía la dirección O/D del mismo. El AU puede proporcionar el nombre de guía y la dirección O/D al STRM. Otro AU puede limitarse a suministrar al STRM el nombre de guía del destinatario. El STRM pedirá a la guía la dirección O/D del destinatario y la añadirá al sobre. El ATM originador normalmente realiza la búsqueda del nombre o de la dirección O/D.
En la figura 12/X.400 se muestra un modelo funcional que describe ese proceso.
Figura 12/X.400, p.
13.3
Configuraciones físicas
En la figura 13/X.400 se muestran algunas configuraciones físicas posibles del modelo funcional indicado anteriormente. Cuando un agente de usuario de guía (AUG) y un agente de sistema de guía (ASG) están realizados en sistemas físicamente separados, un protocolo normalizado de guía, definido en las Recomendaciones de la serie X.500, regula sus interacciones. Con frecuencia, resultará conveniente que un AU o un ATM esté situado en el mismo lugar que un AUG/ASG. No obstante, pueden darse otras configuraciones físicas.
Figura 13/X.400, p.
14
Listas de distribución en el
STM
14.1
Introducción
La posibilidad de utilizar una lista de distribución (LD) es una capacidad facultativa del STM, proporcionada por medio del servicio TRM. La expansión de la LD permite al emisor hacer que un mensaje se transmita a un grupo de destinatarios, dando el nombre del grupo en vez del nombre de cada uno de los destinatarios finales.
14.2
Propiedades de una LD
La propiedades de una LD pueden describirse como sigue:
-
Miembros de LD:
usuarios y otras LD que recibirán
mensajes dirigidos a la LD.
-
Permiso de depósito de LD:
lista de usuarios y otras
LD a los que se permite hacer uso de la LD para enviar mensajes a los miembros
de la LD.
-
Punto de expansión de la LD:
cada LD tiene una
dirección O/D inequívoca. Esta dirección O/D identifica el punto de expansión,
que es el dominio o ATM donde se añaden a la lista de destinatarios los nombres
de los miembros de la LD. El mensaje se transporta al punto de expansión, antes
de la expansión, como se indica en la figura 14/X.400.
-
Propietario de LD:
usuario responsable de la gestión
de una LD.
14.3
Depósito
El depósito de un mensaje a una LD es similar al depósito de un mensaje a un usuario. El originador puede incluir el nombre O/D de la LD, el nombre de guía, la dirección O/D, o ambos (para más detalles véase el 12 ). El originador no necesita saber que el nombre O/D utilizado es el de una LD. Sin embargo, el originador puede, utilizando el elemento de servicio prohibición de expansión de la LD, prohibir al STRM la expansión de un mensaje que por inadvertencia se ha dirigido a una LD.
14.4
Utilización de una guía por la LD
Una guía puede o no ser utilizada para almacenar información sobre las propiedades de la LD. Entre la información que puede almacenarse está la siguiente: miembros de la LD, propietario de la LD, permiso de depósito de la LD y punto de expansión de la LD.
14.5
Expansión de la LD
En el punto de expansión, el ATM responsable de la expansión de la LD:
a)Consultará la información sobre la LD, por ejemplo en la guía, utilizando
los derechos de acceso otorgados al ATM. (
Nota
- Como esto
lo hace el ATM en el punto de expansión, el soporte de las LD en el STM no
requiere una guía interconectada globalmente.)
b)Verificará si la expansión está o no permitida, comparando la identidad del emisor con el permiso de depósito de la LD.
c)Si se permite la expansión, añadirá los miembros de la LD a la lista de destinatarios del mensaje y les transmitirá el mensaje.
Figura 14/X.400, p.
14.6
Jerarquización
Un miembro de una LD puede ser otra LD, como se indica en la figura 14/X.400. En este caso el mensaje es reenviado desde el punto de expansión de la LD progenitora hacia el punto de expansión LD miembro para ulterior expansión. De este modo durante cada expansión sólo se añaden al mensaje los miembros de una LD.
Durante la expansión de una LD anidada, la identidad de la LD progenitora (por ejemplo, LD1 en la figura 14/X.400), en vez de la identidad del originador del mensaje, se compara con el permiso de depósito de la LD miembro (por ejemplo, LD2 en la figura 14/X.400).
Nota
- Pueden definirse estructuras de LD que se
refieren a una LD anidada particular más de una vez a diferentes niveles del
anidamiento. El depósito en una de esas LD progenitoras puede causar que un
destinatario reciba copias múltiples del mismo mensaje. El mismo resultado
puede ocurrir si se direcciona un mensaje a LD múltiples que contienen un
miembro común. La correlación de dichas copias puede hacerse en el AU del
destinatario y/o en el AM.
14.7
Control de repetición
Si cierta LD es directa o indirectamente miembro de sí misma (situación que puede surgir, y que es válida), o cuando las LD están combinadas con redireccionamiento, el mensaje podría volver a la misma lista y circular indefinidamente. El STRM detecta esta posible situación y evita que se produzca.
14.8
Entrega
A la entrega del mensaje, el destinatario se entera que recibió el mensaje como miembro de una LD, y por medio de qué LD o cadena de LD lo obtuvo.
14.9
Control del bucle de encaminamiento
Un mensaje puede originarse en un dominio/ATM, extenderse a un segundo dominio/ATM y después ser devuelto a un miembro de la LD en el primer dominio/ATM. El STRM no tratará esto como un error de bucle de encaminamiento.
14.10
Notificaciones
Las notificaciones de entrega y de no entrega pueden generarse tanto en el punto de expansión de la LD (por ejemplo, si se niega el permiso de depósito) como en el momento de la entrega al destinatario final.
Cuando un mensaje procedente de una LD genera una notificación, esta notificación es enviada a la LD de la cual provino el mensaje. Entonces la LD, según la pauta seguida por la lista, transmitirá la notificación al propietario de la lista, a la LD o al originador del que obtuvo el mensaje, o ambos, como se indica en la figura 15/X.400.
Figura 15/X.400, p.
Nota
- Cuando las notificaciones son enviadas al
originador tras la expansión de la LD, el originador puede recibir muchas
notificaciones de entrega/no entrega para un destinatario (la propia LD)
especificado por el originador. El originador puede incluso recibir más de una
notificación de un destinatario final, si dicho destinatario recibió el mensaje
más de una vez a través de listas diferentes.
14.11
Política de tratamiento de la LD
Un ATM puede o no proporcionar diferentes pautas sobre el tratamiento de las LD. Dichas pautas, o políticas, determinarán si las notificaciones generadas a la entrega a miembros de la LD deben hacerse retornar por medio de las LD anteriores, o al originador si no hay tales LD anteriores, y/o al propietario de la lista. Si la pauta es que sólo se envíen notificaciones al propietario de la lista, entonces el originador recibirá las notificaciones si las solicitó, únicamente durante la expansión de dicha LD. Para poder cumplir con esta restricción, al realizar la expansión el STRM reajustará las solicitudes de notificación de acuerdo con la pauta para la lista.
15
Capacidades de seguridad del
STM
15.1
Introducción
Dada la naturaleza distribuida del STM es conveniente disponer de mecanismos de protección contra diversos riesgos que puedan afectar a la seguridad del sistema. A continuación se describe la naturaleza de esos riesgos y las capacidades que se pueden utilizar para contrarrestarlos.
15.2
Riesgos que afectan a la seguridad del
STM
15.2.1
Riesgos de acceso
El acceso de un usuario no válido al STM es uno de los principales riesgos que afectan a la seguridad del sistema. Si se puede evitar que los usuarios no válidos utilicen el sistema, se reducirán considerablemente los riesgos de seguridad.
15.2.2
Riesgos entre mensajes
Los riesgos entre mensajes provienen de agentes no autorizados, ajenos a la comunicación del mensaje, y pueden manifestarse de las siguientes maneras:
-
Impostura:
Un usuario que no tiene prueba de la
identidad de la persona con la que comunica puede ser fácilmente engañado por
un impostor y revelar información importante.
-
Modificación del mensaje:
Un mensaje genuino, que ha
sido modificado por un agente no autorizado mientras era transferido a través
del sistema, puede engañar al destinatario del mensaje.
-
Reproducción:
Los mensajes cuyos originadores y
contenidos son genuinos pueden ser observados por un agente no autorizado, que
podrá así reproducirlos de modo que el destinatario deseado del mensaje reciba
esa reproducción en una fecha posterior. El móvil de esta acción puede ser
extraer más información del destinatario deseado, o confundirlo.
-
Análisis de tráfico:
El análisis de tráfico de
mensajes entre los usuarios TM puede permitir averiguar a un espía si se
transmiten datos entre dos usuarios, cuántos, y con qué frecuencia. Aunque no
pueda determinarse el contendio de los mensajes, el espía puede deducir una
cierta cantidad de información a partir de las características del tráfico
cursado (por ejemplo, continuo, por ráfagas, esporádico o nulo).
15.2.3
Riesgos intra-mensajes
Estos riesgos tienen su origen en los participantes reales en la comunicación del mensaje, y pueden manifestarse de la siguiente manera:
-
No reconocimiento de mensajes:
Uno de los
participantes reales en la comunicación puede negar su intervención en la
misma. Ello podría acarrear consecuencias importantes, si se realizan
transacciones financieras a través del STM.
-
Violación del nivel de seguridad:
Si un dominio de
gestión dentro del STM emplea niveles diferentes de autorizaciones de seguridad
(por ejemplo, nivel público, personal, privado o confidencial para la
compañía), deberá impedirse que los usuarios envíen o reciban mensajes para los
que su autorización de seguridad sea insuficiente a fin de no comprometer la
seguridad del dominio de gestión.
15.2.4
Riesgo de las memorias de datos
El STM tiene cierto número de memorias de datos que deben ser protegidos contra los siguientes riesgos:
-
Modificación de la información de encaminamiento:
La
modificación no autorizada del contenido de la guía podría conducir a un
encaminamiento indebido de los mensajes e incluso a su pérdida, en tanto que la
modificación no autorizada de la memoria de datos de entrega diferida o de la
memoria de datos de retención para entrega podría engañar o confundir al
destinatario deseado.
-
Entrega anticipada:
Un agente no autorizado podría
hacer una copia de un mensaje de entrega diferida y enviarla al destinatario
deseado mienstras el ATM retiene la entrega del original. Ello podría engañar
al destinatario del mensaje y hacer que conteste al originador antes de lo
esperado por éste, o simplemente confundir al destinatario deseado.
15.3
Modelo de seguridad
Pueden proporcionarse características de seguridad ampliando las capacidades de los componentes del sistema de tratamiento de mensajes de modo que incluyan diversos mecanismos de seguridad.
Hay dos aspectos de la seguridad en el tratamiento de mensajes: gestión de acceso y administración seguras y mensajería segura.
15.3.1
Gestión de acceso y administración seguras
En este punto, las capacidades se refieren al establecimiento de una asociación autenticada entre componentes adyacentes, y al establecimiento de parámetros de seguridad para dicha asociación. Esto puede aplicarse a un par cualquiera de componentes del sistema de tratamiento de mensajes: AU/ATM, ATM/ATM, MM/ATM, etc.
15.3.2
Mensajería segura
En este punto, las capacidades se refieren a la aplicación de las características de seguridad para proteger mensajes en el sistema de tratamiento de mensajes, de acuerdo con una política de seguridad definida. Esto incluye elementos de servicio que permitan a diversos componentes verificar el origen de los mensajes y la integridad de su contenido, y elementos de servicio para evitar la revelación no autorizada del contenido del mensaje.
Las capacidades de esta sección abarcan la aplicación de características de seguridad para proteger mensajes depositados directamente en el sistema de transferencia de mensajes por un agente de usuario, almacenador de mensajes o una unidad de acceso. No abarcan la aplicación de características de seguridad para proteger la comunicación entre los usuarios y el sistema de tratamiento de mensajes, o la comunicación de usuario TM a usuario TM (una gran parte de la comunicación de usuario TM a usuario TM está protegida entre dos AU). Por consiguiente no se aplican, por ejemplo, a la comunicación entre un terminal de usuario distante y su AU ni a la comunicación entre estos equipos terminales de usuario y otros usuarios del STM. Las capacidades de seguridad para proteger la comunicación de usuario TM son para ulterior estudio.
Muchos de los elementos de servicio de la mensajería segura proporcionan una capacidad de originador a destinatario y requieren del uso de agentes de usuario con capacidades de seguridad. No requieren el uso de un sistema de transferencia de mensajes con prestaciones de seguridad. [Por ejemplo, puede aplicarse disponiendo la confidencialidad del contenido que el originador cifre el contenido del mensaje y que el destinatario lo descifre, con diversos parámetros de seguridad transferidos dentro del sobre del mensaje. Tal mensaje puede ser transmitido por cualquier STRM que pueda tratar el formato del contenido (octetos no formateados) y tratar transparentemente los campos de seguridad en el sobre.]
Algunos de los elementos de servicio de mensajería segura inplican la interacción con el sistema de transferencia de mensajes y requieren el uso de agentes de transferencia de mensaje con capacidades de seguridad. (Por ejemplo, incuestionabilidad del depósito requiere que el ATM, en el que se deposita el mensaje, contenga mecanismos para generar un campo de prueba de depósito.)
Algunos de los elementos de servicio de mensajería segura se aplican a la MM así como a los AU y ATM, por ejemplo el etiquetado de seguridad del mensaje. Sin embargo, en general, la MM es transparente a las características de seguridad que se aplican entre los AU del originador y del destinatario.
En el cuadro 2/X.400 se presenta el alcance de los elementos de servicio de
mensajería segura. Se describen los elementos de servicio atendiendo a cuál
componente STM es el
`proveedor'
y cuál el
`usuario'
del servicio
de seguridad. Por ejemplo, la autenticación de origen de sonda es generada por
un AU de origen y puede ser utilizada por los ATM por los que pasa la sonda.
Esta Recomendación describe el uso de servicio de seguridad por el AU, y el ATM. La forma en que estas características se aplican a las unidades de acceso requiere ulterior estudio.
15.4
Características de seguridad del
STM
Los elementos de servicio que describen las características de seguridad del STM se definen en el anexo B y se clasifican en el 19 . A continuación se presenta una descripción general de dichas capacidades:
-
Autenticación del origen del mensaje:
Permite al
destinatario, o a cualquier ATM por el que pasa el mensaje, autenticar la
identidad del originador de un mensaje.
-
Autenticación del origen del informe:
Permite al
originador autenticar el origen de un informe de entrega/no entrega.
-
Autenticación del origen de la sonda:
Permite a
cualquier ATM por el que pasa la sonda, autenticar el origen de la sonda.
-
Prueba de entrega:
Permite al originador de un mensaje
autenticar el mensaje entregado y su contenido así como la identidad del (de
los) destinatario(s).
-
Prueba de depósito:
Permite al originador de un
mensaje autenticar que el mensaje fue depositado en el STRM para entrega al (a
los) destinatario(s) especificado(s) inicialmente.
-
Gestión de acceso seguro:
Proporciona la autenticación
entre componentes adyacentes y el establecimiento del contexto de seguridad.
-
Integridad del contenido:
Permite al destinatario
verificar que el contenido original de un mensaje no ha sido modificado.
-
Confidencialidad del contenido:
Impide la revelación
no autorizada del contenido del mensaje a una parte que no sea el destinatario
deseado.
-
Confidencialidad del flujo del mensaje:
Permite al
originador de un mensaje asegurar que el flujo del mensaje a través del STM se
mantenga secreto.
-
Integridad de la secuencia de mensajes:
Permite al
originador proporcionar a un destinatario la prueba de que se ha conservado la
secuencia de los mensajes.
-
No rechazo del origen:
Proporciona al (a los)
destinatario(s) de un mensaje una prueba del origen del mensaje y su contenido,
lo caul le(s) protegerá contra cualquier intento del originador de negar
falsamente haber enviado el mensaje o su contenido.
-
No rechazo de la entrega:
Proporciona al originador
del mensaje una prueba de la entrega del mensaje, lo cual le protegerá contra
cualquier intento del destinatario de negar falsamente haber recibido el
mensaje o su contenido.
-
No rechazo del depósito:
Proporciona al originador de
un mensaje una prueba del depósito del mensaje, lo cual le protegerá contra
cualquier intento del STRM de negar falsamente que el mensaje fue depositado
para entrega al (a los) destinatario(s) especificado(s) inicialmente.
-
Etiquetado de seguridad de los mensajes
: Proporciona
una capacidad para categorizar un mensaje, indicando su sensibilidad, lo que
determina el tratamiento del mensaje según la política de seguridad en vigor.
Cuadro 2/X.400 [T2.400], p.
15.5
Gestión de la seguridad
Los aspectos de un esquema asimétrico de gestión de claves para ofrecer las prestaciones antes mencionadas son proporcionados por el marco de autenticación del sistema de guía, descrito en la Recomendación X.509. La guía almacena copias certificadas de claves públicas para usuarios del STM, que pueden emplearse para proporcionar autenticación y facilitar el intercambio de claves para su utilización en mecanismos de confidencialidad de datos y de integridad de datos. Los certificados pueden leerse de la guía utilizando el protocolo de acceso a la guía descrito en la Recomendación X.519.
Las Recomendaciones sobre otros tipos de esquemas de gestión de claves, incluyendo la encripción simétrica, para ofrecer las prestaciones de seguridad, requieren ulterior estudio.
16
Conversión en el STM
El STRM proporciona funciones de conversión que permiten a los usuarios introducir mensajes en uno o más formatos codificados, denominados tipos de información codificada (TIC), y hacer que se entreguen en otros TIC a usuarios con diferentes capacidades AU y tipos de terminal. Esta capacidad es inherente al STRM y aumenta la posibilidad de entrega al adaptar el mensaje a las capacidades de terminal de los destinatarios. Los TIC disponibles en el STM se enumeran en la Recomendación X.411. Las conversiones y el uso de los elementos de servicio relacionados con la conversión están disponibles para TIC no definidos en la Recomendación X.411, pero admitidos por ciertos dominios, sea bilateralmente entre estos dominios o dentro de un mismo dominio.
Los usuarios del TM tienen cierto control sobre el proceso de conversión a través de diversos elementos de servicio que se describen en el anexo B. Entre ellos figura la posibilidad de que el usuario solicite expresamente la conversión necesaria o, absteniéndose de hacerlo, deje que el STRM determine la necesidad de efectuar la conversión y el tipo correspondiente. Los usuarios también tienen la posibilidad de solicitar que no se efectúe una conversión, o que no se la realice si implicase una pérdida de información. Cuando el STRM realiza una conversión en un mensaje, informa al AU al que se le entrega ese mensaje que se ha realizado la conversión y cuáles eran los TIC originales.
El proceso de conversión de los mensajes IP puede efectuarse en partes determinadas del cuerpo de tipos específicos, cuando éstas están presentes. En la Recomendación X.408 se describen los aspectos generales de la conversión y se indican detalladamente las reglas específicas para la conversión entre diferentes TIC.
Las conversiones detalladas en la Recomendación X.408 son aquellas entre télex, AI5, teletex, facsímil G3, G4 clase 1 y videotex, voz y modo mixto.
17
Utilización del STM en la
prestación de servicios públicos
El sistema de tratamiento de mensajes se utiliza en la prestación de servicios públicos TM, que ofrecen las Administraciones a sus abonados. Estos servicios públicos TM se definen en las Recomendaciones de la serie F.400 del CCITT, y comprenden:
-Servicio público de transferencia de mensajes (Rec. F.410).
-Servicio público de mensajería interpersonal (Rec. F.420).
Además, las Administraciones ofrecen servicios públicos complementarios que permiten la intercomunicación entre los servicios del CCITT y los servicios TM públicos mencionados anteriormente, de la siguiente manera:
-Intercomunicación con servicios públicos de entrega física (Rec. F.415).
-Intercomunicación entre el servicio MIP y el servicio télex (Rec. F.421).
-Intercomunicación entre el servicio MIP y el servicio teletex (Rec. F.422).
La Recomendación F.401 describe los aspectos de denominación y direccionamiento para los servicios TM públicos.
18
Finalidad
Los elementos de servicio son características, funciones o capacidades particulares del STM. Todos los elementos de servicio aplicables al STM se definen en el anexo B, y se enumeran en orden alfabético inglés con un número de referencia correspondiente. La realización de esos elementos de servicio del STM se describen en otras Recomendaciones de la serie X.400.
Los elementos de servicio están asociados a los diversos servicios prestados por el STM. Hay elementos de servicio para el servicio de transferencia de mensajes que suministran una capacidad de transporte básica para enviar y recibir mensajes entre los AU. Hay elementos de servicio para el servicio de mensajería interpersonal, que permiten el envío y la recepción de mensajes entre una clase particular de AU denominados AU de MIP. Hay elementos de servicio para el servicio de entrega física, que permiten a los usuarios del TM enviar mensajes a fin de que se entreguen por medios físicos a destinatarios que no son usuarios del TM. Hay elementos de servicio disponibles específicamente para el uso de almacenes de mensajes.
Los elementos de servicio para el servicio MIP incluyen los disponibles para el servicio TRM, el servicio EF y el almacén de mensajes, así como los específicos, aplicables al servicio MIP.
En el cuadro 3/X.400 se indican todos los elementos de servicio disponibles en el STM, precisándose con cuáles de los servicios actualmente definidos (servicio TRM, servicio MIP y servicio EF) están específicamente asociados o si son específicos de la memoria de mensajes, y se da el número de referencia correspondiente a la definición del anexo B.
Tableau 3/X.400 [1T3.400], p. 18
Tableau 3/X.400 [2T3.400], p. 19
19 Clasificación
19.1
Finalidad de la clasificación
Los elementos de servicio del STM se clasifican en pertenecientes a un servicio básico (llamado también base para EF y MM) y facilidades facultativas de usuario. Los elementos de servicio pertenecientes a un servicio básico son inherentes a ese servicio; constituyen el servicio básico y siempre se los proporciona y están disponibles para la utilización del mismo.
Otros elementos de servicio, denominados facilidades facultativas de usuario, pueden ser seleccionados por el abonado o usuario, bien mensaje por mensaje o por un periodo de tiempo convenido. Cada facilidad facultativa de usuario visible para el usuario se clasifica como esencial o adicional. Las facilidades facultativas de usuario esenciales (E) deberán estar disponibles para todos los usuarios STM. Las facilidades facultativas de usuario adicionales (A) pueden estar disponibles para uso nacional, e internacional sobre la base de acuerdos bilaterales.
19.2
Servicio de transferencia de mensajes
básico
El servicio TRM básico permite a un AU depositar y recibir mensajes. Si un mensaje no puede ser entregado, se informa al AU de origen por medio de una notificación de no entrega. Cada mensaje es identificado de una manera única e inequívoca. Para facilitar una comunicación significativa, el AU puede especificar el o los tipos de información codificada que podrán contener los mensajes que le sean entregados. Cada mensaje entregado va acompañado de la indicación del tipo de contenido, del o los tipos de información codificada originales, de cualquier conversión realizada, y el o los tipos de información codificada resultantes. Además, para cada mensaje se indica la hora del depósito y la de entrega. Los elementos de servicio TRM que pertenecen al servicio TRM básico se enumeran en el cuadro 4/X.400.
Cuadro 4/X.400 [T4.400], p.
19.3
Facilidades facultativas de usuario del servicio
TRM
Las facilidades facultativas de usuario del servicio TRM pueden seleccionarse mensaje por mensaje o para un periodo de tiempo convenido. Cada facilidad facultativa de usuario visible para el usuario se clasifica como esencial o adicional, según lo estipulado en el 19.1 . En el cuadro 5/X.400 se enumeran los elementos de servicio que conforman las facilidades facultativas de usuario del servicio TRM, con su clasificación y su disponibilidad (PM: por mensaje; AC: acuerdo contractual). Las facilidades facultativas de usuario para el servicio EF y almacén de mensajes, si bien forman parte de las facilidades facultativas de usuario del servicio TRM, no se indican en el presente cuadro por estar sujetas a que se suministre una UAEF o un MM, y son objeto de clasificaciones distintas en los cuadros 6/X.400 a 9/X.400.
Cuadro 5/X.400 [T5.400], p.
19.4
Intercomunicación de los servicios TM/EF de
base
Puede proporcionarse la intercomunicación de los servicios TM/EF de base para mejorar el servicio TRM, permitiendo que los mensajes se entreguen a los destinatarios en un formato físico (típicamente una copia impresa) mediante un servicio de entrega material tal como el servicio postal. Esta capacidad puede ser empleada por cualquier aplicación que utilice el servicio TRM. En el cuadro 6/X.400 se enumeran los elementos de servicio TM/EF que pertenecen a la intercomunicación TM/EF de base disponibles por cada destinatario. Cuando se proporcione esta intercomunicación a través de UAEF, se admitirán todos los elementos de servicio del cuadro 6/X.400.
Cuadro 6/X.400 [T6.400], p.
19.5
Facilidades facultativas de usuario para la
intercomunicación de los servicios TM/EF
Los elementos de servicio TM/EF de base ( 19.4 ) junto con las facilidades facultativas de usuario enumeradas a continuación, pueden utilizarse juntos para proporcionar intercomunicación de los servicios TM/EF. Esta capacidad puede ser utilizada por cualquier aplicación que emplee el servicio TRM ampliado. Las facilidades facultativas de usuario del servicio EF pueden seleccionarse por cada destinatario, y se enumeran en el cuadro 7/X.400.
Cuadro 7/X.400 [T7.400], p.
19.6
Memoria de mensajes de base
La memoria de mensajes de base se encuentra disponible en forma facultativa para proporcionar el almacenamiento y la gestión de mensajes entrantes, actuando como intermediario entre un AU y un ATM. La MM puede usarse en cualquier aplicación que utilice el servicio TRM. Los elementos de servicio que pertenecen a la memoria de mensajes de base se indican en el cuadro 8/X.400. Cuando se proporciona una MM, se deben admitir todos los elementos de servicio que se muestran en el cuadro 8/X.400.
Cuadro 8/X.400 [T8.400], p.
19.7
Facilidades facultativas de usuario de la MM
Los elementos de servicio de la MM de base ( 19.6 ) junto con las facilidades facultativas de usuario que se indican más adelante, pueden emplearse conjuntamente para un uso potenciado de una memoria de mensajes. La MM potenciada se puede emplear en cualquier aplicación que utilice el servicio TRM. Los elementos de servicio que comprenden las facilidades facultativas de usuario MM se indican en el cuadro 9/X.400.
Cuadro 9/X.400 [T9.400], p.
19.8
Servicio de mensajería interpersonal
básico
El servicio de mensajería interpersonal básico, que utiliza el servicio TRM, permite a un usuario enviar y recibir mensajes IP. Un usuario prepara los mensajes IP con la ayuda de su agente de usuario (AU). Los agentes de usuario cooperan entre sí para facilitar la comunicación entre sus respectivos usuarios. Para enviar un mensaje IP, el usuario de origen deposita el mensaje en su AU, especificando el nombre O/D del destinatario que debe recibir el mensaje IP. El mensaje IP, junto con el cual se transmite un identificador, es enviado por el AU de origen al AU de destino a través del servicio de transferencia de mensajes.
Después de haber sido entregado satisfactoriamente al AU de destino, el mensaje IP puede ser recibido por el destinatario. Para facilitar una comunicación significativa, un destinatario puede especificar el o los tipos de información codificada que podrán contener los mensajes IP que permitirá sean entregados a su AU. Cada mensaje IP entregado va acompañado de la indicación del o los tipos de información codificada originales, de cualquier conversión o conversiones que se hayan realizado, y del o los tipos de información codificada resultante. Además, en cada mensaje IP se especifican la hora de depósito y la hora de entrega. En el servicio básico se proporciona una notificación de no entrega. En el cuadro 10/X.400 se enumeran los elementos de servicio MIP que pertenecen al servicio MIP básico.
Cuadro 10/X.400 [T10.400], p.
19.9
Facilidades facultativas de usuario del servicio
MIP
Un conjunto de elementos de servicio del servicio MIP son facilidades facultativas de usuario. Estas facilidades pueden seleccionarse mensaje por mensaje o por un periodo de tiempo convenido, y se enumeran en los cuadros 11/X.400 y 12/X.400, respectivamente. Las facilidades de usuario locales pueden ser proporcionadas convenientemente junto con algunas de estas facilidades facultativas de usuario.
Las facilidades facultativas de usuario del servicio MIP seleccionadas mensaje por mensaje son clasificadas tanto para el origen como para el destino por los AU. Si un DG ofrece estas facilidades facultativas de usuario para ser originadas por los AU, el usuario puede crear y enviar mensajes IP de acuerdo con los procedimientos definidos para el elemento de servicio asociado. Si un DG ofrece estas facilidades facultativas de usuario para su recepción por los AU, AM y UA, el AU, la MM y UAEF receptor podrá recibir y reconocer la indicación asociada con el elemento de servicio correspondiente e informar al usuario de la facilidad facultativa de usuario solicitada. Cada facilidad de usuario se clasifica como adicional (A) o esencial (E) para los AU desde estas dos perspectivas.
Nota
- Con el protocolo de acceso descrito en las
Recomendaciones T.330, los terminales teletex pueden utilizar el servicio MIP
básico y las facilidades facultativas de usuario proporcionadas por el sistema
de tratamiento de mensajes.
Tableau 11/X.400 [1T11.400], p. 27
Tableau 11/X.400 [2T11.400], p. 28
Tableau 12/X.400 [T12.400], p. 29
MONTAGE:
Annexe A sur le reste de cette page
DISK.2 NF01/001 OPM = 02 (cs,)
(1BT) (BT..)
(87.TE.02.S)
(A1.23s) / [26s]
FOLIOS: 41 - 75
(DO PRC.COSY.2)
MEP {TPS.NON.PHOTO "[PA1]"} : OK= [1]
Saisie 26.07.89 RM
ID + LASER 24.10.89 AF
MAJ diskette ........ ..
Corr. LASER (1re épreuve) = 3eme 31.10.89 UT
Espaces réservés ........ ..
AJOUTER (PA1) (CL1,0,0,0) pour MEP
MEP + LASER ........ ..
Corr. MEP ........ ..
Insertion des tableaux (tabulateurs...) ........ ..
BAT du 13/11/89 16.11.89 PV
MAJ s/disquettes 6.12.89 CD
MONTAGE: TABLEAU 12/F.400 en tête de cett page
ANEXO A (a la Recomendación X.400)
Glosario de términos
Nota
- Las explicaciones proporcionadas no son
necesariamente definiciones en el sentido estricto. Véanse también las
definiciones del anexo B y las proporcionadas en otras Recomendaciones de la
serie X.400 (especialmente la Recomendación X.402) de donde se tomaron muchos
de los términos. Los términos tienen diferentes niveles de abstracción, que
dependen de su origen.
A.1@
unidad de acceso (UA)
@
E: access unit (AU)
F: unité d'accès (UA)
\En el contexto de un sistema de tratamiento de mensajes, objeto funcional, componente del STM, que enlaza otro sistema de comunicación (por ejemplo un sistema de entrega física o la red télex) con el STRM y por medio del cual sus patronos efectúan tratamiento de mensajes como usuarios indirectos.
En el contexto de servicios de tratamiento de mensajes, la unidad que permite a los usuarios de un servicio intercomunicar con servicios de tratamiento de mensajes tales como el servicio MIP.\
A.2@
destinatario real
@
E: actual recipient
F: destinataire effectif
\En el contexto del tratamiento de mensajes, destinatario potencial con relación al cual se efectúa una entrega o afirmación.\
A.3@
administración
@
E: administration
F: administration
\En el contexto del CCITT una Administración (miembro de la UIT) o una empresa privada de explotación reconocida.\
A.4@
nombre de dominio de administración
@
E: administration domain name
F: nom d'un domaine d'administration
\En el contexto del tratamiento de mensajes, atributo normalizado de una forma de nombre que identifica un DGAD con relación al país indicado por un nombre de país.\
A.5@
dominio de gestión de administración (DGAD)
@
E: administration management domain (ADMD)
F: domaine de gestion d'administration (DGAD)
\Dominio de gestión que comprende sistemas de mensajería manejados por una Administración.\
A.6@
destinatario alternativo
@
E: alternate recipient
F: destinataire suppléant
\En el contexto del tratamiento de mensajes, usuario o lista de distribución a los que el originador puede (pero no necesita) solicitar que un mensaje o sonda sea transmitido únicamente si no puede transmitirse a cierto destinatario preferido.\
A.7@
atributo
@
E: attribute
F: attribut
\En el contexto del tratamiento de mensajes, elemento de información, componente de una lista de atributos, que describe a un usuario o lista de distribución y que también puede localizarlo en relación a la estructura física u organizacional del STM (o la red subyacente).\
A.8@
lista de atributos
@
E: attribute list
F: liste d'attributs
\En el contexto del tratamiento de mensajes, estructura de datos, conjunto ordenado de atributos, que constituyen una dirección O/D.\
A.9@
tipo de atributo
@
E: attribute type
F: type d'attribut
\Identificador que designa una clase de información (por ejemplo nombres personales). Forma parte de un atributo.\
A.10@
valor de atributo
@
E: attribute value
F: valeur d'attribut
\Instancia de la clase de información designada por un tipo de atributo (por ejemplo, un nombre personal especial). Forma parte de un atributo.\
A.11@
servicio básico
@
E: basic service
F: service de base
\En el contexto del tratamiento de mensajes, suma de características inherentes a un servicio.\
A.12@
cuerpo
@
E: body
F: corps
\Componente de un mensaje. Otros componentes son el encabezamiento y el sobre.\
A.13@
parte del cuerpo
@
E: body part
F: partie du corps
\Componente del cuerpo de un mensaje.\
A.14@
nombre común
@
E: common name
F: nom courant
\En el contexto del tratamiento de mensajes, atributo normalizado de una forma de dirección O/D, que identifica al usuario o lista de distribución, con relación a la entidad designada por otro atributo (por ejemplo un nombre de organización).\
A.15@
contenido
@
E: content
F: contenu
\En el contexto del tratamiento de mensajes, objeto de información, parte de un mensaje, que el STRM no examina ni modifica, salvo para conversión durante el transporte del mensaje.\
A.16@
tipo de contenido
@
E: content type
F: type de contenu
\En el contexto del tratamiento de mensajes, identificador, en el sobre del mensaje, que identifica el tipo (por ejemplo sintaxis y semántica) del contenido del mensaje.\
A.17@
conversión
@
E: conversion
F: conversion
\En el contexto del tratamiento de mensajes, suceso de transmisión en el que un ATM transforma parte del contenido de un mensaje de un tipo de información codificada a otro, o bien altera una sonda de manera que aparezca que los mensajes descritos fueron así modificados.\
A.18@
nombre de país
@
E: country name
F: nom de pays
\En el contexto del tratamiento de mensajes, atributo normalizado de una forma de nombre que identifica a un país. Un nombre de país es una designación unívoca de un país con fines de envío y recepción de mensajes.
Nota
- En el contexto de entrega física se aplican
reglas adicionales. (Véase también nombre del país de entrega física y la
Recomendación F.415.)\
A.19@
entrega
@
E: delivery
F: remise
\En el contexto del tratamiento de mensajes, paso de transmisión en el que un ATM transporta un mensaje o informa al AM o AU de un destinatario potencial del mensaje o del originador del mensaje de asunto del informe o sonda.\
A.20@
informe de entrega
@
E: delivery report
F: rapport de remise
\En el contexto del tratamiento de mensajes, informe que acusa la entrega, no entrega, exportación o afirmación del mensaje de asunto o sonda, o la expansión de una lista de distribución.\
A.21@
depósito directo
@
E: direct submission
F: dépôt direct
\En el contexto del tratamiento de mensajes, paso de transmisión en el que el AU o MM del originador transmite un mensaje o sonda a un ATM.\
A.22@
usuario directo
@
E: direct user
F: utilisateur direct
\En el contexto del tratamiento de mensaje, usuario que efectúa tratamiento de mensajes por uso directo del STRM.\
A.23@
guía
@
E: directory
F: annuaire
\Colección de sistemas abiertos que cooperan para proporcionar servicios de guía.\
A.24@
nombre de guía
@
E: directory name
F: nom d'annuaire
\Nombre de una inscripción en una guía.
Nota
- En el contexto del tratamiento de mensajes,
inscripción en la guía que permitirá extraer la dirección O/D para el depósito
de un mensaje.\
A.25@
agente de sistema de guía (ASG)
@
E: directory system agent (DSA)
F: agent de système d'annuaire (ASA)
\Proceso de aplicación ISA que forma parte de la guía, y cuyo papel es proporcionar a los AUG y/o a otros ASG, acceso a la base de información de la guía.\
A.26@
agente de usuario de guía (AUG)
@
E: directory user agent (DUA)
F: agent d'usager d'annuaire (AUA)
\Proceso de aplicación ISA que representa a un usuario que obtiene acceso a la guía. Cada AUG sirve a un solo usuario, de modo que la guía puede controlar el acceso a la información de la guía en base a los nombres de AUG. Los AUG pueden también proporcionar una gama de facilidades locales para ayudar a los usuarios a satisfacer sus solicitudes (indagaciones) e interpretar las respuestas.\
A.27@
lista de distribución (LD)
@
E: distribution list (DL)
F: liste de distribution (LD)
En el contexto del tratamiento de mensajes, objeto funcional, componente del entorno de tratamiento de mensajes, que representa un grupo predeterminado de usuarios y otras listas de distribución y que es un destinatario potencial de los objetos de información por un STM.
Los miembros de la lista pueden contener nombres de O/D que identifican a usuarios o a otras listas de distribución.\
A.28@
expansión de una lista de distribución
@
E: distribution list expansion
F: allongement de liste de distribution
\En el contexto del tratamiento de mensajes, suceso de transmisión en el que un ATM hace que una lista de distribución sea sustituida por los miembros de la misma, que serán los destinatarios inmediatos del mensaje.\
A.29@
nombre de lista de distribución
@
E: distribution list name
F: nom de liste de distribution
\Nombre O/D asignado para representar un conjunto de direcciones O/D y nombres de guía.\
A.30@
dominio
@
E: domain
F: domaine
\Véase dominio de gestión.\
A.31@
atributos definidos por el dominio
@
E: domain defined attributes
F: attributs définis d'un domaine
\Atributos opcionales de una dirección O/D asignados a nombres bajo la responsabilidad de un dominio de gestión.\
A.32@
elemento de servicio
@
E: element of service
F: élément de service
\Unidad funcional para segmentar y describir características de tratamiento de mensajes.\
A.33@
tipo de información codificada (TIC)
@
E: encoded information type (EIT)
F: type de codage (TC)
\En el contexto del tratamiento de mensajes, identificador, en el sobre de un mensaje, que identifica un tipo de información codificada representada en el contenido del mensaje. Identifica el medio y formato (por ejemplo texto AI5, facsímil grupo 3) de una porción individual del contenido.\
A.34@
sobre
@
E: envelope
F: enveloppe
\En el contexto del tratamiento de mensajes, objeto de información, parte de un mensaje, cuya composición varía de un paso de transmisión a otro y que identifica diversamente al originador del mensaje y los destinatarios potenciales, documenta su pasado y dirige su ulterior transmisión por el STRM, y caracteriza su contenido.\
A.35@
conversión explícita
@
E: explicit conversion
F: conversion explicite
\En el contenido del tratamiento de mensajes, conversión en la que el originador selecciona los tipos inicial y final de información codificada.\
A.36@
componentes de ampliación de dirección de entrega
física
@
E: extension of physical delivery address components
F: développement de composants d'adresse de remise
physique
\Atributo normalizado de una dirección postal O/D como medio para proporcionar información adicional sobre el punto de entrega física en una dirección postal, por ejemplo el nombre de un barrio, el número de un apartamento y del piso en un edificio grande.\
A.37@
componentes de ampliación de dirección postal O/D
@
E: extension of postal O/R address components
F: développement de composants d'adresse postale E/D
\Atributo normalizado de una dirección postal O/D como medio para proporcionar información adicional que especifique al destinatario en una dirección postal, por ejemplo, por una unidad de organización.\
A.38@
dirección postal O/D formatizada
@
E: formatted postal O/R address
F: adresse postale E/D formatée
Dirección O/D basada en una dirección postal con atributos.\
A.39@
encabezamiento
@
E: heading
F: en-tête
\Componente de un mensaje IP. Otros componentes son el sobre y el cuerpo.\
A.40@
destinatario inmediato
@
E: immediate recipient
F: destinataire direct
\En el contexto del tratamiento de mensajes, uno de los destinatarios potenciales asignados a un caso particular de un mensaje o sonda (por ejemplo un caso creado por división).\
A.41@
conversión implícita
@
E: implicit conversion
F: conversion implicite
\En el contexto del tratamiento de mensajes, conversión en la que el ATM elige los tipos de información codificada inicial y final.\
A.42@
depósito indirecto
@
E: indirect submission
F: dépôt indirect
\En el contexto del tratamiento de mensajes, etapa de transmisión en el que un AU originador transfiere un mensaje o sonda a un ATM a través de una MM.\
A.43@
usuario indirecto
@
E: indirect user
F: utilisateur indirect
\En el contexto del tratamiento de mensajes, usuario que participa en el tratamiento de mensajes por el uso indirecto del STM, es decir, por medio de otro sistema de comunicación (por ejemplo un sistema de entrega física o una red télex) al que está enlazado el STM.
Nota
- Los usuarios indirectos se comunican con
usuarios directos del STM por medio de unidades de acceso.\
A.44@
intercomunicación
@
E: intercommunication
F: intercommunication
\En el contexto del tratamiento de mensajes, relación entre servicios en la que uno de los servicios es un servicio de tratamiento de mensajes que permite al usuario del servicio de tratamiento de mensajes comunicarse con usuarios de otros servicios.
Nota
- Como ejemplos pueden citarse la
intercomunicación entre el servicio MIP y el servicio télex, así como la
intercomunicación entre los servicios de tratamiento de mensajes y los
servicios de entrega física.\
A.45@
servicio de mensajería interpersonal
@
E: interpersonal messaging service
F: service de messagerie de personne à personne
\Servicio de mensajería entre usuarios que pertenecen al mismo dominio de gestión o a diferentes dominios de gestión, por medio de tratamiento de mensajes, basado en el servicio de transferencia de mensajes.\
A.46@
Mensaje IP
@
E: IP-message
F: message PP
\Contenido de un mensaje en el servicio MIP.\
A.47@
atributos postales locales
@
E: local postal attributes
F: attributs postaux locaux
\Atributos normalizados de una dirección postal O/D como medio para distinguir entre lugares que tienen un mismo nombre (por ejemplo por nombre de provincia, nombre de país, o atributo geográfico) en una dirección postal.\
A.48@
dominio de gestión (DG)
@
E: management domain (MD)
F: domaine de gestion (DG)
\En el contexto del tratamiento de mensajes, grupo de sistema de mensajería -de los cuales al menos uno contiene o realiza un ATM- que es manejado por una sola organización. Es un bloque constructivo primario utilizado en la construcción organizacional del STM. Se refiere a una zona de organización para la prestación de servicios.
Nota
- Un dominio de gestión puede, pero no tiene
necesariamente que, coincidir con una zona geográfica.\
A.49@
nombre de dominio de gestión
@
E: management domain name
F: nom d'un domaine de gestion
\Designación unívoca de un dominio de gestión para el envío y la recepción de mensajes.\
A.50@
miembros
@
E: members
F: membres
\En el contexto del tratamiento de mensajes, grupo de usuarios y listas de distribución implicados por un nombre de lista de distribución.\
A.51@
mensaje
@
E: message
F: message
\Instancia de la clase primaria de objeto de información transmitida por medio de transferencia de mensajes y que comprende un sobre y un contenido.\
A.52@
tratamiento de mensajes (TM)
@
E: message handling (MH)
F: messagerie (traitement des messages) (M)
\Tarea distribuida de procesamiento de información que integra las subtareas intrínsecamente relacionadas de transferencia de mensajes y el almacenamiento de mensajes.\
A.53@
entorno de tratamiento de mensajes
@
E: message handling environment
F: environnement de traitement de messages
\Entorno en el que se realiza el tratamiento de mensajes incluyendo STM, usuarios y listas de distribución.
Suma de todos los componentes de los sistemas de tratamiento de mensajes.
Nota
- Ejemplos de componentes.
-agentes de transferencia de mensajes,
-agentes de usuario,
-almacenes de mensajes,
-unidades de acceso,
-usuarios.\
A.54@
servicio de tratamiento de mensajes
@
E: message handling service
F: service de messagerie
\Servicio proporcionado por medio de sistemas de tratamiento de mensajes.
Nota 1
- El servicio puede ser proporcionado por medio
de los dominios de gestión de la administración o dominios de gestión privados.
Nota 2
- Ejemplos de servicios de tratamiento de
mensajes:
-servicio de mensajería interpersonal (servicio MIP),
-servicio de transferencia de mensajes (servicio TRM).\
A.55@
sistema de tratamiento de mensajes (STM)
@
E: message handling system (MHS)
F: système de messagerie (STM)
\Objeto funcional componente del entorno del tratamiento de mensajes, que transporta objetos de información de una parte a otra.\
A.56@
almacenamiento de mensajes
@
E: message storage
F: mémorisation des messages
\Almacenamiento automático para extracción posterior de objetos de información transmitidos por transferencia de mensaje. Es un aspecto del tratamiento de mensajes.\
A.57@
memoria de mensajes (MM); almacenador de mensajes
(AM)
@
E: message store (MS)
F: mémoire des messages (MM)
\Objeto funcional, componente del STM, que proporciona a un solo usuario directo capacidades de almacenamiento de mensajes.\
A.58@
transferencia de mensajes (TRM)
@
E: message transfert (MT)
F: transfert de messages (TM)
\Transporte de objetos de información no efectuado en tiempo real entre partes que utilizan computadores como intermediarios. Es un aspecto del tratamiento de mensajes.\
A.59@
agente de transferencia de mensajes (ATM)
@
E: message transfert agent (MTA)
F: agent de transfert de messages (ATM)
\Objeto funcional, componente del STRM, que transmite efectivamente objetos de información a usuarios y listas de distribución.\
A.60@
servicio de transferencia de mensajes
@
E: message transfer service
F: service de transfert de messages
\Servicio relativo al depósito, transferencia y entrega de mensajes para otros servicios de mensajería.\
A.61@
sistema de transferencia de mensajes (STRM)
@
E: message transfer system (MTS)
F: système de transfert de messages (système TM)
\Objeto funcional consiste en uno o más agentes de transferencia de mensajes y que provea la transferencia de mensajes con almacenamiento y retransmisión entre agentes de usuario, memorias de mensajes y unidades de acceso.\
A.62@
sistema de mensajería
@
E: messaging system
F: système de messagerie
\Un sistema de computador (que puede pero no tiene necesariamente que ser un sistema abierto) que contiene o realiza uno o más objetos funcionales. Es un bloque constructivo utilizado en la construcción física del STM.\
A.63@
dirección O/D nemotécnico
@
E: mnemonic O/R address
F: adresse mnémonique E/D
\Dirección O/D que identifica nemotécnicamente a un usuario o lista de distribución con relación al DGAD por medio de la cual se accede al usuario o se expande la lista de distribución. Identifica un DGAM, y a un usuario o lista de distribución con relación a ese DGAD.\
A.64@
autoridad de denominación
@
E: naming authority
F: autorité responsable de l'appellation
\Autoridad responsable de la atribución de nombres.\
A.65@
dirección de red
@
E: network address
F: adresse réseau
\En el contexto del tratamiento de mensajes, atributo normalizado de una forma de dirección O/D, que proporciona la dirección de red de un terminal. Comprende las cifras del plan de numeración internacional para los puntos de acceso a la red.\
A.66@
no entrega
@
E: non-delivery
F: non-remise
\En el contexto del tratamiento de mensajes, suceso de transmisión en el que un ATM determina que el STRM no puede entregar un mensaje a uno o más de los destinatarios inmediatos, o no puede entregar el informe al originador del mensaje o sonda en cuestión.\
A.67@
acceso no registrado
@
E: non-registered access
F: accès non homologué
\En el contexto de los servicios de tratamiento de mensajes, acceso al servicio a través de medios de telecomunicación que estén a disposición del público en general por parte de usuarios que no han sido registrados explícitamente por el proveedor del servicio ni tienen asignada una dirección O/D.\
A.68@
dirección O/D numérica
@
E: numeric O/R address
F: adresse numérique E/D
\En el contexto del tratamiento de mensajes, dirección O/D que identifica numéricamente a un usuario en relación con un DGAD por medio del cual se gana acceso al usuario. Identifica un DGAD y un usuario con relación a ese DGAD. Identifica a un usuario de los STRM por medio de un teclado numérico.\
A.69@
identificador de usuario numérico
@
E: numeric user identifier
F: identificateur numérique d'utilisateur
\Atributo de una dirección O/D como una secuencia única de información numérica para identificar a un usuario.\
A.70@
dirección O/D
@
E: O/R address
F: adresse E/D
\En el contexto del tratamiento de mensajes, lista de atributos que distingue a un usuario o LD de otro e identifica el punto de acceso del usuario al STM o el punto de expansión de la lista de distribución.\
A.71@
nombre O/D
@
E: O/R name
F: nom E/D
\En el contexto del tratamiento de mensajes, objeto de información por medio del cual un usuario puede ser designado como el originador, o usuario o lista de distribución designados como destinatario potencial de un mensaje o sonda. Un nombre O/D permite distinguir un usuario o lista de distribución de otro, u otra, y también puede identificar su punto de acceso al STM.\
A.72@
facilidades facultativas de usuario
@
E: optional user facilities
F: services complémentaires offerts en option à
l'utilisateur
\En el contexto de los servicios de tratamiento de mensajes, son elementos de servicio que pueden ser seleccionados por el usuario sobre una base contractual (periodo de tiempo convenido) o para cada mensaje.
Nota 1
- Las facilidades facultativas de usuario se
clasifican en esenciales y adicionales.
Nota 2
- Las facilidades facultativas de usuario
esenciales deben ponerse a la disposición de todos los usuarios de tratamiento
de mensajes.
Nota 3
- Las facilidades facultativas de usuario
adicionales se ponen a disposición para uso nacional, o internacional sobre la
base de acuerdos bilaterales entre los proveedores del servicio.\
A.73@
nombre de la organización
@
E: organization name
F: nom d'organisation
\Atributo normalizado de una dirección O/D como designación unívoca de una organización con la finalidad de enviar y recibir mensajes.\
A.74@
nombre de la unidad organizadora
@
E: organizational unit name
F: nom d'une unité d'organisation
\Atributo normalizado de una dirección O/D como designación unívoca de una unidad organizacional de una organización con la finalidad de enviar y recibir mensajes.\
A.75@
originador
@
E: originator
F: expéditeur
\En el contexto de tratamiento de mensajes, el usuario (pero no la lista de distribución) que es la fuente final de un mensaje o sonda.\
A.76@
nombre personal
@
E: personal name
F: nom personnel
\En el contexto de tratamiento de mensajes, atributo normalizado de una forma de dirección O/D que identifica a una persona relacionada a la entidad designada por otro atributo (por ejemplo un nombre de organización).
Nota
- Los componentes pueden ser, por ejemplo:
-apellido,
-nombre (de pila),
-iniciales,
-calificador de generación.\
A.77@
entrega física (EF)
@
E: physical delivery (PD)
F: remise physique (RP)
\Entrega de un mensaje en forma física, por ejemplo una carta, a través del sistema de entrega física.\
A.78@
unidad de acceso de entrega física (UAEF)
@
E: physical delivery access unit (PDAU)
F: unité d'accès de remise physique (UARP)
\Unidad de acceso que somete los mensajes (pero no las sondas ni los informes) a reproducción física.\
A.79@
componentes de dirección de entrega física
@
E: physical delivery address components
F: composants d'une adresse de remise physique
\En una dirección postal, contiene la información necesaria para la entrega física local dentro de la zona de entrega física de la oficina de entrega física, es decir, una dirección-calle, una dirección-apartado postal, una dirección de lista de correos o, como otra posibilidad, un nombre unívoco.
Nota
- La información generalmente está limitada a una
línea de hasta 30 caracteres gráficos imprimibles. Se puede suministrar
información adicional utilizando el tipo de atributo
`ampliación de
componentes de dirección de entrega física'
.\
A.80@
nombre de país de entrega física
@
E: physical delivery country name
F: nom du pays de remise physique
\En el contexto de entrega física, descripción unívoca del país del destino final.\
A.81@
dominio de entrega física
@
E: physical delivery domain
F: domaine de remise physique
\Dominio de responsabilidad de una organización que presta servicios de entrega física y, opcionalmente un ATM/UAEF.\
A.82@
componentes de dirección de oficina de entrega
física
@
E: physical delivery office address components
F: composants d'une adresse de bureau de remise
physique
\En una dirección postal, contienen la información que especifica la oficina responsable de la entrega física local.
Nota
- La información generalmente está limitada a una
línea de hasta 30 caracteres gráficos imprimibles. En algunos países el código
postal va después de los componentes de dirección de oficina de entrega física,
en una línea aparte (posiblemente junto con el nombre de país).\
A.83@
nombre de oficina de entrega física
@
E: physical delivery office name
F: nom du bureau de remise physique
\Atributo normalizado de una dirección O/D postal, en el contexto de la entrega física, que especifica el nombre de la ciudad, localidad, etc. en donde está situada la oficina de entrega física, o donde se realiza la entrega física.\
A.84@
número de oficina de entrega física
@
E: physical delivery office number
F: numéro du bureau de remise physique
\Atributo normalizado y, en una dirección postal O/D, medio para distinguir entre dos o más oficinas de entrega física en una ciudad, etc.\
A.85@
nombre de la organización de entrega física
@
E: physical delivery organization name
F: nom d'organisation de remise physique
\Nombre de forma libre de la entidad destinataria dentro de la dirección postal, tomando en cuenta las limitaciones de longitud especificadas.\
A.86@
nombre personal de entrega física
@
E: physical delivery personal name
F: nom personnel de remise physique
\En una dirección postal, nombre de forma libre del destinatario individual, que contiene el apellido y, opcionalmente, los nombres, iniciales, títulos y calificador de generación, tomando en cuenta las limitaciones de longitud especificadas.\
A.87@
servicio de entrega física
@
E: physical delivery service
F: service de remise physique
\Servicio proporcionado por un sistema de entrega física.\
A.88@
nombre del servicio de entrega física
@
E: physical delivery service name
F: nom du service de remise physique
\Atributo normalizado de una dirección postal O/D en forma del nombre del servicio en el país que recibe electrónicamente el mensaje en nombre del servicio de entrega física.\
A.89@
sistema de entrega física (SEF)
@
E: physical delivery system (PDS)
F: système de remise physique (SRP)
\Sistema que realiza la entrega física. Un tipo importante de servicio de entrega física es el sistema postal.\
A.90@
mensaje físico
@
E: physical message
F: message physique
\Objeto físico que incluye un sobre de relevo y su contenido, por ejemplo una carta.\
A.91@
reproducción física
@
E: physical rendition
F: conversion physique
\Transformación de un mensaje STM en un mensaje físico, por ejemplo imprimiendo el mensaje en papel e introduciéndolo en un sobre de papel.\
A.92@
código postal
@
E: postal code
F: code postal
\Atributo normalizado de una dirección postal O/D para especificar la zona geográfica, y en el contexto del STM, utilizado para el encaminamiento de mensajes.\
A.93@
dirección postal O/D
@
E: postal O/R address
F: adresse postale E/D
@
\En el contexto de tratamiento de mensajes, dirección O/D que identifica a un usuario por medio de su dirección postal. Identifica al servicio de entrega física por medio del cual se accede al usuario y proporciona la dirección postal del usuario.\
A.94@
componentes de dirección postal O/D
@
E: postal O/R address components
F: composants d'une adresse postale E/D
\En una dirección postal, contienen la información para describir al emisor o destinatario por medio de su nombre (nombre personal de entrega física, nombre de organización de entrega física).
Nota
- En una dirección postal, se limita, en general,
la información a una línea de 30 caracteres imprimibles. Puede proporcionarse
información adicional utilizando el tipo de atributo
`componentes de
ampliación de la dirección postal O/D'
.\
A.95@
dirección-apartado de correos
@
E: post office box address (P.O. box address)
F: adresse de case postale
\Atributo normalizado en la dirección postal que indica que se solicita la entrega física mediante un apartado de correos. Lleva un número de apartado de correos para la distribución a dicho apartado.\
A.96@
dirección-lista de correos
@
E: poste restante address
F: adresse poste restante
\Atributo normalizado en la dirección postal que indica que se solicita la entrega física en ventanilla. También puede llevar un código.\
A.97@
destinatario potencial
@
E: potential recipient
F: destinataire potentiel
\En el contexto del tratamiento de mensajes, cualquier usuario o lista de distribución hacia la cual se transporta un mensaje o sonda en el curso de la transmisión. En forma equivalente, destinatario substituto o miembro, alternativo o preferido.\
A.98@
receptor preferido
@
E: preferred recipient
F: destinataire préféré
\En el contexto del tratamiento de mensajes, uno de los usuarios y listas de distribución, que el originador elige como destino preferido de la sonda o mensaje.\
A.99@
nombre de dominio privado
@
E: private domain name
F: nom d'un domaine privé
\En el contexto del tratamiento de mensajes, atributo normalizado de una forma de dirección O/D que identifica a un DGPR con relación al DGAD denotado por un nombre de dominio de administración.
Nota
- Son administradas por el DGAD al que está
asociado el DGPR.\
A.100@
dominio de gestión privado (DGPR)
@
E: private management domain (PRMD)
F: domaine de gestion privé (DGPR)
\En el contexto del tratamiento de mensajes, dominio de gestión que incluye sistemas de mensajería manejados por una organización que no es una Administración.\
A.101@
sonda
@
E: probe
S: essai
\En el contexto del tratamiento de mensajes, ejemplo de una clase secundaria de objetos de información transmitidos por medio de transferencia de mensajes, que describe una clase de mensajes, y que se utiliza para determinar la entregabilidad de dichos mensajes.\
A.102@
servicio público de tratamiento de mensajes
@
E: public message handling service
F: service public de messagerie
\Servicio de tratamiento de mensajes ofrecido por una Administración.\
A.103@
servicios públicos
@
E: public services
F: services publics
\En el contexto de las telecomunicaciones, los servicios ofrecidos por las Administraciones.\
A.104@
recepción
@
E: receipt
F: réception
\En el contexto del tratamiento de mensajes, paso de transmisión en el que, ora un AU transmite un mensaje o informe a su usuario directo, o el sistema de comunicación que sirve al usuario indirecto, transmite dicho objeto de información a ese usuario.\
A.105@
destinatario
@
E: recipient
F: destinataire
\Véase destinatario real.\
A.106@
repetición
@
E: recursion
F: récursivité
\En el contexto del tratamiento de mensajes, el hecho de que un mensaje vuelva a la misma lista de distribución de origen y potencialmente circule indefinidamente.\
A.107@
redireccionamiento
@
E: redirection
F: réacheminement
\En el contexto del tratamiento de mensajes, suceso de transmisión en el que un ATM reemplaza a un usuario, entre los destinatarios inmediatos del mensaje, por otro usuario que fue seleccionado previamente por el primer usuario para dicho mensaje.\
A.108@
acceso registrado
@
E: registered access
F: accès homologué
\En el contexto de los servicios de tratamiento de mensajes, acceso al servicio por parte de usuarios que han sido registrados por el proveedor del servicio para utilizarlo y a los que se ha asignado una dirección O/D.\
A.109@
informe
@
E: report
F: rapport
\En el contexto del tratamiento de mensajes, ejemplo de una clase secundaria de objeto de información transmitida por medio de transferencia de mensajes. Es generado por el STRM e informa del resultado o progreso de la transmisión de un mensaje o sonda a uno o más destinatarios potenciales.\
A.110@
recuperación
@
E: retrieval
F: extraction
\En el contexto del tratamiento de mensajes, paso de transmisión en el cual una memoria de mensajes de un usuario transporta un mensaje o informa al AU del usuario. El usuario es un destinatario real del mensaje o el originador del mensaje o sonda de asunto.\
A.111@
capacidades de seguridad
@
E: security capabilities
F: capacité de sécurité
\En el contexto del tratamiento de mensajes, mecanismos que protegen contra diversos riesgos de seguridad.\
A.112@
acceso especializado
@
E: specialized access
F: accès spécialisé
\En el contexto del tratamiento de mensajes, participación de unidades de acceso especializadas que proporcionan la intercomunicación entre servicios de tratamiento de mensajes y otros servicios de telecomunicación.\
A.113@
atributo normalizado
@
E: standard attribute
F: attribut normalisé
\Atributo cuyo tipo está ligado a cierta clase de información.\
A.114@
dirección-calle
@
E: street address
F: adresse de rue
\Un atributo normalizado en la dirección postal que proporciona información para la distribución local y la entrega física, es decir el nombre de la calle, el identificador de la calle (como calle, plaza, avenida) y el número de la casa.\
A.115@
asunto
@
E: subject
F: objet
\En el contexto del tratamiento de mensajes, la información, parte del encabezamiento, que resume el contenido del mensaje tal como lo ha especificado el originador.\
A.116@
mensaje de asunto
@
E: subject message
F: message objet
\Mensaje que es el asunto de un informe.\
A.117@
sonda de asunto
@
E: subject probe
F: essai objet
\Sonda que es el asunto de un informe.\
A.118@
depósito
@
E: submission
F: dépôt
\Depósito directo o depósito indirecto.\
A.119@
destinatario sustituto
@
E: substitute recipient
F: destinataire substitut
\En el contexto del tratamiento de mensajes, usuario o lista de distribución hacia el cual un destinatario miembro, alternativo o preferido (pero no otro substituto), puede haber elegido redireccionar mensajes (pero no sondas).\
A.120@
identificador de terminal
@
E: terminal identifier
F: identificateur de terminal
\Atributo normalizado en una dirección O/D que proporciona información para identificar un terminal entre varios.
Nota
- Pueden citarse como ejemplos el distintivo
télex o y el identificador de terminal de teletex.\
A.121@
dirección O/D de terminal
@
E: terminal O/R address
F: adresse terminale E/D
\En el contexto del tratamiento de mensajes, dirección O/D que identifica a un usuario por medio de la dirección de red de su terminal y que puede identificar el DGAM a través del cual se accede a ese terminal. Los terminales identificados pueden pertenecer a redes diferentes.\
A.122@
tipo de terminal
@
E: terminal type
F: type de terminal
\Atributo normalizado de una dirección O/D que indica el tipo de un terminal.
Nota
- Ejemplos: télex, teletex, facsímil G3, facsímil
G4, AI5, terminal videotex.\
A.123@
transferencia
@
E: transfer
F: transfert
\En el contexto del tratamiento de mensajes, un paso de transmisión en el que un ATM transporta un mensaje, sonda o informe a otro ATM.\
A.124@
sistema de transferencia
@
E: transfer system
F: système de transfert
\Sistema de mensajería que contiene un ATM; opcionalmente puede contener una o más unidades de acceso, pero no contendrá ni un AU, ni un almacenador de mensajes.\
A.125@
transmisión
@
E: transmittal
F: transmission
\Transporte o tentativa de transporte de un mensaje desde su originador hasta sus destinatarios potenciales, o de una sonda desde su originador hasta ATM capaces de afirmar cualquier entregabilidad descrita del mensaje a sus destinatarios potenciales. También incluye el transporte o tentativa de transporte, al originador del mensaje o sonda, de cualquier informe provocado por el mensaje o sonda. Es una secuencia de pasos y sucesos de transmisión.\
A.126@
dirección postal O/D no formatizada
@
E: unformatted postal O/R address
F: adresse postale E/D non formatée
\Dirección O/D basada en una dirección postal no formatizada.\
A.127@
nombre postal exclusivo
@
E: unique postal name
F: nom postal unique
\En una dirección postal, atributo normalizado que describe el punto de entrega física por medio de un nombre único, por ejemplo el de un edificio.\
A.128@
usuario
@
E: user
F: usager/utilisateur
\En el contexto del tratamiento de mensajes, objeto funcional (por ejemplo una persona), componente del entorno de tratamiento de mensajes que, más bien que proporcionar, interviene en el tratamiento de mensajes y que es una fuente o destino potencial de los objetos de información transportados por el STM.\
A.129@
agente de usuario (AU)
@
E: user agent (UA)
F: agent d'usager (AU)
\En el contexto del tratamiento de mensajes, objeto funcional, componente del STM, por medio del cual un usuario directo individual interviene en tratamiento de mensajes.
Componente del STM con el que interactúa el usuario.\
ANEXO B (a la Recomendación X.400)
Definiciones de los elementos
de servicio
Nota
- Las abreviaturas que aparecen en
el renglón de los epígrafes tienen los siguientes significados:
@TRMTransferencia de mensajes\
@MIPMensajería interpersonal\
@EFEntrega física\
@MMMemoria de mensajes\
@PDPor cada destinatario (disponible por cada uno de los destinatarios)\
B.1
Gestión de acceso
Este elemento de servicio permite a un AU y a un ATM establecer accesos entre sí y tratar información asociada con el establecimiento del acceso.
El elemento permite al AU y al ATM identificar y validar recíprocamente sus identidades. Permite al AU especificar su dirección O/D y mantener la seguridad de acceso. Cuando se logra la seguridad de acceso por medio de contraseñas, éstas pueden actualizarse periódicamente.
Nota
- El elemento de servicio gestión de acceso
seguro proporciona una forma más segura de gestión de acceso.
B.2
Reproducción física adicional
Este elemento de servicio permite a un usuario originador solicitar a la UAEF que suministre las facilidades de reproducción adicionales (por ejemplo, clase de papel, impresión en color, etc.). Se requiere un acuerdo bilateral para utilizar este elemento de servicio.
B.3
Destinatario alternativo
autorizado
Este elemento de servicio permite a un AU de origen especificar que el mensaje depositado puede entregarse a otro destinatario como se indica más adelante.
Un DG de destino interpretará todos los atributos de usuario para seleccionar un AU destinatario. Cabe distinguir tres casos:
1)Todos los atributos concuerdan exactamente con los de un AU de abonado. Se trata de entregar el mensaje a este AU.
2)Los atributos suministrados son insuficientes, o concuerdan con los de más de un AU de abonado. El mensaje no puede entregarse.
3)Se suministra por lo menos el conjunto mínimo de atributos requeridos por el DG de destino. Sin embargo, teniendo en cuenta todos los atributos, éstos no concuerdan con los de ningún AU.
En el tercer caso, un DG que admite el elemento de servicio asignación de destinatario alternativo puede entregar el mensaje a un AU que haya sido asignado para recibir tales mensajes. A este AU se le notificará la dirección O/D del destinatario deseado especificada por el originador. La entrega a este AU se comunicará al originador mediante una notificación de entrega, si así lo ha solicitado.
B.4
Asignación de destinatario
alternativo
Este elemento de servicio confiere a un AU la facultad de que se le entreguen mensajes para los cuales no hay concordancia exacta entre los atributos de destinatario especificados y el nombre del usuario. Este AU se especifica en términos de uno o más atributos para los cuales debe haber una concordancia exacta, y uno o más atributos para los cuales es aceptable cualquier valor. Por ejemplo, una organización puede establecer un AU para recibir todos los mensajes para los cuales el nombre del país, el nombre de dominio de gestión de administración y el nombre de la organización (por ejemplo, el nombre de la compañía) concuerdan exactamente, pero el nombre personal del destinatario no corresponde a ninguna persona conocida por un STM en esa organización. Esto permite a la organización tratar manualmente los mensajes para estas personas.
Para que reasigne un mensaje a un destinatario alternativo, el originador debe haber solicitado el elemento de servicio destinatario alternativo autorizado.
B.5
Indicación de los usuarios
autorizantes
Este elemento de servicio permite al originador indicar al destinatario los nombres de la o las personas que autorizaron su envío. Por ejemplo, una persona puede autorizar una acción particular que se comunica subsiguientemente a los interesados por otra persona, por ejemplo, una secretaria. Se considera que la primera persona autoriza su envío mientras que la segunda es la que envió el mensaje (originador). Esto no implica autorización en el nivel de firma.
B.6
Indicación de reenvío automático
Este elemento de servicio permite al destinatario determinar que un cuerpo de un mensaje IP entrante contiene un mensaje IP que ha sido reenviado automáticamente. De este modo, el destinatario puede distinguir cuándo un mensaje IP entrante contiene en el cuerpo un mensaje IP reenviado (como se describe en el Î B.31). Al igual que el mensaje IP reenviado, un mensaje IP reenviado automáticamente puede ir acompañado de información (por ejemplo, impresión de la hora, indicación de conversión) asociada con su entrega original.
Nota
- La indicación de que se ha producido el reenvío
automático de un mensaje IP permite al AU de la MIP destinataria, si así se
elige, evitar otro reenvío automático y por ende la posibilidad de bucles.
Además, el AU de la MIP destinataria puede elegir o no el reenvío automático
basado en otros criterios (por ejemplo, clasificación de sensibilidad).
Cuando un AU de MIP reenvía automáticamente un mensaje IP, lo hace constar en el mismo. Si se ha solicitado notificación de recepción/no recepción para el mensaje de usuario así reenviado automáticamente, el AU de MIP genera una notificación de no recepción informando al originador de ese reenvío automático del mensaje IP. La notificación incluye facultativamente un comentario suministrado por el destinatario deseado originalmente. Ningún AU de MIP genera otra notificación aplicable al mensaje IP reenviado automáticamente.
B.7
Reproducción física básica
Este elemento de servicio permite a la UAEF proporcionar las facilidades básicas de transformación para convertir el mensaje STM en un mensaje físico. Esta es la acción por defecto que debe ejecutar la UAEF.
B.8
Indicación de destinatario de copia
ciega
Este elemento de servicio permite al originador proporcionar los nombres O/D de uno o más usuarios adicionales o LD que son destinatarios deseados del mensaje IP que se envía. Estos nombres no se revelan a los destinatarios primarios ni a los destinatarios de copias. El hecho de revelar o no a los destinatarios adicionales la presencia de los otros es un asunto de carácter local.
B.9
Indicación de cifrado de parte del
cuerpo
Este elemento de servicio permite al originador indicar al destinatario que una parte específica del cuerpo del mensaje IP que se envía ha sido cifrada. Puede utilizarse el cifrado para impedir una inspección o modificación no autorizada de la parte del cuerpo. El destinatario puede utilizar este elemento de servicio para determinar que alguna parte (o partes) del cuerpo del mensaje IP deben ser descifradas. Sin embargo, este elemento de servicio, por sí mismo, no cifra ni descifra ninguna parte del cuerpo.
B.10
Confidencialidad del contenido
Este elemento de servicio permite al originador de un mensaje proteger el contenido del mensaje contra su revelación a otro que no sea el destinatario o los destinatarios deseados. La confidencialidad del contenido se entiende para cada mensaje y puede utilizar técnicas de cifrado simétricas o asimétricas.
B.11
Integridad del contenido
Este elemento de servicio permite al originador del mensaje proporcionar al destinatario del mensaje un medio de verificar que el contenido del mensaje no ha sido modificado. La integridad del contenido se entiende para cada destinatario y puede utilizar una técnica de cifrado simétrica o asimétrica.
B.12
Indicación de tipo de contenido
Este elemento de servicio permite a un AU de origen indicar el tipo de contenido para cada mensaje depositado. Al AU destinatario pueden habérsele entregado uno o más tipos de contenido. Un ejemplo de tipo de contenido es el contenido generado por la clase MIP de AU cooperantes.
B.13
Prohibición de conversión
Este elemento de servicio permite a un AU ordenar al STRM que no efectúe conversiones del tipo de información codificada implícitas para un determinado mensaje depositado.
B.14
Prohibición de conversión en caso de pérdida
de información
Este elemento de servicio permite a un AU de origen ordenar al STRM que no efectúe conversiones del tipo de información codificada para un determinado mensaje depositado si dichas conversiones pudieran ocasionar una pérdida de información. La pérdida de información se trata con detalle en la Recomendación X.408.
En caso de que se seleccionaran este elemento de servicio y de prohibición de conversión, se dará prioridad a este último.
Nota
- Este elemento de servicio no ofrecerá
protección contra una posible pérdida de información en ciertos casos en los
que el destinatario utiliza un dispositivo entrada/salida cuyas capacidades son
desconocidas para el ATM.
B.15
Indicación de conversión
Este elemento de servicio permite al STRM indicar al AU destinatario que el STRM realizó la conversión del tipo de información codificada en un mensaje entregado. El AU destinatario es informado de los tipos resultantes.
B.16
Recogida en ventanilla
Este elemento de servicio permite a un usuario de origen ordenar al SEF que mantenga el mensaje físico listo para la recogida en ventanilla en la oficina de correos especificada por el originador, o en la oficina de correos más cercana a la dirección del destinatario que ofrece el servicio de recogida de ventanilla.
B.17
Recogida en ventanilla con
aviso
Este elemento de servicio permite a un usuario de origen ordenar al SEF que mantenga el mensaje físico listo para la recogida en ventanilla en la oficina de correos especificada por el originador, o en la oficina de correos más cercana a la dirección del destinatario que ofrece el servicio de recogida en ventanilla, e informe al destinatario por vía telefónica, télex o teletex utilizando el número suministrado por el originador.
B.18
Indicación de referencia
recíproca
Este elemento de servicio permite al originador asociar al mensaje IP que se envía los identificadores globales exclusivos de uno o más mensajes IP. Esto permite al AU de MIP del destinatario, por ejemplo, extraer del registro una copia de los mensajes IP referenciados.
B.19
Entrega diferida
Este elemento de servicio permite a un AU de origen ordenar al STRM que no entregue un mensaje que deposita antes de una fecha y hora determinadas. La entrega se efectuará lo más próxima posible a la fecha y hora especificadas, pero no antes. La fecha y hora especificadas para la entrega diferida están sujetas a un límite que es definido por el dominio de gestión del originador.
Nota
- El almacenamiento del mensaje se efectuará en
el país originador.
B.20
Cancelación de entrega diferida
Este elemento de servicio permite que un AU de origen ordene al STRM que cancele un mensaje de entrega diferida depositado con anterioridad. Es posible que la tentativa de cancelación no siempre tenga éxito. Los posibles motivos de fallo son: expiración del plazo de entrega diferida, o que el mensaje ha sido reenviado ya dentro del STRM.
B.21
Notificación de entrega
Este elemento de servicio permite a un AU de origen solicitar que se le envíe una notificación explícita cuando un mensaje depositado ha sido correctamente entregado a un AU o unidad de acceso de destino. La notificación se relaciona con el mensaje depositado mediante un identificador de mensaje e incluye la fecha y hora de la entrega. En caso de un mensaje con múltiples destinos, el AU de origen puede solicitar este elemento de servicio por cada destinatario.
Cuando un mensaje se entrega después de la expansión de la lista de distribución, entonces, según la pauta de la lista de distribución, la notificación podrá enviarse al propietario de la lista o al originador del mensaje o a ambos.
La notificación de entrega no implica que el AU o el usuario hayan realizado ninguna acción, por ejemplo examinar el contenido del mensaje.
B.22
Indicación de hora de entrega
Este elemento de servicio permite al STRM indicar a un AU destinatario la fecha y hora en la que el STRM entregó un mensaje. En el caso de entrega física, este elemento de servicio indica la fecha y hora en la que la UAEF asumió la responsabilidad de imprimir y entregar el mensaje físico.
B.23
Entrega por el servicio burofax
Este elemento de servicio permite al usuario de origen ordenar a la UAEF y el SEF asociado que utilicen el servicio burofax para el transporte y la entrega.
B.24
Designación de destinatarios por el nombre
de guía
Este elemento de servicio permite a un AU de origen utilizar un nombre de guía en vez de una dirección O/D de un destinatario individual.
B.25
Revelación de otros
destinatarios
Este elemento de servicio permite que un AU de origen, al depositar un mensaje con múltiples destinos, ordene al STRM que revele los nombres O/D de todos los demás destinatarios a cada AU destinatario cuando le entregue el mensaje. Los nombres O/D revelados serán los suministrados por el AU de origen. Si se utiliza una expansión de LD, sólo se revelará el nombre de LD especificado por el originador y no los nombres de sus miembros.
B.26
Indicación de historia de la expansión de la
LD
Este elemento de servicio proporciona a un destinatario, en el momento de la entrega, información sobre la(s) lista(s) de distribución por las cuales llegó el mensaje. Es un asunto local en lo que se refiere a la cantidad de información que se presenta al destinatario.
B.27
Prohibición de expansión de la
LD
Este elemento de servicio permite al usuario originador especificar que si cualesquiera de los destinatarios puede, directamente o por reasignación, referirse a una lista de distribución, no habrá expansión. En su lugar se devolverá al AU de origen una notificación de no entrega, a menos que se haya solicitado la prevención de notificación de no entrega.
B.28
SCU (servicio de correo
urgente)
Este elemento de servicio permite al usuario de origen ordenar al SEF que transporte y entregue el mensaje físico producido a partir del mensaje STM, por medio del servicio acelerado de circulación y entrega de cartas (tal como el SCU o servicio local equivalente) en el país de destino.
B.29
Indicación de fecha de
expiración
Este elemento de servicio permite al originador indicar al destinatario la fecha y hora después de la cual considera que el mensaje IP no es válido. La finalidad de este elemento de servicio es indicar la evaluación del originador de la aplicabilidad actual de un mensaje IP. No se especifica la acción particular del AU de MIP en nombre de su destinatario, ni la acción del propio destinatario. Posibles acciones pudieran ser archivar o suprimir el mensaje IP después de transcurrida la fecha de expiración.
B.30
Conversión explícita
Este elemento de servicio permite a un AU originador pedir que el STRM realice una conversión especificada, tal como la requerida cuando hay interfuncionamiento entre diferentes servicios telemáticos. Cuando se entrega un mensaje después que se ha realizado la conversión, se informa al AU destinatario de los tipos de información codificada originales así como los tipos de información codificada actuales del mensaje.
Nota 1
- Este elemento de servicio está destinado a
permitir el interfuncionamiento con terminales/servicios telemáticos.
Nota 2
- Cuando se utilizan nombres LD junto con este
elemento de servicio, la conversión se aplicará a todos los miembros de la LD.
B.31
Indicación de mensaje IP
reenviado
Este elemento de servicio permite que se envíe un mensaje IP reenviado, o
un mensaje IP reenviado más su
`información de entrega'
, como el cuerpo
(o como una de las partes del cuerpo) de un mensaje IP. Junto con la parte del
cuerpo se envía una indicación de que se transmite la parte del cuerpo. En un
cuerpo de múltiples partes, las partes del cuerpo reenviadas pueden incluirse
junto con las partes del cuerpo de otros tipos. La
`información de
entrega'
es la información transportada por el STRM cuando se entrega un
mensaje IP (por ejemplo, indicaciones hora de entrega e indicación de
conversión). Sin embargo, la inclusión de esta información de entrega junto con
un mensaje IP reenviado no garantiza en modo alguno que esta información de
entrega sea válida por el STRM.
Los elementos de servicio indicación de petición de notificación recepción e indicación de notificación de no recepción no son afectados por el reenvío de un mensaje IP.
B.32
Selección de grado de entrega
Este elemento de servicio permite a un AU de origen solicitar que la
transferencia por conducto del STRM se efectúe con carácter
urgente
o
no urgente
, en lugar de
normal
. Los periodos de tiempos definidos para las
transferencias urgente y no urgente son respectivamente más corto y más largo
que el definido para la transferencia normal. Esta indicación también se envía
al destinatario con el mensaje.
B.33
Retención para entrega
Este elemento de servicio permite a un AU destinatario solicitar que el STRM retenga sus mensajes y sus notificaciones de retorno para su entrega en un momento posterior. El AU indica al STRM cuándo estará indisponible para aceptar la entrega de mensajes y notificaciones del STRM y también, cuándo volverá a estar disponible para ello. El STRM puede indicar al AU que hay mensajes en espera debido a los criterios que el AU ha establecido para su retención. La responsabilidad de la gestión de este elemento de servicio incumbe al ATM de destino.
Los criterios para solicitar que se retenga la entrega de un mensaje son: el tipo de información codificada, el tipo del contenido, la longitud máxima del contenido y la prioridad. El mensaje será retenido hasta que expire el plazo de entrega máximo para ese mensaje, a menos que el destinatario libere la retención antes de su expiración.
Nota
- El elemento de servicio retención para entrega
es distinto de la facilidad de almacenamiento de mensajes. El elemento de
servicio de retención para entrega proporciona almacenamiento temporal para
facilitar la entrega y solamente después de que el mensaje se ha transferido al
AU de destinatario, se devuelve la notificación de entrega. La facilidad de
almacenamiento de mensajes aumenta el almacenamiento de un AU y puede
utilizarse para almacenar mensajes durante un periodo de tiempo ampliado. A
diferencia del elemento de servicio retención para entrega, las notificaciones
de entrega se devuelven tan pronto como el mensaje se transfiere (es decir, se
entrega) al almacén de mensajes.
B.34
Conversión implícita
Este elemento de servicio permite que el STRM efectúe para un AU de destino, durante un periodo de tiempo, toda conversión requerida por mensajes antes de entregarlos. Este elemento de servicio no lo solicitan explícitamente ni el AU de origen ni el de destino. Si las capacidades de tipo de información codificada del AU de destino permiten más de un tipo de conversión, se efectúa la más apropiada. Cuando se entrega un mensaje después que se ha realizado la conversión, se indican al AU destinatario los tipos de información codificada original así como los tipos de información codificada actual del mensaje.
B.35
Indicación de importancia
Este elemento de servicio permite al originador indicar a los destinatarios
su evaluación de la importancia del mensaje IP enviado. Se definen tres niveles
de importancia:
poca
,
normal
y
mucha
.
Este elemento de servicio no está relacionado con el elemento de servicio selección de grado de entrega proporcionado por el STRM. No se especifica la acción particular realizada por el destinatario o por su AU de MIP basada en la categorización de importancia. La finalidad es permitir al AU de MIP destinatario, por ejemplo, presentar mensajes IP por orden de importancia o alertar al destinatario sobre la llegada de mensajes IP de mucha importancia.
B.36
Indicación de copia incompleta
Este elemento de servicio permite al originador indicar que este mensaje IP es una copia incompleta de un mensaje IP con la misma identificación de mensaje IP, y que esa parte o esas partes del cuerpo y/o campos de encabezamiento del mensaje IP original están ausentes.
B.37
Identificación del mensaje IP
Este elemento de servicio permite a los AU de MIP cooperantes transmitir un identificador globalmente único para cada mensaje IP enviado o recibido. El identificador de mensaje IP está compuesto de un nombre O/D del originador y un identificador que es único respecto a dicho nombre. Los AU de MIP y los usuarios utilizan este identificador para hacer referencia a mensajes IP previamente enviados o recibidos (por ejemplo, en notificaciones de recepción).
B.38
Indicación de idioma
Este elemento de servicio permite a un AU de origen indicar el tipo o tipos de idioma de un mensaje IP depositado.
B.39
Designación de la última entrega
Este elemento de servicio permite a un AU de origen especificar el último plazo para la entrega del mensaje. Si el STRM no puede efectuar la entrega en el plazo especificado, el mensaje no se entrega y se cancelará. En el caso de los mensajes con múltiples destinatarios, el último plazo de entrega puede expirar antes de que se haya efectuado la entrega a todos los destinatarios, pero ello no anulará ninguna entrega que haya tenido lugar.
B.40
Confidencialidad del flujo del
mensaje
Este elemento de servicio permite al originador del mensaje proteger la información que podría derivarse de la observación del flujo del mensaje.
Nota
- Sólo se admite una forma limitada de este
elemento de servicio.
B.41
Identificación de mensajes
Este elemento de servicio permite al STRM proporcionar a un AU un identificador único para cada mensaje depositado en el STRM, o entregado por éste. Los AU y el STRM utilizan este identificador para hacer referencia a un mensaje previamente depositado en relación con elementos de servicio tales como notificación de entrega y no entrega.
B.42
Autenticación del origen del
mensaje
Este elemento de servicio permite al originador de un mensaje proporcionar al (a los) depositario(s) del mensaje y a cualquier ATM a través del cual el mensaje sea transferido, un medio de autentificar el origen del mensaje (por ejemplo, una firma). La autenticación del origen del mensaje puede proporcionarse, o bien al (a los) destinatario(s) del mensaje y a cualquier ATM a través del cual el mensaje se ha transferido, mensaje por mensaje, utilizando una técnica de cifrado asimétrica, o bien únicamente al (a los) destinatario(s) del mensaje, destinatario por destinatario, utilizando una técnica asimétrica, o una técnica simétrica de cifrado.
B.43
Etiquetado de seguridad del
mensaje
Este elemento de servicio permite al originador de un mensaje (o sonda) asociar al mensaje (y a cualquier informe sobre el mensaje o sonda) una indicación de la sensibilidad del mensaje (una etiqueta de seguridad). La etiqueta de seguridad del mensaje puede ser utilizada por el STRM y el (los) destinatario(s) del mensaje para determinar el tratamiento del mensaje de acuerdo con la política de seguridad en vigor.
B.44
Integridad de la secuencia de
mensajes
Este elemento de servicio permite al originador del mensaje proporcionar al destinatario del mensaje un medio de verificar que se ha conservado la secuencia de mensajes del originador al destinatario (sin pérdida, cambio del orden o repetición de mensajes). La integridad de la secuencia de mensajes se entiende destinatario por destinatario, y para lograrla puede utilizarse una técnica de cifrado simétrica o asimétrica.
B.45
Entrega a múltiples destinos
Este elemento de servicio permite a un AU de origen especificar que el mensaje que deposita se entregue a más de un AU destinatario. Este elemento de servicio no implica la entrega simultánea a todos los AU especificados.
B.46
Cuerpo de múltiples partes
Este elemento de servicio permite al originador enviar a un destinatario o destinatarios un mensaje IP con un cuerpo que está dividido en varias partes. La naturaleza y atributos, o el tipo, de cada parte del cuerpo se transmiten junto con la parte del cuerpo.
B.47
Notificación de no entrega
Este elemento de servicio permite al STRM notificar a un AU de origen que un mensaje no fue entregado al AU o a los AU destinatarios especificados. El motivo por el cual no se entregó el mensaje se incluye como parte de la notificación. Por ejemplo, el AU de destino puede ser desconocido para el STRM.
En el caso de un mensaje multidestino, una notificación de no entrega puede referirse a cualquiera o a todos los AU destinatarios a los cuales el mensaje no puede entregarse.
Cuando un mensaje no es entregado después de la expansión de la lista de distribución, entonces, según la pauta de la lista de distribución, la notificación puede ser enviada al propietario de la lista, al originador del mensaje o a ambos.
B.48
Indicación de petición de notificación de
no recepción
Este elemento de servicio permite al originador pedir que se le notifique cuando se estima que el mensaje IP no puede ser recibido. En el caso de un mensaje IP con múltiples destinatarios, el originador puede solicitar este elemento de servicio destinatario por destinatario.
El AU de origen transmite esta petición al AU de destino. El AU de destino produce automáticamente una notificación de no recepción cuando tiene lugar cualquiera de los sucesos siguientes:
1)El AU del destinatario reenvía automáticamente el mensaje IP a otro usuario.
2)El AU del destinatario descarta el mensaje IP antes de la recepción.
3)El abono del destinatario se ha terminado antes de que pueda recibir el mensaje IP.
Dado que la recepción puede producirse cuando haya transcurrido un periodo de longitud arbitraria desde la entrega, el hecho de que el destinatario no tome conocimiento del mensaje IP, incluso durante un periodo de tiempo prolongado (por ejemplo, durante un largo viaje de negocios) no constituye una no recepción y, en consecuencia, no se emite una notificación.
Nota
- No se puede asignar ningún valor jurídico a
este elemento de servicio.
B.49
No rechazo de la entrega
Este elemento de servicio permite al originador del mensaje obtener del (de los) destinatario(s) del mensaje la prueba irrefutable de que el mensaje fue entregado al (a los) destinatario(s). Esto ofrecerá protección contra cualquier tentativa ulterior, por parte del (de los) destinatario(s) de negar haber recibido el mensaje o su contenido. El no rechazo de la entrega se ofrece al originador de un mensaje por cada destinatario, mediante técnicas de cifrado asimétricas.
B.50
No rechazo del origen
Este elemento de servicio permite al originador del mensaje proporcionar al (a los) destinatario(s) del mensaje una prueba irrefutable del origen del mensaje. Esto ofrecerá protección contra cualquier tentativa ulterior, por parte del originador de anular el mensaje o su contenido. El no rechazo del origen se proporciona al (a los) destinatario(s) de un mensaje, mensaje por mensaje, mediante técnicas de cifrado asimétricas.
B.51
No rechazo del depósito
Este elemento de servicio permite al originador del mensaje obtener una prueba irrefutable de que el mensaje fue depositado en el STRM para ser entregado al (a los) destinatario(s) especificados inicialmente. Esto ofrecerá protección contra cualquier tentativa ulterior, por parte del STRM, de negar haber recibido el mensaje para su entrega al (a los) destinatario(s) especificado(s) inicialmente. El no rechazo del depósito se proporciona al originador de un mensaje, mensaje por mensaje, mediante técnicas de cifrado asimétricas.
B.52
Indicación de obsolescencia
Este elemento de servicio permite al originador indicar que uno o más mensajes IP que envió anteriormente son obsoletos. El mensaje IP que transmite esta indicación sustituye al mensaje IP obsoleto.
La acción que debe realizar el destinatario o su AU de MIP es un asunto de carácter local. Sin embargo, la finalidad es, por ejemplo, permitir al AU de MIP o al destinatario suprimir o archivar mensajes IP obsoletos.
B.53
Correo ordinario
Este elemento de servicio permite al SEF transportar y entregar la carta producida por un mensaje STM en el modo disponible mediante el servicio postal de cartas ordinarias en el país de destino. Esta es la acción por defecto para el transporte y entrega de un mensaje físico.
B.54
Indicación de los tipos de información
codificada originales
Este elemento de servicio permite a un AU originador especificar al STRM los tipos de información codificada de un mensaje depositado. Cuando se entrega el mensaje también se indican al AU destinatario los tipos de información codificada del mensaje especificados por el AU originador.
B.55
Indicación de originador
Este elemento de servicio permite transmitir la identidad del originador al destinatario. La finalidad de este elemento de servicio MIP es identificar al originador de una manera cómoda para el usuario. En cambio, el STRM proporciona al destinatario la dirección O/D y el nombre de guía (si lo hay) autenticados del originador. Los nombres LD no se utilizarán en la indicación de originador.
B.56
Destinatario alternativo solicitado por el
originador
Este elemento de servicio permite a un AU de origen especificar, para cada destinatario deseado, un destinatario alternativo al que el STRM puede entregar el mensaje, en caso de no poder entregarlo a aquél. El destinatario alternativo puede ser una lista de distribución. A efectos de determinar el éxito o el fracaso (y, por tanto, las notificaciones de entrega y no entrega), la entrega al destinatario alternativo solicitado por el originador es equivalente a la entrega al destinatario deseado. Si el destinatario deseado ha solicitado el redireccionamiento de los mensajes entrantes, y si el AU de origen ha solicitado redireccionamiento autorizado por el originador, el sistema tratará primero de redireccionar el mensaje. Si no lo logra, el sistema intentará entregar el mensaje al destinatario alternativo designado.
B.57
Notificación de entrega física por
STM
Este elemento de servicio permite al usuario de origen solicitar al STM que genere y devuelva una notificación explícita que informe al originador sobre el éxito o el fracaso de la entrega de un mensaje físico. La notificación proporciona información sobre la entrega, pero el SEF no proporciona ningún registro físico.
Nota 1
- La notificación incluye la fecha y hora de la
entrega, basándose en la confirmación de entrega proporcionada por la persona
que efectúa la entrega, el destinatario u otra persona autorizada. Esto está
sujeto a la reglamentación nacional del país de destino y también depende del
tipo de entrega solicitada (por ejemplo en el caso de correo certificado al
destinatario en persona, el propio destinatario será la persona que efectúe la
confirmación).
Nota 2
- Esta notificación no implica que el
destinatario haya realizado una acción cualquiera (como el examen del contenido
del mensaje).
Nota 3
- Cuando se solicita este elemento de servicio,
y el mensaje físico no puede ser entregado, será devuelto o destruido según las
disposiciones reglamentarias nacionales del país de destino, lo que significa
que la acción por defecto del elemento de servicio B.91 queda anulada.
B.58
Notificación de entrega física por el
SEF
Este elemento de servicio permite a un usuario de origen solicitar al SEF que genere y devuelva una notificación explícita que le informe del éxito o fracaso de la entrega del mensaje físico. La notificación sirve como dato de entrega, que el usuario de origen puede conservar como referencia.
Nota 1
- La notificación incluye la fecha y hora de la
entrega, y en el caso de entrega correcta, la firma de la persona que confirma
la entrega. La persona que confirma puede ser la persona a que se hace la
entrega, el propio destinatario, u otra persona autorizada. Esto está sujeto a
la reglamentación nacional del país de destino y también depende del tipo de
entrega solicitada (por ejemplo en el caso de correo certificado al
destinatario en persona, el propio destinatario será la persona que confirme).
Nota 2
- Esta notificación no implica que el
destinatario haya realizado una acción cualquiera (como el examen del contenido
del mensaje).
Nota 3
- Cuando se solicita este elemento de servicio,
y el mensaje físico no puede ser entregado, será devuelto o destruido según las
disposiciones reglamentarias nacionales del país de destino, lo que significa
que la acción por defecto del elemento de servicio B.91 queda anulada.
B.59
Autorización de reenvío físico
Este elemento de servicio permite al SEF reenviar el mensaje físico a una dirección de reenvío si el destinatario ha cambiado de dirección y ha indicado esto al SEF. Esta es la acción por defecto que ejecuta el SEF.
B.60
Prohibición de reenvío físico
Este elemento de servicio permite a un usuario de origen ordenar al SEF que no reenvíe el mensaje físico a la dirección de reenvío.
B.61
Prevención de notificación de no
entrega
Este elemento de servicio permite a un AU de origen ordenar al STRM que no devuelva una notificación de no entrega al AU de origen si estima que el mensaje que se deposita es inentregable. En el caso de mensajes con múltiples destinos, el AU de origen puede solicitar este elemento de servicio para cada destinatario.
B.62
Indicación de destinatarios primarios y de
copias
Este elemento de servicio permite al originador proporcionar los nombres del o de los usuarios o LD que son los destinatarios primarios deseados del mensaje IP, y los nombres de los cero o más usuarios o LD que son los destinatarios deseados de copias de mensaje IP. La finalidad es permitir que el destinatario determine la categoría en que se ha colocado a cada uno de los destinatarios especificados (incluido el propio destinatario). La distinción exacta entre estas dos categorías de destinatarios no se ha especificado. Sin embargo, podría suponerse, por ejemplo, que los destinatarios primarios han de realizar una acción relacionada con el mensaje IP, mientras que los destinatarios de copias reciben el mensaje IP solamente para información.
Nota
- Como ejemplo de este elemento de servicio, en
un memorándum típico, los destinatarios primarios se designan normalmente por
la instrucción
`a'
mientras que
`cc:'
identifica a los
destinatarios de copias.
B.63
Sonda
Este elemento de servicio permite a un AU averiguar si un mensaje determinado podrá entregarse, antes de depositarlo efectivamente. El STRM proporciona la información de depósito y genera notificaciones de entrega y/o no entrega para indicar si podrá entregarse un mensaje con la misma información de depósito a los AU destinatarios especificados.
El elemento de servicio sonda comprende la facultad de comprobar si el tamaño tipo de contenido y/o los tipos de información codificada del mensaje harían imposible su entrega. La significación del resultado de una sonda depende de que el AU o los AU destinatarios hayan registrado en el STRM los tipos de información codificada, el tipo de contenido y el tamaño de mensaje máximo que pueden aceptar. Este elemento de servicio está sujeto a los mismos objetivos de plazo de entrega que la clase urgente. En el caso de las LD, una sonda no indica nada sobre la posibilidad de entrega satisfactoria a los miembros de la LD, sino solamente si el originador tiene derecho a entregar a la LD.
B.64
Autenticación del origen de la
sonda
Este elemento de servicio permite al originador de una sonda proporcionar, a cualquier ATM por el que se transfiere la sonda, un medio de autenticar el origen de la sonda (es decir una firma). La autenticación del origen de la sonda se hace sonda por sonda, mediante una técnica de cifrado asimétrica.
B.65
Prueba de la entrega
Este elemento de servicio permite al originador de un mensaje obtener del (de los) destinatario(s) del mensaje el medio de autenticar la identidad del (de los) destinatario(s), así como del mensaje entregado y su contenido. La autenticación de los destinatarios del mensaje se proporciona al originador de un mensaje, para cada destinatario, mediante técnicas de cifrado simétricas o asimétricas.
B.66
Prueba del depósito
Este elemento de servicio permite al originador de un mensaje obtener del STRM el medio de autenticar que el mensaje fue depositado para su entrega al destinatario deseado inicialmente. La autenticación del depósito del mensaje se proporciona mensaje por mensaje, mediante técnicas de cifrado simétricas o asimétricas.
B.67
Indicación de petición de notificación de
recepción
Este elemento de servicio permite al originador pedir que se le notifique la recepción del mensaje IP que se envía. En el caso de un mensaje con múltiples destinatarios, el originador puede solicitar este elemento de servicio destinatario por destinatario. Este elemento de servicio también invoca implícitamente la indicación de petición de notificación de no recepción.
El AU de origen transmite su petición al AU de destino. El destinatario puede ordenar a su AU que satisfaga esas peticiones, ya sea automáticamente (por ejemplo, cuando presenta por primera vez el mensaje IP en el terminal del destinatario), o en cumplimiento de su orden explícita. El destinatario también puede ordenar a su AU que, de manera general o caso por caso, haga caso omiso de esas peticiones.
B.68
Redireccionamiento desautorizado por el
originador
Este elemento de servicio permite a un AU de origen ordenar al STRM, si el destinatario ha solicitado el elemento de servicio redireccionamiento de mensajes entrantes, que el redireccionamiento no se aplique a un determinado mensaje depositado.
B.69
Redireccionamiento de mensajes
entrantes
Este elemento de servicio permite a un AU ordenar al STRM que dirija los mensajes entrantes que llevan su dirección a otro AU o a una LD durante un periodo de tiempo especificado, o hasta que sea revocado.
Nota 1
- Este es un servicio STRM que no precisa la
entrega al destinatario deseado antes de que pueda tener lugar el
redireccionamiento. En consecuencia, es diferente del elemento de servicio
indicación de MIP reenviado automáticamente.
Nota 2
- Cuando están aplicando medidas de seguridad,
en función de las etiquetas de seguridad, mensajes entrantes diferentes podrán
ser redireccionados a distintos destinatarios alternativos, o no ser
redireccionados en absoluto.
B.70
Correo certificado
Este elemento de servicio permite a un usuario de origen ordenar al SEF que trate el mensaje físico como correo certificado.
B.71
Correo certificado para el destinatario en
persona
Este elemento de servicio permite a un usuario de origen ordenar al SEF que trate el mensaje físico como correo certificado, y que lo entregue únicamente al propio destinatario.
B.72
Indicación de petición de
respuesta
Este elemento de servicio permite al originador pedir que el destinatario envíe un mensaje IP en respuesta al mensaje IP que contiene la petición. El originador puede especificar también hasta qué fecha deberá enviarse la respuesta, y el usuario o usuarios y LD a los cuales el originador solicita (pero no exige) que estén entre los destinatarios preferidos de cualquier respuesta. El destinatario es informado de la fecha y nombres, pero le corresponde decidir si responde o no, y a quién.
Nota
- Un destinatario de copia ciega deberá
considerar cuidadosamente a quién envía una respuesta, a fin de que se conserve
el significado del elemento de servicio indicación de destinatario de copia
ciega.
B.73
Indicación de mensaje IP de
respuesta
Este elemento de servicio permite al originador de un mensaje IP indicar el (a los) destinatario(s) que este mensaje IP se envía como respuesta a otro mensaje IP. Según los deseos del originador del mensaje al que se responde, una respuesta, y la decisión final del originador de la respuesta, pueden ser enviadas:
1)a los destinatarios especificados en la indicación de petición de respuesta del mensaje al que se responde;
2)al originador del mensaje al que se responde;
3)al originador y a otros destinatarios;
4)a una lista de distribución, de la que el originador del mensaje al que se responde puede ser un miembro receptor;
5)a otros destinatarios, elegidos por el originador de la respuesta.
Los destinatarios de la respuesta la reciben como mensaje IP ordinario, junto con una indicación del mensaje IP al que se está respondiendo.
B.74
Autenticación de origen del
informe
Este elemento de servicio permite al originador de un mensaje (o sonda) autenticar el origen de un informe sobre la entrega o no entrega del mensaje (o sonda) de asunto (una firma). La autenticación del origen del informe se hace informe por informe, mediante una técnica de cifrado asimétrica.
B.75
Petición de dirección
reenviante
Este elemento de servicio permite a un usuario de origen ordenar al SEF que proporcione la dirección reenviante, si el destinatario cambió su dirección y lo indicó al SEF.
Este elemento de servicio puede utilizarse con el elemento de servicio autorización de reenvío físico o prohibición de reenvío físico. El suministro de la dirección reenviante por el SEF a un usuario de origen está sujeto a la reglamentación nacional del país de destino. La acción por defecto es el no suministro de la dirección reenviante.
B.76
Método de entrega solicitado
Este elemento de servicio permite al usuario solicitar para cada destinatario, el método o métodos de entrega preferidos (por ejemplo, mediante una unidad de acceso). Si el método de entrega preferido no puede proporcionarse, no hay entrega.
B.77
Entrega restringida
Este elemento de servicio permite a un AU de destino indicar al STRM que no está preparado para recibir mensajes de ciertos AU o LD de origen.
Nota 1
- Este elemento de servicio puede solicitarse
de una de dos maneras:
a)Especificación por el AU de destino de los originadores no autorizados; todos los demás originadores se consideran autorizados.
b)Especificación por el AU de destino de los originadores autorizados; todos los demás originadores se consideran no autorizados.
Nota 2
- El servicio abstracto STRM especificado en la
Recomendación X.411 no proporciona una realización técnica de este elemento de
servicio. El que se proporcione puede ser objeto de una futura normalización.
B.78
Devolución de contenido
Este elemento de servicio permite a un AU de origen pedir que el contenido de un mensaje depositado se devuelva con cualquier notificación de no entrega. Sin embargo, esto no se realizará si se ha efectuado cualquier conversión del tipo de información codificada en el contenido del mensaje.
B.79
Gestión de acceso seguro
Este elemento de servicio permite a un usuario STRM establecer una asociación con el STRM, o al STRM establecer una asociación con un usuario STRM, o a un ATM establecer una asociación con otro ATM. También establece las credenciales fuertes de los objetos para que interactúen, así como el contexto, y el contexto de seguridad, de la asociación. La gestión de acceso seguro puede utilizar técnicas de cifrado simétricas o asimétricas. Cuando la seguridad de acceso se logra por medio de credenciales fuertes, éstas pueden actualizarse periódicamente.
B.80
Indicación de sensibilidad
Este elemento de servicio permite al originador de un mensaje IP especificar directrices sobre el grado de seguridad del mensaje IP con relación a su recepción. La finalidad es que la indicación de sensibilidad controle puntos como los siguientes:
1)si el destinatario debe acreditar su identidad para recibir el mensaje IP;
2)si debe permitirse o no que el mensaje IP se imprima en una impresora compartida;
3)si el AU de MIP debe permitir o no al destinatario que reenvíe el mensaje IP recibido;
4)si debe autorizarse o no que el mensaje IP se reenvíe automáticamente.
La indicación de sensibilidad puede comunicarse al destinatario o ser interpretada directamente por su AU de MIP.
Si no se indica ningún nivel de sensibilidad, debe suponerse que el originador del mensaje IP no ha previsto ninguna restricción sobre la disposición ulterior del mensaje IP por parte del destinatario, y éste queda en libertad de reenviarlo, imprimirlo o proceder como estime conveniente.
Se definen tres niveles específicos de sensibilidad por encima del nivel por defecto:
-
Personal:
^ El mensaje IP se envía al destinatario como
individuo, sin atender a su función. Sin embargo, ello no implica que el
mensaje IP sea privado.
-
Privado:
^ El mensaje IP contiene información que sólo
puede ser vista (u oída) por el destinatario, exclusivamente. El AU de MIP del
destinatario puede proporcionar servicios para asegurar el cumplimiento de esta
condición en nombre del originador del mensaje IP.
-
Confidencial para la compañía:
^ El mensaje IP contiene
información que debe ser tratada de acuerdo con los procedimientos específicos
de la compañía.
B.81
Entrega especial
Este elemento de servicio permite a un usuario de origen ordenar al SEF que transporte la carta producida a partir del mensaje STM mediante el sistema de circulación de la correspondencia ordinaria y que la entregue por un mensajero especial.
B.82
Alerta de mensaje almacenado
Este elemento de servicio permite al usuario de una MM registrar conjuntos importantes de criterios que pueden provocar el envío al usuario de una alerta, cuando llega a la MM un mensaje que satisface los criterios seleccionados. La generación de alerta puede efectuarse como sigue:
1)Si el AU está conectado
`en línea'
con la MM, el mensaje de alerta
será enviado al AU en cuanto un mensaje que satisfaga los criterios registrados
para la generación de alertas llegue a la MM. Si el AU está conectado
`fuera
de línea'
, entonces, la próxima vez que el AU se conecte a su MM después de
llegar a la MM un mensaje que satisfaga los criterios registrados, el usuario
será informado de que hay uno o más casos de alerta, cuyos detalles pueden
precisarse mediante un resumen de mensajes almacenados.
2)Además, o como alternativa al N.o 1, la MM puede utilizar otros mecanismos para informar al usuario.
B.83
Reenvío automático de mensajes
almacenados
Este elemento de servicio permite a un usuario de una MM registrar peticiones de que la MM reenvíe automáticamente mensajes seleccionados que le sean entregados. El usuario de la MM puede seleccionar, registrándolos, varios conjuntos de criterios elegidos entre los atributos disponibles en la MM, y los mensajes que satisfagan cada conjunto de criterios serán automáticamente reenviados a uno o más usuarios o LD. También se puede especificar la inclusión de un texto por criterio de selección con cada mensaje reenviado automáticamente.
B.84
Supresión de mensajes almacenados
Este elemento de servicio permite a un AU de destino suprimir algunos de sus mensajes en la MM. Los mensajes no pueden suprimirse si no han sido previamente listados.
B.85
Captura de mensajes almacenados
Este elemento de servicio permite a un AU de destino extraer de la MM algunos de sus mensajes, o porciones de un mensaje. El AU puede capturar un mensaje (o porciones de un mensaje) basándose en los mismos criterios de búsqueda que se pueden emplear para el listado de mensajes almacenados.
B.86
Listado de mensajes almacenados
Este elemento de servicio proporciona a un AU de destino una lista de información sobre algunos de sus mensajes almacenados en la MM. La información comprende los atributos del sobre y del contenido de un mensaje, y otros añadidos por la MM. El AU puede limitar el número de mensajes que se incluirán en la lista.
B.87
Resumen de mensajes almacenados
Este elemento de servicio proporciona a un AU de destino un cómputo del número de mensajes que satisfacen criterios especificados fundados en uno o más atributos de los mensajes almacenados en la MM.
B.88
Indicación de asunto
Este elemento de servicio permite al originador indicar al destinatario o destinatarios el asunto del mensaje IP enviado. La información de asunto debe suministrarse al destinatario.
B.89
Indicación de hora de depósito
Este elemento de servicio permite al STRM indicar a un AU de origen y al AU de destino la fecha y hora en que se depositó un mensaje en el STRM. En el caso de la entrega física, este elemento de servicio también permite al UAEF indicar la fecha y la hora de depósito del mensaje físico.
B.90
Cuerpo tipificado
Este elemento de servicio permite que se transmitan la naturaleza y atributos del cuerpo del mensaje IP junto con el cuerpo. Debido a que el cuerpo puede sufrir conversiones, el tipo de cuerpo puede cambiar a lo largo del tiempo.
B.91
Correo inentregable con devolución del
mensaje físico
Este elemento de servicio permite al SEF devolver el mensaje físico sin demora, con una indicación de motivo para el originador, si no puede ser entregado al destinatario. Esta es la acción por defecto que debe realizar el SEF.
Nota
- En el caso de entrega por lista de correos, la
devolución del mensaje físico se efectuará después de un cierto periodo de
tiempo.
B.92
Utilización de lista de
distribución
Este elemento de servicio permite a un AU de origen especificar una lista de distribución en lugar de todos los destinatarios individuales (usuarios o LD anidadas) mencionados en ella. Los STRM añadirán los miembros de la lista a los destinatarios del mensaje y los enviarán a dichos miembros. Unas listas de distribución pueden ser miembros de otras listas de distribución, en cuyo caso la lista de destinatarios puede ser sucesivamente ampliada en diversos lugares, en el STRM.
B.93
Registro de capacidades de
usuario/AU
Este elemento de servicio permite a un AU indicar a su ATM, mediante su registro, cualquiera de las siguientes capacidades, o todas ellas, sin restricción, con respecto a la recepción de mensajes:
1)el o los tipos de contenido de los mensajes que está dispuesto a recibir;
2)la longitud máxima del contenido de los mensajes que está dispuesto a recibir;
3)el o los tipos de información codificada de los mensajes que está dispuesto a recibir.
El ATM no entregará a un AU un mensaje que no corresponda a las capacidades registradas, o que las rebase.
ANEXO C (a la Recomendación X.400)
Cambio de los elementos de
servicio a partir de 1984
C.1
Nuevos elementos de servicio
en 1988
^ (Véase el cuadro C-1/X.400.)
Tableau C-1/X.400 [T13.400], p.
C.2
Correspondencia entre los cuadros relativos a los
elementos de servicio en las versiones de 1984 y 1988 del
Libro del CCITT
^(Véase la figura C-1/X.400.)
Figura C-1/X.400, p.
C.3
Clasificación de los nuevos elementos de servicio
Los nuevos elementos de servicio que se añadieron a las Recomendaciones de la serie X.400 de 1984 para crear las Recomendaciones de la serie X.400/F.400 de 1988 se clasifican, todos ellos, como facilidades facultativas de usuario adicionales, con las siguientes excepciones:
C.3.1
Servicio TRM
-indicación de historia de la expansión de la LD;
-método de entrega solicitado.
C.3.2
Servicio MIP
-indicación de historia de la expansión de la LD;
-indicación de idioma;
-método de entrega solicitado.
C.3.3
Intercomunicación entre los servicios TM/EF
Si bien algunos de los elementos de servicio utilizados en esta
intercomunicación se clasifican como
de base
(véase la
Recomendación X.400,
19.4
), y algunos se clasifican como facilidades
facultativas de usuario esenciales (véase la Recomendación X.400,
19.5
), la provisión de la intercomunicación de los servicios TM/EF
es en sí misma facultativa. Cuando se proporciona esta intercomunicación, los
elementos de servicio de base y las facilidades facultativas de usuario deben
ser admitidas tal como se clasifican en esta Recomendación.
C.3.4
Memoria de mensajes
Si bien algunos de los elementos de servicio utilizados con el almacén de
mensajes se clasifican como
de base
(véase la
Recomendación X.400,
19.6
), y otros se clasifican como facilidades
facultativas de usuario esenciales (véase la Recomendación X.400,
19.7
), la provisión de una memoria de mensajes es en sí misma
facultativa y por lo tanto las clasificaciones son únicamente aplicables al
proveedor de un almacén de mensajes.
C.4
Cambios en la clasificación de los elementos de servicio
de 1984
Todos los elementos de servicio de la versión de 1984 han conservado su clasificación con la siguiente excepción:
-petición de notificación de no recepción.
C.4.1
Cambios diversos
El elemento de servicio que en 1984 se denominaba tipos de información codificada registrada se conoce ahora como registro de capacidades de usuario, y se ha ampliado en su funcionalidad.
Para facilitar la lectura, se ha revisado la redacción de algunas de las definiciones de elementos de servicio de 1984.
ANEXO D (a la Recomendación X.400)
Diferencias entre la
Recomendación X.400 del CCITT y la norma de ISO 10021-1
(Este anexo no forma parte de la Recomendación) Este anexo señala las
principales diferencias que existen entre esta Recomendación y la norma
internacional correspondiente de la ISO. Dado que, en muchos casos, las
diferencias conciernen a la inclusión o exclusión de una palabra, oración o
frase, y a que éstas ocurren en muchos sitios a todo lo largo del texto, este
anexo no señala específicamente estos puntos. Más bien resume lo esencial de
estas diferencias.
Las diferencias principales son las siguientes:
1)A lo largo del texto, el CCITT hace referencia a los servicios del CCITT y a su relación con el STM.
2)La figura 5/X.400 que muestra las relaciones entre los dominios de gestión y las notas correspondientes.
3)Los papeles desempeñados por el DGAD y el DGPR en la denominación.
4)La utilización del STM en la prestación de servicios públicos ( 17 ).
5)En el texto de la ISO no figura la nota sobre la responsabilidad del almacenamiento de mensajes con entrega diferida (véase el Î B.19 del anexo B).
MONTAGE: RECOMMANDATION X.401 sur le reste de cette page
Anexo D
Disk 570 (1) NF01/012 (OPM = 01)
- NF01/012 (OPM = 01)
X.200 Disk 571 (2) NF01/007 (OPM = 02)
10.2.1.1.1 Disk 572 (3) NF01/046 (OPM = 03)
(cs,.) Disk ... NF../... (OPM = ..)
(1BT) (BT..) Disk ... (.) NF../... (OPM = ..)
(87.TE.03.S)
(A1.23s) / [26s]
FOLIOS: 75 - 106
(AS) (DO PRC.COSY.2)
MEP {TPS.NON.PHOTO "[PA1]"} : OK= [1]
Saisie diskettes 570^-^572 17.08.89 IR/RM/PR
ID + Vérif. + diskette MAJ + laser 22.09.89 PV
Corr. LASER (1re épreuve) = 3eme 16.10.89 GG
Espaces réservés + Transfert + Impr. 23.10.89 PC
AJOUTER (PA1) (CL1,0,0,0) pour MEP
MEP + LASER 25.10.89 GH/PC
Corr. MEP ........ ..
Insertion des tableaux (tabulateurs 6) 25.10.89 PC
BAT du 8/11/89 10.11.89 PV
MAJ s/disquettes 6.12.89 CD
MONTAGE: FIN DE LA RECOMMANDATION F.400 EN-TêTE DE CETTE
PAGE
Recomendación X.402
SISTEMAS DE TRATAMIENTO DE MENSAJES:
ARQUITECTURA GLOBAL
(Melbourne, 1988)
El establecimiento en diversos países de servicios telemáticos y de servicios
de mensajes con almacenamiento y retransmisión de mensajes controlados por
computadores, y asociados a redes públicas de datos, crea la necesidad de
establecer normas que faciliten el intercambio internacional de mensajes entre
los abonados a estos servicios.
El CCITT,
considerando
(a)la necesidad de los sistemas de tratamiento de mensajes;
(b)la necesidad de almacenar y transferir mensajes de diferentes tipos;
(c)que la Recomendación X.200 define el modelo de referencia de interconexión de sistemas abiertos para aplicaciones del CCITT;
(d)que las Recomendaciones X.208, X.217, X.218 y X.219 sirven de base para las aplicaciones del CCITT;
(e)que las Recomendaciones de la serie X.500 definen los sistemas de guía;
(f)que los sistemas de tratamiento de mensajes se definen en la serie de Recomendaciones: X.400, X.402, X.403, X.407, X.408, X.411, X.413 y X.419;
(g)que la mensajería interpersonal se define en las Recomendaciones X.420 y T.330,
recomienda por unanimidad
(1)que los modelos abstractos de un sistema de tratamiento de mensajes se definen en la sección 2;
(2)que las configuraciones de un sistema de tratamiento de mensajes se definen en la sección 3;
(3)que la denominación, el direccionamiento y el encaminamiento en los sistemas de tratamiento de mensajes se definen en la sección 4;
(4)que el uso de la guía por los sistemas de tratamiento de mensajes se define en la sección 5;
(5)que la realización ISA de un sistema de tratamiento de mensajes se especifica en la sección 6.
íNDICE
SECCIóN 1 -
Introducción
0
Introducción
1
Objeto
2
Referencias
2.1Interconexión de sistemas abiertos
2.2Sistemas de guía
2.3Sistemas de tratamiento de mensajes
3
Definiciones
3.1Interconexión de sistemas abiertos
3.2Sistemas de guía
3.3Sistemas de tratamiento de mensajes
4
Abreviaturas
5
Convenios
5.1NSA.1
5.2Grado
5.3Términos
SECCIóN 2 -
Modelos abstractos
6
Visión de conjunto
7
Modelo funcional
7.1Objetos funcionales primarios
7.2Objetos funcionales secundarios
7.3Objetos funcionales terciarios
7.4Tipos de UA seleccionados
8
Modelo de información
8.1Mensajes
8.2Sondas
8.3Informes
9
Modelo operacional
9.1Transmisión
9.2Funciones de la transmisión
9.3Pasos de la transmisión
9.4Eventos de la transmisión
10
Modelos de seguridad
10.1Políticas de seguridad
10.2Servicios de seguridad
10.3Elementos de seguridad
SECCIóN 3 -
Configuraciones
11
Visión de conjunto
12
Configuraciones funcionales
12.1Respecto a la guía
12.2Respecto a la memoria de mensajes
13
Configuraciones físicas
13.1Sistemas de mensajería
13.2Configuraciones representativas
14
Configuraciones organizativas
14.1Dominios de gestión
14.2Configuraciones representativas
15
El STM global
SECCIóN 4 -
Denominación, direccionamiento y
encaminamiento
16
Visión de conjunto
17
Denominación
17.1Nombres de guía
17.2Nombres de O/D
18
Direccionamiento
18.1Listas de atributos
18.2Juegos de caracteres
18.3Atributos normalizados
18.4Equivalencia de listas de atributos
18.5Formas de direcciones O/D
18.6Atributos condicionales
19
Encaminamiento
SECCIóN 5 -
Uso de la guía
20
Visión de conjunto
21
Autenticación
22
Resolución de nombre
23
Ampliación de LD
24
Evaluación de capacidades
SECCIóN 6 -
Realización por ISA
25
Visión de conjunto
26
Elementos de servicio de aplicación
26.1El concepto de ESA
26.2ESA simétricos y asimétricos
26.3ESA de tratamiento de mensajes
26.4ESA de apoyo
27
Contextos de aplicación
Anexo A
-Clases de objetos de guía y atributos
Anexo B
-Definición de referencia de identificadores de
objetos
Anexo C
-Definición de referencia de clases de objetos
de guía y atributos
Anexo D
-Amenazas contra la seguridad
Anexo E
-Provisión de servicios de seguridad en la
Recomendación X.411
Anexo F
-Diferencias entre la Recomendación del CCITT y
la Norma ISO
Anexo G
-índice
SECCIóN 1 - INTRODUCCIóN
0 Introducción
La presente Recomendación forma parte de una serie de Recomendaciones sobre el tratamiento de mensajes. Esta serie proporciona un amplio esquema de sistemas de tratamiento de mensajes (STM) constituidos por cualquier número de sistemas abiertos cooperantes.
Un STM tiene por objeto permitir a los usuarios el intercambio de mensajes, sobre la base de su almacenamiento y retransmisión. Un mensaje presentado en nombre de un usuario, el originador, es transportado por el sistema de transferencia de mensajes (STRM) y entregado a continuación a los agentes de uno o más usuarios adicionales, los destinatarios. Las unidades de acceso (UA) enlazan el STRM con sistemas de comunicación de otro tipo (por ejemplo, sistemas postales). El usuario recibe la ayuda de un agente de usuario (AU) para la preparación, el almacenamiento y la visualización de los mensajes. Facultativamente, puede recibir la ayuda de un dispositivo de almacenamiento de mensajes (AM) para almacenarlos. El STRM consta de cierto número de agentes de transferencia de mensajes (ATM) que, de manera colectiva, realizan la función de transferencia de almacenamiento y retransmisión de mensajes.
Esta Recomendación especifica la arquitectura global del STM, y sirve como introducción técnica al mismo.
El texto de la presente Recomendación es objeto de un acuerdo conjunto CCITT-ISO. La especificación correspondiente de la ISO es la ISO 10021-2.
1
Objeto
Esta Recomendación define la arquitectura global del STM y sirve como introducción técnica al mismo.
En otras Recomendaciones se especifican otros aspectos del tratamiento de mensajes. La Recomendación X.400 da una visión general, no técnica, del tratamiento de mensajes. La prueba de conformidad de los componentes del STM se describe en la Recomendación X.403. Los convenios establecidos al definir los servicios abstractos proporcionados por los componentes del STM se definen en la Recomendación X.407. Las reglas detalladas según las cuales el STRM convierte los contenidos de los mensajes de un TIC a otro se definen en la Recomendación X.408. El servicio abstracto que proporciona el STRM y el procedimiento que gobierna su operación distribuida se definen en la Recomendación X.411. El servicio abstracto proporcionado por el AM se define en la Recomendación X.413. Los protocolos de aplicación que gobiernan las interacciones de los componentes del STM se especifican en la Recomendación X.419. El sistema de mensajería interpersonal, que es una aplicación del tratamiento de mensajes, se define en la Recomendación X.420. El acceso telemático al sistema de mensajería interpersonal se especifica en la Recomendación T.330.
En el cuadro 1/X.402 se indican de manera resumida las Recomendaciones del CCITT y las normas internacionales de la ISO relacionadas con el tratamiento de mensajes.
Tableau 1/X.402 [T1.402], p.
La guía, que es el instrumento principal para la difusión de la información
relacionada con las comunicaciones entre los componentes del STM, se define en
las Recomendaciones de la serie X.500 (véase el cuadro 2/X.402).
El fundamento arquitectural del tratamiento de mesajes figura en otras Recomendaciones. El modelo de referencia de ISA se define en la Recomendación X.200. En las Recomendaciones X.208 y X.209 se definen la notación NSA.1 para la especificación de las estructuras de datos de los servicios abstractos y los protocolos de aplicación y las reglas de codificación asociadas. La manera de establecer y liberar asociaciones, el ACSE, se especifica en las Recomendaciones X.217 y X.227. En las Recomendaciones X.218 y X.228 se define el método ESTF de transporte fiable de las UDPA por las asociaciones. La manera de efectuar peticiones a otros sistemas abiertos, el ESOD, se especifica en las Recomendaciones X.219 y X.229.
En el cuadro 3/X.402 se indican, en síntesis, las Recomendaciones del CCITT y las normas internacionales de la ISO básicas para el tratamiento de mensajes.
Tableau 2/X.402 [T2.402], p. 2
Tableau 3/X.402 [T3.402], p. 3
La presente Recomendación está estructurada como a continuación se indica. La
sección 1 es la de introducción. En la sección 2 se presentan los modelos
abstractos de tratamiento de mensajes. En la sección 3 se especifica la manera
de configurar el STM para satisfacer una diversidad de exigencias de tipo
funcional, físico u organizativo. En la sección 4 se describe la denominación y
el direccionamiento de usuarios y listas de distribución y el encaminamiento
hacia ellos de los objetos de información. En la sección 5 se indican los usos
que el STM puede hacer de la guía. En la sección 6 se describe cómo se realiza
el STM utilizando la ISA. Los anexos contienen importante información
suplementaria.
No se establecen requisitos de conformidad en relación con esta Recomendación.
2
Referencias
En esta Recomendación y en otras de la misma serie se citan los documentos que se indican a continuación.
2.1
Interconexión de sistemas abiertos
En esta Recomendación y en otras de la misma serie se citan las siguientes especificaciones de la ISA:
X.200Modelo de referencia de interconexión de sistemas abiertos para aplicaciones del CCITT (véase también la Norma ISO 7498)
X.208Especificación de la notación de sintaxis abstracta uno (NSA.1) (véase también la Norma ISO 8824)
X.209Especificación de las reglas básicas de codificación de la notación de sintaxis abstracta uno (NSA.1) (véase también la Norma ISO 8825)
X.217Definición del servicio de control de asociación para la interconexión de sistemas abiertos para aplicaciones del CCITT (véase también la Norma ISO 8649)
X.218Transferencia fiable: modelo y definición de servicios (véase también la Norma ISO 9066-1)
X.219Operaciones a distancia: modelo, notación y definición del servicio (véase también la Norma ISO 9072-1)
X.227Especificación del protocolo de control de asociación para la interconexión de sistemas abiertos para aplicación del CCITT (véase también la Norma ISO 8650)
X.228Transferencia fiable: especificación del protocolo (véase también la Norma ISO 9066-2)
X.229Operaciones a distancia: especificación del protocolo (véase también la Norma ISO 9072-2)
2.2
Sistemas de guía
En esta Recomendación y en otras de la misma serie se citan las siguientes especificaciones de conceptos, modelos y servicios de sistemas de guía:
X.500La guía - Visión de conjunto de conceptos, modelos y servicios (véase también la Norma ISO 9594-1)
X.501La guía - Modelos (véase también la Norma ISO 9594-2)
X.509La guía - Marco de autenticación (véase también la Norma ISO 9594-8)
X.511La guía - Definición del servicio abstracto (véase también la Norma ISO 9594-3)
X.518La guía - Procedimientos para operación distribuida (véase también la Norma ISO 9594-4)
X.519La guía - Especificaciones de protocolos (véase la Norma ISO 9594-5)
X.520La guía - Tipos de atributos seleccionados (véase también la Norma ISO 9594-6)
X.521La guía - Clases de objetos seleccionadas (véase también la Norma ISO 9594-7)
2.3
Sistemas de tratamiento de mensajes
En esta Recomendación y en otras de la misma serie se citan las siguientes especificaciones de sistemas de tratamiento de mensajes:
T.330Acceso telemático al servicio de mensajería interpersonal
X.400Sistema de tratamiento de mensajes: Visión de conjunto del sistema y del servicio (véase también la Norma ISO 10021-1)
X.403Sistemas de tratamiento de mensajes: Pruebas de conformidad
X.407Sistemas de tratamiento de mensajes: Convenios para la definición del servicio abstracto (véase también la Norma ISO 10021-3)
X.408Sistemas de tratamiento de mensajes: Reglas de conversión de tipos de información codificada
X.411Sistemas de tratamiento de mensajes: Definición del servicio abstracto y procedimientos (véase también la Norma ISO 10021-4)
X.413Sistemas de tratamiento de mensajes: Definición del servicio abstracto de almacenamiento de mensajes (véase también la Norma ISO 10021-5)
X.419Sistemas de tratamiento de mensajes: Especificaciones de protocolo (véase también la Norma ISO 10021-6)
X.420Sistemas de tratamiento de mensajes: Sistema de mensajería interpersonal (véase también la Norma ISO 10021-7)
3
Definiciones
Las definiciones que se indican a continuación se aplican a efectos de la presente Recomendación y de otras de la misma serie.
3.1
Interconexión de sistemas abiertos
3.1.1 En esta Recomendación y en otras de la misma serie se emplean los nombres de las siete capas del modelo de referencia así como los siguientes términos definidos en la Recomendación X.200:
a)sintaxis abstracta;
b)entidad de aplicación (EA);
c)proceso de aplicación;
d)unidad de datos de protocolo de aplicación (UDPA);
e)elemento de servicio de aplicación (ESA);
f)tarea de tratamiento de la información distribuida;
g)capa;
h)sistema abierto;
i)interconexión de sistemas abiertos (ISA);
j)par;
k)contexto de presentación;
l)protocolo;
m)modelo de referencia;
n)sintaxis de transferencia;
o)elemento de usuario (EU).
3.1.2 En esta Recomendación y en otras de la misma serie se emplean los nombres de los tipos y valores de datos NSA.1 así como los siguientes términos definidos en las Recomendaciones X.208 y X.209:
a)notación de sintaxis abstracta uno (NSA.1);
b)reglas básicas de codificación;
c)explícito;
d)exportación;
e)implícito;
f)importación;
g)macro;
h)módulo;
i)rótulo;
j)tipo;
k)valor.
3.1.3 En esta Recomendación y en otras de la misma serie se emplean los siguientes términos definidos en la Recomendación X.217:
a)asociación de aplicación; asociación;
b)contexto de aplicación (CA);
c)elemento de servicio control de asociación (ESCA);
d)iniciador;
e)respondedor.
3.1.4 En esta Recomendación y en otras de la misma serie se emplean los siguientes términos definidos en la Recomendación X.218:
a)transferencia fiable (TF);
b)elemento de servicio transferencia fiable (ESTF).
3.1.5 En esta Recomendación y en otras de la misma serie se emplean los siguientes términos definidos en la Recomendación X.219:
a)argumento;
b)asíncrono;
c)vinculado;
d)parámetro;
e)error distante;
f)operación distante;
g)operaciones distantes (OD);
h)elemento de servicio, operaciones distantes (ESOD);
i)resultado;
j)síncrono;
k)no vinculado.
3.2
Sistemas de guía
En esta Recomendación y en otras de la misma serie se emplean los siguientes términos definidos en las Recomendaciones de la serie X.500:
a)atributo;
b)certificado;
c)autoridad certificadora;
d)trayecto de la certificación;
e)inscripción en la guía;
f)agente de sistema de guía (ASG);
g)guía;
h)función confusión;
i)nombre;
j)clase de objeto;
k)objeto;
l)autenticación simple;
m)autenticación fuerte.
3.3
Sistemas de tratamiento de mensajes
A efectos de la presente Recomendación y de otras de la misma serie, son de aplicación las definiciones cuya relación figura en el anexo G.
4
Abreviaturas
A efectos de la presente Recomendación y de otras de la misma serie, son de aplicación las siglas cuya relación figura en el anexo G.
5
Convenios
En esta Recomendación se utilizan los convenios descriptivos indicados a continuación.
5.1
NSA.1
Esta Recomendación emplea, en sus anexos A y C, diversos convenios de descripción basados en la NSA.1, para definir información propia del tratamiento de mensajes, que pueda contener la guía. Utiliza, en particular, las macros OBJECT-CLASS, ATTRIBUTE y ATTRIBUTE-SYNTAX de la Recomendación X.501, para definir las clases de objetos, los atributos y las sintaxis de atributo propias del tratamiento de mensajes.
La NSA.1 aparece en el anexo A como ayuda a la explicación y en el anexo C, innecesariamente en buena medida, como referencia. Cuando hay diferencias entre ambos, se indica una especificación de error.
Obsérvese que los rótulos de identificación de NSA.1 están implícitos en todo el módulo NSA.1 que se define en el anexo C; el módulo es definitivo a este respecto.
5.2
Grado
Cuando en esta Recomendación se describe una clase de estructura de datos
(por ejemplo, direcciones O/D) que tiene componentes (por ejemplo, atributos),
a cada componente se le asigna uno de los siguientes
grados
:
a)
obligatorio (O)
: un componente obligatorio estará
presente en cada caso de la clase;
b)
facultativo (F)
: un componente facultativo estará
presente en un caso de la clase, a discreción del objeto (por ejemplo, usuario)
que suministra ese caso. No hay valor por defecto;
c)
defectible (D)
: un componente defectible estará
presente en un caso de la clase, a discreción del objeto (por ejemplo, usuario)
que ofrece ese caso. En su ausencia se aplica un valor por defecto especificado
por esta Recomendación;
d)
condicional (C)
: un componente condicional estará
presente en un caso de la clase, tal como exige esta Recomendación.
5.3
Términos
En el resto de la presente Recomendación, los términos se escriben en
negritas
al definirlos, en
bastardilla
cuando se hace referencia a los mismos antes de su definición y sin realce
especial en otras ocasiones.
Los términos que son nombres propios se presentan en letras mayúsculas; no así los términos genéricos.
SECCIóN 2 - MODELOS ABSTRACTOS
6 Visión de conjunto
En esta sección se presentan modelos abstractos de
tratamiento de mensajes
, que
proporcionan la arquitectura básica para la elaboración de las
especificaciones, más detalladas, que figuran en otras Recomendaciones de la
serie.
El @
tratamiento de mensajes
@ es \una tarea distribuida
del tratamiento de la información, que comprende las siguientes subtareas
intrínsecamente relacionadas:
a)
transferencia de mensajes
: Transmisión diferida de
objetos de información entre usuarios, empleando computadores como
intermediarios.
b)
almacenamiento de mensajes
: Almacenamiento automático,
para su posterior recuperación, de objetos de información, transportados
mediante la transferencia de mensajes.\
La sección 2 abarca los siguientes temas:
a)modelo funcional;
b)modelo de información;
c)modelo operacional;
d)modelo de seguridad.
Nota
- El tratamiento de mensajes tiene una pluralidad
de aplicaciones, una de las cuales es la mensajería interpersonal que se
describe en la Recomendación X.420.
7 Modelo funcional
En este punto se da un modelo funcional de tratamiento de mensajes. De la realización concreta del modelo se ocupa otra Recomendación de la serie.
El @
entorno del tratamiento de mensajes (ETM)
\ comprende
objetos funcionales
`primarios'
de varios tipos: el
sistema de tratamiento de mensajes
(STM)
, los
usuarios
y las
listas de
distribución
. A su vez, el STM, puede descomponerse en objetos funcionales
`secundarios'
, de menor nivel y de varios tipos: el
sistema de transferencia de mensajes (STRM)
, los
agentes de usuario
, las
memorias de
mensajes
y las
unidades de acceso
. El
STRM
, en fin, puede descomponerse en objetos funcionales
`terciarios'
, aun de menor nivel y de un solo tipo; los
agentes de transferencia de mensajes
.
Los tipos de objetos funcionales primarios, secundarios y terciarios y los
tipos de
unidades de acceso
seleccionadas se definen y
describen por separado en los puntos que siguen.
Tal como se precisa a continuación, los objetos funcionales se adaptan a veces a una o más aplicaciones del tratamiento de mensajes, por ejemplo la mensajería interpersonal (véanse las Recomendaciones X.420 y T.330). Un objeto funcional, que ha sido adaptado a una aplicación, comprende la sintaxis y la semántica del contenido de los mensajes intercambiados en esa aplicación.
Como asunto local, los objetos funcionales pueden tener capacidades
superiores a las especificadas en esta Recomendación o en otras de la misma
serie. En concreto, un
agente de usuario
típico tiene
capacidades de preparación, reproducción y almacenamiento de mensajes que no
están normalizadas.
7.1
Objetos funcionales primarios
El ETM comprende el
sistema de tratamiento de
mensajes
, los
usuarios
y las
listas
de distribución
. Entre estos objetos funcionales primarios se produce una
interacción. A continuación se definen y describen los tipos de objetos.
En la figura 1/X.402 se representa de manera esquemática esa interacción.
Figure 1/X.402, (N), p.
7.1.1
Sistema de tratamiento de mensajes
La finalidad principal del tratamiento de mensajes es transportar objetos
de información de un usuario a otro. Al objeto funcional que lleva a cabo esta
tarea se le denomina @
sistema de tratamiento de mensajes
(STM)
\.
El ETM consta de un solo STM.
7.1.2
Usuarios
La finalidad principal del STM es transportar objetos de información entre
usuarios
. Al objeto funcional (por ejemplo, una persona)
que más que proporcionar tratamiento de mensajes, participa en ese tratamiento,
se le denomina
usuario
.
Cabe distinguir las siguientes clases de usuarios:
a)@
usuario directo
@: \Usuario que participa en el
tratamiento de mensajes utilizando directamente el STM.\
b)@
usuario indirecto
@: \Usuario que participa en el
tratamiento de mensajes utilizando indirectamente el STM, es decir, a través de
otro sistema de comunicaciones (por ejemplo, un sistema postal o una red télex)
al que está enlazado el STM.\
El ETM consta de un número cualquiera de usuarios.
7.1.3
Lista de distribución
Mediante el STM, un usuario puede hacer llegar objetos de información a
grupos de usuarios previamente especificados, así como a usuarios individuales.
Se llama @
lista de distribución (LD)
@ al objeto funcional
que representa a un grupo de usuarios previamente especificado y a otras LD.
Una LD representa cero o más usuarios y LD, a los que se les denomina sus
miembros
. De las LD (si es que hay alguna) se dice que están
jerarquizadas. Pedir al STM que transporte un objeto de información (por
ejemplo, un
mensaje
) a una LD equivale a pedirle que lo
transporte a sus miembros. Téngase en cuenta que se trata de un proceso
recurrente.
El derecho a transportar
mensajes
a una LD
determinada, o el permiso para hacerlo, puede estar bajo control. A ese
derecho, se le denomina
permiso de depósito
. Como asunto
local, es posible restringir más aún el uso de una LD.
El ETM consta de un número cualquiera de LD.
Nota
- Una LD podría estar más restringida,
limitándola por ejemplo al transporte de
mensajes
^ con un
determinado
tipo de contenido
.
7.2
Objetos funcionales secundarios
El STM comprende el
sistema de transferencia de
mensajes
, los
agentes de usuarios
, las
memorias de mensajes
y las
unidades de
acceso
. Entre estos objetos funcionales secundarios se produce una
interacción. Más adelante se definen y describen los tipos de objetos.
En la figura 2/X.402 se representa de forma esquemática esa interacción.
Figure 2/X.402, (N), p.
7.2.1
Sistema de transferencia de mensajes
En el STM se produce un transporte de objetos de información a usuarios
individuales y a los miembros de las LD. El objeto funcional que realmente los
transporta se llama @
sistema de transferencia de mensajes
(STRM)
\. El STRM es un sistema de comunicación de almacenamiento y
retransmisión, del que se puede decir que es la columna vertebral del STM.
El STRM es de uso general y facilita toda clase de aplicaciones del
tratamiento de mensajes. Además, el STRM puede adaptarse a una o más
aplicaciones particulares, es decir, puede efectuar una
conversión
.
El STM consta de un solo STRM.
7.2.2
Agentes de usuario
El objeto funcional por medio del cual un usuario directo aislado participa
en el tratamiento de mensajes se denomina @
agente de usuario
(AU)
\.
Un AU típico está adaptado a una o más aplicaciones particulares del tratamiento de mensajes.
El STM consta de un número cualquiera de AU.
Nota
- En el caso de un AU que preste servicio a un
usuario humano, lo típico es que la interacción entre agente y usuario se
establezca a través de un dispositivo de entrada/salida (por ejemplo, un
teclado, una pantalla, un dispositivo de barrido, una impresora o una
combinación de algunos de estos dispositivos).
7.2.3
Memorias de mensajes
El usuario típico debe almacenar la información que recibe. El objeto
funcional que proporciona a un usuario directo (aislado) la capacidad de
almacenar mensajes se llama @
memoria de mensajes (MM)
\. Cada
MM está asociada a un AU, pero no todos los AU tienen MM asociada.
Las MM son de uso general y facilitan todas las aplicaciones de tratamiento
de mensajes. Además, una MM puede adaptarse a una o más aplicaciones
particulares, de tal modo que pueda, con mayor facilidad,
presentar
mensajes y permitir la
recuperación de mensajes
asociados a esa aplicación.
El STM consta de un número cualquiera de MM.
Nota
- Como asunto local, un AU puede proporcionar
capacidad de almacenamiento de objetos de información que complementa o
sustituye la de una MM.
7.2.4
Unidades de acceso
El objeto funcional que enlaza al STRM con otro sistema de comunicaciones
(por ejemplo, un sistema postal o la red télex) y, a través del cual, sus
patronos participan en el tratamiento de mensajes como usuarios indirectos, se
denomina
unidad de acceso (UA)
.
Una UA típica está adaptada a un sistema de comunicaciones particular y a una o más aplicaciones particulares del tratamiento de mensajes.
El STM consta de un número cualquiera de UA.
7.3
Objetos funcionales terciarios
El STRM está formado por
agentes de transferencia de
mensajes
. Entre estos objetos funcionales terciarios se produce una
interacción. Más adelante se definen y describen los tipos de objetos
terciarios.
En la figura 3/X.402 se representa de manera esquemática esa interacción.
Figure 3/X.402, (N), p.
7.3.1
Agentes de transferencia de mensajes
El STRM transporta objetos de información a usuarios y LD según el modo de
almacenamiento y retransmisión. Al objeto funcional que proporciona el eslabón
de la cadena de almacenamiento y retransmisión del STRM se le denomina
agente de transferencia de mensajes (ATM)
.
Los ATM son de uso general y facilitan las aplicaciones del tratamiento de
mensajes. Además, un ATM se puede adaptar a una o más aplicaciones
particulares, es decir, puede efectuar una
conversión
.
El STR consta de un número cualquiera de ATM.
7.4
Tipos de UA seleccionados
Como se ha descrito anteriormente, entre el STM y otros tipos de sistemas
de comunicaciones se produce un interfuncionamiento a través de las UA. En los
párrafos que siguen se presentan varios tipos de UA seleccionados: de
entrega física
, de acceso telemático y por télex.
7.4.1
Entrega física
Una
unidad de acceso de entrega física (UAEF)
es una UA
que somete los
mensajes
^ (pero no las
sondas
^ ni los
informes
) a
reproducción física
, y transporta los
mensajes físicos
resultantes a un
sistema
de entrega física
.
A la transformación de un
mensaje
^ en un
mensaje físico
^ se le denomina
reproducción
física
. Un
mensaje físico
es un objeto físico (por
ejemplo, una carta y su sobre de papel) que contiene un
mensaje
.
Un
sistema de entrega física (SEF)
es un sistema que
efectúa la
entrega física
. El sistema postal es un tipo
importante de SEF. Se llama
entrega física
a la
transferencia de un mensaje físico a un patrón de un SEF, uno de los usuarios
indirectos a los que la UAEF proporciona capacidades de tratamiento de
mensajes.
La mensajería interpersonal es una de las aplicaciones del tratamiento de mensajes proporcionadas por todas las UAEF (véase la Recomendación X.420).
7.4.2
Telemática
En la Recomendación X.420 se presentan las unidades de acceso telemático, que proporcionan, en exclusiva, la mensajería interpersonal.
7.4.3
Télex
En la Recomendación X.420 se presentan las unidades de acceso télex, que proporcionan, en exclusiva, la mensajería interpersonal.
8
Modelo de información
En este punto se presenta un modelo de información del tratamiento de mensajes. La realización concreta del modelo es objeto de otras Recomendaciones de la serie.
El STM y el STRM pueden transportar objetos de información de tres clases:
mensajes
,
sondas
^ e
informes
. En la primera columna del cuadro 4/X.402 figuran
esas tres clases. Para cada una de ellas se indican, en la segunda columna, los
tipos de objetos funcionales - usuario, AU, MM, ATM y UA - que son origen y
destino final de tales objetos.
Tableau 4/X.402 [T4.402], p.
En los puntos que siguen se definen y describen los objetos de información
cuyo resumen figura en el cuadro 4/X.402.
8.1
Mensajes
La finalidad principal de la transferencia de mensajes es el transporte de
objetos de información llamados
mensajes
de un usuario a
otros. Un mensaje, como se muestra en la figura 4/X.402, consta de las
siguientes partes:
a)@
sobre
@: \Objeto de información cuya composición varía
de un
paso de transmisión
a otro, y que identifica de
manera diversa al
originador
del mensaje y a los
destinatarios potenciales
, informa sobre el transporte
previo y dirige el siguiente por el STRM, y caracteriza el
contenido
del mensaje.\
b)@
contenido
@: \Objeto de información que el STRM ni
examina ni modifica, si no es a efectos de
conversión
,
mientras transporta el mensaje.\
Figure 4/X.402, (N), p.
Una parte de información, que figura en el sobre, identifica el tipo de
contenido. El
tipo de contenido
es un identificador (un
identificador de objeto o entero NSA.1) que indica la sintaxis y la semántica
del contenido en su conjunto. Ese identificador permite al STRM determinar si
el mensaje ha de
entregarse
o no a usuarios particulares,
y permite a los AU y MM interpretar y tratar el contenido.
Otra parte de información, que figura asimismo en el sobre, identifica los
tipos de información codificada representada en el contenido. Un
tipo de información codificada (TIC)
es un identificador (un
identificador de objeto o entero NSA.1) que indica el soporte y el formato (por
ejemplo, texto AI N.o 5 o facsímil del grupo 3) de partes individuales del
contenido. Permite además al STRM determinar si el mensaje se ha de entregar o
no a usuarios particulares, e identificar las oportunidades de
hacer
el mensaje entregable, convirtiendo una porción del
contenido de un TIC a otro.
8.2
Sondas
Un segundo objetivo de la transferencia de mensajes es transportar objetos
de información llamados
sondas
desde un usuario a otros (es
decir, llevarlos hasta los ATM que prestan servicio a esos usuarios). Una sonda
describe una clase de mensajes y se utiliza para determinar si deben
entregarse
o no dichos mensajes.
A un mensaje descrito por una sonda se le llama
mensaje descrito
La sonda consta de un solo sobre. El sobre contiene, en gran parte, la misma información que para un mensaje. Además del tipo de contenido y los tipos de información codificada del mensaje descrito, en el sobre figura la longitud de su contenido.
El
depósito
^ de una sonda da lugar a un comportamiento
del STRM que es, en buena medida, el mismo que suscitaría el
depósito
de cualquier mensaje descrito, salvo que en el
caso de la sonda, se prescinde de la
ampliación y de la entrega
de la LD
. En concreto, y aparte de las consecuencias de la supresión de la
ampliación de la LD
, la sonda da lugar a los mismos
informes
a que daría lugar cualquier mensaje descrito. En
esto reside la utilidad de las sondas.
8.3
Informes
Un tercer objetivo de la transferencia de mensajes es transportar a los
usuarios unos objetos de información, llamados
informes
. Un
informe, generado por el STRM, comunica el resultado o la marcha de la
transmisión
de un mensaje o de una sonda a uno o más
destinatarios potenciales.
Al mensaje o a la sonda que sean objeto de un informe se les llama
mensaje objeto
o
sonda objeto
,
respectivamente.
Un informe referido a un determinado
destinatario
potencial
^ se lleva hasta el
originador
^ del mensaje
o de la sonda objeto, a menos que el
destinatario
potencial
sea un
destinatario miembro
. En este último
caso, el informe es transportado a la LD a la que pertenezca el
destinatario miembro
. Como asunto
local, (es decir, cuando exista una política establecida para esa LD
particular), el transporte del informe puede proseguir hasta el propietario de
la LD, a otro que contenga LD (en caso de jerarquización) o al originador del
mensaje objeto (en su caso), o a ambos.
Los resultados a los que puede referirse un informe único son de las siguientes clases:
a)@
informe de entrega
@: \
Entrega
,
exportación
^ o
afirmación
^ del
mensaje objeto o de la sonda objeto, o bien
ampliación de la
LD
.\
b)@
informe de no entrega
@: \
No
entrega
o
no afirmación
^ del mensaje objeto o de la
sonda objeto.\
Un informe puede comprender uno o más informes de entrega y/o no entrega.
Un mensaje o una sonda puede dar lugar a varios informes de entrega y/o no
entrega relativos a un determinado
destinatario potencial
.
Cada uno de ellos marca el tránsito de un
paso
o
evento
de transmisión diferente.
9 Modelo operacional
En este punto se presenta un modelo operacional de tratamiento de mensajes. La realización concreta del modelo es objeto de otras Recomendaciones de la serie.
El STM puede transportar un objeto de información a usuarios individuales,
LD o una combinación de ambos. El transporte se lleva a cabo por un proceso
llamado
transmisión
, que comprende
pasos
y
eventos
. A continuación se
definen y describen el proceso y sus subdivisiones, así como el papel que los
usuarios y las LD desempeñan en éste.
9.1
Transmisióm
Se llama
transmisión
al transporte o tentativa de
transporte de un mensaje o de una sonda. La transmisión abarca el transporte
del mensaje desde su
originador
a sus
destinatarios potenciales
y el transporte de la sonda
desde su
originador
hasta los ATM, facultados para
afirmar
la
entregabilidad
o no del
mensaje descrito a los
destinatarios potenciales
de
aquélla. La transmisión comprende también el transporte o tentativa de
transporte al
originador
de cuantos informes provoquen el
mensaje o la sonda.
La transmisión se desarrolla a través de una secuencia de
pasos de transmisión
^ y
eventos
. Un
paso de transmisión
(o
paso
) consiste en el transporte de un mensaje, una sonda o
un informe desde un objeto funcional a otro
`adyacente'
al primero. Un
evento de transmisión
(o
evento
) consiste
en el tratamiento de un mensaje, una sonda o un informe en un objeto funcional,
tratamiento que puede influir en la selección, por parte del objeto funcional,
del siguiente paso o evento.
En la figura 5/X.402 se presenta de manera esquemática el flujo de información de la transmisión. Se muestran en ella los tipos de objetos funcionales - usuarios directos, usuarios indirectos, AU, MM, ATM y UA - que pueden tomar parte en una transmisión, los objetos de información - mensajes, sondas, e informes - que pueden ser transportados entre aquéllos y los nombres de los pasos de transmisión mediante los cuales se efectúan esos transportes.
Figure 5/X.402, (N), p.
La figura 5/X.402 destaca el hecho de que, un mensaje o informe, pueden ser
extraídos repetidamente y que sólo el primer transporte de un objeto extraído
desde el AU al usuario constituye
recepción
.
El evento tiene un papel destacado en la transmisión. La
división
^duplica un mensaje o sonda y reparte, entre los
objetos de información resultantes, la responsabilidad de sus
destinatarios inmediatos
. Se llaman
destinatarios inmediatos
a los destinatarios potenciales
asociados a un caso particular de un mensaje o sonda. Un ATM efectúa una
división si el siguiente paso o evento, necesario para transportar un mensaje o
sonda a algunos destinatarios inmediatos, difiere del necesario para
transportarlo a otros. En cada una de las descripciones de pasos y eventos que
a continuación se hacen, se supone que el paso o evento es adecuado para todos
los destinatarios inmediatos, situación que puede crearse, si es preciso, por
división.
9.2
Funciones de la transmisión
Los usuarios y las LD desempeñan una diversidad de papeles en la
transmisión de un mensaje o una sonda. A esos papeles se les clasifica, de
manera informal, en paquetes
`origen'
, papeles
`destino'
y
categorías a las que se pueden elevar los usuarios o las LD.
9.2.1 Un usuario puede desempeñar el siguiente papel
`origen'
en la
transmisión de un mensaje o sonda:
a)@
originador
@: \Usuario (no LD) que es origen último de
un mensaje o sonda.\
9.2.2 Un usuario o una LD pueden desempeñar alguno de los siguientes
papales
`destino'
en la transmisión de un mensaje o sonda:
a)@
destinatario deseado
@: \Uno de los usuarios o de las
LD que el originador especifica como destinos de un mensaje o una sonda.\
b)@
destinatario alternativo especificado por el
originador
@: \Usuario (o LD si hay alguna) al que el originador pide que
sea transportado un mensaje o sonda, si no puede transportarse a un determinado
destinatario deseado.\
c)@
destinatario miembro
@: \LD o usuario al cual se
transporta un mensaje (pero no una sonda), como resultado de una
ampliación de LD
.\
d)@
destinatario alternativo designado por el
destinatario
@: \Usuario (o LD si hay alguna) elegido por un destinatario
miembro, o receptor deseado o alternativo al especificado por el originador,
para que
redireccione
mensajes.\
9.2.3 Un usuario o una LD pueden adquirir alguna de las siguientes categorías durante la transmisión de un mensaje o una sonda:
a)@
destinatario potencial
@: \Cualquier LD o usuario hacia
el cual se transporta un mensaje en cualquier momento durante la transmisión.
Ha de tratarse necesariamente de un destinatario deseado o alternativo al
especificado por el originador o al asignado.\
b)@
destinatario efectivo
(o
receptor
)@: \Un destinatario potencial para el cual tiene
lugar la
entrega
o la
afirmación
.\
9.3
Pasos de la transmisión
En la primera columna del cuadro 5/X.402 figura una lista de los tipos de pasos que pueden producirse en una transmisión. Para cada tipo de la lista se indica, en la segunda columna, si ese paso está normalizado o no en la presente Recomendación o en otras de la misma serie; en la tercera columna, las clases de objetos de información - mensajes, sondas e informes - cuyo transporte está permitido en ese paso y en la cuarta columna, las clases de objetos funcionales - usuarios, AU, MM, ATM y UA - que pueden participar en ese paso como origen o destino del objeto.
El cuadro 5/X.402 está dividido en tres secciones. Los pasos de la primera
sección corresponden a la
`creación'
de mensajes y sondas, los de la
última a la
`distribución'
de mensajes e informes y los de la de en
medio a la
`remisión'
de mensajes, sondas e informes.
En los puntos que siguen se definen y describen cada uno de los tipos de pasos de transmisión cuya relación figura en el cuadro 5/X.402.
Tableau 5/X.402 [T5.402], p.
9.3.1
Origen
En un paso de
origen
, un usuario directo transporta un
mensaje o una sonda a su AU, o bien un usuario indirecto hace otro tanto al
sistema de comunicaciones que le presta servicio. Este paso genera el mensaje o
la sonda y constituye el primero de su transmisión.
El referido usuario es el originador del mensaje o de la sonda. Como tal originador identifica los destinatarios deseados de uno u otro objetos funcionales. Además, para cada destinatario deseado, puede identificar un destinatario alternativo, aunque no es preciso que lo haga.
9.3.2
Depósito
En un paso de
depósito
se transporta a un ATM, un
mensaje o sonda que quedan a cargo del STRM. Cabe distinguir los dos tipos
siguientes de depósito:
a)@
depósito indirecto
@: \Paso de transmisión en el que el
AU del originador transporta un mensaje o sonda a su MM y en el que la MM
efectúa un
depósito directo
. Este paso sigue al de
origen.\
Es un paso que sólo puede darse si el usuario dispone de una MM.
b)@
depósito directo
@: \Paso de transmisión en el que el
AU o la MM originador transportan un mensaje o sonda a un ATM. Este paso sigue
al de origen o se produce como parte de un depósito indirecto.\
Es posible dar este paso tanto si el usuario está equipado con una MM como si no lo está.
El depósito indirecto y el directo son funcionalmente equivalentes, salvo en lo que se refiere a las capacidades adicionales de las que es posible disponer con el primero. El depósito indirecto puede diferir del directo en otros aspectos (por ejemplo, en el número de sistemas abiertos con los que debe establecer una interacción aquel que incorpore un AU) y ser por ello preferible al depósito directo.
Al AU o a la MM que participa en el depósito directo se le llama
agente de depósito
. Un agente de depósito se da a conocer al
STRM mediante un proceso de registro, como resultado del cual el agente de
depósito y el STRM quedan mutuamente informados de sus respectivos nombres, de
sus localizaciones y de cualesquiera otras características necesarias para su
interacción.
9.3.3
Importación
En un paso de
importación
, una UA transporta un mensaje,
una sonda o un informe a un ATM. Este paso introduce en el STRM un objeto de
información llevado en otro sistema de comunicaciones, y se produce a
continuación de su transporte por dicho sistema.
Nota
- El concepto de importación es un concepto
genérico. La manera cómo se efectúe este paso varía, naturalmente, de una UA a
otra.
9.3.4
Transferencia
En un paso de
transferencia
, un ATM transporta un
mensaje, una sonda o un informe a otro ATM. En este paso, el transporte del
objeto de información tiene lugar a lo largo de distancias físicas y, a veces,
organizativas. Se produce a continuación del depósito directo o de la
importación o de una transferencia previa.
Por supuesto, este paso sólo puede darse si el STRM consta de varios ATM.
Cabe distinguir, según sea el número de
DG
^ afectados,
los siguientes tipos de transferencia:
a)@
transferencia interna
@: \Transferencia que implica a
varios ATM en un solo
DG
.\
b)@
transferencia externa
@: \Transferencia que implica a
varios ATM en diferentes
DG
.\
9.3.5
Exportación
En un paso de
exportación
, un ATM transporta un mensaje,
una sonda o un informe a una UA. En este paso, se lanza un objeto de
información desde el STRM hacia otro sistema de comunicaciones. El paso se
produce a continuación del depósito directo, de la importación o de la
transferencia.
El ATM puede generar, como parte de este paso, un informe de entrega.
Nota
- El concepto de exportación es un concepto
genérico. La manera cómo se efectúe este paso varía, naturalmente, de una UA a
otra.
9.3.6
Entrega
En un paso de
entrega
, un ATM transporta un mensaje o un
informe a una MM o a un AU. La MM y el AU corresponden a un destinatario
potencial del mensaje o al originador del mensaje o sonda objeto del informe.
En este paso se confía el objeto de información a un representante del usuario
y se produce tras el depósito directo, la importación o la transferencia.
Además, se eleva al usuario en cuestión a la categoría de destinatario
efectivo.
En el caso de un mensaje el ATM puede generar, como parte de este paso, un informe de entrega.
Se llama
agente de entrega
a la MM o al AU que
participan en la misma. Un agente de entrega se da a conocer al STRM mediante
un proceso de registro, como resultado del cual el agente de entrega y el STRM
quedan mutuamente informados de sus respectivos nombres, de sus localizaciones
y de cualesquiera otras características necesarias para su interacción.
9.3.7
Recuperación
En un paso de
recuperación
, la MM de un usuario
transporta un mensaje o un informe a su AU. El usuario en cuestión es un
destinatario efectivo del mensaje o el originador del mensaje o de la sonda
objeto. Este paso extrae del almacenamiento el objeto de información de manera
no destructiva. Se produce tras el paso de entrega o de una recuperación
previa.
El paso de recuperación sólo puede darse si el usuario está equipado con una MM.
9.3.8
Recepción
En un paso de
recepción
, un AU transporta un mensaje o
informe a su usuario directo, o bien el sistema de comunicaciones que presta
servicio a un usuario indirecto transporta ese objeto de información a dicho
usuario. En cualquier caso, este paso transporta el objeto a su destino último.
Si se trata de un usuario directo, este paso sucede a la entrega del objeto o a la primera recuperación (solamente). Si se trata de un usuario indirecto, sucede al transporte de un objeto de información por el sistema de comunicaciones que sirve al usuario. En cualquiera de los dos casos, el usuario es un destinatario potencial (pero si es usuario directo, es destinatario no ya potencial sino efectivo) del mensaje objeto o la sonda objeto.
9.4
Eventos de la transmisión
En la primera columna del cuadro 6/X.402 se da una relación
de los tipos de eventos que pueden producirse en una transmisión. Para cada
tipo de evento se indica, en la segunda columna, los tipos de objetos de
información, - mensajes, sondas e informes - para los que pueden desarrollarse
tales eventos, y en la tercera columna, los tipos de objetos funcionales -
usuarios, AU, MM, ATM y UA - a los que les está permitido desarrollarlos.
Todos los eventos se producen dentro del STRM.
Figure omitted: 22 Tableau 6/X.402 [T6.402]
Tableau 6/X.402 [T6.402], p.
Los tipos de eventos de transmisión, resumidos en el cuadro 6/X.402 son
definidos y descritos separadamente en los puntos que siguen.
9.4.1
División
En un evento de
división
, un ATM duplica un mensaje o
sonda y reparte, entre los objetos de información resultantes, la
responsabilidad de sus destinatarios inmediatos. Este evento permite de manera
efectiva a un ATM transportar independientemente un objeto a varios
destinatarios potenciales.
Un ATM efectúa una división cuando el siguiente paso o evento, necesario para el transporte de una sonda o mensaje a algunos destinatarios inmediatos, difiere del necesario para transportarlo a otros.
9.4.2
Combinación
En un evento de
combinación
, un ATM combina varios casos
del mismo mensaje o sonda, o dos o más informes, de entrega y/o no entrega para
el mismo mensaje o sonda objeto.
Un ATM puede, aunque no necesariamente, efectuar una combinación cuando determine que, para transportar a sus destinos varios objetos de información muy relacionados, hacen falta los mismos eventos y el mismo paso siguiente.
9.4.3
Resolución de nombre
En un evento de
resolución de nombre
, un ATM agrega la
dirección O/D
^ correspondiente al
nombre
O/D
^ que identifica a uno de los destinatarios inmediatos de un mensaje o
una sonda.
9.4.4
Ampliación de LD
En un evento de
ampliación de LD
, un ATM asigna una LD
de entre los destinatarios de un mensaje (pero no de una sonda) a sus miembros,
que de este modo se convierten en destinatarios miembros. Este evento elimina
la falta de dirección de la especificación de los destinatarios inmediatos.
A una LD determinada se le somete a ampliación siempre en una localización
preestablecida, dentro del STRM. Esta localización se llama
punto
de ampliación
de la LD, y viene identificada por una
dirección
O/D
.
El ATM puede generar, como parte de este evento, un informe de entrega.
La ampliación de la LD está sujeta al permiso de presentación. En el caso de una LD jerarquizada, ese permiso debe haber sido concedido a la LD de la que aquélla es miembro. De lo contrario, el permiso debe haber sido concedido al originador.
9.4.5
Redireccionamiento
En un evento de
redireccionamiento
, un ATM sustituye a
un usuario o a una LD entre los destinatarios inmediatos de un mensaje o de una
sonda, por un destinatario alternativo, especificado por el originador o
asignado por el destinatario.
9.4.6
Conversión
En un evento de
conversión
, un ATM transforma partes del
contenido de un mensaje de un TIC en otro, o altera una sonda de modo que
parezca que los mensajes descritos fueron igualmente modificados. Este evento
aumenta la probabilidad de que un objeto de información pueda ser entregado o
afirmado, adaptándolo a sus destinatarios inmediatos.
Se distinguen los dos tipos de conversión que se indican a continuación, y que difieren en cómo se eligen el TIC de la información a convertir y el TIC resultante de la conversión:
a)@
conversión explícita
@: \Conversión en la que el
originador elige tanto el TIC inicial como el final.\
b)@
conversión implícita
@: \Conversión en la que el ATM
elige los TIC finales, en función de los TIC iniciales y de las capacidades del
AU.\
9.4.7
No entrega
En un evento de
no entrega
, un ATM establece que el STRM
no puede entregar un mensaje a sus destinatarios inmediatos, o no puede
entregar un informe al originador de su mensaje o sonda objeto. Este evento
detiene el transporte de un objeto al que el STRM considere intransportable.
En el caso de mensaje, el ATM genera, como parte de este evento, un informe de no entrega.
Un ATM efectúa una no entrega cuando, por ejemplo, determina que los destinatarios inmediatos no están especificados adecuadamente, que no aceptan la entrega de mensajes como el mensaje de que se trate, o que no se les ha entregado dentro de los límites de tiempo preestablecidos.
9.4.8
No afirmación
En un evento de
no afirmación
, un ATM establece que el
STRM no puede entregar un mensaje descrito a los destinatarios inmediatos de
una sonda. Este evento determina parcial o totalmente la respuesta a la
cuestión planteada por una sonda.
El ATM genera, como parte de ese evento, un informe de no entrega.
Un ATM produce una no afirmación cuando, por ejemplo, encuentra que los destinatarios inmediatos no están especificados adecuadamente o que no aceptarían la entrega de un mensaje descrito.
9.4.9
Afirmación
En un evento de
afirmación
, un ATM establece que el STRM
puede entregar cualquier mensaje descrito a los destinatarios inmediatos de una
sonda. Este evento determina parcial o totalmente la respuesta a la cuestión
planteada por una sonda y eleva a los destinatarios inmediatos a la categoría
de destinatarios efectivos.
El ATM puede generar, como parte de este evento, un informe de entrega.
Un ATM produce una afirmación una vez que ha constatado que los destinatarios inmediatos están especificados adecuadamente y, si esos destinatarios son usuarios (pero no LD), que aceptarían la entrega de cualquier mensaje descrito. Si los destinatarios inmediatos son LD, el ATM producirá una afirmación si existe la LD y si el originador tiene el permiso de presentación pertinente.
9.4.10
Encaminamiento
En un evento de
encaminamiento
, un ATM selecciona el ATM
`adyacente'
al que transferirá un mensaje, sonda o informe. Este evento
determina, de manera incremental, el camino de un objeto de información a
través del STRM y, obviamente, sólo puede producir si el STRM consta de varios
ATM.
Hay dos tipos de encaminamiento, que difieren entre sí por la clase de transferencia para la que preparan:
a)@
encaminamiento interno
@: \Encaminamiento que prepara
para una transferencia interna (es decir, una transferencia dentro de un
DG
).\
b)@
encaminamiento externo
@: \Encaminamiento que prepara
para una transferencia externa (es decir, una transferencia entre distintos
DG
).\
Un ATM realiza un encaminamiento cuando determina que no puede efectuar ningún otro evento ni dar ningún paso con respecto a un objeto.
10
Modelo de seguridad
En este punto se presenta un modelo de seguridad abstracto para la transferencia de mensajes. La realización concreta del modelo es tema de otras Recomendaciones de la serie. El modelo de seguridad proporciona un marco para la descripción de los servicios de seguridad que contrarrestan los riesgos potenciales (véase el anexo D) del STM, y de los elementos de seguridad que facilitan estos servicios.
Las características de seguridad constituyen una ampliación facultativa del STM, que pueden emplearse para minimizar el riesgo de exposición de bienes de capital y recursos a las infracciones de una política de seguridad (riesgos). Su objetivo es proporcionar seguridad con independencia de los servicios de comunicaciones proporcionados por otras entidades, de nivel superior o inferior. Los riesgos pueden combatirse mediante el recurso a la seguridad de tipo físico, la seguridad de los computadores (COMPUSEC) o los servicios de seguridad proporcionados por el STM. Según cuales sean los riesgos que se contemplen, se seleccionarán unos u otros servicios de seguridad de STM en combinación con adecuadas medidas de seguridad física y de COMPUSEC. Los servicios de seguridad facilitados por el STM se describen más adelante. La denominación y la estructuración de los servicios se basan en la norma ISO 7498-2.
Nota
- A pesar de estas características de seguridad,
pueden producirse ciertas agresiones contra las comunicaciones entre un usuario
y el STM o contra las comunicaciones de usuario a usuario (por ejemplo, en el
caso de usuarios que acceden al STM a través de una unidad de acceso, o de
usuarios con acceso a distancia a sus AU). Para contrarrestar esas agresiones
es preciso ampliar los servicios y modelos actuales de seguridad, lo que
requiere
ulterior estudio
.
En muchos casos, la amplitud de los tipos de riesgos queda cubierta por varios de los servicios anotados.
Los servicios de seguridad se facilitan mediante el uso de elementos de servicio del sobre de mensajes del STRM. El sobre contiene argumentos propios de la seguridad, tal como se describe en la Recomendación X.411. La descripción de los servicios de seguridad que figura más adelante, se hace de la siguiente manera: en el 10.2 se da una relación de los servicios con su definición e indicación, en cada caso, de cómo pueden ser proporcionados empleando los elementos de seguridad de la Recomendación X.411 y en el 10.3 se describen uno a uno los elementos de seguridad con definición, en cada caso, del elemento de servicio, y referencias a sus argumentos constituyentes, según la Recomendación X.411.
Muchas de las técnicas empleadas se basan en mecanismos de cifrado. Los servicios de seguridad del STM permiten elegir los algoritmos con flexibilidad. Sin embargo, en algunos casos, sólo se ha definido totalmente en esta Recomendación la utilización del cifrado asimétrico. En una futura versión de la Recomendación se podrán utilizar mecanismos alternativos de cifrado simétrico.
Nota
- Las expresiones
`servicio de seguridad'
y
`elemento de seguridad'
que se emplean en este punto no deben
confundirse con las expresiones
`elemento de servicio'
y
`servicio'
empleadas en la Recomendación X.400. Las primeras expresiones
se utilizan en este punto para mantener la armonía con ISO 7498-2.
10.1
Políticas de seguridad
Los servicios de seguridad del STM deben poder facilitar una amplia gama de políticas de seguridad, que va más allá de los límites del propio STM. Los servicios seleccionados y los riesgos contra los que se pretende asegurarse dependerán de la aplicación concreta y de los niveles de confianza que se tenga en las distintas partes del sistema.
La política de seguridad define cómo reducir a un nivel aceptable el riesgo de exposición al peligro de los bienes de capital.
Además será preciso el funcionamiento entre dominios diferentes, cada uno de ellos con su propia política de seguridad. Se deberán establecer acuerdos bilaterales sobre ese interfuncionamiento, ya que las políticas globales de seguridad, más amplias que la del mero STM, a que esos dominios estén sujetos, diferirán de todos modos entre sí. Debe definirse esto de tal manera que no se entre en conflicto con la política de seguridad de ninguno de los dos dominios y que el acuerdo llegue efectivamente a formar parte de la política de seguridad global de ambos.
10.2
Servicio de seguridad
Se definen en este punto los servicios de seguridad de la transferencia de mensajes. La denominación y la estructura de los mismos se basa en la norma ISO 7498-2.
Los servicios de seguridad de la transferencia de mensajes son de amplias y variadas clases. Esas clases, y los servicios correspondientes a cada una de ellas, aparecen relacionadas en el cuadro 7/X.402.
A lo largo de la serie de definiciones de servicios que viene a continuación se hace referencia a la figura 6/X.402, que representa el modelo funcional del STM de forma simplificada. En el texto se hace referencia en varias ocasiones a las etiquetas numeradas.
10.2.1
Servicios de seguridad de autenticación de
origen
Estos servicios de seguridad facilitan la autenticación de la identidad de entidades pares comunicantes y de fuentes de datos.
10.2.2.1
Servicios de seguridad de autenticación de
origen de datos
Estos servicios de seguridad permiten la confirmación del origen de un mensaje, una sonda o un informe a todas las entidades afectadas (es decir, los ATM o los usuarios del STRM destinatarios). No pueden proteger contra la duplicación de mensajes, sondas e informes.
10.2.1.1.1
Servicio de seguridad de autenticación de
origen de mensajes
Este servicio de seguridad permite la confirmación del origen de un mensaje.
El servicio puede proporcionarse utilizando el elemento de seguridad de autenticación de origen de mensajes o el de integridad de argumento de mensajes. El primero se puede emplear para dar servicio de seguridad a cualquiera de las partes afectadas (1 a 5 inclusive, en la figura 6/X.402), mientras que el segundo sólo puede utilizarse para proporcionar servicio de seguridad a los usuarios del STRM (1 ó 5 en la figura 6/X.402). El elemento de seguridad elegido depende de la política de seguridad vigente.
10.2.1.1.2
Servicio de seguridad de autenticación de
origen de sondas
El servicio de seguridad de autenticación de origen de sondas permite la confirmación del origen de una sonda.
Este servicio puede proporcionarse utilizando el elemento de seguridad de autenticación de origen de sondas. Puede emplearse el elemento de seguridad para dar el servicio a cualquiera de los ATM a través de los cuales se transfiere la sonda (2 a 4 inclusive, en la figura 6/X.402).
10.2.1.1.3
Servicio de seguridad de autenticación de
origen de informes
El servicio de seguridad de autenticación de origen de informes permite la confirmación del origen de un informe.
Este servicio puede proporcionarse utilizando el elemento de seguridad de autenticación de origen de informes. El elemento de seguridad se emplea para dar servicio de seguridad al originador del mensaje o de la sonda objeto, así como a cualquiera de los ATM a través de los cuales se transfiere el informe (1 a 5 inclusive, en la figura 6/X.402).
Tableau 7/X.402 [T7.402], p. 12
Figure 6/X.402, (N), p. 13
10.2.1.2
Servicio de seguridad de prueba de
depósito
Este servicio de seguridad permite al originador de un mensaje obtener la confirmación de que ha sido recibido por el STRM para su entrega al destinatario o destinatarios especificados originalmente.
El servicio puede proporcionarse utilizando el elemento de seguridad de prueba de depósito.
10.2.1.3
Servicio de seguridad de prueba de
entrega
Este servicio de seguridad permite al originador de un mensaje obtener la confirmación de que ha sido entregado por el STRM al destinatario o destinatarios deseados.
El servicio puede proporcionarse utilizando el elemento de seguridad de prueba de entrega.
10.2.2
Servicio de seguridad de gestión de acceso
seguro
El servicio de seguridad de gestión de acceso seguro se ocupa de la protección de los recursos contra su utilización no autorizada. Puede dividirse en dos componentes: servicio de autenticación de entidades pares y servicio de contexto de seguridad.
10.2.2.1
Servicio de seguridad de autenticación de
entidades pares
Este servicio de seguridad se proporciona al establecer una conexión, para confirmar la identidad de la entidad que se conecta. Puede utilizarse en los enlaces 1-2, 2-3, 3-4 ó 4-5 de la figura 6/X.402 y asegura, al utilizarlo únicamente, contra los intentos de suplantación o de reactuación no autorizada de una conexión previa, por parte de una entidad.
El elemento de seguridad de intercambio de autenticación facilita este servicio. Téngase en cuenta que como consecuencia de la utilización de este elemento de seguridad, pueden liberarse otros datos, que en determinadas circunstancias podrían emplearse para facilitar un servicio de seguridad de confidencialidad de conexión y/o de integridad de conexión.
10.2.2.2
Servicio de seguridad de contexto de
seguridad
Este servicio de seguridad se utiliza para limitar el alcance del paso de mensajes entre entidades, por referencia a las etiquetas de seguridad asociadas a los mensajes. Es un servicio que está, por tanto, en estrecha relación con el de seguridad de etiquetado de seguridad de mensajes, que permite la asociación de mensajes y etiquetas de seguridad.
Los elementos de seguridad de contexto de seguridad y registro facilitan el servicio de contexto de seguridad.
10.2.3
Servicios de seguridad de confidencialidad de
datos
Estos servicios de seguridad protegen los datos contra su revelación no autorizada.
10.2.3.1
Servicio de seguridad de confidencialidad
de conexión
El STM no presta un servicio de seguridad de confidencialidad de conexión. No obstante, pueden proporcionarse datos en capas subyacentes para la invocación de tal servicio, como resultado del empleo del elemento de seguridad de intercambio de autenticación, para proporcionar el servicio de seguridad de autenticación de entidades pares. Este servicio de seguridad puede ser necesario en alguno de los enlaces 1-2, 2-3, 3-4 ó 4-5 de la figura 6/X.402.
10.2.3.2
Servicio de seguridad de confidencialidad
de contenido
El servicio de seguridad de confidencialidad de contenido garantiza que el contenido de un mensaje sólo sea conocido por su emisor y su destinatario.
Es posible proporcionar este servicio mediante una combinación de los elementos de seguridad de confidencialidad de contenido y de confidencialidad de argumento de mensajes. Este último se puede emplear para transferir una clave secreta, utilizada con el primero en el cifrado del contenido del mensaje. Con estos elementos de seguridad, se proporciona el servicio desde el usuario 1 al usuario 5 del STRM, de la figura 6/X.402, siendo el mensaje ininteligible para los ATM.
10.2.3.3
Servicio de seguridad de confidencialidad de
flujo de mensajes
Este servicio de seguridad protege contra la extracción de información que podría lograrse mediante la observación del flujo de mensajes. El STM proporciona este servicio sólo de forma limitada.
La técnica del sobre doble permite que un mensaje completo se convierta en contenido de otro mensaje. Esta técnica puede emplearse para ocultar la información de direccionamiento en determinados tramos del STRM. Junto con el rellano de tráfico (que queda fuera del objeto actual de esta Recomendación) podría utilizarse para lograr la confidencialidad del flujo de mensajes. Otros elementos de este servicio, tales como el control del encaminamiento o los pseudónimos, quedan también fuera del objeto de esta Recomendación.
10.2.4
Servicios de seguridad de integridad de
datos
Estos servicios de seguridad se proporcionan para contrarrestar riesgos activos contra el STM.
10.2.4.1
Servicio de seguridad de integridad de
conexión
El STM no presta un servicio de seguridad de integridad de conexión. No obstante, pueden proporcionarse datos en capas subyacentes para la invocación de tal servicio, utilizando el elemento de seguridad de intercambio de autenticación en la prestación del servicio de seguridad de autenticación de entidades pares. El servicio puede ser necesario en alguno de los enlaces 1-2, 2-3, 3-4 ó 4-5 de la figura 6/X.402.
10.2.4.2
Servicio de seguridad de integridad de
contenido
Este servicio de seguridad garantiza la integridad del contenido de un mensaje. Para ello, se habilita la determinación de si el contenido del mensaje ha sido o no modificado. El servicio no permite detectar reactuaciones de mensajes, lo que si es facilitado, en cambio, por el servicio de seguridad de integridad de secuencia de mensajes.
El servicio puede proporcionarse de dos modos diferentes, utilizando dos diferentes combinaciones de elementos de seguridad.
El elemento de seguridad de integridad de contenido junto con el de integridad de argumento de mensajes y, en algunos casos, el de confidencialidad de argumento de mensajes, pueden utilizarse para prestar servicio de seguridad a un destinatario de mensajes, es decir, para la comunicación del usuario 1 al usuario 5 del STRM, de la figura 6/X.402. El elemento de seguridad de integridad de contenido se emplea para computar una verificación de integridad de contenido, como una función del contenido total del mensaje. Dependiendo de cual sea el método de cómputo de la verificación, puede ser necesaria una clave secreta que se envía, de manera confidencial, al destinatario del mensaje, utilizando el elemento de seguridad de confidencialidad de argumento de mensajes. Mediante el elemento de seguridad de integridad de argumento de mensajes se protege la verificación de integridad del contenido contra posibles cambios. La integridad de cualquier argumento de mensaje confidencial se garantiza utilizando el elemento de seguridad de confidencialidad de argumento de mensajes.
También puede emplearse el elemento de seguridad de autenticación de origen de mensajes para prestar este servicio de seguridad.
10.2.4.3
Servicio de seguridad de integridad de
secuencia de mensajes
Este servicio de seguridad protege al originador y al destinatario de una secuencia de mensajes, contra el reordenamiento de la secuencia. Al mismo tiempo, protege contra la reactuación de mensajes.
Puede proporcionarse el servicio haciendo uso de una combinación de los elementos de seguridad de integridad de secuencia de mensajes y de integridad de argumento de mensajes. El primero da a cada mensaje un número de secuencia que puede protegerse contra posibles cambios mediante el segundo elemento. Es posible proporcionar simultáneamente confidencialidad e integridad del número de secuencia de mensajes, empleando el elemento de seguridad de confidencialidad de argumento de mensajes.
Estos elementos de seguridad facilitan el servicio para la comunicación del usuario 1 al usuario 5 del STRM, de la figura 6/X.402, y no a los ATM intermedios.
10.2.5
Servicio de seguridad de no
rechazo
Estos servicios de seguridad dan garantía absoluta a un tercero, después de que el mensaje ha sido depositado, enviado o entregado, de que el depósito, el envío o la recepción se han producido tal como se dice. Téngase en cuenta que, para que esto funcione correctamente, la política de seguridad debe abarcar de manera explícita la gestión de claves asimétricas, a efectos de servicios de no rechazo, si se utilizan algoritmos asimétricos.
10.2.5.1
Servicio de seguridad de no rehazo de
origen
Este servicio de seguridad da al destinatario o destinatarios de un mensaje garantía absoluta del origen del mismo, de su contenido y de su etiqueta de seguridad de mensaje asociada.
El servicio puede proporcionarse de dos modos diferentes, utilizando dos combinaciones distintas de elementos de seguridad. Téngase en cuenta que la prestación de este servicio es muy similar a la del servicio de seguridad de integridad de contenido (más débil).
El elemento de seguridad de integridad de contenido junto con el de integridad de argumento de mensajes y, en algunos casos, el de confidencialidad de argumento de mensajes, pueden utilizarse para prestar servicio de seguridad a un destinatario de mensajes, es decir, para la comunicación del usuario 1 al usuario 5 del STRM, de la figura 6/X.402. El elemento de seguridad de integridad de contenido se emplea para computar una verificación de integridad de contenido, como una función del contenido total del mensaje. Dependiendo de cuál sea el método de cómputo de la verificación, puede ser necesaria una clave secreta que se envía, de manera confidencial, al destinatario del mensaje utilizando el elemento de seguridad de confidencialidad de argumento de mensajes. Mediante el elemento de seguridad de integridad de mensajes se protege la verificación y, si hace falta, a la etiqueta de seguridad de mensajes, contra un posible cambio y/o rechazo. Cualquier argumento de mensaje confidencial queda protegido contra cambio y/o rechazo utilizando el elemento de seguridad de confidencialidad de argumento de mensajes.
Si no se requiere el servicio de seguridad de confidencialidad de contenido, también es posible emplear, como base de este servicio de seguridad, el elemento de seguridad de autenticación de origen de mensajes. En este caso puede proporcionarse el servicio de seguridad a todos los elementos del STM, es decir, a todos los usuarios del STRM y ATM de la figura 6/X.402.
10.2.5.2
Servicio de seguridad de no rechazo de
depósito
Este servicio de seguridad da, al originador del mensaje, garantía absoluta de que el mensaje ha sido depositado en el STRM para su entrega al destinatario o destinatarios originalmente especificados.
El servicio se proporciona utilizando el elemento de seguridad de prueba de depósito, de manera muy similar a como se utiliza ese elemento de seguridad para facilitar el servicio de seguridad de prueba de depósito (más débil).
10.2.5.3
Servicio de seguridad de no rechazo de entrega
Este servicio de seguridad da, al originador del mensaje, garantía absoluta de que el mensaje ha sido entregado al destinatario o destinatarios originalmente especificados.
El servicio se proporciona utilizando el elemento de seguridad de prueba de entrega, de manera muy similar a como se utiliza ese elemento de seguridad para facilitar el servicio de seguridad de prueba de entrega (más débil).
10.2.6
Servicio de seguridad del etiquetado de
seguridad de mensajes
Este servicio de seguridad permite asociar etiquetas de seguridad a todas las entidades del STM, es decir, los ATM y los usuarios del STRM. Conjuntamente con el servicio de seguridad de contexto de seguridad, facilita la ejecución de políticas de seguridad que precisen qué partes del STM pueden tratar mensajes, mediante las etiquetas de seguridad asociadas especificadas.
El servicio lo proporciona el elemento de seguridad de la etiqueta de seguridad de mensajes. Los elementos de seguridad de integridad de argumento de mensajes y de confidencialidad de argumento de mensajes aseguran la integridad y confidencialidad de la etiqueta.
10.2.7
Servicio de gestión de la
seguridad
El STM necesita cierto número de servicios de gestión de seguridad. Los únicos servicios de gestión previstos en la Recomendación X.411 tratan del cambio de credenciales y del registro de etiquetas de seguridad de usuario del STRM.
10.2.7.1
Servicio de seguridad de cambio de
credenciales
Este servicio de seguridad permite a una entidad del STM cambiar las credenciales que le afectan, contenidas en otra entidad del STM. Puede proporcionarse utilizando el elemento de seguridad de cambio de credenciales.
10.2.7.2
Servicio de seguridad de registros
Este servicio de seguridad permite el establecimiento en un ATM, de las etiquetas de seguridad autorizadas para un determinado usuario del STRM. Puede proporcionarse utilizando el elemento de seguridad de registros.
10.2.7.3
Servicio de seguridad de registro de la MM
Este servicio de seguridad permite el establecimiento de las etiquetas de seguridad que son admisibles para el usuario de la MM.
10.3
Elementos de seguridad
En los puntos que siguen se describen los elementos de seguridad, disponibles en los protocolos de la Recomendación X.411, para facilitar los servicios de seguridad en el STM. Esos elementos están relacionados directamente con los argumentos de varios servicios descritos en la Recomendación X.411. Este punto tiene por objeto extraer los elementos de las definiciones de servicios de la Recomendación X.411 que tienen relación con la seguridad, y definir la función de cada uno de esos elementos de seguridad identificados.
10.3.1
Elementos de seguridad de
autenticación
Estos elementos de seguridad se definen para facilitar los servicios de seguridad de autenticación e integridad.
10.3.1.1
Elementos de seguridad de intercambio de
autenticación
El elemento de seguridad de intercambio de autenticación está concebido para autenticar, posiblemente de manera mutua, la identidad de un usuario del STRM a un ATM, de un ATM a un ATM, de un ATM a un usuario del STRM de una MM a un AU o de un AU a una MM. Se basa en la utilización o el intercambio de datos secretos, tales como contraseñas o testigos cifrados asimétricamente o simétricamente. El resultado del intercambio es la confirmación de la identidad de la otra parte y, facultativamente, la transferencia de datos confidenciales que pueden utilizarse para la provisión del servicio de seguridad de confidencialidad de conexiones y/o de integridad de conexiones, en capas subyacentes. Dicha autenticación sólo es válida en el instante en que se produce, dependiendo la continuidad de la validez de la identidad autenticada de si se utiliza o no intercambio de datos confidenciales, o algún otro mecanismo, para establecer un trayecto de comunicación seguro. El establecimiento y uso de un trayecto de comunicación seguro está fuera del alcance de la presente Recomendación.
Este elemento de seguridad emplea el argumento de credenciales de iniciador y el resultado de credenciales de contestador de los servicios vinculados al STRM, a la MM y a un ATM. Las credenciales transferidas son contraseñas o testigos.
10.3.1.2
Elementos de seguridad de autenticación de origen
de datos
Estos elementos de seguridad están concebidos de manera específica para facilitar los servicios de autenticación de origen de datos, aunque también se les puede emplear para proporcionar determinados servicios de integridad de datos.
10.3.1.2.1
Elemento de seguridad de autenticación de origen
de mensajes
El elemento de seguridad de autenticación de origen de mensajes permite, a cualquiera que reciba o transfiera un mensaje, autenticar la identidad del usuario del STRM que originó el mensaje. Esto puede significar la prestación del servicio de seguridad de autenticación de origen de mensajes o del de no rechazo de origen.
El elemento de seguridad implica la transmisión, como parte de mensaje, de una verificación de autenticación de origen de mensajes, computada como una función del contenido del mensaje, del identificador de contenido de mensajes y de la etiqueta de seguridad de mensajes. Si también hace falta el servicio de seguridad de confidencialidad de contenido, el control de verificación se computa como una función del contenido del mensaje cifrado, en vez de una función del no cifrado. Actuando sobre el contenido del mensaje según es transportado en el mensaje global (es decir, después del elemento de seguridad facultativo de confidencialidad de contenido), cualquier entidad del STM puede verificar la integridad del mensaje global sin necesidad de ver el texto en claro del contenido del mensaje. No obstante, si se hace uso del servicio de seguridad de confidencialidad de contenido, no puede emplearse el elemento de seguridad de autenticación de origen de mensajes para proporcionar el servicio de seguridad de no rechazo de origen.
El elemento de seguridad utiliza la verificación de autenticación de origen de mensajes, que es uno de los argumentos de los servicios de depósito de mensajes, transferencia de mensajes y entrega de mensajes.
10.3.1.2.2
Elemento de seguridad de autenticación de origen
de sondas
De manera similar al elemento de seguridad de autenticación de origen de mensajes, el de origen de sondas permite a cualquier ATM autenticar la identidad del usuario del STRM que originó una determinada sonda.
Este elemento de seguridad utiliza la verificación de autenticación de origen de sondas, que es uno de los 5 argumentos del servicio de depósito de sondas.
10.3.1.2.3
Elemento de seguridad de autenticación de origen
de informes
De manera similar al elemento de seguridad de autenticación de origen de mensajes, el de origen de informes permite, a cualquier ATM o usuario del STRM que recibe un informe, autenticar la identidad del ATM que lo originó.
Este elemento de seguridad utiliza la verificación de autenticación de origen de informes, que es uno de los argumentos del servicio de entrega de informes.
10.3.1.3
Elemento de seguridad de prueba de depósito
Este elemento de seguridad proporciona al originador de un mensaje los medios para establecer que el mensaje fue aceptado por el STM para su transmisión.
El elemento de seguridad está constituido por dos argumentos: una petición de prueba de depósito enviada con un mensaje en el momento del depósio, y la prueba de depósito devuelta al usuario del STRM como parte de los resultados del depósito de mensajes. El STRM genera la prueba de depósito, que es computada como una función de todos los argumentos del mensaje depositado, del identificador de depósito de mensajes y del momento en que se produce el depósito de mensajes.
Puede utilizarse el argumento de prueba de depósito para facilitar el servicio de seguridad de prueba de depósitos. Dependiendo de cuál sea la política de seguridad en vigor, puede también facilitar el servicio de seguridad de no rechazo de depósito (más fuerte).
La petición de prueba de depósito es un argumento del servicio de depósito de mensajes. La prueba de depósito es uno de los resultados del servicio de depósito de mensajes.
10.3.1.4
Elemento de seguridad de prueba de entrega
Este elemento de seguridad proporciona al originador de un mensaje medios para establecer que el mensaje fue entregado en destino por el STM.
El elemento de seguridad está constituido por varios argumentos. El originador del mensaje incluye una petición de prueba de entrega en el mensaje depositado, y esta petición se entrega a cada destinatario con el mensaje. Un destinatario puede entonces computar la prueba de entrega como una función de un cierto número de argumentos asociados al mensaje. El STRM devuelve la prueba de entrega al originador del mensaje, como parte de un informe sobre los resultados del depósito de mensajes original.
Es posible utilizar la prueba de entrega para facilitar el servicio de seguridad de prueba de entrega. Dependiendo de cuál sea la política de seguridad en vigor, podría también facilitar el servicio de seguridad de no rechazo de entrega (más fuerte).
La petición de prueba de entrega es un argumento de los servicios de depósito de mensajes, transferencia de mensajes y entrega de mensajes. La prueba de entrega es a la vez uno de los resultados del servicio de entrega de mensajes y uno de los argumentos de los servicios de transferencia de informes y de entrega de informes.
Nota
- La no recepción de una prueba de entrega no
implica la no entrega.
10.3.2
Elementos de seguridad de gestión de acceso
seguro
Estos elementos de seguridad se definen para facilitar el servicio de seguridad de acceso seguro y los servicios de gestión de la seguridad.
10.3.2.1
Elemento de seguridad de contexto de seguridad
Cuando un usuario del STRM o un ATM se vincula a un ATM o a un usuario del STRM, la operación de vinculación especifica el contexto de seguridad de la conexión. Esto limita el alcance del paso de mensaje por referencia a las etiquetas asociadas a los mensajes. Además, el contexto de seguridad de la conexión puede ser alterado temporalmente para mensajes depositados o entregados.
El propio contexto de seguridad consta de una o más etiquetas de seguridad, que definen la sensibilidad de interacciones que pueden producirse, en línea con la política de seguridad en vigor.
El contexto de seguridad es un argumento de los servicios vinculados al STRM y a un ATM.
10.3.2.2
Elemento de seguridad de registros
El elemento de seguridad de registros permite el establecimiento en un ATM de etiquetas de seguridad autorizadas de un usuario del STRM.
El servicio de registros proporciona este elemento. Dicho servicio permite a un usuario del STRM cambiar los argumentos, contenidos en el STRM, relativos a la entrega de mensajes a ese usuario del STRM.
10.3.2.3
Elemento de seguridad de registro de la MM
El elemento de seguridad de registro de la MM permite el establecimiento de las etiquetas de seguridad admisibles del usuario de la MM.
El servicio de registro de la MM proporciona este elemento. Dicho servicio permite a un usuario de la MM cambiar los argumentos, contenidos en la MM, relativos a la recuperación de mensajes dirigidos a ese usuario de la MM.
10.3.3
Elementos de seguridad de confidencialidad de
datos
A todos estos elementos de seguridad, basados en la utilización del cifrado, les afecta la provisión de la confidencialidad de los datos que pasan de una entidad del STM a otra.
10.3.3.1
Elemento de seguridad de confidencialidad de
contenidos
El elemento de seguridad de confidencialidad de contenidos garantiza la protección del mensaje contra indiscreciones durante la transmisión, mediante un elemento de seguridad cifrado. El elemento de seguridad funciona de modo tal que solo el destinatario y el emisor del mensaje pueden conocer el texto en claro del contenido del mensaje.
La especificación del algoritmo de cifrado, la clave empleada y cualquier otro dato de inicialización, se transportan utilizando los elementos de seguridad de confidencialidad de argumento de mensajes y de integridad de argumento de mensajes. El algoritmo y la clave se emplean entonces para cifrar o descifrar los contenidos de los mensajes.
Este elemento de seguridad hace uso del identificador de algoritmo de confidencialidad de contenidos, que es un argumento de los servicios de depósito de mensajes, transferencia de mensajes y entrega de mensajes.
10.3.3.2
Elemento de seguridad de confidencialidad
de argumento de mensajes
El elemento de seguridad de confidencialidad de argumento de mensajes proporciona la confidencialidad, la integridad y, si hace falta, la irrevocabilidad de los datos de destinatario asociados a un mensaje. De manera específica, estos datos incluirán cuantas claves criptográficas y datos conexos hagan falta para el funcionamiento adecuado de los elementos de seguridad de confidencialidad e integridad, caso de que se invoquen esos elementos.
El elemento de seguridad funciona mediante el testigo de mensajes. Los datos a proteger por el elemento de seguridad de confidencialidad de argumento de mensajes constituyen los datos cifrados, dentro del testigo de mensajes. Los datos cifrados del testigo de mensajes resultan ininteligibles para todos los ATM.
El testigo de mensajes es un argumento de los servicios de depósito de mensajes, de transferencia de mensajes y de entrega de mensajes.
10.3.4
Elementos de seguridad de integridad de
datos
Estos elementos se proporcionan para facilitar la prestación de los servicios de integridad de datos, autenticación de datos y no rechazo.
10.3.4.1
Elemento de seguridad de integridad de
contenidos
El elemento de seguridad de integridad de contenidos protege el contenido de un mensaje contra posibles modificaciones durante la transmisión.
Este elemento emplea uno o más algoritmos de criptografía. La especificación del algoritmo o algoritmos, la clave o claves utilizadas y cualquier otro dato de inicialización se transportan utilizando los elementos de seguridad de confidencialidad e integridad de argumento de mensajes. El resultado de la aplicación de los algoritmos y de la clave es la verificación de integridad de contenidos, que se envía en el sobre del mensaje. El elemento de seguridad sólo está disponible para el destinatario o destinatarios del mensaje, puesto que actúa en el texto en claro de los contenidos de los mensajes.
Si se protegiera el control de verificación de integridad de contenidos utilizando el elemento de seguridad de integridad de argumentos de mensajes, se le podría emplear, dependiendo de cuál fuese la política de seguridad en vigor, para facilitar la prestación del servicio de seguridad de no rechazo de origen.
El control de verificación de integridad de contenido es un argumento de los servicios de depósito de mensajes, transferencia de mensajes y entrega de mensajes.
10.3.4.2
Elemento de seguridad de integridad de argumento
de mensajes
El elemento de seguridad de integridad de argumento de mensajes proporciona la integridad y, si hace falta, la irrevocabilidad de determinados argumentos asociados a un mensaje. De manera específica, estos argumentos pueden comprender cualquier selección del identificador de algoritmo de confidencialidad de contenidos, del control de verificación de integridad de contenidos, de la etiqueta de seguridad de mensajes, de la petición de prueba de entrega y del número de secuencia de mensajes.
El elemento de seguridad funciona mediante el testigo de mensajes. Los datos a proteger por el elemento de seguridad de integridad de argumento de mensajes constituyen los datos firmados, dentro del testigo de mensajes.
El testigo de mensajes es un argumento de los servicios de depósito de mensajes, transferencia de mensajes y entrega de mensajes.
10.3.4.3
Elemento de seguridad de integridad de secuencia de
mensajes
El elemento de seguridad de integridad de secuencia de mensajes protege al emisor y al destinatario de un mensaje contra la recepción de mensajes desordenados o duplicados.
Cada mensaje tiene asociado un número de secuencia de mensajes. Este número identifica la posición de un mensaje en una secuencia, desde el originador al destinatario. Así pues, cada pareja originador-destinatario que necesite utilizar este elemento de seguridad deberá mantener una secuencia precisa de números de mensajes. Este elemento de seguridad no facilita la inicialización o sincronización de números de secuencia de mensajes.
10.3.5
Elementos de seguridad de no
rechazo
En la Recomendación X.411 no se definen, de manera específica, los elementos de seguridad de no rechazo. Los servicios de no rechazo pueden proporcionarse mediante una combinación de otros elementos de seguridad.
10.3.6
Elementos de seguridad de la etiqueta de
seguridad
La finalidad de estos elementos de seguridad es facilitar el etiquetado de seguridad en el STM.
10.3.6.1
Elemento de seguridad de etiqueta de seguridad de
mensajes
Se pueden etiquetar los mensajes con datos según se especifique en la política de seguridad vigente. La etiqueta de seguridad de mensajes está a disposición de los ATM intermedios, como parte de la política de seguridad global del sistema.
Es posible enviar una etiqueta de seguridad de mensajes como un argumento de mensajes y que sea protegida por el elemento de seguridad de integridad de argumento de mensajes o el de autenticación de origen de mensajes, del mismo modo que otros argumentos de mensajes.
Si son necesarias, tanto la confidencialidad como la integridad, se puede proteger la etiqueta de seguridad de mensajes, de manera alternativa, utilizando el elemento de seguridad de confidencialidad de argumento de mensajes. En este caso, la etiqueta así protegida es un argumento de originador-destinatario, y puede diferir de la etiqueta de seguridad de mensajes en la envolvente del mensaje.
10.3.7
Elemento de seguridad de gestión de la
seguridad
10.3.7.1
Elemento de seguridad de cambio de
credenciales
El elemento de seguridad de cambio de credenciales permite actualizar las credenciales de un usuario del STRM o de un ATM.
El elemento de seguridad lo proporciona el servicio de cambio de credenciales del STRM.
10.3.8
Técnica del sobre doble
Es posible dar protección adicional a un mensaje completo, incluidos los parámetros del sobre, especificando que el contenido de un mensaje es, en sí mismo, un mensaje completo, es decir, que se dispone de una técnica de doble sobre.
Se puede recurrir a esta técnica aunque se utilice el argumento del tipo de contenido, que permite especificar que el contenido de un mensaje es un sobre interno. Ese tipo de contenido significa que el contenido es, por sí mismo, un mensaje (sobre y contenido) que el destinatario indicado en el sobre externo debe reexpedir al destinatario indicado en el sobre interno.
El tipo de contenido es un argumento de los servicios de depósito, transferencia y entrega de mensajes.
MONTAGE: SECTION 3 SUR LE RESTE DE CETTE PAGE
Disk. 574 NF01/003 OPM: 02 member-of-group NF01/016 OPM: 02 id-mhsac NF01/020 OPM: 02 id-at-mhs-supported-optional-attributes NF01/023 OPM: 02 NF01/029 OPM: 02 member-of-group NF01/037 OPM: 02 (cs,1) - (cs,1) Disk. 574 NF02/055
(1BT) (BT..)
(87.TE.04.S)
(A1.23s) / [26s]
FOLIOS: 106 - 146
(DO PRC.COSY.2)
MEP {TPS.NON.PHOTO "[PA1]"} : OK= [1]
Saisie 17.08.89 SJ
ID + LASER 25.09.89 CW
MAJ diskette 26.09.89 CW
Corr. LASER (1re épreuve) = 3eme ........ ..
AJOUTER (PA1) (CL1,0,0,0) pour MEP
MEP + LASER 30.10.89 GH/PC
Corr. MEP ........ ..
Insertion des tableaux (tabulateurs 6) 2.11.89 PC
BAT du 14/11/89 16.11.89 PV
MAJ s/disquettes 6.12.89 CD
MONTAGE: FIN DE LA SECTION 2 EN-TêTE DE CETTE PAGE
SECCIóN 3 - CONFIGURACIONES
11 Visión de conjunto
En esta sección se especifica cómo configurar el STM para satisfacer cualquiera de los diversos requisitos de tipo funcional, físico y organizativo.
La sección abarca los siguientes temas:
a)configuraciones funcionales;
b)configuraciones físicas;
c)configuraciones organizativas;
d)el
STM global
.
12 Configuraciones funcionales
Se especifican en este punto las posibles configuraciones funcionales del STM. La variedad de tales configuraciones está en relación directa con la presencia o ausencia de la guía y con la utilización o no, por parte de un usuario directo, de una MM.
12.1
Respecto a la guía
Con respecto a la guía, el STM puede configurarse para un usuario, o colectivo de usuarios (véase por ejemplo, el 14.1 ), de dos maneras distintas: con la guía o sin ella. Un usuario sin acceso a la guía carecerá de las capacidades descritas en la sección cinco.
Nota
- Es posible que durante un cierto periodo de
tiempo exista una guía no plenamente interconectada, sino sólo parcialmente,
mientras se elabora la guía (global) que hacen posible las Recomendaciones
sobre guías.
12.2
Respecto a la memoria de mensajes
Con respecto a la MM, el STM puede configurarse, para un usuario directo particular, de dos maneras distintas: con MM o sin ella. Un usuario sin acceso a una MM no tiene capacidad de almacenar mensajes. En tal circunstancia, dependerá de su AU para el almacenamiento de objetos de información, con una capacidad que será un asunto local.
Las dos configuraciones funcionales identificadas anteriormente, se representan de manera esquemática en la figura 7/X.402, que ilustra además una posible configuración del STRM y su vinculación a otro sistema de comunicaciones a través de un AU. En esta figura, el usuario 2 está equipado con una MM, mientras que el usuario 1 no lo está.
Figura 7/X.402, p.
13 Configuraciones físicas
En este punto se especifican las posibles configuraciones físicas del STM,
es decir, cómo puede realizarse el STM como un conjunto de sistemas de
computadores interconectados. Puesto que el número de configuraciones es
ilimitado, los
sistemas de mensajería
se describen a
partir de los cuales se construye el STM, y se identifican unas cuantas
configuraciones representativas importantes.
13.1
Sistemas de mensajería
A las unidades elementales utilizadas en la construcción física del STM se
les denomina
sistemas de mensajería
. Un
sistema de mesajería
es un sistema por computador
(posiblemente, aunque no necesariamente, un sistema abierto) que contiene, o
realiza, uno o más objetos funcionales.
Los sistemas de mensajería son de los tipos que se representan de manera esquemática en la figura 8/X.402.
En la primera columna del cuadro 8/X.402 se da una relación de los tipos de sistemas de mensajería representados en la figura 8/X.402. Para cada tipo de esa relación, la segunda columna indica las clases de objetos funcionales - AU, MM, ATM y UA - que pueden estar presentes en dicho sistema de mensajería, si su presencia es obligatoria o facultativa y si el sistema de mensajería consta simplemente de uno o posiblemente de múltiples objetos.
El cuadro 8/X.402 está dividido en dos secciones. Los sistemas de mensajería de los tipos de la primera sección prestan servicio a un solo usuario, mientras que los de la segunda pueden prestar servicio a un solo usuario o a varios usuarios.
Nota
- Para la admisión de tipos de sistemas de
mensajería se han tenido en cuenta los siguientes principios fundamentales:
a)Una UA y el ATM con el que interactúa se hallan típicamente ubicados en la misma posición, puesto que no se ha normalizado ningún protocolo que gobierne su interacción.
b)Un ATM se halla típicamente coubicado con múltiples AU o MM, porque, de los protocolos normalizados, sólo el de transferencia lleva un mensaje simultáneamente a destinatarios múltiples. La entrega en serie de un mensaje a destinatarios múltiples servidos por un sistema de mensajería, tal como exigiría el protocolo de entrega, resultaría ineficaz.
c)Nada se consigue ubicando varios ATM en el mismo emplazamiento, en un sistema de mensajería, puesto que un solo ATM presta servicio a múltiples usuarios, y la finalidad de un ATM es transportar objetos funcionales entre sistemas y no dentro de tales sistemas (con esto no se pretende excluir la posibilidad de que varios procesos relacionados con un ATM coexistan en un único sistema por computador).
d)La coubicación de una UA con un ATM no afecta al comportamiento del sistema con respecto al resto del STM. Un solo tipo de sistema de mensajería abarca, por tanto, la presencia y la ausencia de la UA.
Los tipos de sistemas de mensajería expuestos de manera resumida en el cuadro 8/X.402 se definen y describen en los puntos siguientes.
Figure 8/X.402, p.2
Tableau 8/X.402 [T8.402], p.3
13.1.1
Sistemas de acceso
Un
@sistema de acceso (A/SYS)@
\contiene un AU, pero no
una MM ni un ATM ni una UA.
Un A/SYS se dedica a un único usuario.\
13.1.2
Sistemas de almacenamiento
Un
@sistema de almacenamiento (S/SYS)@
\contiene una MM,
pero no un AU ni un ATM ni una UA.
Un S/SYS se dedica a un único usuario.\
13.1.3
Sistemas de acceso y almacenamiento
Un
@sistema de acceso y almacenamiento (AS/SYS)@
\contiene un AU, y una MM, pero no un ATM ni una UA.
Un AS/SYS se dedica a un único usuario.\
13.1.4
Sistemas de transferencia
Un
@sistema de transferencia (T/SYS)@
\contiene un ATM,
facultativamente, una o más UA, pero no un AU ni una MM.
Un T/SYS puede prestar servicio a múltiples usuarios.\
13.1.5
Sistemas de acceso y transferencia
Un
@sistema de acceso y transferencia (AT/SYS)@
\contiene uno o más AU, un ATM y, facultativamente, una o más UA, pero no una
MM.
Un AT/SYS puede prestar servicio a múltiples usuarios.\
13.1.6
Sistemas de almacenamiento y transferencia
Un
@sistema de almacenamiento y transferencia (ST/SYS)@
\contiene una o más MM, un ATM y facultativamente, una o más UA, pero no AU.
Un AST/SYS puede prestar servicio a múltiples usuarios.\
13.1.7
Sistema de acceso, almacenamiento y
transferencia
Un
@sistema de acceso, almacenamiento y transferencia
(AST/SYS)@
\contiene uno o más AU, una o más MM, un ATM y
facultativamente, una o más UA.
Un AST/SYS puede prestar servicio a múltiples usuarios.\
13.2
Configuraciones representativas
Los sistemas de mensajería pueden combinarse de diversas maneras para constituir el STM. Las configuraciones físicas posibles son ilimitadas, y por ello no pueden ser enumeradas. De todos modos, en la figura 9/X.402 y en los puntos que siguen, se describen varias configuraciones representativas importantes.
13.2.1
Totalmente centralizada
El STM puede estar totalmente centralizado [caso a) de la figura 9/X.402]. Este diseño se realiza mediante un único AST/SYS que contiene objetos funcionales de todas clases y que puede prestar servicio a múltiples usuarios.
13.2.2
Transferencia y almacenamiento de
mensajes centralizados
El STM puede proporcionar transferencia y almacenamiento de mensajes centralmente, pero con acceso distribuido de los usuarios [caso b) de la figura 9/X.402]. Este diseño se realiza mediante un único ST/SYS y, por cada usuario, un A/SYS.
13.2.3
Transferencia de mensajes
centralizada
El STM puede proporcionar transferencia de mensajes centralmente, pero con almacenamiento de mensajes y acceso de usuarios distribuidos [caso c) de la figura 9/X.402]. Este diseño se realiza mediante un único T/SYS y, por cada usuario, un A/SYS sólo o un S/SYS con un A/SYS asociado.
Figure 9/X.402, p.
13.2.4
Totalmente distribuida
El STM puede proporcionar transferencia de mensajes incluso de manera distribuida [caso d) de la figura 9/X.402]. Este diseño implica múltiples ST/SYS o T/SYS.
14 Configuraciones organizativas
En este punto se especifican las configuraciones organizativas posibles del
STM, es decir, cómo puede realizarse el STM en forma de conjuntos de sistemas
de mensajería interconectados, pero gestionados independientemente (estando los
propios sistemas conectados entre sí). Como el número de configuraciones es
ilimitado, se describen los tipos de
dominios de gestión
a
partir de los cuales se construye el STM, y se identifican unas cuantas
configuraciones representativas importantes.
14.1
Dominios de gestión
A los bloques primarios, utilizados en la construcción de STM, se les
denomina
dominios de gestión
. Un
dominio de
gestión (DG)
(o
dominio
) es un conjunto de sistemas de
mensajería - por lo menos uno, que contenga o realice un ATM - gestionado por
una única organización.
Lo anterior no impide que una organización gestione un conjunto de sistemas
de mensajería (por ejemplo, un solo A/SYS) que no tiene categoría de DG por
falta de un ATM. Ese grupo de sistemas de mensajería, bloque secundario
utilizado en la construcción del STM, son de la
`incumbencia'
de un DG.
Los DG son de varios tipos, cada uno de los cuales se define y describe en los puntos que siguen.
14.1.1
Dominio de gestión de administración
Un
@dominio de gestión de administración (DGAD)@
\comprende varios sistemas de mensajería gestionados por una Administración. La
distinción técnica principal entre un DGAD y un
DGPR
es
que el primero se halla por encima del segundo en los regímenes jerárquicos de
direccionamiento (véase el
18
) y encaminamiento (véase el
19
) del STM.
Nota
- Un DGAD proporciona tratamiento de mensajes al
público.\
14.1.2
Dominio de gestión privado
Un
@dominio de gestión privado (DGPR)@
\comprende
sistemas de mensajería gestionados por una organización distinta de una
Administración. La distinción técnica principal entre un DGPR y un DGAD es que
el primero se halla por debajo del segundo en los regímenes jerárquicos de
direccionamiento (véase el
18
) y encaminamiento (véase el
19
) del STM.
Nota
- Un DGPR proporciona tratamiento de mensajes,
por ejemplo, a los empleados de una compañía, o a esos empleados en un
determinado emplazamiento de la compañía.\
14.2
Configuraciones representativas
Los DG pueden combinarse de diversas maneras para constituir el STM. Las configuraciones organizativas posibles son ilimitadas, y por ello no pueden enumerarse. De todos modos, en la figura 10/X.402 y en los puntos que siguen se describen varias configuraciones representativas importantes.
Figura 10/X.402, p.
14.2.1
Totalmente centralizada
Todo el STM puede ser gestionado por una organización [caso a) de la figura 10/X.402]. Este diseño se realiza mediante un único DG.
14.2.2
Conectada directamente
El STM puede ser gestionado por varias organizaciones, estando los sistemas de mensajería de cada una de ellas conectados a los sistemas de mensajería de todas las demás [caso b) de la figura 10/X.402]. Este diseño se realiza mediante múltiples DG interconectados por pares.
14.2.3
Conectada indirectamente
El STM puede ser gestionado por varias organizaciones, actuando los sistemas de mensajería de una como intermediarios entre los sistemas de mensajería de las otras [caso c) de la figura 10/X.402]. Este diseño se realiza mediante múltiples DG uno de los cuales está interconectado con todos los demás.
15
El STM global
Uno de los principales objetivos de esta Recomendación y de otras de la serie es facilitar la construcción del STM global, un STM que permita el tratamiento de mensajes intra e interorganizativo, y también intra e internacional, a escala mundial.
El STM global abarca, casi con toda seguridad, la gama completa de configuraciones funcionales especificadas en el 12 .
La configuración física del STM global es un híbrido de las configuraciones puras especificadas en el 13 , sumamente complejo y con un alto grado de distribución física.
La configuración organizativa del STM global es una combinación híbrida de las configuraciones puras especificadas en el 14 , sumamente compleja y con un alto grado de distribución organizativa.
En la figura 11/X.402 se da un ejemplo de posibles interconexiones, que no
pretende identificar todas las configuraciones posibles. Tal como se indica en
la figura 11/X.402 los DGAD juegan un papel central en el STM global. Mediante
su interconexión internacional se constituye la columna vertebral de la
transferencia de mensajes. Interconectándolos a nivel nacional, y dependiendo
de cuáles sean los reglamentos nacionales, pueden también proporcionar
entramados básicos, a ese mismo nivel, unidos al entramado internacional. Los
DGAD sirven también como primera autoridad de denominación, en la
asignación de direcciones O/D
a usuarios y LD.
Los DGPR desempeñan un contenido más bien periférico en el STM global, estando conectados al eje central de los DGAD, que actúa de intermediario entre ellos.
Figura 11/X.402, p.
SECCIóN 4 - DENOMINACIóN, DIRECCIONAMIENTO Y ENCAMINAMIENTO
16 Vision de conjunto
En esta sección se describen la denominación y el direccionamiento de usuarios y LD, y el encaminamiento hacia ellos de objetos de información.
La sección comprende los siguientes temas:
a)denominación;
b)direccionamiento;
c)encaminamiento.
17
Denominación
En este punto se especifica cómo se denomina a los usuarios y LD a efectos
de tratamiento de mensajes en general y transferencia de mensajes en
particular. Se definen los
nombres O/D
y se describe el
papel que desempeñan en ellos los nombres de guía.
Cuando un AU o una MM depositan un mensaje o una sonda, identifican al STRM
los destinatarios potenciales. Cuando el STRM entrega un mensaje, identifica el
originador a cada AU o MM del destinatario potencial. Los
nombres O/D
son las estructuras de datos por medio de las
cuales se realiza esa identificación.
17.1
Nombres de guía
Un nombre de guía es un componente de un
nombre O/D
.
El nombre de guía identifica un objeto a la guía. Presentando ese nombre a la
guía, el STM puede acceder la inscripción en la guía de un usuario o una LD. El
STRM obtiene de esa inscripción, por ejemplo, la
dirección
O/D
del usuario o de la LD.
No todos los usuarios o LD están inscritos en la guía y, por consiguiente, no todos ellos tienen un nombre de guía.
Nota 1
- Muchos usuarios y LD carecerán de nombre de
guía mientras no se generalice la difusión de ésta, como elemento auxiliar del
STM. Gran número de usuarios indirectos (por ejemplo, patrones postales) no
tendrán tales nombres mientras no se disponga ampliamente de la guía, como un
adjunto a otros sistemas de comunicación.
Nota 2
- A los usuarios y a las LD se les puede
asignar nombres de guía incluso antes de que se ponga en marcha una guía
interconectada y distribuida, preestableciendo las autoridades de denominación,
de las que dependerá la guía en su momento.
Nota 3
- El nombre
de guía típico le
resulta más cómodo y estable al usuario que la dirección
O/D típica
porque la segunda está expresada necesariamente desde el punto
de vista de la estructura organizativa o física del STM, mientras que el
primero no lo está. Se pretende por ello que, con el tiempo, los nombres de
guía se conviertan necesariamente en el principal medio de identificación de
los usuarios y las LD fuera del STM (es decir, por otros usuarios), y que el
empleo de las
direcciones O/D
se limite en gran medida al
STRM (es decir, por los ATM).
17.2
Nombres O/D
Cada usuario o LD tiene uno o más
nombres O/D
. Un
nombre O/D
es un identificador por medio del cual puede un
usuario ser designado como originador, o un usuario o una LD ser designados
como destinatario potencial de un mensaje o sonda. El nombre O/D distingue a un
usuario o una LD de otro, y puede identificar además su punto de acceso al STM.
Un nombre O/D incluye un nombre de guía, una
dirección
O/D
o ambas cosas. Si está presente y es válido, el nombre de guía
identifica de manera inequívoca al usuario o a la LD (aunque no es
necesariamente el único que podrá hacerlo). La
dirección
O/D
, cuando existe, hace eso mismo y más (véase el
18.5
).
En depósito directo, el AU o la MM del originador de un mensaje o sonda
pueden incluir cualquiera de los dos componentes, o ambos, en cada nombre O/D
que suministran. Si se omite la
dirección O/D
, el STRM la
obtiene a partir de la guía, utilizando el nombre de guía. Si se omite el
nombre de guía, el STRM prescinde de él. Si se incluyen ambos, el STRM confía
en primer lugar en la
dirección O/D
. Si constatara que la
dirección O/D
era inválida (por ejemplo, porque se hubiera
quedado obsoleta), procedería como si la
dirección O/D
hubiera sido omitida, confiando en el nombre de guía.
En entrega, el STRM incluye una
dirección O/D
y
posiblemente un nombre de guía en cada nombre O/D que suministra al
destinatario de un mensaje o al originador de un mensaje o sonda objeto de un
informe. El nombre de guía se incluye si el originador lo ha suministrado, o si
se identificó como miembro de una LD ampliada.
Nota
- La redirección o la ampliación de LD pueden dar
lugar a que el STRM lleve a un AU o a una MM en entrega, nombres O/D que el AU
o la MM no suministraron en depósito directo.
18
Direccionamiento
En este punto se especifica la manera de direccionar a usuarios y LD. Se
definen las
direcciones O/D
, se describe la estructura de
las
listas de atributos
a partir de las que se elaboran,
se examinan los conjuntos de caracteres con los que se componen los
atributos
individuales, se dan reglas para determinar si
dos
listas de atributos
son equivalentes y para la
inclusión de
atributos
condicionales en tales listas y se
definen los
atributos normalizados
que pueden figurar en
ellas.
Para transportar un mensaje, una sonda o un informe a un usuario, o para
ampliar una LD especificada como destinatario potencial de un mensaje o una
sonda, el STRM debe localizar el usuario o la LD relativos a sus propias
estructuras física y organizativa. Las
direcciones O/D
son
las estructuras de datos mediante las cuales se realizan todas estas
localizaciones.
18.1
Lista de atributos
Las
direcciones O/D
de usuarios y LD son listas de
atributos. Una
lista de atributos
es un conjunto ordenado de
atributos
.
Un
@atributo@
es un \elemento de información que
describe a un usuario o LD y que puede también ubicarlo en relación con la
estructura física y organizativa del STM (o la red inherente al mismo).\
Un atributo consta de las siguientes partes:
a)
@tipo de atributo (o tipo)@
: \Identificador que indica
una clase de información (por ejemplo, nombres personales).\
b)
@valor de atributo (o valor)@
: \Ejemplo de la clase de
información indicada por el tipo de atributo (por ejemplo, un nombre
personal).\
Los atributos son de las dos clases siguientes:
a)
@atributo normalizado@
: \Atributo cuyo tipo está
vinculado a una clase de información por esta Recomendación.
El valor de cada atributo normalizado, excepto el del
tipo-terminal
, es una cadena o bien un grupo de cadenas.\
b)
@atributo definido por el dominio@
: \Atributo cuyo tipo
está vinculado a una clase de información por un DG.
Tanto el tipo como el valor de cada atributo definido por el dominio son cadenas o grupos de cadenas.\
Nota
- El uso generalizado de atributos normalizados
genera direcciones O/D más uniformes y por tanto más cómodas para el usuario.
No obstante, es de prever que no todos los DG serán capaces de emplear tales
atributos inmediatamente. La finalidad de los atributos definidos por el
dominio es permitir a un DG que retenga durante cierto tiempo los convenios
primitivos de direccionamiento existentes. Se pretende sin embargo, que todos
los DG tiendan al empleo de atributos normalizados, y que los atributos
definidos por el dominio se utilicen sólo con carácter provisional.
18.2
Juegos de caracteres
Los valores de atributos normalizados y los tipos y valores de atributos definidos por el dominio se elaboran a partir de cadenas numéricas, imprimibles y teletex, según los siguientes criterios:
a)El tipo o valor de un determinado atributo definido por el dominio puede ser una cadena imprimible, una cadena teletex o ambas. Se elegirá lo mismo para el tipo y para el valor.
b)Las clases de cadenas con las que pueden elaborarse valores de atributos normalizados y la manera de elaborarlos (por ejemplo, como una sola cadena o varias) difiere de un atributo a otro (véase el 18.3 ).
El valor de un atributo consta de cadenas de una de las siguientes variedades, dependiendo de su tipo: numérico sólo, imprimible sólo, numérico e imprimible e imprimible y teletex. En relación con esto, las siguientes reglas gobiernan cada caso de comunicación:
a)Donde se permitan cadenas tanto numéricas como imprimibles, podrán suministrarse indiferentemente cadenas de una u otra variedad (pero no de ambas).
b)Donde se permitan cadenas tanto imprimibles como teletex, podrán suministrarse cadenas de una u otra variedad, o de ambas, pero las cadenas imprimibles se suministrarán lo menos posible cuando se transporten los atributos internacionalmente. Si se suministran cadenas tanto imprimibles como teletex, ambas deberán transportar la misma información, de tal modo que en la recepción pueda ignorarse una de las dos sin pérdida de seguridad.
La longitud de cada cadena y de cada secuencia de cadenas en un atributo se limitará tal como se indica en la especificación más detallada de atributos (por ejemplo, NSA.1) de la Recomendación X.411.
Nota 1
- Se permiten las cadenas teletex en valores de
atributos para facilitar la inclusión, por ejemplo, de caracteres acentuados,
utilizados normalmente en muchos países.
Nota 2
- No todos los dispositivos de entrada/salida
permiten la introducción y visualización, por ejemplo, de caracteres
acentuados. Las cadenas imprimibles son necesarias, a nivel internacional, para
asegurar que esas limitaciones de los dispositivos no impiden la comunicación.
18.3
Atributo normalizados
En la primera columna del cuadro 9/X.402 figura la lista de tipos de atributos normalizados. Para cada tipo enumerado se indican en la segunda columna los conjuntos de caracteres - numéricos, imprimibles y teletex - con los que está permitido elaborar valores de atributos.
El cuadro 9/X.402 tiene tres secciones. Los tipos de atributos de la
primera son de naturaleza general, los de la segunda están relacionados con el
encaminamiento a
un SEF y los de la tercera, con el
direccionamiento dentro de
un SEF.
Cuadro 9/X.402 [T9.402], p.
Los tipos de atributos normalizados, resumidos en el cuadro 9/X.402, se
definen y describen individualmente en los puntos que siguen.
18.3.1
Nombre-dominio-administración
Nombre-dominio-administración
es un atributo normalizado
que identifica un DGAD relativo al país indicado por un nombre-país.
El valor de este atributo es una cadena numérica o imprimible, elegida de entre un conjunto de tales cadenas administrado para este fin por el país aludido anteriormente.
Nota
- El valor de atributo que consta de un único
espacio (
` '
) se reservará para los siguientes fines.
Si lo permite
el país indicado por el atributo de
nombre-país, un único espacio designará cualquiera (es decir, todos) los DGAD
dentro del país. Esto afecta tanto a la identificación de usuarios dentro del
país como al encaminamiento de mensajes, sondas e informaciones hacia y entre
los DGAD de ese país. En relación con lo primero, es preciso que las
direcciones O/D de los usuarios dentro del país se elijan de tal modo que se
asegure su carácter inequívoco, incluso en ausencia de los nombres verdaderos
de los DGAD de usuarios. En relación con lo segundo, ello permite que los DGPR
de dentro y los DGAD de fuera del país encaminen mensajes, sondas e informes a
cualquiera de DGAD de dentro del país indiscriminadamente, y exige que estos
últimos se interconecten de manera tal que los mensajes, las sondas y los
informes sean llevados a sus destinos.
18.3.2
Nombre-común
Nombre común
es un atributo normalizado que identifica a
una LD o a un usuario relativo a la entidad indicada por otro atributo (por
ejemplo, un nombre-organización).
El valor de este atributo es una cadena imprimible, una cadena teletex o ambas. Sea imprimible o teletex, la cadena se elige de entre un conjunto de tales cadenas administrado para este fin (y quizá para otros) por la entidad aludida anteriormente.
Nota
- Entre otras muchas posibilidades, un
nombre-común podría identificar un cometido organizativo (por ejemplo,
`Director de mercadotecnia'
).
18.3.3
Nombre-país
Nombre-país
es un atributo normalizado que identifica a
un país.
El valor de este atributo es una cadena numérica que da uno de los números asignados al país por la Recomendación X.121, o una cadena imprimible que da el par de caracteres asignados al país por la norma ISO 3166.
18.3.4
Componentes-ampliación-dirección-O/D-postal
Componentes-ampliación-dirección-O/D-postal
es un
atributo normalizado que proporciona, en una dirección postal, información
adicional necesaria para identificar al destinatario (por ejemplo, una unidad
organizativa).
El valor de este atributo es una cadena imprimible, una cadena teletex o ambas.
18.3.5
Componentes-ampliación-dirección-entrega-física
Componentes-ampliación-dirección-entrega-física
es un
atributo normalizado que especifica, en una dirección postal, información
adicional necesaria para identificar el punto exacto de entrega (por ejemplo,
número de piso y despacho en un gran edificio).
El valor de este atributo es una cadena imprimible, una cadena teletex o ambas.
18.3.6
Atributos-postales-locales
Atributos-postales-locales
es un atributo normalizado
que especifica el lugar de distribución, distinto del indicado por un atributo
de nombre-oficina-entrega-física (por ejemplo, una zona geográfica) de los
mensajes físicos de un usuario.
El valor de este atributo es una cadena imprimible, una cadena teletex o ambas.
18.3.7
Dirección-red
Dirección-red
es un atributo normalizado que da la
dirección de red de un terminal.
Este atributo tiene algunos de los siguientes valores:
a)una cadena numérica de conformidad con la Recomendación X.121;
b)dos cadenas numéricas tal como se especifican en las Recomendaciones E.163 y E.164;
c)una dirección de punto de acceso al servicio de presentación (PASP).
Nota
- Entre las cadenas admitidas por la
Recomendación X.121 se encuentra un número télex precedido por la cifra de
escape télex (8).
18.3.8
Identificador-usuario-numérico
Identificador-usuario-numérico
es un atributo
normalizado que identifica numéricamente a un usuario relativo al DGAD,
indicado por un nombre-dominio-administración.
El valor de este atributo es una cadena numérica elegida entre un conjunto de tales cadenas, administrado para este fin por el DGAD aludido anteriormente.
18.3.9
Nombre-organización
Nombre-organización
es un atributo normalizado que
identifica una organización. Como asunto nacional, esta identificación puede
referirse al país indicado por un nombre-país (de tal modo que cada
nombre-organización identifique una única entidad dentro del país) o referirse
al DG indentificado por un nombre-dominio-privado, por un
nombre-dominio-administración, o por ambos.
El valor de este atributo es una cadena imprimible, una cadena teletex o ambas. Sea imprimible o teletex, la cadena se elige de entre un conjunto de tales cadenas, administrado para este fin (y quizá para otros) por el país o el DG aludido anteriormente.
Nota
- En los países en que cada atributo
nombre-organización debe corresponder a una entidad única a escala nacional, se
precisa una autoridad nacional para el registro de dichos atributos.
18.3.10
Nombres-unidades-organizativas
Nombre-unidades-organizativas
es un atributo normalizado
que identifica una o más unidades (por ejemplo, divisiones o departamentos) de
la organización indicada por un nombre-organización, siendo cada unidad,
excepto la primera, una subunidad de las unidades cuyos nombres le preceden en
el atributo.
El valor de este atributo es una secuencia ordenada de cadenas imprimibles, una secuencia ordenada de cadenas teletex o ambas. Sea imprimible o teletex, cada cadena se elige de entre un conjunto de tales cadenas, administrado para este fin (y quizá para otros) por la organización (o unidad abarcadora) aludida anteriormente.
18.3.11
Nombre-servicio-entrega-física
Nombre-servicio-entrega-física
es un atributo
normalizado que identifica a un servicio de entrega física relativo al DGAD
indicado por un nombre-dominio-administración.
El valor de este atributo es una cadena imprimible elegida de entre un conjunto de tales cadenas, administrado para este fin el DGAD aludido anteriormente.
18.3.12
Nombre-personal
Nombre-personal
es un atributo normalizado que
identifica una persona con respecto a la entidad indicada por otro atributo
(por ejemplo, un nombre-organización).
El valor de este atributo comprende los siguientes cuatro elementos de información, de las que la primera es obligatoria y las otras facultativas:
a)el apellido de la persona;
b)el nombre de la persona;
c)las iniciales de todos sus apelativos, excepto la del apellido;
d)su generación (por ejemplo
`hijo'
).
La información anterior se proporciona en forma de cadenas imprimibles, cadenas teletex o ambas.
18.3.13
Nombre-país-entrega-física
Nombre-país-entrega-física
es un atributo normalizado
que identifica el país en el que un usuario recibe la entrega de mensajes
físicos.
El valor de este atributo está sometido a las mismas limitaciones que el de un nombre-país.
18.3.14
Nombre-oficina-entrega-física
Nombre-oficina-entrega-física
es un atributo normalizado
que identifica la ciudad, el pueblo, etc. en el que se halla la oficina postal
a través de la cual un usuario recibe la entrega de mensajes físicos.
El valor de este atributo es una cadena imprimible, una cadena teletex o ambas.
18.3.15
Número-oficina-entrega-física
Número-oficina-entrega-física
es un atributo normalizado
que distingue entre varias oficinas postales indicadas por un único
nombre-oficina-entrega-física.
El valor de este atributo es una cadena imprimible, una cadena teletex o ambas.
18.3.16
Nombre-organización-entrega-física
Nombre-organización-entrega-física
es un atributo
normalizado que identifica una organización patrón postal.
El valor de este atributo es una cadena imprimible, una cadena teletex o ambas.
18.3.17
Nombre-personal-entrega-física
Nombre-personal-entrega-física
es un atributo
normalizado que identifica un patrón postal.
El valor de este atributo es una cadena imprimible, una cadena teletex o ambas.
18.3.18
Dirección-apartado-correos
Dirección-apartado-correos
es un atributo normalizado
que especifica el número del casillero de la oficina postal en el que un
usuario recibe la entrega de mensajes físicos.
El valor de este atributo es una cadena imprimible, una cadena teletex o ambas, a elegir entre el conjunto de tales cadenas asignadas para este fin por la oficina postal indicada por un atributo de nombre-oficina-entrega-física.
18.3.19
Código-postal
Código-postal
es un atributo normalizado que especifica
el código postal para la zona geográfica en la que el usuario recibe la entrega
de los mensajes físicos.
El valor de este atributo es una cadena imprimible o numérica, elegida de entre el conjunto de tales cadenas, mantenido y normalizado para este fin por la Administración del país identificado por un atributo de nombre-país-entrega-física.
18.3.20
Dirección-lista-correos
Dirección-lista-correos
es un atributo normalizado que
identifica el código que un usuario da a la oficina postal para que acopie los
mensajes físicos que se le deben entregar.
El valor de este atributo es una cadena imprimible, una cadena teletex o ambas, elegida de entre el conjunto de tales cadenas asignadas a este fin por la oficina postal indicada por un atributo de nombre-oficina-entrega-física.
18.3.21
Nombre-dominio-privado
Nombre-dominio-privado
es un atributo normalizado que
identifica un DGPR relativo al DGAD. Como asunto nacional, esta identificación
puede referirise al país indicado por un nombre-país (de tal modo que cada
nombre de DGPR identifique una única entidad dentro del país) o referirse al
DGAD indentificado por un nombre-dominio-administración.
El valor de este atributo es una cadena numérica o imprimible elegida de entre un conjunto de tales cadenas administradas para este fin por el país o el DGAD aludido anteriormente.
Nota
- En los países en que cada nombre de DGPR debe
corresponder a una entidad única a escala nacional, se precisa una autoridad
nacional para el registro de dichos nombres.
18.3.22
Dirección-calle
Dirección-calle
es un atributo normalizado que
especifica la dirección de calle [por ejemplo, número de la casa y nombre de la
calle y tipo (por ejemplo,
`camino'
)] en la que el usuario recibe la
entrega de mensajes físicos.
El valor de este atributo es una cadena imprimible, una cadena teletex o ambas.
18.3.23
Identificador-terminal
Identificador-terminal
es un atributo normalizado que da
el identificador terminal de un terminal (por ejemplo, un distintivo télex o un
identificador de terminal de teletex).
El valor de este atributo es una cadena imprimible.
18.3.24
Tipo-terminal
Tipo-terminal
es un atributo normalizado que da el tipo
de un terminal.
El valor de este atributo es uno cualquiera de los siguientes:
télex
,
teletex
,
facsímil G3
,
facsímil G4
,
ter minal AI5
o
videotex
.
18.3.25
Dirección-postal-no-formatizada
Dirección-postal-no-formatizada
es un atributo
normalizado que especifica una dirección postal de usuario de forma libre.
El valor de este atributo es una secuencia de cadenas imprimibles, representando cada una una línea de texto, o bien una única cadena teletex, estando las líneas separadas tal como se especifica para tales cadenas, o bien ambas.
18.3.26
Nombre-postal-exclusivo
Nombre-postal-exclusivo
es un atributo normalizado que
identifica el punto de entrega, distinto del indicado por un dirección-calle,
un dirección-apartado-correos o un dirección-lista-correos, (por ejemplo, un
edificio o un caserío) de los mensajes físicos de un usuario.
El valor de este atributo es una cadena imprimible, una cadena teletex o ambas.
18.4
Equivalencia de listas de atributos
Varias direcciones O/D, y por tanto varias listas de atributos, pueden indicar el mismo usuario o la misma LD. Esta multiplicidad de direcciones O/D se debe en parte (pero sólo en parte) a las siguientes reglas de equivalencia de listas de atributos:
a)El orden relativo de atributos normalizados es intrascendente.
b)Cuando el valor de un atributo normalizado pueda ser una cadena numérica o una cadena imprimible equivalente, la elección entre ellas se considerará intrascendente.
Nota
- Esta regla se aplica incluso al atributo
normalizado nombre-país cuando la elección entre las formas Rec. X.121 o ISO
3166 se considere irrelevante. Cuando en la Rec. X.121 se asignen a un país más
de un número, la relevancia del número utilizado no ha sido normalizada en esta
Recomendación.
c)Cuando el valor de un atributo normalizado pueda ser una cadena imprimible, una cadena teletex equivalente o ambas, la elección entre las tres posibilidades se considerará intrascendente.
d)Cuando el valor de un atributo normalizado puede contener letras, los tipos de esas letras se considerarán intrascendentes.
e)En un tipo o valor de atributo definido por el dominio o en un valor de atributo normalizado, todos los espacios precedentes, todos los espacios subsiguientes y todos los intermedios consecutivos menos uno, se considerarán intrascendentes.
Nota 1
- Un DG puede imponer reglas de equivalencia
adicionales a los atributos que asigna a sus propios usuarios y LD. Podría
definir, por ejemplo, reglas relativas a los caracteres de puntuación en los
valores de atributos, el tipo de las letras de tales atributos o el orden
relativo de los atributos definidos por el dominio.
Nota 2
- En el plano nacional, los DG pueden imponer
reglas de equivalencia adicionales respecto a los atributos normalizados cuyos
valores se dan como cadenas teletex, en particular las reglas para la deducción
de las cadenas imprimibles equivalentes.
18.5
Formas de direcciones O/D
Todo usuario o LD tiene asignadas una o más direcciones O/D. Una dirección O/D es una lista de atributos que distingue a un usuario de otro e identifica el punto de acceso del usuario al STM o al punto de ampliación de la LD.
Una dirección O/D puede tomar alguna de las formas que, de manera resumida, se indican en el cuadro 10/X.402. En la primera columna del cuadro se da una relación de los atributos disponibles para la elaboración de direcciones O/D. Para cada forma de dirección O/D, la segunda columna indica los atributos que pueden aparecer en estas direcciones O/D y sus grados (véase también el 18.6 ).
El cuadro 10/X.402 tiene cuatro secciones. Los tipos de atributos de la primera son los de carácter general, los de la segunda y la tercera son específicos de la entrega física. La cuarta sección comprende los atributos definidos por el dominio.
Las formas de direcciones O/D, expuestas de manera resumida en el cuadro 10/X.402, se definen y describen individualmente en los puntos que siguen.
18.5.1
Dirección O/D nemotécnica
Dirección O/D nemotécnica
es una dirección que
identifica nemotécnicamente a un usuario o una LD. Identifica a un DGAD y a un
usuario o una LD relativos a éste.
Una dirección O/D nemotécnica consta de los siguientes atributos:
a)un nombre-país y un nombre-dominio-administración, que juntos identifican a un DGAD;
b)un nombre-dominio-privado, un nombre-organización, un nombres-unidades-organizativas, un nombre-personal o nombre-común o una combinación de los anteriores; y facultativamente uno o más atributos definidos por el dominio, que, conjuntamente, identifican a un usuario o una LD relativos al DGAD mencionado en a).
18.5.2
Dirección O/D numérica
Dirección O/D numérica
es una dirección que identifica
numéricamente a un usuario. Identifica a un DGAD y a un usuario relativo a él.
Una dirección O/D numérica consta de los siguientes atributos:
a)un nombre-país y un nombre-dominio-administración, que conjuntamente identifican a un DGAD;
b)un identificador-usuario-numérico y, de manera condicional, un nombre-dominio-privado, que juntos identifican al usuario relativo al DGAD mencionado en a);
c)de manera condicional, uno o más atributos definidos por el dominio que proporcionan información adicional a la de identificación del usuario.
18.5.3
Dirección O/D postal
Dirección O/D postal
es una dirección que identifica a
un usuario por su dirección postal. Identifica al servicio de entrega física a
través del cual ha de accederse al usuario y da la dirección postal del mismo.
Se distinguen las siguientes clases de direcciones O/D postales:
a)
formatizada
: Dirección O/D postal que especifica la
dirección postal de un usuario mediante varios atributos. Para esta forma de
dirección O/D postal, la presente Recomendación prescribe, con cierto detalle,
la estructura de direcciones postales.
b)
no formatizada
: Dirección O/D postal que especifica una
dirección postal de un usuario en un solo atributo. Para esta forma de
dirección O/D postal, la presente Recomendación no prescribe mayormente la
estructura de las direcciones postales.
Table 10/X.402 [T10.402], p.
Una dirección O/D postal, tanto si es formalizada como si no lo es, consta de
los siguientes atributos:
a)un nombre-país y un nombre-país-administración, que juntos identifican a un DGAD;
b)de manera condicional, un nombre-dominio-privado, un nombre-servicio-entrega-física o ambos, que juntos identifican al servicio de entrega física mediante el cual se accede al usuario;
c)un nombre-país-entrega-física y un código-postal que juntos identifican la zona geográfica en la que el usuario recibe la entrega de mensajes físicos.
Una dirección O/D postal formatizada comprende, además, uno de cada uno de los atributos de direccionamiento postal (véase el cuadro 9/X.402) excepto el de dirección-postal-no-formatizada, que necesita el SEF para identificar el patrón postal.
Una dirección O/D postal no formatizada incluye, adicionalmente, un atributo de dirección-postal-no-formatizada.
Nota
- El número total de caracteres de los valores de
todos los atributos, excepto nombre-país, nombre-dominio-administración y
nombre-servicio-entrega-física, en una dirección O/D postal, deberá ser lo
bastante reducido para permitir su reproducción en 6 líneas de 30 caracteres,
que es el tamaño de una ventanilla de sobre típica. El algoritmo de
reproducción es específico de la UAEF, pero es probable que incluya
delimitadores de inserción (por ejemplo, espacios) entre algunos de los valores
de atributos.
18.5.4
Dirección O/D terminal
Dirección O/D terminal
es una dirección que identifica
un usuario mediante el número de red y, si es preciso, el tipo de su terminal.
También puede identificar el DGAD a través del cual se accede a ese terminal.
En el caso de un terminal telemático, da la dirección de red del terminal y,
posiblemente, su identificador y tipo de terminal. En el caso de un terminal
télex, da su número de télex.
Una dirección O/D terminal consta de los siguientes atributos:
a)una dirección-red;
b)de manera condicional, un identificador-terminal;
c)de manera condicional, un tipo-terminal;
d)de manera condicional, un nombre-país y un nombre-dominio-administración que juntos identifican un DGAD;
e)de manera condicional, un nombre-dominio-privado y, condicionalmente asimismo, uno o más atributos definidos por el dominio, todos los cuales proporcionan información adicional a la que identifica al usuario.
Los atributos de nombre-dominio-privado y definido por el dominio sólo estarán presentes si también lo están los de nombre-dominio-administración y nombre-país.
18.6
Atributos condicionales
La presencia o ausencia en una dirección O/D particular, de los atributos señalados como condicionales en el cuadro 10/X.402, se determina según los criterios que a continuación se exponen.
Si se accede a un usuario o LD a través de un DGPR, los atributos utilizados para encaminar mensajes al DGPR están presentes en la dirección O/D, a discreción del DGAD indicado por los atributos nombre-país y nombre-dominio-administración de la dirección O/D y de acuerdo con las reglas establecidas por él. El DGAD no impone más limitaciones a los atributos de la dirección O/D. Si no se accede a un usuario a través de un DGPR, todos los atributos condicionales, excepto los específicos de las direcciones O/D postales, figuran en una dirección O/D a discreción del DGAD indicado por los atributos nombre-país y nombre-dominio-administración y de acuerdo con las reglas establecidas por él.
Todos los atributos condicionales específicos de las direcciones O/D postales están presentes o ausentes en tales direcciones O/D, de modo que se satisfagan las exigencias de direccionamiento postal de los usuarios a los que identifican.
19
Encaminamiento
Para transportar un mensaje, sonda o informe a un usuario o al punto de ampliación de una LD, un ATM debe, no sólo localizar el usuario o la LD (es decir obtener su dirección O/D), sino también seleccionar un encaminamiento hacia esa ubicación.
El encaminamiento externo es un proceso incremental y sólo vagamente normalizado. A continuación se sugieren algunos principios para el encaminamiento externo. El interno queda fuera del alcance de esta Recomendación.
Estos principios son ilustrativos, y no son definitivos.
a)En un STM que conste de un único DG, la cuestión del encaminamiento, naturalmente, no se plantea.
b)Un DGPR puede estar conectado a un único DGAD. Cuando esto ocurre, el encaminamiento implica necesariamente al DGAD.
c)Un DGAD puede estar conectado a múltiples DGPR. Si este es el caso, el encaminamiento puede basarse en atributos de dirección O/D condicionales, incluyendo el de nombre-dominio-privado, pero sin limitarse a él.
d)Un DG puede estar conectado directamente a algunos otros DG, pero no a
todos. Cuando la dirección O/D identifica a un DG con el que no existe conexión
directa, el encaminamiento se puede basar en
acuerdos
bilaterales
con los DG con los que sí existen conexiones directas, y en
otras reglas locales.
e)Cuando el DG está conectado directamente al DG identificado por la dirección O/D, el objeto es encaminado, por sistema, directamente a ese DG.
f)Por
acuerdo bilateral
, un DG podría encaminar un
objeto a otro DG a efectos de, por ejemplo, conversión.
g)Un DG puede encaminar a una dirección O/D mal formada siempre que, naturalmente, contenga por lo menos los atributos requeridos para ello.
Nota
- Los acuerdos bilaterales y las reglas locales a
que se ha aludido anteriormente, quedan fuera del alcance de esta
Recomendación, y pueden estar basados en consideraciones de tipo técnico,
político o económico, o de otra clase.
SECCIóN 5 -
20 Visión de conjunto
En esta sección se describen los usos que el STM puede hacer de la guía, cuando se dispone de ella. Si el STM no dispone de guía, la manera según la cual realiza las mismas tareas, si es que las realiza, es un asunto local.
La sección comprende los siguientes temas:
a)autenticación;
b)resolución de nombres;
c)ampliación de LD;
d)evaluación de capacidades.
21 Autenticación
Un objeto funcional puede efectuar la autenticación utilizando información almacenada en la guía.
22 Resolución de nombres
Un objeto funcional puede llevar a cabo la resolución de nombres utilizando la guía.
Un objeto que posee el nombre de guía de un usuario o de una LD y cuya dirección o direcciones O/D desea obtener, presenta ese nombre a la guía y pide los siguientes atributos de la inscripción en la guía del objeto:
a)
Direcciones O/D del STM
;
b)
Métodos de entrega preferidos del STM
.
Para hacerlo de manera satisfactoria, el objeto debe primero autenticarse él mismo a la guía, y tener derechos de acceso a la información solicitada.
23 Ampliación de LD
Un objeto funcional puede llevar a cabo la ampliación de una LD utilizando la guía, previa verificación de que existen los permisos de depósitos necesarios.
Para obtener los miembros de una LD cuyo nombre de guía posee, el objeto presenta ese nombre a la guía y pide los siguientes atributos de la inscripción en la guía del objeto:
a)
miembros de LD del STM
;
b)
permisos de depósito de LD del STM
;
c)
métodos de entrega preferidos del STM
.
Para hacerlo de manera satisfactoria, el ATM debe primero autenticarse él mismo a la guía, y tener derechos de acceso a la información solicitada.
24 Evaluación de capacidades
Un objeto funcional puede evaluar las capacidades de un usuario o LD utilizando la guía.
Los atributos de guía siguientes representan capacidades de usuario de posible importancia en el tratamiento de mensajes:
a)
longitud de contenido entregable del STM
;
b)
tipos de contenido entregables del STM
;
c)
TIC entregables del STM
d)
métodos de entrega preferidos del STM
.
Los atributos de guía siguientes representan capacidades de MM de posible importancia en el tratamiento de mensajes:
a)
acciones automáticas facilitadas por el STM
;
b)
tipos de contenido facilitados por el STM
;
c)
atributos facultativos facilitados por el STM
.
Para evaluar determinada capacidad de un usuario o MM cuyo nombre de guía posee, el objeto presenta ese nombre a la guía y pide los atributos asociados a esa capacidad, que figuran en la inscripción en la guía del objeto.
Para hacerlo de manera satisfactoria, el ATM debe primero autenticarse él mismo a la guía y tener derechos de acceso a la información solicitada.
SECCIóN 6 - REALIZACIóN POR ISA
25 Visión de conjunto
En esta sección se describe cómo se realiza el STM por medio de la ISA.
La sección comprende los siguientes temas:
a)elementos de servicio de aplicación;
b)contextos de aplicación.
26 Elementos de servicio de aplicación
En este punto se identifican los @elementos de servicio de aplicación (ESA)\ que figuran en la realización mediante ISA del tratamiento de mensajes.
En la ISA, las capacidades de comunicación de sistemas abiertos se
organizan en grupos de capacidades relacionadas, llamados ESA. En la presente
sección, se examina este concepto, a partir del modelo de referencia ISA, se
establece una distinción entre ESA
simétricos
y
asimétricos
y se presentan los ESA definidos para el
tratamiento de mensajes o que le sirven de apoyo.
Nota
- El STM depende no sólo de los ESA examinados,
sino también del elemento de servicio de acceso a la guía, definido en la
Recomendación X.519. Sin embargo, como este ESA no figura en los
CA
para tratamiento de mensajes (véase la Recomendación
X.419), no se analiza aquí.
26.1
El concepto de ESA
La figura 12/X.402 ilustra el concepto de ESA. En ella se representan de manera esquemática dos sistemas abiertos en comunicación. Sólo se muestran las partes de los sistemas abiertos relacionados con la ISA, a las que se llama entidades de aplicación (EA). Cada EA consta de un EU y de uno o más ESA. El EU representa la parte organizativa o de control de una EA, que define el cometido del sistema abierto (por ejemplo, el de un ATM). Por su parte, un ESA representa uno de los conjuntos de capacidad de comunicaciones, o servicios (por ejemplo, depósito o transferencia de mensajes), que el EU necesita para desempeñar su cometido.
A la relación entre dos EA en sistemas abiertos diferentes se le llama asociación de aplicación. Los ESA de un sistema abierto se comunican con sus ESA pares del otro a través de una conexión de presentación entre ellos. Esa comunicación es la que crea y mantiene la relación inherente a la asociación de aplicación. Para que varios ESA se combinen de manera satisfactoria en una única EA, deben estar diseñados de manera que coordinen su utilización de la asociación de aplicación.
Figura 12/X.402, p.
Un ESA desempeña el papel, en gran medida mecánico, de trasladar las
peticiones formuladas por su EU, y las respuestas, a y desde la forma dictada
por el protocolo de aplicación que gobierna la interacción del ESA con su ESA
par del sistema abierto al que la asociación le conecta. El ESA efectúa un
servicio, o una parte del mismo, abstracto, a efectos de comunicación de la ISA
(véase la Recomendación X.407).
Nota
- En sentido estricto, el papel de un sistema
abierto viene determinado por el comportamiento de sus procesos de aplicación.
En el contexto del tratamiento de mensajes, un proceso de aplicación realiza un
objeto funcional de uno de los tipos definidos en el
7
. A su vez, un
EU es una parte de un proceso de aplicación.
26.2
ESA simétricos y asimétricos
Cabe distinguir los siguientes dos tipos de ESA, ilustrados en la figura 13/X.402:
a)
@simétrico@
: \ESA por medio del cual un EU suministra y
consume un servicio. El ESA para transferencia de mensajes, por ejemplo, es
simétrico, porque ambos sistemas abiertos, cada uno de los cuales incorpora un
ATM, ofrece y puede consumir por medio de él el servicio de transferencia de
mensajes.\
a)
@asimétrico@
: \ESA por medio del cual un EU suministra
y consume un servicio, pero no ambas cosas; dependiendo de cómo esté
configurado el ESA. El ESA para entrega de mensajes, por ejemplo, es
asimétrico, porque sólo el sistema abierto que incorpora un ATM ofrece el
servicio asociado, y sólo el otro sistema abierto, que incorpora un AU o una
MM, lo consume.\
Figura 13/X.402, p.
Con respecto a un determinado ESA asimétrico, un EU suministra un servicio que
el otro consume. Los ESA, coubicados con los EU, ayudan en el suministro y
consumo del servicio. Los cuatro papeles resultantes se muestran en la figura
14/X.402, con la siguiente terminología:
a)
EU suministrador de x
: Proceso de aplicación que
suministra el servicio representado por el ESA asimétrico
x
.
b)
ESA suministrador de x
: ESA asimétrico
x
configurado para coubicación con un EU suministrador de
x
.
c)
EU consumidor de x
: Proceso de aplicación que consume
el servicio representado por el ESA asimétrico
x
.
d)
ESA consumidor de x
: ESA asimétrico
x
configurado para coubicación con un EU consumidor de
x
.
Figura 14/X.402, p,
Como se ha indicado, los cuatro papeles descritos anteriormente están
definidos en relación con un determinado ESA. Cuando una EA consta de varios
ESA asimétricos, estos papeles se asignan independientemente a cada ESA. Así,
tal como se muestra en la figura 15/X.402, un único EU podría servir como
consumidor con respecto a un ESA y como suministrador con respecto a otro.
Figura 15/X.402, p,
26.3
ESA de tratamiento de mensajes
En la primera columna del cuadro 11/X.402 figura la lista de los ESA que proporcionan los diversos servicios del tratamiento de mensajes. Para cada ESA de la primera columna, se indica en la segunda si es simétrico o asimétrico. La tercera columna identifica los objetos funcionales - AU, MM, ATM y UA - que están asociados al ESA, como consumidores o como suministradores.
Cuadro 11/X.402 [T11.402], p.
Los ESA de tratamiento de mensajes, resumidos en el cuadro 11/X.402, se
presentan por separado en los puntos que siguen. En la Recomendación X.419
figuran sus definiciones.
26.3.1
Transferencia de mensajes
El @elemento de servicio transferencia de mensajes (ESTM)\ es el medio por el cual se efectúa el paso de transmisión de transferencia.
26.3.2
Depósito de mensajes
El @elemento de servicio depósito de mensajes (ESDM)\ es el medio por el cual se efectúa el paso de transmisión de depósito.
26.3.3
Entrega de mensajes
El @elemento de servicio entrega de mensajes (ESEM)\ es el medio por el cual se efectúa el paso de transmisión de entrega.
26.3.4
Recuperación de mensajes
El @elemento de servicio recuperación de mensajes (ESRM)\ es el medio por el cual se efectúa el paso de transmisión de extracción.
26.3.5
Administración de mensajes
El @elemento de servicio de administración de mensajes (ESAM)\ es el medio por el cual un AU, una MM o ATM archiva, en cada uno de los otros dos la información que facilita y controla su interacción subsiguiente, mediante el ESDM, ESM, el ESRM y el ESAM.
26.4
ESA de apoyo
En la primera columna del cuadro 12/X.402 figura la lista de los ESA de uso general, de los que dependen los ESA de tratamiento de mensajes. Para cada ESA de la primera columna, se indica en la segunda si es simétrico o asimétrico.
Cuadro 12/X.402 [T12.402], p.
Los ESA de apoyo, resumidos en el cuadro 12/X.402 se presentan por separado
en los puntos que siguen.
26.4.1
Operaciones distantes
El @elemento de servicio operaciones distantes (ESOD)\ es el medio por el cual, los ESA asimétricos de tratamiento de mensajes, estructuran sus interacciones de petición-respuesta, entre sistemas abiertos consumidores y suministradores.
El ESOD se define en la Recomendación X.219.
26.4.2
Transferencia fiable
El @elemento de servicio transferencia fiable (ESTF)\ es el medio por el cual diversos ESA de tratamiento de mensajes, simétricos y asimétricos, transportan objetos de información - especialmente grandes, (por ejemplo, mensajes facsímil) - entre sistemas abiertos, de modo que se garantice su almacenamiento seguro en sus destinos.
El ESTF se define en la Recomendación X.218.
26.4.3
Control de asociación
El @elemento de servicio control de asociación (ESCA)\ es el medio por el cual se establecen, se liberan y, en otros aspectos, se gestionan todas las asociaciones de aplicación entre sistemas abiertos.
El ESCA se define en la Recomendación X.217.
27 Contextos de aplicación
En la ISA, las capacidades de comunicación (es decir, los ESA) de dos sistemas abiertos son dirigidos, para un fin determinado, mediante @contextos de aplicación (CA).\ Un CA es una especificación detallada del empleo de una asociación entre dos sistemas abiertos, es decir, un protocolo.
Un CA especifica cómo debe establecerse la asociación (por ejemplo, qué parámetros de inicialización se deben intercambiar), qué ESA deben participar en una comunicación entre pares a través de la asociación, qué limitaciones han de imponerse (si es que se impone alguna) a su utilización individual de la asociación, si el consumidor de cada ESA asimétrico es el iniciador o el contestador y cómo puede liberarse la asociación (por ejemplo, qué parámetros de finalización se deben intercambiar).
Todo CA tiene asignado un nombre (un identificador de objeto NSA.1). El iniciador de una asociación indica al contestador cuál es el CA que dirigirá el uso de la asociación, haciéndole llegar el nombre del CA por medio del ESCA.
Un CA identifica también con un nombre (un identificador de objeto NSA.1) las sintaxis abstractas de las UDPA que puede llevar una asociación, como resultado de su utilización por los ESA del CA. De manera convencional, se asigna un nombre bien al conjunto de las UDPA asociadas a cada ESA individual o bien al CA como un todo. El iniciador de una asociación indica al contestador la o las sintaxis abstractas, enviándole sus nombres por medio del ESCA.
Las sintaxis abstractas de una UDPA es su estructura como objeto de información (por ejemplo, un conjunto NSA.1 que comprenda un código de instrucción entero y un argumento de instrucción cadena AI5). Se diferencia de la sintaxis de transferencia de la UDPA, que es como se representa el objeto de información para transmisión entre dos sistemas abiertos (por ejemplo, un octeto indicando un conjunto NSA.1, seguido por un octeto que dé la longitud del conjunto, etc.).
Los CA, por medio de los cuales se proporcionan los diversos servicios de tratamiento de mensajes, se especifican en la Recomendación X.419. A estos protocolos se les conoce por P1, P3 y P7.
Nota
- La naturaleza del contenido de un mensaje no
entra en la definición del CA de tratamiento de mensajes, porque el contenido
queda englobado (como una cadena de octetos) en los protocolos que lo
transportan.
ANEXO A (a la Recomendación R.402)
Clases de objetos de
guía y atributos
Varias clases de objetos de guía, atributos y sintaxis de atributos son específicos del tratamiento de mensajes. Se definen en el presente anexo utilizando los macros OBJECT-CLASS, ATTRIBUTE y ATTRIBUTE-SYNTAX respectivamente, de la Recomendación X.501.
A.1
Clases de objetos
A continuación se especifican las clases de objetos del tratamiento de mensajes.
Nota
- Las clases de objetos de guía descritos en este
anexo pueden combinarse con otras clases de objetos, por ejemplo, los definidos
en la Recomendación X.521. En el
9
de la Recomendación X.501 figura
una explicación del modo en que pueden combinarse las clases de objetos de guía
en una inscripción de guía. El anexo B de la Recomendación X.521 da más
información sobre las formas de nombres de guía y posibles estructuras de
árboles de informaciones de guía.
A.1.1
Lista de distribución del STM
Un objeto
lista de distribución del STM
es una LD. Los
atributos de su inscripción identifican su nombre común, permisos de depósito y
direcciones O/D y, en la medida en que estén presentes los atributos
pertinentes, describen la LD, identifican su organización, sus unidades
organizativas y su propietario, mencionan objetos relacionados e identifican
sus tipos de contenido entregable, TIC entregables, miembros y métodos de
entrega preferidos.
mhs-distribution-list OBJECT-CLASS SUBCLASS OF top MUST CONTAIN^{ commonName, mhs-dl-submit-permissions, mhs-or-addresses^} MAY CONTAIN^{ description, organization, organizationalUnitName, owner seeAlso, mhs-deliverable-content-types, mhs-deliverable-eits, mhs-dl-members, mhs-preferred-delivery-methods^} ::= id-oc-mhn-distribution-list
A.1.2
Memoria de mensajes del STM
Un objeto
memoria de mensajes del STM
es una EA que
realiza una MM. Los atributos de su inscripción, en la medida en que estén
presentes, describen la MM, identifican a su propietario y enumeran los
atributos facultativos, las acciones automáticas y los tipos de contenido que
facilita.
mhs-message-store OBJECT-CLASS SUBCLASS OF aplicationEntity MAY CONTAIN^{ description, owner, mhs-supported-optional-atributes, mhs-supported-automatic-actions, mhs-supported-content-types^} ::= id-oc-mhs-message-store
A.1.3
Agente de transferencia de mensajes del STM
Un objeto
agente de transferencia de mensajes del STM
es
una EA que pone en ejecución un ATM. Los atributos de su inscripción, en la
medida que estén presentes, describen el ATM e identifican a su propietario y
la longitud de su contenido entregable.
mhs-message-transfer-agent OBJECT-CLASS SUBCLASS OF applicationEntity MAY CONTAIN^{ description, owner, mhs-deliverable-content-length^} ::= id-oc-mhs-message-transfer-agent
A.1.4
Usuario del STM
Un objeto
usuario del STM
es un usuario genérico del STM
(el usuario genérico del STM puede tener, por ejemplo, una dirección comercial,
o una dirección privada, o ambas). Los atributos de su inscripción identifican
la dirección O/D del usuario y, en la medida en que estén presentes, los
atributos pertinentes identifican la longitud del contenido entregable del
usuario, tipos de contenido y TIC, su MM y sus métodos de entrega preferidos.
mhs-user OBJECT-CLASS SUBCLASS OF top MUST CONTAIN^{ mhs-or-adresses^}, MAY CONTAIN { mhs-deliverable-content-length, mhs-deliverable-content-types, mhs-deliverable-eits, mhs-message-store, mhs-preferred-delivery-methods^} ::= id-oc-mhs-user
A.1.5
Agente de usuario del STM
Un objeto
agente de usuario del STM
es una EA que
realiza un AU. Los atributos de su inscripción, en la medida en que estén
presentes, identifican al propietario del AU, la longitud de su contenido
entregable, tipos de contenido y TIC, y su dirección O/D.
mhs-user-agent OBJECT-CLASS SUBCLASS OF applicationEntity MAY CONTAIN^{ owner, mhs-deliverable-content-length, mhs-deliverable-content-types, mhs-deliverable-eits, mhs-or-addresses} ::= id-oc-mhs-user-agent
A.2
Atributos
Los atributos específicos del tratamiento de mensajes son los que se indican a continuación.
A.2.1
Longitud de contenido entregable del STM
El atributo
longitud del contenido entregable del STM
identifica la longitud máxima del contenido de los mensajes cuya entrega
aceptará un usuario.
Un valor de este atributo es un entero.
mhs-deliverable-content-length ATTRIBUTE WITH ATTRIBUTE-SYNTAX integerSyntax SINGLE VALUE ::= id-at-mhs-deliverable-content-length
A.2.2
Tipos de contenido entregable del STM
El atributo
tipos de contenido entregable del STM
identifica los tipos de contenido de los mensajes cuya entrega aceptará el
usuario.
Un valor de este atributo es un identificador de objeto.
mhs-deliverable-content-types ATTRIBUTE WITH ATTRIBUTE-SYNTAX objectIdentifierSyntax MULTI VALUE ::= id-at-mhs-deliverable-content-types
A.2.3
TIC entregables del STM
El atributo
TIC entregables del STM
identifica los TIC de
los mensajes cuya entrega aceptará el usuario.
Un valor de este atributo es un identificador de objeto.
mhs-deliverable-eits ATTRIBUTE WITH ATTRIBUTE-SYNTAX objectIdentfierSyntax MULTI VALUE ::= id-at-mhs-deliverable-eits
A.2.4
Miembros de LD del STM
El atributo
miembros de LD del STM
identifica los
miembros de una LD.
Un valor de este atributo es un nombre O/D.
mhs-dl-members ATTRIBUTE WITH ATTRIBUTE-SYNTAX mhs-or-name-syntax MULTI VALUE ::= id-at-mhs-dl-members
A.2.5
Permisos de depósito de LD del STM
El atributo
permisos de depósito de LD del STM
identifica los usuarios y las LD que pueden depositar mensajes a una LD.
Un valor de este atributo es un permiso de depósito de LD.
mhs-dl-submit-permissions ATTRIBUTE WITH ATTRIBUTE-SYNTAX mhs-dl-submit-permission-syntax MULTI VALUE ::= id-at-mhs-dl-submit-permissions
A.2.6
Memoria de mensajes del STM
El atributo
memoria de mensajes del STM
identifica una
MM de usuario por un nombre.
El valor de este atributo es un nombre distinguido de guía.
mhs-message-store ATTRIBUTE WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax SINGLE VALUE ::= id-at-mhs-message-store
A.2.7
Direcciones O/D del STM
El atributo
direcciones O/D del STM
especifica las
direcciones O/D de un usuario o de una LD.
Un valor de este atributo es una dirección O/D.
mhs-or-addresses ATTRIBUTE WITH ATTRIBUTE-SYNTAX mhs-or-address-syntax MULTI VALUE ::= id-at-mhs-or-addresses
A.2.8
Métodos de entrega preferidos del STM
El atributo
métodos de entrega preferidos del STM
identifica, en orden decreciente de preferencias, los métodos de entrega que
prefiere un usuario.
Un valor de este atributo es un método de entrega preferido.
mhs-preferred-delivery-methods ATTRIBUTE WITH ATTRIBUTE-SYNTAX RequestedDeliveryMethod MATCHES FOR EQUALITY SINGLE VALUE ::= id-at-mhs-preferred-delivery-methods
A.2.9
Acciones automáticas permitidas por el STM
El atributo
acciones automáticas permitidas por el STM
identifica las acciones automáticas que un AM admite totalmente.
Un valor de este atributo es un identificador de objeto.
mhs-supported-automatic-actions ATTRIBUTE WITH ATTRIBUTE-SYNTAX objectIdentifierSyntax MULTI VALUE ::= id-at-mhs-supported-automatic-actions
A.2.10
Tipos de contenido permitidos por el STM
El atributo
tipos de contenido permitidos por el STM
identifica los tipos de contenido de los mensajes cuya sintaxis semántica
permite totalmente una MM.
Un valor de este atributo es un identificador de objeto.
mhs-supported-content-types ATTRIBUTE WITH ATTRIBUTE-SYNTAX objectIdentifierSyntax MULTI VALUE ::= id-at-mhs-supported-content-types
A.2.11
Atributos facultativos permitidos por el STM
El atributo
atributos facultativos permitidos por el STM
identifica los atributos facultativos que permite totalmente una MM.
Un valor de este atributo es un identificador de objeto.
mhs-supported-optional-attributes ATTRIBUTE WITH ATTRIBUTE-SYNTAX objectIdentifierSyntax MULTI VALUE ::= id-at-mhs-supported-optional-attributes
A.3
Sintaxis de atributos
Las sintaxis de atributos específicos del tratamiento de mensajes son las que se indican a continuación.
A.3.1
Permiso de depósito de LD del STM
La sintaxis de atributo
permiso de depósito de LD del
STM
caracteriza un atributo, cada uno de cuyos valores es un permiso de
depósito.
mhs-dl-submit-permission-syntax ATTRIBUTE-SYNTAX SYNTAX DLSubmitPermission MATCHES FOR EQUALITY ::= id-as-mhs-dl-submit-permission
DLSubmitPermission ::= CHOICE^{ individual[0] ORName, member-of-dl[1] ORName, pattern-match[2] ORNamePattern, member-of-group[3] Name^}
El valor de un permiso de depósito de LD presentado será del tipo
individual
.
Un permiso de depósito de LD concede, dependiendo de su tipo, acceso de presentación a los cero o más usuarios o listas de distribución siguientes:
a)
Individual
: Usuario o LD (no ampliada) alguno de
cuyos nombres O/D es igual al nombre O/D especificado.
b)
Miembro-de-ld
: Cada miembro de la LD, o de cada LD
jerarquizada de manera recurrente, alguno de cuyos nombres O/D es igual al
nombre O/D especificado.
c)
Concordancia-de-esquemas
: Cada usuario o LD (no
ampliada) alguno de cuyos nombres O/D satisface el esquema de nombres O/D
especificado.
ORNamePattern ::= ORName
d)
Miembro-de-grupo
: Cada miembro de grupo-de-nombres, o
de cada grupo-de-nombres jerarquizado, de manera recurrente, cuyo nombre está
especificado.
Se considera que un valor presentado es igual a un valor objetivo de este tipo si los dos son idénticos, atributo por atributo. Además, se puede declarar igualado en otras condiciones, que son asunto local.
A.3.2
Dirección O/D del STM
La sintaxis del atributo
dirección O/D del STM
caracteriza a un atributo cada uno de cuyos valores es una dirección O/D.
mhs-or-address-syntax ATTRIBUTE-SYNTAX SYNTAX ORAddress MATCHES FOR EQUALITY ::= id-as-mhs-or-address
Un valor de dirección O/D presentado es igual a un valor de dirección O/D objetivo en las condiciones especificadas en el 18.4 .
A.3.3
Nombre O/D del STM
La sintaxis del atributo
nombre O/D del STM
caracteriza
a un atributo cada uno de cuyos valores es un nombre O/D.
mhs-or-name-syntax ATTRIBUTE-SYNTAX SYNTAX ORName MATCHES FOR EQUALITY ::= id-as-mhs-or-name
Un valor de nombre O/D presentado es igual a un valor de nombre O/D objetivo si los dos son idénticos, atributo por atributo. Puede además declararse igualdad bajo otras condiciones, que son asunto local.
ANEXO B (a la Recomendación X.402)
Definiciones de
referencia de identificadores de objetos
En él se definen, a efectos de referencia, diversos identificadores de objetos mencionados en el módulo NSA.1 del anexo C. Se utiliza NSA.1.
Todos los identificadores de objetos asignados por esta Recomendación lo son en el presente anexo. El anexo B es definitivo para todos, excepto para los de los módulos del NSA.1 y del propio STM. Las asignaciones definitivas para el primero se producen en los mismos módulos; en los párrafos IMPORT aparecen otras referencias a los mismos. El segundo es fijo.
MHSObjectIdentifiers {joint-iso-ccitt
mhs-motis(6) arch(5) modules(0) object-identifiers(0)}
DEFINITIONS IMPLICIT TAGS ::=
BEGIN --
Prólogo
--
Exporta todo
.
IMPORTS --
nada
-- ;
ID ::= OBJECT IDENTIFIER
--
Aspectos del STM
id-mhsacID ::=^{^joint-iso-ccitt mhs-motis(6) mhsac(0)^}
--
Contexto de aplicación del STM
--
Véase la Recomendación X.419
id-ipmsID ::=^{^joint-iso-ccitt mhs-motis(6) ipms(1)^}
--
Mensajería interpersonal
--
Véase la Recomendación X.420
id-asdcID ::=^{^joint-iso-ccitt mhs-motis(6) asdc (2)^}
--
Convenios de definición de servicio abstracto
--
Véase la Recomendación X.407
id-mtsID ::=^{^joint-iso-ccitt mhs-motis(6) mts (3)^}
--
Sistema de transferencia de mensajes
--
Véase la Recomendación X.411
id-msID ::=^{^joint-iso-ccitt mhs-motis(6) ms (4)^}
--
Memoria de mensajes
--
Véase la Recomendación X.413
id-archID ::=^{^joint-iso-ccitt mhs-motis(6) arch (5)^}
--
Arquitectura global
--
Véase esta Recomendación
id-groupID ::=^{^joint-iso-ccitt mhs-motis(6) group(6)^}
--
Reservado
--
Categorías
id-modID ::=^{^id-arch 0} --
módulos, no definitivo
id-oc ID ::=^{^id-arch 1} --
clases de objetos
id-at ID ::=^{^id-arch 2} --
tipos de atributos
id-as ID ::=^{^id-arch 3} --
sintaxis de atributos
--
Módulos
id-object-identifiers ID ::= {id-mod 0} --
no
definitivo
id-directory-objects-and-attributes; ID ::= {id-mod 1}
--
no definitivo
--
Clases de objetos
id-oc-mhs-distribution-list ID ::= {id-oc 0^} id-oc-mhs-message-store ID ::= {id-oc 1^} id-oc-mhs-message-transfer-agent ID ::=^{^id-oc 2^} id-oc-mhs-user ID ::=^{^id-oc 3^} id-oc-mhs-user-agent ID ::=^{^id-oc 4^}
--
Atributos
id-at-mhs-deliverable-content-length ID ::=^{^id-at 0^} id-at-mhs-deliverable-content-types ID ::=^{^id-at 1^} id-at-mhs-deliverable-eits ID ::=^{^id-at 2^} id-at-mhs-dl-members ID ::=^{^id-at 3^} id-at-mhs-dl-submit-permissions ID ::=^{^id-at 4^} id-at-mhs-message-store ID ::=^{^id-at 5^} id-at-mhs-or-addresses ID ::=^{^id-at 6^} id-at-mhs-preferred-delivery-methods ID ::=^{^id-at 7^} id-at-mhs-supported-automatic-actions ID ::=^{^id-at 8^} id-at-mhs-supported-content-types ID ::=^{^id-at 9^} id-at-mhs-supported-optional-attributes ID ::=^{^id-at 10^}
--
Sintaxis de atributos
id-as-mhs-dl-submit-permission ID ::=^{^id-as 0^} id-as-mhs-or-address ID ::=^{^id-as 1^} id-as-mhs-or-name ID ::=^{^id-as 2^}
END --
final de los identificadores de objetos de STM
ANEXO C (a la Recomendación R.402)
Definición^ de
referencia de clases de objetos de guía y atributos
Este anexo, que complementa el anexo A define a efectos de referencia las clases de objetos, los atributos y las sintaxis de atributos específicos del tratamiento de mensajes. Para ello, se hace uso de las macro OBJECT-CLASS, ATTRIBUTE y ATTRIBUTE SYNTAX de la Recomendación X.501.
MHSDirectoryObjectsAndAttributes^{^joint-iso-ccitt
mhs-motis(6) arch(5) modules(0) directory(1)^}
DEFINITIONS IMPLICIT TAGS ::=
BEGIN --
Prólogo
--
Exporta todo
IMPORTS
--
Identificadores de objetos del STM
id-as-mhs-dl-submit-permission, id-as-mhs-or-address, id-as-mhs-or-name-, id-at-mhs-deliverable-content-length, id-at-mhs-deliverable-content-types, id-at-mhs-deliverable-eits, id-at-mhs-dl-members, id-at-mhs-dl-submit-permissions, id-at-mhs-message-store, id-at-mhs-or-addresses, id-at-mhs-preferred-delivery-methods, id-at-mhs-supported-automatic-actions, id-at-mhs-supported-content-types, id-at-mhs-supported-optional-attributes, id-oc-mhs-distribution-list, id-oc-mhs-message-store, id-oc-mhs-message-transfer-agent, id-oc-mhs-user, id-oc-mhs-user-agent ---- FROM MHSObjectIdentifiers^{^joint-iso-ccitt mhs-motis(6) arch(5) modules(0) object-identifiers(0)^}
--
Servico abstracto del STM
ORAddress, ORName, RequestedDeliveryMethod
----
FROM MTSAbstractService^{^joint-iso-ccitt
mhs-motis(6) mts(3) modules(0) mTS-abstract-service(3)}
--
Marco de información
ATTRIBUTE, ATTRIBUTE-SYNTAX, Name, OBJECT-CLASS
----
FROM InformationFramework^{^joint-iso-ccitt
ds(5) modules(1) informationFramework(a)^}
--
Clases de objeto seleccionadas
applicationEntity
top
----
FROM SelectedObjectClasses^{^joint-iso-ccitt
ds(5) modules(1) selectedObjectClasses(6)^}
--
Tipos de atributo seleccionados
commonName, description, distinguishedNameSyntax,
integerSyntax, objectIdentifierSyntax, organization,
organizationalUnitName, owner, seeAlso
----
FROM SelectedAttributeTypes^{^joint-iso-ccitt
ds(5) modules(1) selectedAttributeTypes(5)^};
--
CLASES DE OBJETOS
--
Lista de distribución del STM
mhs-distribution-list OBJECT-CLASS
SUBCLASS OF top
MUST CONTAIN {
commonName,
mhs-dl-submit-permissions,
mhs-or-addresses^}
MAY CONTAIN^{
description,
organization,
organizationalUnitName,
ower,
seeAlso,
mhs-deliverable-content-types,
mhs-deliverable-eits,
mhs-dl-members,
mhs-preferred-delivery-methods^}
::= id-oc-mhs-distribution-list
--
Memoria de mensajes del STM
mhs-message-store OBJECT-CLASS
SUBCLASS OF applicationEntity
MAY CONTAIN^{
description,
owner,
mhs-supported-optional-attributes,
mhs-supported-automatic-actions,
mhs-supported-content-types^}
::= id-oc-mhs-message-store
--
Agente de transferencia de mensajes del STM
mhs-message-transfer-agent OBJECT-CLASS
SUBCLASS OF applicationEntity
MAY CONTAIN^{
description,
owner,
mhs-deliverable-content-length^}
::= id-oc-mhs-message-transfer-agent
--
Usuario del STM
mhs-user OBJECT-CLASS
SUBCLASS OF TOP
MUST CONTAIN^{
mhs-or-addresses^}
MAY CONTAIN^{
mhs-deliverable-content-length,
mhs-deliverable-content-types,
mhs-deliverable-eits,
mhs-message-store,
mhs-preferred-delivery-methods^}
::= id-oc-mhs-user
--
Agente de usuario del STM
mhs-user-agent OBJECT-CLASS
SUBCLASS OF applicationEntity
MAY CONTAIN^{
owner,
mhs-deliverable-content-length,
mhs-deliverable-content-types,
mhs-deliverable-eits,
mhs-or-addresses^}
::= id-oc-mhs-user-agent
--
ATRIBUTOS
--
Longitud de contenido entregable del STM
mhs-deliverable-content-length ATTRIBUTE
WITH ATTRIBUTE-SYNTAX integerSyntax
SINGLE VALUE
::= id-at-mhs-deliverable-content-length
--
Tipos de contenido entregable del STM
mhs-deliverable-content-types ATTRIBUTE
WITH ATTRIBUTE-SYNTAX objectIdentifierSyntax
MULTI VALUE
::= id-at-mhs-deliverable-content-types
--
TIC entregables del STM
mhs-deliverable-eits ATTRIBUTE
WITH ATTRIBUTE-SYNTAX objectIdentifierSyntax
MULTI VALUE
::= id-at-mhs-deliverable-eits
--
Miembros de LD del STM
mhs-dl-members ATTRIBUTE
WITH ATTRIBUTE-SYNTAX mhs-or-name-syntax
MULTI VALUE
::= id-at-mhs-dl-members
--
Permisos de depósito de LD del STM
mhs-dl-submit-permissions ATTRIBUTE
WITH ATTRIBUTE-SYNTAX mhs-dl-submit-permission-syntax
MULTI VALUE
::= id-at-mhs-dl-submit-permissions
--
Direcciones O/D del STM
mhs-or-addresses ATTRIBUTE
WITH ATTRIBUTE-SYNTAX mhs-or-address-syntax
MULTI VALUE
::= id-at-mhs-or-addresses
--
Memoria de mensajes del STM
mhs-message-store ATTRIBUTE
WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax
SINGLE VALUE
::= id-at-mhs-message-store
--
Métodos de entrega preferidos del STM
mhs-preferred-delivery-methods ATTRIBUTE
WITH ATTRIBUTE-SYNTAX RequestedDeliveryMethod
MATCHES FOR EQUALITY
SINGLE VALUE
::= id-at-mhs-preferred-delivery-methods
--
Acciones automáticas admitidas por el STM
mhs-supported-automatic-actions ATTRIBUTE
WITH ATTRIBUTE-SYNTAX objectIdentifierSyntax
MULTI VALUE
::= id-at-mhs-supported-automatic-actions
--
Tipos de contenido admitidos por el STM
mhs-suppported-content-types ATTRIBUTE
WITH ATTRIBUTE-SYNTAX objectIdentifierSyntax
MULTI VALUE
::= id-at-mhs-supported-content-types
--
Atributos facultativos admitidos por el STM
mhs-supported-optional-attributes ATTRIBUTE
WITH ATTRIBUTE-SYNTAX objectIdentifierSyntax
MULTI VALUE
::= id-at-mhs-supported-optional-attributes
--
SINTAXIS DE ATRIBUTO
--
Permiso de presentación de LD de STM
mhs-dl-submit-permission-syntax ATTRIBUTE-SYNTAX
SYNTAX DLSubmitPermission
MATCHES FOR EQUALITY
::= id-as-mhs-dl-submit-permission
DLSubmitPermission ::= CHOICE^{
individual [0] ORName,
member-of-dl [1] ORName,
pattern-match [2] ORNamePattern,
member-of-group [3] Name^}
ORNamePattern ::= ORName
--
Dirección O/D del STM
mhs-or-address-syntax ATTRIBUTE-SYNTAX
SYNTAX ORAddress
MATCHES FOR EQUALITY
::= id-as-mhs-or-address
--
Nombre O/D del STM
mhs-or-syntax ATTRIBUTE-SYNTAX
SYNTAX ORName
MATCHES FOR EQUALITY
::= id-as-mhs-or-name
END --
final de la guía del STM
ANEXO D
Amenazas contra la seguridad
En el 15.1 de la Recomendación X.400 se da una visión general de las amenazas contra la seguridad del STM. En esta Recomendación se consideran las amenazas tal como se plantean en el STM: amenazas en el acceso, amenazas entre mensajes, amenazas en los propios mensajes y amenazas en su almacenamiento. Todas estas amenazas pueden aparecer en las diversas formas siguientes:
a) suplantación;
b) secuenciamiento de mensajes;
c) modificación de información
d) denegación de servicio;
e) fuga de información;
f) rechazo;
g) otras amenazas del STM.
Además, las amenazas pueden surgir por accidente o intento doloroso, y pueden tener un carácter activo o pasivo. Las agresiones al STM se dirigirán hacia sus debilidades potenciales, y pueden comprender un cierto número de amenazas. Este anexo se ocupa de amenazas individuales, examinándose varios tipos amplios de amenazas, que de todos modos no constituyen una relación exhaustiva de las mismas.
En el cuadro D-1/X.402 se indica cómo hacer frente a esas amenazas utilizando los servicios de seguridad del STM. La lista de amenazas que aquí se da es indicativa, no definitiva.
Cuadro D-1/X.402, [T13.402] p.
D.1
Suplantación
El fenómeno llamado suplantación ocurre cuando una entidad finge, con
éxito, ser una entidad distinta de la que es, y puede tener lugar de diferentes
maneras. Un usuario no autorizado del STRM puede simular a otro para acceder
sin permiso a las facilidades del STRM, o actuar en detrimento de un usuario
válido, por ejemplo, desechando sus mensajes. Un usuario del STRM puede
suplantar a otro y acusar recibo, falsamente, de un mensaje en nombre del
receptor
`válido'
. Un mensaje puede ser introducido en el STRM por un
usuario que utilice falsamente la identidad de otro. Un usuario del STRM, un AM
o un ATM se pueden enmascarar como si fuesen un usuario, un AM o un ATM
distintos.
Entre las amenazas de tipo suplantación figuran las siguientes:
a) simulación y mal uso del STRM;
b) falso acuse de recibo;
c) falsa originación de un mensaje;
d) simulación de un ATM a un usuario del STRM;
e) simulación de un ATM a otro ATM.
Una suplantación incluye normalmente otras formas de agresión y, en un sistema seguro, puede implicar series de autenticaciones de usuarios válidos, por ejemplo, en la reactuación o modificación de mensajes.
D.2
Secuenciamiento de mensajes
Las amenazas contra la secuenciación de mensajes se producen cuando un mensaje se repite, entero o en parte, se le desplaza en el tiempo o se reordena. Puede recurrirse a esto para aprovecharse de la información de autenticación de un mensaje válido o reordenar o desplazar en el tiempo mensajes válidos. Si bien con los servicios de seguridad del STM es imposible evitar la reactuación de mensajes, sí cabe detectarlas y eliminar los efectos de esa amenaza.
Entre las amenazas a la secuenciación de mensajes figuran las siguientes:
a) reactuación de mensajes;
b) reordenación de mensajes;
c) adelanto de mensajes;
d) retraso de mensajes.
D.3
Modificación de información
La información para un destinatario deseado, la información de encaminamiento y otros datos relativos a la gestión pueden perderse o modificarse sin que ello se detecte. Es algo que puede ocurrir con cualquier elemento del mensaje, por ejemplo, su etiquetado, el contenido, los atributos, el destinatario o el originador. La degradación de la información de encaminamiento o de otro tipo de información de la gestión, almacenada en los ATM o utilizada por ellos, puede dar lugar a que el STRM pierda mensajes o bien a que funcione de manera incorrecta.
Entre las amenazas de tipo modificación de información figuran las siguientes:
a) modificación de mensajes;
b) destrucción de mensajes;
c) degradación del encaminamiento y de otra información de gestión.
D.4
Denegación de servicio
La denegación de servicio se produce cuando una entidad deja de realizar su cometido o evita que otras realicen los suyos. Puede tratarse de una denegación de acceso o de comunicaciones (que da lugar a otros problemas, como los de sobrecarga), una eliminación deliberada de mensajes dirigidos a un determinado destinatario, o una invención de tráfico extra. Se denegará el STRM si se provoca el fallo o el funcionamiento incorrecto de un ATM. Además, un usuario del STRM puede dar lugar a que dicho servicio se deniegue a otro usuario, saturándolo con mensajes que podrían sobrecargar la capacidad de conmutación de un ATM o llenar el espacio de almacenajes de mensajes de que se disponga.
Entre las amenazas de denegación de servicio figuran las siguientes:
a) denegación de comunicaciones;
b) fallo del ATM;
c) saturación del STRM.
D.5
Rechazo
El rechazo tiene lugar cuando un usuario del STRM o el propio STRM pueden negar a posteriori el depósito, la recepción o la originación de un mensaje.
Entre las amenazas de rechazo figuran las siguientes:
a) denegación de origen;
b) denegación de depósito;
c) denegación de entrega.
D.6
Fuga de información
Un ente no autorizado puede captar información vigilando las transmisiones o accediendo sin permiso a la información almacenada en alguna entidad del STM o por suplantación. En algunos casos, la presencia en el sistema de un usuario del STRM puede ser un asunto delicado y debe preservarse su anonimato. También es posible que un usuario del STRM distinto del destinatario deseado se haga con un mensaje enviado al segundo. Este podría ser el resultado de la simulación y del mal uso del STRM, o de haber provocado el funcionamiento incorrecto de un ATM. Además, observando el tráfico se pueden obtener otros detalles sobre la información que fluye por un STRM.
Entre las amenazas de fuga de información, figuran las siguientes:
a) pérdida de confidencialidad;
b) pérdida de anonimato;
c) apropiación indebida de mensajes;
d) análisis de tráfico.
D.7
Otras amenazas
En un sistema de seguridad de nivel único o de nivel múltiple, puede haber cierto número de amenazas relativas al etiquetado de seguridad, por ejemplo, el encaminamiento a través de un nodo al que no se le puede confiar información particularmente valiosa o en donde los sistemas utilizan procedimiento de etiquetado diferentes. Pueden existir amenazas a la implantación de una política de seguridad basada en la separación lógica utilizando etiquetas de seguridad. Es posible que un usuario del STRM origine un mensaje y le asigne una etiqueta para la que no está autorizado. Cabe también que un usuario del STRM o un ATM establezcan o acepten una asociación con un contexto de seguridad, para el que no tienen autorización.
Entre las
`otras amenazas'
aludidas en el epígrafe, figuran las
siguientes:
a) originador no autorizado para etiqueta de seguridad de mensajes (depósito inadecuado);
b) usuario del STRM/ATM no autorizado para el contexto;
c) encaminamiento erróneo;
d) procedimientos de etiquetado diferentes.
ANEXO E (a la Recomendación R.402)
Provisión de
servicios de seguridad
en la Recomendación
X.411
Este anexo forma parte de la presente Recomendación.
En el cuadro E-1/X.402 se indica qué elementos de servicio de la Recomendación X.411 pueden utilizarse para facilitar los servicios de seguridad descritos en el 10.2 .
Tableau E-1/X.402, [T14.402] p.
ANEXO F
Diferencias entre la Recomendación del CCITT y la norma
ISO
Este anexo no forma parte de la presente Recomendación.
En él se da una relación de todas las diferencias, excepto las puramente estilísticas, entre esta Recomendación y la correspondiente norma internacional de la ISO.
Entre ambas especificaciones hay las diferencias siguientes:
a) La Norma Internacional de la ISO que corresponde a esta Recomendación muestra la conexión directa de dos DGPR situados en el mismo país, la de dos DGPR situados en países diferentes, y la de un solo DGPR conectado a dos DGAD, lo que no hace esta Recomendación (véase la figura 11/X.402).
b) La Norma Internacional de la ISO que corresponde a esta Recomendación no requiere que los DGAD y los DGPR estén relacionados jerárquicamente para direccionamiento y encaminamiento; mientras que esta Recomendación sí lo requiere (véanse los 14.1.1, 14.1.2, 15 y 19).
c) Cuando un atributo de dirección O/D admite cadenas imprimibles y teletex, la Norma Internacional de la ISO que corresponde a esta Recomendación, no requiere que se proporcione la cadena imprimible, como mínimo, cuando los atributos se estén transportando internacionalmente, mientras que esta Recomendación sí lo requiere (véase el 18.2 ).
ANEXO G
índice
Este anexo no forma parte de la presente
Recomendación.
Este anexo constituye el índice de esta Recomendación. Proporciona los números de los puntos donde se definen los elementos de cada categoría. El tratamiento de cada categoría es exhaustivo.
Este anexo presenta un índice de los elementos (si los hay) en las siguientes categorías:
a) abreviaturas;
b) términos;
c) elementos de información;
d) módulos NSA.1;
e) macros NSA.1;
f) tipos NSA.1;
g) valores NSA.1;
h)
acuerdos bilaterales
i)
elementos que requieren ulterior estudio
;
j)
elementos a preparar
.
G.1
Abreviaturas
A/SYS 13.1.1
AS/SYS 13.1.3
ASG 3.2
AST/SYS 13.1.7
AT/SYS 13.1.5
ATM 7.3.1
AU 7.2.2
C 5.2
CA 3.1.3, 27
COMPUSEC 10
D 5.2
DG 14.1
DGAD 14.1.1
DGPR 14.1.2
EA 3.1.1
ESA 3.1.1, 26
ESAM 26.3.5
ESCA 3.13, 26.4.3
ESDM 26.3.2
ESEM 26.3.3
ESOD 3.1.5, 26.4.1
ESRM 26.3.4
ESTF 3.1.4, 26.4.2
ESTM 26.3.1
ETM 7
EU 3.1.1
F 5.2
IS
ISA 3.1.1
LD 7.1.3
MM 7.2.3
NSA.1 13.1.2
O 5.2
OD 3.1.5
P1 27
P3 27
P7 27
S/SYS 13.1.2
SEF 7.4.1
ST/SYS 13.1.6
STM 7.1.1
STRM 7.2.1
T/SYS 13.1.4
TF 3.1.4
TIC 8.1
UA 7.2.4
UDPA 3.1.1
UAEF 7.4.1
G.2
Términos
afirmación 9.4.9
agente de depósito 9.3.2
agente de entrega 9.3.6
agente de transferencia de mensajes 7.3.1
agente de usuario 7.2.2
almacenamiento de mensajes 6
ampliación de LD 9.4.4
asimétrico 26.2
atributo 18.1
atributo definido por el dominio 18.1
atributo normalizado 18.1
atributos-postales-locales 18.3.6
código postal 18.3.19
combinación 9.4.2
componentes-ampliación-dirección-entrega física 18.3.5
componentes-ampliación-dirección-O/D postal 18.3.4
condicional 5.2
contenido 8.1
conversión 9.4.6
conversión explícita 9.4.6
conversión implícita 9.4.6
defectible 5.2
depósito 9.3.2
depósito directo 9.3.2
depósito indirecto 9.3.2
destinatario 9.2
destinatario alternativo al destinatario asignado 9.2
destinatario alternativo especificado por el originador 9.2
destinatario deseado 9.2
destinatario efectivo 9.2
destinatario indirecto 9.2
destinatario inmediato 9.1
destinatario miembro 9.2
destinatario potencial 9.2
dirección-apartado-correos 18.3.18
dirección-calle 18.3.22
dirección-lista-correos 18.3.20
dirección-postal-no-formatizada 18.3.25
dirección O/D 18.5
dirección O/D numérica 18.3.2
dirección O/D nemotécnica 18.5.1
dirección O/D postal 18.5.3
dirección O/D terminal 18.5.4
dirección-red 18.3.7
división 9.4.1
dominio 14.1
dominio de gestión 14.1
dominio de gestión de administración 14.1.1
dominio de gestión privado 14.1.2
encaminamiento 9.4.10
encaminamiento externo 9.4.10
encanamiento interno 9.4.10
entorno de tratamiento de mensajes 7
entrega 9.3.6
entrega física 7.4.1
ESA consumidor 26.2
ESA suministrador 26.2
EU consumidor 26.2
EU suministrador 26.2
evento 9.1
evento de transmisión 9.1
exportación 9.3.5
recuperación 9.3.7
facultativo 5.2
formatizado 18.5.3
grado 5.2
indentificador terminal 18.3.23
identificador-usuario-numérico 18.3.8
importación 9.3.3
informe 8.3
informe de entrega 8.3
informe de no entrega 8.3
jerarquizado 7.1.3
lista de atributos 18.1
lista de distribución 7.1.3
memoria de mensajes 7.2.3
mensaje 8.1
mensaje descrito 8.2
mensaje físico 7.4.1
mensaje objeto 8.3
miembros 7.1.3
no entrega 9.4.7
no formatizado 18.5.3
no afirmación 9.4.8
nombre-común 18.3.2
nombre-dominio-administración 18.3.1
nombre-dominio-privado 18.3.21
nombre O/D 17.2
nombre-organización 18.3.9
nombre-organización-entrega-física 18.3.16
nombre-país 18.3.3
nombre-país-entrega-física 18.3.13
nombre-personal 18.3.12
nombre-personal-entrega-física 18.3.17
nombre-postal-exclusivo 18.3.26
nombre-servicio-entrega-física 18.3.11
nombre-unidades-organizativas 18.3.10
número-oficina-entrega-física 18.3.14
obligatorio 5.2
origen 9.3.1
originador 9.2
paso de transmisión 9.1
permiso de depósito 7.1.3
punto de ampliación 9.4.4
recepción 9.3.8
redirección 9.4.5
reproducción física 7.4.1
resolución de nombre 9.4.3
simétrico 26.2
sistema de acceso 13.1.1
sistema de acceso y almacenamiento 13.1.3
sistema de acceso, almacenamiento y transferencia 13.1.7
sistema de acceso y transferencia 13.1.5
sistema de almacenamiento 13.1.2
sistema de almacenamiento y transferencia 13.1.6
sistema de entrega física 7.4.1
sistema de mensajería 13.1
sistema de transferencia 13.1.4
sistema de transferencia de mensajes 7.2.1
sistema de tratamiento de mensajes 7.1.1
sonda
sonda objeto 8.3
STM global 15
tipo 18.1
tipo de atributo 18.1
tipo de contenido 8.1
tipo de información codificada 18.1
tipo-terminal 18.3.24
transferencia 9.3.4
transferencia externa 9.3.4
transferencia interna 9.3.4
transferencia de mensajes 6
transmisión 9.1
tratamiento de mensajes 6
unidad de acceso 7.2.4
unidad de acceso de entrega física 7.4.1
usuario 7.1.2
usuario directo 7.1.2
usuario indirecto 7.1.2
valor 18.1
valor de atributo 18.1
(H.T.=OUI)
TAB.???
FICHIER: H.T. =
(87.TA.97.S)
(SANS FORMULES) Tableaux: 23 - Tabulateurs: 0 M NF03/002
(BT..) Disk ... NF../... (OPM = ..)
(87.TE.05.S)
(A1.23s) / [26s]
FOLIOS: 147 - 178 (DO
PRC.COSY.2)
MEP {TPS.NON.PHOTO "[PA1]"} : OK= [1]
Saisie diskettes 575-576 18.08.89 RM/PR
ID + Vérif. + diskette MAJ + laser 26.09.89 PV
Corr. LASER (1re épreuve) = 3eme 16.10.89 GG
Espaces réservés + Transfert + Impr. 25.10.89 JC
AJOUTER (PA1) (CL1,0,0,0) pour MEP
MEP + LASER 30.10.89 GH/PC
Corr. MEP ........ ..
Insertion des tableaux (tabulateurs 2) 31.10.89 PC
BAT du 14/11/89 15.11.89 PV
MAJ s/disquettes 6.12.89 CD
Recomendación X.403
SISTEMAS DE TRATAMIENTO DE MENSAJES:
PRUEBAS DE CONFORMIDAD
(Melbourne, 1988)
El CCITT,
considerando
(a) la necesidad de sistemas de tratamiento de mensajes;
(b) la necesidad de asegurar la interoperabilidad de los sistemas de tratamiento de mensajes;
(c) la necesidad de especificaciones de pruebas de conformidad para los sistemas de tratamiento de mensajes;
(d) que las Recomendaciones de la serie X.400 especifican los sistemas de tratamiento de mensajes;
(e) el estado actual de la metodología de pruebas de ISA y la notación dentro de CCITT-ISO,
recomienda por unanimidad
(1) que la metodología de pruebas para los sistemas de tratamiento de mensajes sea la descrita en esta Recomendación;
(2) que la notación utilizada para definir las especificaciones de pruebas para sistemas de tratamiento de mensajes sea la descrita en esta Recomendación;
(3) que el alcance y contenido de los manuales de especificación de pruebas de conformidad del CCITT para sistemas de tratamiento de mensajes sean los descritos en esta Recomendación.
íNDICE
0
Introducción
1
Objeto y campo de aplicación
2
Referencias
3
Definiciones
4
Abreviaturas
5
Convenios
6
Visión de conjunto
7
Requisitos de conformidad
8
Metodología de pruebas
9
Estructura de las series de pruebas
10
Información que deben suministrar los realizadores
11
Notación de pruebas
12
Procedimientos de evaluación de la conformidad
Anexo A
-Notación de pruebas
Anexo B
-Proformas ECRP de SMIP (P2)
Anexo C
-Proformas ECRP de STRM (P1)
Anexo D
-Proformas ECRP de STF
0 Introducción
Esta Recomendación describe los métodos de prueba, criterios de prueba y notación de prueba que deben utilizarse para las pruebas de conformidad de los sistemas de tratamiento de mensajes basados en las Recomendaciones de la serie X.400 de 1984, complementadas por la guía del realizador de la serie X.400 (versión 5).
1 Objeto y campo de aplicación
Los protocolos de tratamiento de mensajes, en el contexto de la presente Recomendación, se encuentran en las Recomendaciones de la serie X.400 (1984) y en la guía del realizador de la serie X.400 (versión 5).
Sus especificaciones de pruebas abstractas se encuentran en los manuales de especificación de pruebas de conformidad del CCITT asociados con la presente Recomendación:
-Manual de especificación de pruebas de conformidad para SMIP (P2)
-Manual de especificación de pruebas de conformidad para STRM (P1)
-Manual de especificación de pruebas de conformidad para SPF.
Aunque estos manuales se mencionan en la presente Recomendación, no forman parte de ella.
Si bien para el interfuncionamiento es necesario contar con la operación correcta y completa de los protocolos de sesión, transporte y otras capas inferiores, la prueba de estas capas está fuera del alcance de esta Recomendación. Además, las pruebas de conformidad de las Recomendaciones de la serie X.400 deben verificar que el servidor de transferencia fiable (STF) utiliza debidamente las capas inferiores a él.
Las pruebas definidas en este documento se aplican al trabajo entre varios dominios (DGAD a DGAD y DGAD a DGPR). Se relacionan con cualquier ATM o AU en un dominio que acepta comunicaciones con otros dominios.
Las pruebas de conformidad de la semántica y sintaxis de la información de la parte de cuerpo real transmitida en una PARTE DE CUERPO (BODY PART) está fuera del alcance de este documento.
La finalidad de esta Recomendación es reducir al mínimo el tiempo y costo que los fabricantes de realizaciones X.400 y proveedores de servicios X.400 deban emplear para garantizar un alto grado de interoperabilidad de sus equipos. Este propósito se logra con un conjunto de especificaciones de pruebas de conformidad de las Recomendaciones de la serie X.400. El éxito en la ejecución conjunta de las especificaciones de pruebas por dos realizaciones pueden ser aceptado como una evidencia concluyente de la operación completa y correcta de esas realizaciones.
El objeto y finalidad de esta Recomendación es diferente de otras Recomendaciones del CCITT que definen protocolos y servicios de comunicación, tales como las Recomendaciones de la serie X.400 (1984). La finalidad de las Recomendaciones de la serie X.400 es la definición de un sistema de forma inequívoca. Sin embargo, una Recomendación sobre pruebas de conformidad proporciona un subconjunto de pruebas, bien elegidas, de entre un número virtualmente infinito de pruebas, necesarias para garantizar el cumplimiento total de una norma de protocolo. El subconjunto se elige de tal manera que proporcione un alto grado de confianza en que las realizaciones probadas interfuncionarán, a la vez que se toman en cuenta las consideraciones pragmáticas como el tiempo requerido para realizar las pruebas.
Las pruebas de conformidad de normas funcionales están fuera del alcance de la presente Recomendación. Sin embargo, se reconoce que las pruebas de conformidad con las normas funcionales pueden derivarse de estas Recomendaciones y de los manuales de especificación de prueba asociados.
Debe señalarse que la prueba de conformidad de los sistemas de tratamiento de mensajes puede corresponder al marco de los reglamentos nacionales y puede estar sujeta a políticas de prueba de las Administraciones que están fuera del alcance de este documento.
2 Referencias (versión 1984)
Recomendación X.210Convenios relativos a la definición del servicio de capa en la interconexión de sistemas abiertos (ISA).
Recomendación X.400Sistemas de tratamiento de mensajes: modelo de sistemas y elementos de servicio.
Recomendación X.401Sistemas de tratamiento de mensajes: elementos de servicio básicos y facilidades de usuario facultativas.
Recomendación X.408Sistemas de tratamiento de mensajes: reglas de conversión de tipos de información codificada.
Recomendación X.409Sistemas de tratamiento de mensajes: sintaxis y notación de la transferencia de presentación.
Recomendación X.410Sistema de tratamiento de mensajes: operaciones distantes y servidor de transferencia fiable.
Recomendación X.411Sistema de tratamiento de mensajes: capa de transferencia de mensajes.
Recomendación X.420Sistemas de tratamiento de mensajes: capa de agente de usuario del servicio de mensajería interpersonal.
Serie X.400Guía del realizador versión 5
3
Definiciones
3.1
Definiciones de convenios de servicio
Esta Recomendación utiliza los siguientes términos, definidos en la Recomendación X.210, versión 1984:
a)primitiva;
b)petición (primitiva);
c)indicación (primitiva);
d)respuesta (primitiva);
e)confirmación (primitiva).
3.2
Definiciones de tratamiento de mensajes
Esta Recomendación utiliza los siguientes términos, definidos en la Recomendación X.400, versión 1984:
a)dominio de gestión de administración;
b)mensaje interpersonal (Recomendación X.420);
c)mensaje;
d)transferencia de mensajes (Recomendación X.411);
e)originador;
f)dominio de gestión privada;
g)destinatario;
h)usuario.
4
Abreviaturas
En la presente Recomendación se utilizan las siguientes abreviaturas.
DGADDominio de gestión de administración
@PSAPrimitiva de servicio abstracto\
@IDUMétodo de prueba insertada distribuida en una sola capa\
STMSistema de tratamiento de mensajes
SMIPSistema de mensajería interpersonal
@RSPRealización sujeta a pruebas\
@UDPMUnidad de datos del protocolo de mensajes\
TRMTransferencia de mensajes
ATMAgente de transferencia de mensajes
STRMSistema de transferencia de mensajes
P1Protocolo de transferencia de mensajes (Recomendación X.411)
P2Protocolo de mensajería interpersonal (Recomendación X.420)
@PCOPunto de control y observación\
@ECRPEnunciado de conformidad de realización de protocolo\
@ISRPInformación suplementaria de realización de protocolo para pruebas\
@UDPUnidad de datos del protocolo\
DGPRDominio de gestión privado
STFServidor de transferencia fiable
@PASPunto de acceso al servicio\
@PSPParámetro de serie de pruebas\
@NCATNotación combinada tabular y de árbol\
AUAgente de usuario
5
Convenios
No se define ningún convenio para la presente Recomendación.
6 Visión de conjunto
Hay dos tipos de documentos del CCITT relacionados con la prueba de conformidad X.400:
a)la presente Recomendación X.403, titulada
`sistemas de tratamiento de
mensajes: pruebas de conformidad'
;
b)tres manuales de especificaciones de pruebas de conformidad del CCITT conexos, titulados:
-Manual de especificaciones de pruebas de conformidad para SMIP (P2)
-Manual de especificaciones de pruebas de conformidad para STRM (P1)
-Manual de especificaciones de pruebas de conformidad para STF.
La presente Recomendación está destinada a un amplio público. Los manuales están destinados a los realizadores de pruebas y contienen las especificaciones de pruebas detalladas.
6.1
Recomendaciones sobre pruebas de conformidad X.400
Esta Recomendación proporciona la siguiente información:
a)los requisitos de conformidad para las realizaciones X.400;
b)la metodología de prueba;
c)la estructura de las especificaciones de prueba;
d)la información que deben proporcionar los realizadores como prerequisitos de las pruebas de conformidad;
e)la notación de prueba;
f)los procedimientos de evaluación de la conformidad.
6.2
Manuales de especificación de pruebas de conformidad
X.400
Los tres manuales de especificaciones de pruebas de conformidad del CCITT contienen las especificaciones de prueba para SMIP (P2), STRM (P1), STF. Las especificaciones de prueba están escritas en una notación que se expone en términos generales en el 11 . Los manuales de especificaciones de pruebas de conformidad se mencionan en esta Recomendación, pero no forman parte de ella.
Puesto que los manuales contienen especificaciones de prueba detalladas e inequívocas, los usuarios de los manuales deben estar familiarizados con las Recomendaciones de la serie X.400, así como con la metodología de prueba utilizada.
7 Requisitos de conformidad
La finalidad de las especificaciones de prueba de que trata la presente Recomendación es definir pruebas que establezcan un alto grado de confianza en que las diversas capas de protocolo de una realización sometida a prueba son conformes a los requisitos de las Recomendaciones de la serie X.400 (1984).
7.1 Un sistema que pretende ser conforme con el servicio MIP de las Recomendaciones de la serie X.400 tiene que satisfacer correctamente:
-los elementos de servicio MIP básicos definidos en el cuadro 2/X.400;
-las facilidades facultativas de usuario MIP definidas como esenciales en los cuadros 1/X.401 y 2/X.401 (cuando se deba considerar la categorización para generación y recepción);
-las facilidades facultativas de usuario MIP definidas como adicionales en los cuadros 1/X.401 y 2/X.401, que el sistema declare aceptar;
-los requisitos relacionados con el servicio MIP definidos en la versión 5 de la guía del realizador de la serie X.400.
7.2 Un sistema que pretenda ser conforme con el servicio TRM de las Recomendaciones de la serie X.400 debe satisfacer correctamente:
-los elementos de servicio TRM básicos definidos en el cuadro 1/X.400, relacionados con el protocolo STRM (P1);
-las facilidades facultativas de usuario TRM definidas como esenciales en los cuadros 3/X.401 y 4/X.401 y relacionadas con el protocolo STRM (P1);
-las facilidades facultativas de usuario definidas como adicionales en los cuadros 3/X.401 y 4/X.401 y relacionadas con el protocolo STRM (P1), que el sistema declare aceptar;
-los requisitos relacionados con el servicio TRM P1 definidos en la versión 5 de la guía del realizador de la serie X.400.
7.3 El sistema que pretenda ser conforme con el servicio STF de las Recomendaciones de la serie X.400 debe satisfacer correctamente:
-los servicios STF definidos en la Recomendación X.410;
-los requisitos relacionados al servicio STF definidos en la versión 5 de la guía del realizador de la serie X.400.
7.4 La presunta conformidad de una realización con las Recomendaciones de la serie X.400 puede verificarse utilizando los manuales de especificación de pruebas de conformidad de esta Recomendación, para garantizar que:
a)La realización no actúa o reacciona en forma diferente a la descrita en las Recomendaciones.
b)La realización es capaz de tratar los errores de protocolo.
La reacción de una realización al recibir errores de protocolo no está definida en las Recomendaciones de la serie X.400. A los efectos de las pruebas de conformidad, se establece el requisito adicional mínimo de que, en tales casos, la realización continúe operando normalmente.
La ausencia de un elemento de protocolo obligatorio en P2 o P1 se considera como un error de protocolo. Hay que señalar que en un STM realizado, un dominio destinatario puede decidir entregar una UDPM incorrecta. Esto debe ser considerado por el vendedor de equipo como un diseño patentado, y las acciones específicas que se efectúan en estas situaciones son definidas por el vendedor y no están sujetas a conformidad.
c)La realización satisface correctamente los requisitos definidos en la guía del realizador de la serie X.400 en su versión 5.
Las longitudes máximas y el número máximo de apariciones se interpretan de la siguiente manera:
-En el origen: la realización puede admitir sus valores máximos hasta, pero sin exceder, el valor impuesto.
-En el destino: la realización debe admitir los valores máximos impuestos. Puede aceptar valores superiores a los establecidos, pero los requisitos de conformidad exigidos a la realización en caso de recepción de una longitud/ocurrencia que sobrepasa el valor impuesto son los mismos que para los errores de protocolo.
La conformidad a las Recomendaciones de la serie X.400 no puede verificarse en el caso de las realizaciones para las cuales no es posible efectuar todas las pruebas necesarias con respecto a las características clasificadas como obligatorias, básicas o esenciales facultativas.
8 Metodología de pruebas
8.1
Configuraciones de prueba
Se utilizan dos configuraciones de pruebas. La primera se muestra en la figura 1/X.403 y se utiliza para probar SMIP (P2), STRM (P1) y STF.
Figure 1/X.403, (N), p.
La segunda configuración se muestra en la figura 2/X.403 y se utiliza para
probar los aspectos del relevador de protocolo STRM (P1).
Figure 2/X.403, (N), p.
8.2
Puntos de control y observación
Los casos de prueba se describen en forma abstracta en términos de sucesos en los puntos de control y observación (PCO), tanto en el probador como en la realización sometida a prueba (RSP). Generalmente, estos PCO son puntos de acceso al servicio (PAS) y los sucesos generalmente son primitivas de servicio abstracto (PSA). Esto no significa que los fabricantes deban tener PAS a las que se pueda tener acceso, o realizar PSA dentro de sus sistemas. Durante la ejecución de la prueba se puede acceder a los PCO de una RSP en forma indirecta a través de un interfaz de usuario. Cuando la prueba se realiza a través de un interfaz de usuario, la relación de correspondencia de los sucesos entre el PAS y el interfaz de usuario es proporcionada por el proveedor de la RSP, como se describe en el 10.2 .
8.2.1
PCO para SMIP (P2)
Los casos de prueba SMIP (P2) se describen utilizando los puntos de control y observación (PCO) que aparecen en la figura 3/X.403.
Figure 3/X.403, (N), p.
Para el probador, el punto de control y de observación es el punto de acceso
de servicio (PAS) definido en el límite entre la capa de agente de usuario y la
capa de transferencia de mensaje. Este PCO utiliza las primitivas del servicio
de capa de transferencia de mensaje definidas en la Recomendación X.411.
Para la RSP, el PCO es el PAS definido en el límite superior de la capa de agente de usuario. Sin embargo, la Recomendación X.420 no incluye una definición de primitivas de servicio y por lo tanto ha sido necesario establecer primitivas de servicio ficticias para el envío y recepción de mensajes IP, a fin de poder describir formalmente los casos de prueba.
8.2.2
PCO para STRM (P1)
Los casos de prueba STRM (P1) se describen utilizando los PCO que aparecen en la figura 4/X.403.
Figure 4/X.403, (N), p.
Para el probador, el PCO es el PAS definido en el límite entre la capa TRM y
el STF. Este PCO utiliza las primitivas STF definidas en la Recomendación
X.410.
Para las RSP, el PCO es el PAS definido en el límite entre la capa AU y la capa TRM. Este PCO utiliza las primitivas de servicio TRM definidas en la Recomendación X.411.
La prueba de las funciones de relevo requiere más de un PAS probador. Igualmente la prueba de la entrega a destinos múltiples requiere más de un AU en la RSP.
8.2.3
PCO para STF
Los casos de prueba STF se describen utilizando los PCO que aparecen en la figura 5/X.403.
Para el probador, el PCO es el PAS definido en el límite entre el STF y la capa de sesión. Este PCO utiliza las primitivas de servicio de sesión definidas en la Recomendación X.215.
Para la RSP, el PCO es el PAS definido en el límite superior de la capa de agente de usuario. Este PCO utiliza las mismas primitivas de servicio ficticias definidas para SMIP (P2) ( 8.2.1 ).
La descripción de los casos de prueba STF incluye sucesos en un tercer PAS en la RSP (PAS-I) entre la capa TRM y el STF. Los sucesos de este PAS se utilizan únicamente para aclaración y el mismo no sirve de PCO.
Figure 5/X.403, (N), p.
8.3
Estrategia de diseño de pruebas
Las especificaciones de prueba STM están diseñadas con arreglo a los siguientes conceptos:
a)Una especificación de prueba se define como una serie de pruebas compuestas de un número de casos de prueba, tal como se definen en el 11.1 .
b)Los casos de pruebas se definen en términos de:
-eventos PSA de capa inferior en el probador;
-eventos PSA capa superior en la RSP.
c)Los casos de prueba definen la secuencia de estos sucesos PSA y los parámetros asociados, en especial las UDP.
d)Los casos de prueba para comportamiento válido especifican secuencias de sucesos PSA y UDP que concuerdan con las Recomendaciones de la serie X.400.
e)Los casos de prueba para comportamiento no válido se caracterizan por:
-un evento o UDP correcto iniciado por el probador en un estado de protocolo donde no está permitido (un suceso inoportuno), o
-una UDP correcta que incorpora un elemento sintácticamente correcto y dentro de la gama, pero que está en conflicto con el valor negociado, o
-una UDP enviada por el probador y sintácticamente incorrecta (por ejemplo, falta el elemento de protocolo obligatorio, un valor fuera de gama o un indicador de longitud codificado en forma incorrecta), o
-para un STF un evento PSA de capa inferior emitido por el probador utilizado, con parámetros no permitidos o no adecuados (ejemplo: SPSN en SConnect) según las restricciones de la Recomendación X.400.
f)La extensión de la prueba se limita a un número razonable de casos de prueba aplicando los siguientes principios:
1)Para comportamiento válido:
-Si hay un número pequeño de valores de elemento de protocolo válidos, hay que probarlos todos. -Si hay una gama de valores, hay que probar los extremos y algunos de los valores comunes. -Si no hay límites, hay que probar un valor extremo más allá de los valores comunes.
2)Para no válido:
-El número de casos de prueba para un tipo de error especial se reduce a uno o a unos cuantos comunes.
8.3.1
Estrategia de las pruebas X.409
Los casos de prueba de la Recomendación X.409 definidos en los manuales de especificaciones de pruebas de conformidad del CCITT asociados con esta Recomendación son aplicables únicamente a los sistemas de tratamiento de mensajes de las Recomendaciones de la serie X.400. La prueba de X.409 se realiza como parte de las pruebas de STRM (P1), SMIP (P2), y STF. Las características sometidas a prueba son los tipos de datos definidos en la Recomendación X.409, las diversas formas de codificación de longitud y el uso de primitivas y elementos de datos constructores. Para aumentar la posibilidad de realizar las pruebas, los casos de prueba, siempre que sea posible, han sido elegidos utilizando los elementos de protocolo asociados con elementos de servicio obligatorio.
Se identifican dos categorías de pruebas X.409:
-
Pruebas de decodificación
Estas pruebas se establecen identificando las características de la Recomendación X.409 que deben aplicarse y fijando conjuntos de UDP de prueba codificados correcta e incorrectamente y que tengan dichas características. Las pruebas se realizan transmitiendo los UDP de prueba a la RSP y observando la reacción local de la realización y/o cualquier UDP resultante devuelta al probador.
-
Pruebas de codificación
Estas pruebas se establecen identificando un conjunto de peticiones de servicio de usuario que puedan generar UDP cuya codificación aplique las principales características de la Recomendación X.409. El probador debe verificar la validez de los códigos de las UDP resultantes generadas por la RSP.
Las pruebas de decodificación permiten que las características de decodificación de una realización según la Recomendación X.409 se ejerzan plenamente utilizando UDP de prueba válidas e inválidas. Las pruebas de codificación permiten únicamente la verificación de la conducta válida de la codificación de acuerdo con la Recomendación X.409.
8.3.2
Estrategia para la prueba de SMIP (P2)
Se identifica dos categorías de pruebas:
-RSP como originador;
-RSP como destinatario.
Con la RSP como originador, para cada elemento de servicio aceptado por la realización se realizan pruebas:
-invocando el servicio;
-haciendo que el probador verifique la validez de las UDP resultantes;
-haciendo que el probador, según el caso, retorne UDP de respuesta válidas e inválidas al originador.
Con la RSP como destinatario, para cada elemento de servicio se realizan pruebas:
-haciendo que el probador envíe UDP válidas e inválidas para dicho servicio;
-observando la reacción local del AU;
-verificando la validez de cualquier UDP adicional generada por el AU.
Para evitar una duplicación innecesaria de casos de prueba, los elementos del servicio MIP que también sean elementos de servicio TRM (por ejemplo la notificación de entrega) se enumeran dentro de la serie de pruebas STRM (P1) conjuntamente con los elementos de servicio TRM correspondientes, y no dentro de la serie de pruebas SMIP (P2).
Se supone que la prueba de la capa TRM se realiza a través de un agente de usuario.
8.3.3
Estrategia para la prueba de STRM (P1)
Cuando se prueba el funcionamiento de una realización STRM (P1) se identifican cinco categorías de pruebas:
-RSP como originador;
-RSP como destinatario;
-RSP como relevador;
-RSP como destinatario de relevador;
-RSP como destinatario/originador.
Con la RSP como originador, para cada elemento del servicio aceptado por la realización, se realizan las pruebas:
-invocando el servicio;
-verificando la validez de las UDP resultantes.
Con la RSP como destinatario, para cada elemento de servicio admitido por la realización, se realizan las pruebas:
-haciendo que el probador envíe UDP válidas e inválidas a dicho servicio;
-observando la reacción local del AU;
-verificando la validez de cualquier UDP adicional generada por el AU.
Con la RSP como relevador, para cada elemento de servicio se realizan las pruebas:
-haciendo que el probador envíe UDP válidas e inválidas para relevo;
-verificando la validez de la reacción de la RSP.
Con la RSP como destinatario de relevador, para cada elemento de servicio se realizan las pruebas:
-enviando un conjunto de UDP válidas e inválidas dirigidas a más de un destinatario. Al menos, uno de estos destinatarios estará unido a la RSP y los destinatarios adicionales estarán unidos a un ATM a distancia, de tal menera que la RSP pueda enviar el mensaje por relevo;
-verificando la validez de la reacción de la RSP como destinatario;
-verificando que las UDP que son transmitidas por relevo no estén adulteradas y que sean modificadas en forma adecuada.
Con la RSP como destinatario/originador, para cada elemento de servicio aceptado por la realización, se realizan las pruebas:
-invocando a la RSP para que envíe un mensaje a múltiples destinatarios. Al menos, uno de los destinatarios estará unido a la RSP y un destinatario adicional estará unido a un ATM a distancia;
-verificando la validez de la reacción de la RSP como destinatario;
-verificando la validez de las UDP transmitidas por la RSP.
8.3.4
Estrategia para la prueba de STF
Se utilizan las siguientes fases de prueba:
a)
Fase de negociación y establecimiento de
conexión/asociación
La Recomendación X.410 permite diferentes opciones negociables y la fase de negociación se prueba en forma exhaustiva utilizando elementos válidos e inválidos.
b)
Liberación ordenada de la conexión/asociación
Sólo se requieren unas cuentas pruebas para verificar la realización correcta de las características de liberación del STF.
c)
Fase de transferencia de datos con intercambio de
testigos
Las pruebas de transferencia de datos verifican:
-la operación correcta de la transferencia de datos utilizando los valores negociados;
-la operación correcta del intercambio de testigos;
-la confirmación correcta de servicios confirmados;
-la reacción correcta a elementos inválidos (por ejemplo, no negociados).
d)
Recuperación
Se realizan pruebas para verificar que una RSP puede realizar la recuperación correcta después de:
-aborto iniciado por el usuario;
-aborto iniciado por el proveedor;
-informes de excepción;
-puntos de verificación no reconocidos.
9 Estructura de las series de pruebas
Las series de pruebas SMIP (P2) y STRM (P1) tienen una estructura común, diferente de las series de pruebas STF.
9.1
Estructura de las series de pruebas SMIP (P2) y STRM
(P1)
Las series de pruebas SMIP (P2) Y STRM (P1) están formadas por cinco grupos de casos de prueba:
a)
Pruebas iniciales
Las pruebas iniciales verifican las características obligatorias en un pequeño número de casos de prueba. Han sido definidas para verificar que la realización admite correctamente las principales características obligatorias y que es capaz de continuar con todas las pruebas de conformidad.
b)
Pruebas X.409
Las pruebas X.409 verifican la codificación y decodificación de los elementos de protocolo realizada por la RSP. Las pruebas de decodificación se realizan transmitiendo UDP de prueba a la RSP. Las pruebas de codificación se realizan verificando las UDP recibidas de la RSP.
c)
Pruebas del elemento de protocolo
Las pruebas del elemento de protocolo identifican las finalidades de prueba para cada elemento de protocolo en los protocolos SMIP (P2)/STRM (P1). Esto es importante para garantizar una cobertura de pruebas completa para los protocolos SMIP (P2)/STRM (P1). Muchas de estas pruebas son realizadas necesariamente como parte de las pruebas del elemento de servicio.
d)
Pruebas del elemento de servicio
Las pruebas del elemento de servicio verifican la capacidad de la RSP de admitir los elementos de servicio de la Recomendación X.400. Algunas de estas pruebas son realizadas durante las pruebas iniciales y las pruebas de la Recomendación X.409. Las pruebas del elemento de servicio incluyen pruebas para elementos de servicio específicos y pruebas para combinaciones de elementos de servicio interdependientes.
e)
Prueba adicional
El grupo de prueba adicional verifica las características no incluidas en los otros grupos de pruebas.
Como se indica en los anteriores apartados a) a e), el número de casos de prueba ha sido reducido al mínimo aprovechando el hecho de que el funcionamiento de un caso de prueba dado puede abarcar más de un objetivo de prueba. La figura 6/X.403 muestra cómo algunos de los objetivos de prueba identificados en un grupo de prueba específico pueden lograrse por medio de casos de prueba de otro grupo.
Figure 6/X.403, (N), p.
9.2
Estructura de la serie de pruebas STF
La serie de pruebas STF está formada de cinco grupos de casos de prueba:
-pruebas del establecimiento de asociación;
-pruebas de liberación de asociación;
-pruebas de transferencia de datos;
-pruebas de recuperación de asociación;
-pruebas X.409.
Las pruebas del establecimiento de asociación verifican la negociación de los elementos de conexión.
Las pruebas de liberación de asociación verifican la liberación ordenada de las asociaciones.
Las pruebas de transferencia de datos verifican que los datos sean transferidos correctamente y de acuerdo con los valores de los elementos de conexión negociados durante el establecimiento de la asociación.
Las pruebas de recuperación de asociación verifican que la RSP pueda recuperarse de las interrupciones de conexión, en actividades internas y externas.
Las pruebas de la Recomendación X.409 verifican la codificación y decodificación por la RSP de los datos de usuario de servicio de sesión.
10 Información que deben suministrar los
realizadores
10.1
Enunciado de conformidad de realización de
protocolo (ECRP)
El enunciado de conformidad de realización de protocolo (ECRP), es una información suministrada por un realizador, que especifica las características de protocolo establecidas en un sistema de tratamiento de mensajes.
Esta información se utiliza durante las pruebas de conformidad:
-para verificar que las características de protocolo que han sido establecidas sean congruentes con los requisitos de conformidad, en términos de las características obligatorias y facultativas de las Recomendaciones de la serie X.400;
-para seleccionar las pruebas de originador que se realizarán. Las pruebas de destinatario y de relevo se realizarán para verificar el comportamiento del sistema, incluso cuando se le pide que maneje características que no realiza.
En los anexos B, C y D se muestran las proformas de ECRP para SMIP (P2), STRM (P1) y STF. Estas proformas especifican la información que debe suministrar un realizador respecto a:
-los servicios aceptados para las funciones de origen, recepción y relevo;
-las características de protocolo que han sido establecidas para admitir dichos servicios.
El ECRP de SMIP (P2) incluye explícitamente elementos de servicio STRM (P1) puestos a disposición por el SMIP (P2). Para evitar duplicación con la serie de pruebas (STRM (P1), las pruebas de los elementos de servicios STRM (P1) no están incluidas en la serie de pruebas SMIP (P2). Cuando la prueba de STRM (P1) se realiza sin utilizar un AU, puede ser necesario repetir las pruebas de STRM (P1) utilizando un AU para poder asegurar la conformidad con el SMIP (P2).
10.2
Información suplementaria de realización de protocolo
para pruebas (ISRP)
La información suplementaria de realización de protocolo para pruebas (ISRP) es suministrada por un realizador, especificando la información que necesita el probador para realizar una serie de pruebas.
Las series de pruebas de SMIP (P2), STRM (P1) y STF definen el comportamiento de la realización en términos de primitivas de servicio abstracto. Para poder invocar y observar este comportamiento durante la ejecución de las pruebas, el operador de las pruebas debe conocer cómo estas primitivas de servicio abstracto (si las hay) pueden invocarse u observarse en el interfaz de usuario accesible real.
Las proformas ECRP de SMIP (P2), STRM (P1) y STF enumeran todas las primitivas de servicio abstracto de capa superior de la RSP utilizadas en las definiciones de pruebas y requerirán que el realizador especifique cómo se pueden invocar u observar estas primitivas (si las hay).
11 Notación de pruebas
11.1
Definiciones
La notación utilizada para expresar las especificaciones de prueba STM utiliza las siguientes definiciones:
a)@
serie de pruebas
@
\Conjunto de casos de prueba, posiblemente combinados dentro de grupos de prueba jerarquizados, necesarios para realizar las pruebas de conformidad de una realización.
Las series de pruebas no implican una orden de ejecución.\
b)@
grupo de pruebas
@
\Conjunto de casos de prueba relacionados. Los grupos de pruebas pueden estar jerarquizados para proporcionar una estructura lógica de los casos de prueba.\
c)@
caso de pruebas
@
\Especifica la secuencia de los eventos de prueba necesarios para lograr el
propósito de la prueba y asignar un veredicto de
`favorable'
,
`desfavorable'
o
`dudoso'
.\
d)@
evento de prueba
@
\Unidad indivisible de especificación de prueba a nivel de abstracción de la especificación (por ejemplo, envío o recepción de una sola UDP).\
e)@
usuario
@
\Proceso de interfaz de usuario o aplicación de computador que utiliza un STM.\
11.2
Notación
Las series de pruebas de conformidad para los sistemas de tratamiento de mensajes utilizan la notación combinada tabular y de árbol descrita en el anexo A de la presente Recomendación.
Cada especificación de serie de prueba está formada de seis secciones:
1)
Introducción
Contiene una descripción general del objeto de las pruebas y de la estructura de la serie de pruebas.
2)
Resumen de casos de pruebas
Es una lista de todas las pruebas, indicando el identificador de prueba, la referencia de la prueba y un título breve para cada uno de los casos de prueba de la serie de pruebas.
3)
Parte declaraciones
Declara los nombres y tipos de todos los elementos que serán utilizados en la definición de los casos de pruebas.
4)
Parte dinámica
Este es el cuerpo principal de la serie de pruebas y define los casos de prueba en términos de árboles de comportamiento.
5)
Parte limitaciones
Especifica los valores de las PSA y UDP utilizadas en la parte dinámica.
6)
Referencias recíprocas
Proporciona un índice de todos los valores utilizados en el cuerpo principal de la serie de pruebas.
12
Procedimientos de evaluación de
la conformidad
Esta Recomendación trata únicamente de las especificaciones de pruebas abstractas para los sistemas de tratamiento de mensajes. No trata de la realización de estas especificaciones de prueba ni de su ejecución. Este apartado de las Recomendaciones tiene únicamente propósitos informativos, para describir, en términos generales, cómo pueden realizarse las pruebas reales.
12.1
Visión de conjunto del procedimiento
Los procedimientos necesarios para evaluar la conformidad de una realización comprenden:
-la cumplimentación de proformas ISRP y ECRP por el proveedor de la realización;
-la evaluación de estos documentos;
-la selección y ejecución de casos de prueba;
-el análisis de los resultados y la producción de informes de prueba.
12.2
Análisis del ECRP
La primera fase en la evaluación de la conformidad es garantizar que las características anunciadas como aceptadas por una RSP, satisfagan los requisitos de conformidad correspondientes. Los requisitos de conformidad para las realizaciones SMIP (P2), STRM (P1) y STF están definidos en el 7 de esta Recomendación. Esta verificación se realiza analizando la información contenida en los documentos del ECRP.
12.3
Selección de caso de prueba
Las pruebas que deben realizarse se seleccionan principalmente sobre la base de la información contenida en los ECRP. Para cada característica aceptada, en los ECRP, se seleccionan los casos de prueba correspondientes entre las series de prueba y se ejecutan para verificar la correcta realización de estas características en una extensa gama de condiciones válidas e inválidas.
Para características no aceptadas, se ejecutarán algunos casos de prueba de destinatario para explorar las respuestas de la RSP. Puesto que en general las Recomendaciones de la serie X.400 (1984) no definen la conducta que se espera en estas situaciones, estas pruebas se pueden superar con casi cualquier comportamiento, excepto fallo catastrófico de la RSP.
La información contenida en el ISRP también puede indicar ciertas limitaciones sobre los casos de prueba que se pueden ejecutar.
12.4
Ejecución de las pruebas
Se recomienda que las pruebas de los sistemas de tratamiento de mensajes se lleven a cabo en el siguiente orden: primero STF, después STRM (P1), y finalmente SMIP (P2).
Sin embargo, el orden de los casos de prueba dentro de las series de prueba no implica un orden de ejecución. Con independencia de la Recomendación general de que se ejecute primero el grupo de pruebas inicial de SMIP (P2)/STRM (P1), el orden de ejecución de las pruebas puede ser determinado por los operadores de prueba, teniendo en cuenta el entorno de la prueba y los instrumentos de prueba.
Figure 7/X.403, (N), p.
ANEXO A (a la Recomendación X.403)
Notación de pruebas
A.1
Introducción
Este anexo forma parte integrante de la Recomendación y describe la notación utilizada en los manuales y series de prueba.
La notación de prueba que se describe se basa en la notación de prueba denominada notación combinada tabular y de árbol (NCTA) que ha sido desarrollada conjuntamente por la ISO y el CCITT.
La notación descrita en esta Recomendación se deriva de una forma inicial de NCTA y ha sido desarrollada específicamente para las especificaciones de pruebas de conformidad de los STM.
Cada una de las series de pruebas STM se especifica en cinco partes:
-parte declaración;
-parte dinámica;
-parte limitaciones;
-identificación de caso de prueba;
-referencias recíprocas.
A.2
Parte declaración
La parte declaración declara el entorno y los objetos utilizados en las series de prueba y está compuesta de siete secciones:
-configuraciones de prueba;
-parámetros de la serie de pruebas (PSP);
-puntos de acceso al servicio (PAS);
-primitivas de servicio abstracto (PSA);
-unidades de datos de protocolo (UDP);
-temporizadores;
-abreviaturas.
A.2.1
Configuraciones de prueba
En esta sección se enuncian los puntos de control y observación.
A.2.2
Parámetros de la serie de pruebas
Cada serie de pruebas STM tiene un conjunto de parámetros cuyos valores se fijan antes de hacer la prueba y se utilizan para definir un entorno de prueba específico.
Los PSP se presentan en forma tabular tal como se muestra en la figura A-1/X403.
Figure A-1/X.403 (traité comme tableau) [T1.403], p.
Por convenio, el nombre de cada parámetro de la serie de pruebas de la serie
de prueba STM tiene la forma:
PSP$$-&lab;nombre>
A.2.3
Puntos de acceso al servicio
(PAS)
Los puntos de acceso al servicio se utilizan como puntos de control y observación en las series de prueba STM y se presentan en forma tabular como se indica en la figura A-2/X.403.
Figure A-2/X.403 (traité comme tableau) [T2.403], p.
Por convenio, el nombre de un PAS en la serie de prueba STM es generalmente
una letra mayúscula, como T, U, V (para PAS del probador) o I, J, K (para PAS
de la RSP).
A.2.4
Primitivas de servicio abstracto
Cada tipo de PSA y sus parámetros asociados utilizados en la serie de pruebas se presentan en forma tabular como se indica en la figura A-3/X.403.
Figure A-3/X.403 (traité comme tableau) [T3.403], p.
El nombre de la PAS se anota en el campo
`PAS'
y se deriva del nombre
correspondiente en las Recomendaciones de la serie X.400. El PAS en la que se
presenta la PSA se anota en la columna
`NOMBRE'
, junto con la
información en las
`Condiciones/Obligatorio'
(C/O).
Puesto que las Recomendaciones no definen PSA de SMIP (P2), para describir las pruebas de conformidad ha sido necesario establecer PSA ficticias en el límite superior de la capa de agente de usuario. Sin embargo, esto no implica que los fabricantes deban establecer estos PSA en sus sistemas. únicamente sirven para formalizar los requisitos de observación e invocación de los elementos del servicio de SMIP utilizando estas nuevas PSA. La relación entre los elementos de servicio SMIP y la conducta real de la RCP debe especificarse en el ECRP, de acuerdo con la realización.
A.2.5
Unidades de datos de protocolo
Los tipos de UDP utilizadas en la serie de pruebas se presentan en forma tabular, como se muestra en la figura A-4/X.403. Estas UDP no están definidas explícitamente en las series de pruebas, sino que se presentan como una referencia exacta a la definición completa en las Recomendaciones de la serie X.400, dentro de la sección de tipo del cuadro.
Figure A-4/X.403 (traité comme tableau) [T4.403], p.
A.2.6
Temporizadores
Esta sección indica los temporizadores que deben utilizarse. Los valores de temporizador son expresiones en términos de parámetros de series de prueba, y son fijos para la totalidad de las series de prueba. Los valores del temporizador se enuncian en forma tabular, como se indica en la figura A-5/X.403.
Figure A-5/X.403 (traité comme tableau) [T5.403], p.
A.2.7
Abreviaturas
Las abreviaturas utilizadas en la serie de prueba se definen en forma tabular como se indica en la figura A-6/X.403.
Figure A-6/X.403 (traité comme tableau) [T6.403], p.
A.3
Parte dinámica
La parte dinámica define los casos de prueba de una serie de pruebas en forma de árboles de comportamiento.
Los Î A.3.1 y A.3.2 describen, en términos generales, cómo se definen los árboles de comportamiento.
El Î A.3.3 describe el contenido y uso de la biblioteca por defecto.
El Î A.3.4 describe el contenido y uso de la biblioteca de paso de prueba.
El Î A.3.5 describe cómo se especifica cada caso de prueba en el cuerpo principal de una serie de pruebas.
A.3.1
Cuadro proforma de comportamientos de prueba
^
(véase la figura A-7/X.403)
Figure A-7/X.403 (traité comme tableau) [T7.403], p.
&lab;título> COMPORTAMIENTO:
Título del comportamiento: POR DEFECTO para la biblioteca por defecto; DINáMICO para la biblioteca de paso de prueba y casos de prueba.
IDENTIFICADOR:
Proporciona un identificador único para la descripción de comportamiento.
POR DEFECTO:
Enumera los identificadores de las descripciones de comportamiento por
defecto que deben utilizarse junto con el comportamiento dinámico que aparece
en la parte
`DESCRIPCIóN DE COMPORTAMIENTO'
.
DESCRIPCIóN DE COMPORTAMIENTO:
Se define el comportamiento de la prueba utilizando una notación de árbol tal como se describe en el Î A.3.2.
ETIQUETA:
La columna ETIQUETA puede utilizarse para identificar sucesos. Las ramas
entre los sucesos (es decir,
`GO TO'
) se especifican por
`Etiqueta
'
en el árbol de comportamiento.
REFERENCIA DE LIMITACIONES:
Para cada comportamiento de la PSA de la línea del árbol de comportamiento, esta columna proporciona la referencia del valor específico PSA definido en la parte de limitaciones.
COMENTARIOS:
Esta columna permite los comentarios que facilitan la comprensión de los
eventos. Los comentarios adicionales pueden proporcionarse en la zona de
`comentarios ampliados'
. Esta columna también puede utilizarse para
identificar UDP de prueba asociadas con los eventos de prueba.
RESULTADO:
Esta columna indica qué eventos de prueba generan veredictos de prueba. Los valores de los veredictos de prueba son:
-Favorable: No se detectó ningún error de comportamiento en la RSP.
-Desfavorable: Se detectó un comportamiento falso en la RSP.
-Dudoso: El comportamiento observado no permite la asignación de un veredicto de aprobado o fallado.
A.3.2
Notación de árbol para comportamiento de prueba
Los árboles de comportamiento se definen en términos de eventos que, generalmente, tienen la forma:
&lab;PAS>!&lab;evento>
o la forma:
&lab;PAS>?&lab;evento>
El &lab;PAS> es el punto de control y observación en el cual ocurre el &lab;evento>. Los PAS utilizados son los mencionados en la parte declaración.
El símbolo
`!'
indica que el evento fue enviado desde el PAS y
`?'
indica que el evento es recibido en el PAS.
El &lab;evento> puede ser:
-un evento PSA;
-un evento temporizador;
-un seudoevento OTHERWISE (DEOTRAFORMA).
A.3.2.1
Eventos PSA únicos
Si el &lab;evento> es un evento PSA, los nombres de las PSA están especificados en la parte de declaración (el valor se especifica como una referencia en la columna REFERENCIA DE LIMITACIONES).
Renglón de ejemplo para un evento PSA
:
I?DELind
Esto significa que se recibió una indicación de entrega en el PAS de la RSP I.
A.3.2.2
Eventos de temporizador únicos
Si el &lab;evento> es un evento temporizador, estará en la forma de:
&lab;operación> &lab;parámetro>
La operación de
`arranque'
puede tomar una de dos formas:
Arranque &lab;tipo de temporizador>
Arranque (&lab;tipo de temporizador>, &lab;identificación del temporizador>)
donde &lab;tipo de temporizador> se define en la parte de declaración y tiene un valor fijo asociado, definido en términos de PSP. La &lab;identificación del temporizador> permite unir un nombre a un caso de tipo de temporizador.
Las otras operaciones son:
-Cancelar: cancela un temporizador en marcha o suspendido;
-Suspender: suspende un temporizador en marcha;
-Reiniciar: reinicia un temporizador suspendido;
-Temporización: expiración de un temporizador en marcha.
Estas operaciones pueden tomar una de dos formas:
&lab;operación> &lab;tipo de temporizador>
&lab;operación> &lab;identificador de temporizador>
donde &lab;operación> designa la operación. Cuando un temporizador fue
arrancado utilizando la forma
`arranque &lab;tipo de temporizador>'
,
se debe utilizar la forma
`&lab;operación> &lab;tipo de
temporizador>'
; cuando se arrancó el temporizador utilizando la forma
`arranque &lab;identificador del temporizador>'
, debe utilizarse la
forma
`&lab;operación> &lab;identificador del temporizador>'
.
Ejemplo:
I!Arranque T/I-temporizador$$-1
significa que en el PAS de la RSP I se arrancó el T/I-temporizador$$-1 (por ejemplo para el tiempo de transmisión necesario para transferir un UDPAU desde el probador hasta el usuario de la RSP).
I?Temporización T/I-temporizador$$-1
significa que se recibió en el PAS de la RSP la temporización del temporizador mencionado.
A.3.2.3
Eventos OTHERWISE únicos
Si el &lab;evento> es un seudoevento OTHERWISE, esto indica un evento no especificado.
Ejemplo:
T?OTHERWISE
significa que en el PAS T del probador se recibió un evento no especificado.
A.3.2.4
árboles de comportamiento
Los árboles de comportamiento combinan eventos en dos formas:
-como secuencias de eventos;
-como sucesos alternativos.
Los dos tipos de combinaciones se diferencian por su respectiva alineación vertical y de sangrado.
Ejemplo de una secuencia de eventos:
I!SUBreq II?SUBcon I!T?TRNind
Esto significa que el PAS I envía primero una petición de depósito, después el mismo PAS recibe una confirmación de depósito, tras de lo cual el PAS T del probador recibe una indicación de transferencia.
Ejemplo de eventos alternativos:
T?DELind T?Temporización I/T-temporizador
Esto significa que el PAS T recibió una indicación de entrega, o bien recibió la temporización.
Para constituir un árbol de comportamiento complejo, se pueden mezclar los dos tipos de combinaciones.
Ejemplo:
I!SUBreq II?SUBconÄ Å eventos alternativos I!T?TRNind Æ T?DISind
Esto significa que después de enviar I una petición de depósito se recibió en I una confirmación de depósito, seguida por la recepción en T de una indicación de transferencia, o se recibió en T una indicación de desconexión.
A.3.3
Biblioteca por defecto
Los comportamientos por defecto generales que se utilizan en varios casos de prueba se definen en la biblioteca por defecto utilizando el formato que se muestra en la figura A-8/X.403. El nombre del defecto tiene la siguiente forma:
BIB$$-&lab;nombre>
o
BIB$$-&lab;nombre> [X]
donde X reserva un lugar que es reemplazado por un PAS real cuando el elemento por defecto se aplica a un caso de prueba individual.
Nota
- Cuando el comportamiento por defecto individual
se aplica a un solo caso de prueba, la tabla de comportamiento está asociada
con dicho caso de prueba y el identificador no lleva el prefijo
`BIB$$-'
.
Figure A-8/X.403 (traité comme tableau) [T8.403], p.
A.3.4
Biblioteca de paso de prueba
Cuando se utiliza una secuencia de pasos de prueba en varios casos de prueba, pueden incluirse en la biblioteca de pasos de prueba y reciben un nombre en la forma siguiente:
BIB$$-&lab;nombre>
Nota
- Cuando un paso de prueba se aplica a un solo
caso de prueba la tabla de comportamiento está asociada a dicho caso de prueba
y el identificador no lleva el prefijo
`BIB'
$$-.
A.3.5
Caso de prueba
(véase la figura A-10/X.403)
Cada caso de prueba del cuerpo principal de la serie de prueba se describe en términos de tres encabezamientos [a) a c)], y un árbol de comportamiento [d)].
a)
Referencia de prueba e identificador de
prueba
Estos elementos dan una referencia e identificador únicos para cada caso de prueba y se describen en su totalidad en el Î A.5.
b)
Resumen
Proporciona una breve descripción general de la finalidad de la prueba.
c)
Descripción de la prueba (facultativa)
Proporciona una descripción oficiosa de las acciones y eventos que deben realizarse durante la prueba, así como los criterios oficiosos para el veredicto.
d)
árbol de comportamiento
El comportamiento dinámico se describe utilizando la notación de árbol definida en el Î A.3.2.
Figure A-9/X.403 (traité comme tableau) [T9.403], p.
Figure A-10/X.403 (traité comme tableau) [T10.403], p.
A.4
Parte de limitaciones
La parte de limitaciones de una serie de pruebas especifica los valores y codificación para todos los casos de PSA, UDP de prueba, UDP de base y componentes de la biblioteca. La parte de limitaciones está dividida en las siguientes secciones:
- introducción a la parte de limitaciones;
- limitaciones PSA;
- limitaciones UDP de prueba;
- limitaciones UDP de base;
- biblioteca de componentes.
Figure A-11/X.403, (N), p.
A.4.1
Limitaciones PSA
Los valores de las PSA se definen como casos específicos de un PSA genérico.
A.4.1.1
Especificación de una
PSA
`genérica'
Una PSA genérica se define utilizando el formato que aparece en la figura A-12/X.403.
La columna
`CAMPOS'
se utiliza para enumerar todos los parámetros de
la PSA.
La columna
`VALOR o REFERENCIA'
se utiliza para especificar un valor
para cada parámetro, lo cual puede hacerse de cuatro formas:
a) como referencia que puede ser un nombre PSP o un nombre de componente de biblioteca;
b) como un valor explícito;
c) como
`-'
para indicar que este parámetro puede omitirse
en casos específicos de esta PSA.
d) como
`?'
para indicar que, si hay interés en este
componente, y para las PSA
`petición'
, este parámetro
debe tener un valor definido en un caso particular.
Figure A-12/X.403 (traité comme tableau) [T11.403], p.
A.4.1.2
Especificaciones de
casos de PSA
Los valores específicos de las PSA se definen utilizando el formato tabular que aparece en la figura A-13/X.403.
Figure A-13/X.403 (traité comme tableau) [T12.403], p.
La columna
`NOMBRE DEL CASO'
se utiliza para identificar casos
específicos de la PSA utilizada en la serie de pruebas.
La columna
`PARáMETRO MODIFICADO'
identifica, para las PSA
`petición'
, aquellos parámetros cuyos valores deberán modificarse a
partir de la especificación PSA genérica, y para las PSA
`notificación'
aquellos parámetros cuyos valores deben verificarse.
La columna
`VALOR o REFERENCIA'
puede contener valores específicos o
referencias a los componentes de biblioteca de la PSA o UDP de prueba.
A.4.2
Especificación de valores UDP
La serie de prueba STM contiene un gran número de valores UDP de prueba.
Cada UDP está definido en términos de modificaciones a uno de los pocos UDP de
`base'
.
Por comodidad, los componentes UDP que se utilizan comúnmente están definidos en una biblioteca y son utilizados por las UDP de prueba y UDP de base como referencia.
A.4.3
UDP de base
A.4.3.1
Especificación de UDP de
base
Las UDP de base en sí mismas, no se utilizan como UD de prueba, pero sirven de base para derivar las UDP de prueba. Normalmente, sólo hay que especificar unas pocas UDP de base.
El nomre de una UDP de base tiene la siguiente forma:
BASE$$-&lab;UDPtipodenombre>$$-&lab;número>
Ejemplo de una UDP de base:
Tableau [T13.403], p.
El valor o la referencia de valor de cada elemento de la estructura se
especifica dentro de corchetes (
`['
y
`]'
) bajo el encabezamiento
de VALOR o REFERENCIA.
Cuando se especifica, para pruebas de codificación/decodificación, la codificación de una UDP, se utilizan dos columnas adicionales para especificar el código de identificación [ID] y el indicador de longitud [LI] de cada elemento de la UDP. El formato para esto se muestra en el siguiente ejemplo:
Tableau [T14.403], p.
Los valores de ID y LI pueden especificarse en forma explícita para permitir
la definición de códigos inválidos y varias formas de códigos válidos. Se
utiliza la abreviatura nemotécnica
`LI'
para indicar que se permite
cualquier codificación válida de longitud.
A.4.3.2
Identificación de los
componentes que deben modificarse
Un componente que vaya a ser reemplazado en una UDP se identifica por un
trayecto a través de la declaración de la UDP. El trayecto se representa como
una lista de elementos, cada uno separado del siguiente por medio de
`.'
. Los elementos de la lista pueden ser etiquetas que aparecen en un
UDP DE BASE, componentes que aparecen en el lado izquierdo de una declaración
etiquetada, o componentes que aparecen en el lado izquierdo de la expansión de
una referencia de biblioteca, en el lado derecho de una declaración.
Por ejemplo, considérense las siguientes definiciones:
Instance$$- SET{ a [value] b [L$$-Component$$-1] }
L$$-Component$$-1 SET{ c [value] d [L$$-Component$$-2] }
L$$-Component$$-2 SEQUENCE e [value] }
Nota
- [L$$-Component$$-1] está en la biblioteca de
componente.
Para hacer referencia a
`a'
, el trayecto debe ser instance$$-1.a
Para hacer referencia a
`e'
, el trayecto debe ser
instance$$-1.b.d.e.
A.4.4
UDP de prueba
Las UDP de prueba se definen en términos de operaciones sobre las UDP de base. Estas operaciones se refieren a los componentes de biblioteca, PSP o valores específicos.
Hay dos tipos de UDP de prueba:
-
UDP enviadas por el probador
^ (RSP como
destinatario)
Por convenio, los nombres de estas UDP se presentan en la forma
&lab;UDP nombre>$$-x$$-&lab;número>
donde
x
^ es el número de UDP de base de la
cual se derivan las UDP de prueba.
-
UDP recibidas por el probador
^ (RSP como
originador)
Por convenio, los nombres de estas UDP presentan la forma
&lab;UDP nombre>$$-0$$-&lab;número>
donde
`0'
indica que estas UDP de prueba no se derivan
de una UDP de base.
A.4.4.1
UDP de prueba enviadas por el
probador
Una UDP de prueba enviada por el probador a la RSP, normalmente se forma a partir de una UDP de base por medio de la operación REPLACE (REEMPLAZAR).
La especificación tiene la siguiente forma:
Tableau [T15.403], p.
Para los convenios de asignación de valores, véase el Î A.4.6.
Ejemplo:
Tableau [T16.403], p.
Para construir en las UDP de prueba componentes inválidos que hayan de ser
enviados por el probador, algunas veces se utiliza la operación abstracta
REDEFINE (REDEFINIR). Se utiliza conjuntamente con la operación REPLACE en la
siguiente forma:
Tableau [T17.403], p.
El alcance del nuevo tipo definido está limitado a la definición UDP que
contiene la operación REDEFINE.
Adviértase que si el &lab;valor> es una referencia a un elemento definido en otra parte (por ejemplo, un PSP o un componente de biblioteca), la definición del nuevo tipo no afecta al propio elemento referenciado, sino únicamente a su utilización en la UDP real.
Ejemplo:
Tableau [T18.403], p.
El error que se debe construir aquí es la etiqueta errónea del tipo ORName (la
etiqueta correcta sería [APLICATIóN 0]). El alcance de la definición de tipo
erróneo creada por
`REDEFINE'
está limitado a todas las veces que se
presente ORName en la definición de IM$$-UDPAU$$-1$$-3. Esto significa que se
utiliza L$$-ORDescripor$$-1 con el tipo ORName modificado, mientras que la
utilización de este componente de biblioteca en otras UDP o componentes
permanece inalterada.
A.4.4.2
UDP de prueba recibidas por el
probador
Para las UDP recibidas, normalmente sólo una parte de la UDP se relaciona con la finalidad de la prueba.
Un componente que reviste interés es identificado y se le asigna su valor utilizando las técnicas descritas en el Î A.4.3.
El esquema de especificación tiene la siguiente forma:
Tableau [T19.403], p.
Ejemplo:
Tableau [T20.403], p.
A.4.5
Biblioteca de componentes
Los componentes de las UDP están definidos en la biblioteca y se mencionan en las especificaciones de UDP de base, en las especificaciones de UDP de prueba y en otros componentes de la biblioteca.
El nombre de un componente de biblioteca tiene la forma:
L$$-&lab;NSA.1 nombre de tipo>$$-&lab;número> y se especifica utilizando las técnicas descritas en el Î A.4.3.
Ejemplo:
Tableau [T21.403], p.
A.4.6
Convenios de valor
Cuando se definen valores o referencias de valor para los componentes UDP, se aplican los siguientes convenios:
Las referencias de valor identifican componentes definidos dentro de la
biblioteca de componentes o dentro de la sección de parámetros de la serie de
prueba. Los valores CharacterString pueden especificarse dentro de dobles
comillas (por ejemplo,
`abc'
); los valores BitString se especifican
dentro de apóstrofos (por ejemplo 'OA' H ó '0001'B; notación hexadecimal o
notación binaria); los valores enteros se especifican como caracteres numéricos
(por ejemplo, 2); los conjuntos y secuencias de valores se especifican dentro
de llaves, separados por una coma (por ejemplo {
`abc'
, 'OA'H}).
Para las UDP enviadas por el probador:
[?] indica que el valor no influye sobre la prueba y que puede ser cualquier valor legal acorde con la norma de protocolo o con el servicio correspondiente.
[-] Indica que el parámetro está ausente.
[*] Indica que el valor será insertado por el probador antes de la ejecución de la prueba.
Para las UDP recibidas por el probador:
[?] indica que el probador no necesita verificar el valor del parámetro.
[-] indica que el probador verificará la ausencia del parámetro.
Obsérvese que los símbolos
`?'
y
`-'
en las asignaciones de
valores de los componentes UDP tienen otro significado que
`?'
y
`-'
en los esquemas de PSA genéricas.
A.5
Identificación del caso de prueba
Los casos de prueba se identifican totalmente utilizando cuatro componentes:
- un identificador de grupo de prueba;
- un identificador de subgrupo;
- un identificador de validez;
- un número de prueba;
Estos cuatro componentes se especifican en dos formas equivalentes:
- como referencia de prueba, en la que los cuatro componentes son textuales y descriptivos.
Ejemplo:
OriginalEncodedInfoTypeIndication/Recipient/Valid/2
- como un identificador de prueba, donde los cuatro componentes son numéricos y conocidos.
Ejemplo:
307.2.1.2.
A.5.1
Identificación de SMIP (P2) y STRM
(P1)
A.5.1.1
Grupos de prueba
Para los grupos de prueba se han asignado intervalos de números como se indica a continuación:
Pruebas iniciales 001^-^099
Pruebas X.409 100^-^199
Pruebas de los elementos de protocolo 200^-^299 (para los elementos que se presentan con frecuencia)
Pruebas de los elementos de servicio X.400 300^-^399
Pruebas adicionales 400^-^499
A.5.1.2
Subgrupos
Se han asignado identificadores numéricos a los subgrupos de pruebas como se indica a continuación:
Originador 1
Destinatario 2
Codificador 1
Decodificador 2
Relevador 3
Relevador-destinatario 4
Relevador-originador 5
A.5.1.3
Identificadores de validez
Los casos de prueba que ejercen un comportamiento válido se diferencian de los que ejercen la reacción de la RSP ante un comportamiento no válido utilizando los identificadores numéricos que se indican seguidamente:
Válido 1
No válido 2
A.5.1.4
Números de caso de prueba
Los casos de prueba para un grupo/subgrupo/validez especial están numerados en forma secuencial.
A.5.2
Identificación STF
A.5.2.1
Grupos de prueba
Se han asignado intervalos de números para los grupos de prueba, como se muestra a continuación:
Establecimiento de la asociación 1
Liberación de la asociación 2
Transferencia de datos 3
Recuperación de asociación 4
Pruebas X.409 5
A.5.2.2
Subgrupos
Se han asignado identificadores numéricos a los subgrupos STF, como se muestra seguidamente:
Iniciador 1
Respondedor 2
Emisor 1
Destinatario 2
A.5.2.3
Identificadores de validez
Los casos de prueba que ejercen un comportamiento válido se diferencian de los que ejercen la reacción de RSP ante un comportamiento inválido e inoportuno utilizando identificadores numéricos, como se muestra seguidamente:
Válido 1
No válido 2
Inoportuno 3
A.6
Referenciación recíproca
A.6.1
Numeración de referencias
recíprocas
Las series de pruebas STRM (P1) y SMIP (P2) contienen un sistema de referencias recíprocas para las PSA, UDP de prueba y componentes de biblioteca. Las referencias recíprocas aparecen en los márgenes derecho e izquierdo de la serie de pruebas como se muestra en la figura A-14/X.403.
Los números en el margen izquierdo de la serie de pruebas están en orden
secuencial y son
`identificadores de lugar'
. Se presentan siempre que
una PSA, UDP de prueba o componente de biblioteca se encuentra dentro de la
serie de pruebas.
Cada vez que se presenta una PSA, UDP de prueba o componente de biblioteca, también se ponen números en el margen derecho. Estos números son referencias hacia adelante o hacia atrás respecto a los identificadores de lugar de las otras apariciones de las PSA, UDP de prueba o componente de biblioteca.
Cuando no puede encontrarse una referencia hacia atrás o hacia adelante, se
imprime un punto (
`.'
) en el margen derecho. Este no debe aparecer en
las series de pruebas totalmente definidas.
Cuando un renglón en la serie de pruebas contiene más de una PSA, UDP de
prueba o componente de biblioteca, las referencias recíprocas para cada
elemento del renglón se separan por medio de barras verticales (
`|'
) en
el margen derecho, tal como se muestra en la figura A-15/X.403.
Figure A-14/X.403 (traité comme tableau) [T22.403], p.
Figure A-15/X.403 (traité comme tableau) [T23.403], p.
A.6.2
Listado de las referencias recíprocas
Al final de la serie de pruebas STRM (P1) y SMIP (P2) hay un listado de las referencias recíprocas de todas las PSA, UDP de prueba y componentes de biblioteca junto con los identificadores de lugar de todas las veces que aparecen dentro de la serie de pruebas.
Ejemplo:
: : : IM$$-UAPDU$$-1$$-14 586 1467 IM$$-UAPDU$$-1$$-15 587 1470 : : : Los números de la derecha indican los lugares en los que ese elemento aparece dentro de la serie de pruebas.
(H.T.=OUI)
TAB.???
FICHIER: H.T. =
(87.TA.98.S)
(SANS FORMULE) Tableaux: 21 - Tabulateurs: 1 b) NF08/029
Anexo D
Disk. 578ÿ NF01/005 OPM: 02
- NF01/005 OPM: 02
Recomendación X.200 NF01/008 OPM: 02
VALUE NOTATION NF01/017 OPM: 02
::= NF01/017 OPM: 02
id-asdc Disk. 579 NF01/003 OPM: 03
id-mod-object-identifiers NF01/004 OPM: 03
NF01/008 OPM: 03
password NF01/013 OPM: 03
green-management NF01/019 OPM: 03
password NF01/024 OPM: 03
(cs,) - (cs,)
(1BT) (BT..)
(87.TE.06.S)
(A1.23s) / [26s]
FOLIOS: 179 - 227
(DO PRC.COSY.2)
MEP {TPS.NON.PHOTO "[PA1]"} : OK= [1]
Saisie 22.08.89 RM
ID + LASER 03.10.89 JC
MAJ diskette 05.10.89 JC
Corr. LASER (1re épreuve) = 3eme 18.10.89 UT
Espaces réservés 02.11.89 JC
AJOUTER (PA1) (CL1,0,0,0) pour MEP
MEP + LASER 6.11.89 GH/PC
Corr. MEP ........ ..
Insertion des tableaux (tabulateurs 1) 7.11.89 PC
Corr. DIGI. 17.11.89 AF
Corr. DIGI. 27.11.89 AF
BAT ........ ..
MAJ s/disquettes 13.12.89 CD
ANEXO B (a la Recomendación X.403)
Proformas ECRP de
SMIP(P2)
B.1
Generalidades
Como prerrequisito para las pruebas de conformidad, el proveedor de un sistema SMIP(P2) debe proporcionar un enunciado de conformidad de realización de protocolo (ECRP).
La proforma ECRP SMIP(P2) contenida en este anexo especifica la información que debe suministrarse.
Esta información es necesaria para la selección del caso de prueba. Los proveedores deben tener en cuenta que se realizarán pruebas para verificar que los servicios anunciados como no admitidos de hecho no están presentes, en vez de estar realizados incorrectamente.
La ECRP SMIP(P2) se divide en dos partes:
-una parte que solicita información relativa a la aceptación de los elementos de servicio;
-una parte que solicita información relativa a la aceptación de los elementos del protocolo.
La información sobre la aceptación del elemento de servicio se solicita en forma de cuadro en el que, para cada elemento de servicio:
-se indica, en las columnas
`STD'
, la condición del elemento de
servicio como obligatorio (O), facultativo (F) o no aplicable (^-^);
-el proveedor indica, en las columnas
`IMP'
la aceptación real del
elemento de servicio por parte de la realización en el origen y el destino.
La información sobre la aceptación del elemento del protocolo se solicita en forma de cuadro, donde para cada elemento de protocolo:
-se indica la condición del elemento del protocolo al origen y en el destino
como obligatorio (O), o facultativo (F) en las columnas denominadas
(
`STD'
);
-se indica cualquier limitación a la realización en la columna denominada
`CONST STD'
, en donde las limitaciones se interpretan como un mínimo
para recepción y un máximo para origen;
-el proveedor indica, en la columna
`STATUS IMP'
la aceptación real
del elemento de servicio por parte de la realización en el origen o en el
destino;
-el proveedor indica en las columnas
`CONST IMP'
las limitaciones
reales de la realización en el origen y en el destino.
Las limitaciones pueden expresarse como una longitud o tamaño (octetos, bits, .^.^.), un valor (32k - 1) o el número de veces que ocurre el suceso (4), según el elemento que se limita.
B.2
Proforma de los elementos de servicio ECRP
SMIP(P2)
Los requisitos de las Recomendaciones X.400 se muestran en las columnas STD de la proforma utilizando las siguientes claves:
OElemento obligatorio (Recomendación X.401, básico o esencial facultativo)
FElemento facultativo (Recomendación X.401, adicional facultativo)
-Elemento de servicio no aplicable.
Los proveedores de una realización deben utilizar las columnas IMP de la
proforma para especificar la información relativa a la aceptación de los
elementos de servicio. Se sugiere, por conveniencia, que los proveedores
indiquen únicamente con una
`X'
los elementos de servicio que no se
admiten.
B.3
Proformas de los elementos de protocolo SMIP(P2)
ECRP
En las columnas STATUS STD de las proformas, en los cuadros B-2/X.403 a B-4/X.403 se muestran los requisitos de las Recomendaciones X.400 utilizando las siguientes claves:
OElemento obligatorio (Recomendación X.401, básico o esencial facultativo)
FElemento facultativo (Recomendación X.401, adicional facultativo).
Cuadro B-1/X.403 [T24.403], p.
Los elementos de protocolo que corresponden directamente a los elementos de
servicio se indican como obligatorios si sus elementos de servicio
correspondientes aparecen en la Recomendación X.401 (1984) como básico o
esencial facultativo, y como facultativos si los elementos de servicio
correspondientes aparecen en la Recomendación X.401 (1984) como adicionales
facultativos. Otros elementos de protocolo se indican como obligatorios o
facultativos de acuerdo a su asignación en las definiciones UDPA4 en la
Recomendación X.420 (1984).
Las limitaciones pragmáticas de la guía del realizador X.400 aparecen en las columnas CONST STD de las proformas, en los cuadros B-2/X.403 a B-4/X.403.
Los proveedores de una realización deben utilizar:
-las columnas STATUS IMP de cada proforma para especificar la información
relativa a la aceptación de los elementos de protocolo. Por conveniencia, se
sugiere que los proveedores indiquen con una
`X'
únicamente los
elementos de protocolo que no sean aceptados;
-las columnas CONST IMP de cada proforma para especificar las limitaciones reales de la realización.
Tableau B-2/X.403 [T25.403], p.2
Tableau B-3/X.403 [1T26.403], p.3
Tableau B-3/X.403 [2T26.403], p.4
Tableau B-4/X.403 [T27.403], p.5
ANEXO C (a la Recomendación X.403)
Proformas ECRP de
STRM(P1)
Generalidades
Como prerrequisito a las pruebas de conformidad, el proveedor de una realización STRM(P1) debe proporcionar un enunciado de conformidad de realización del protocolo (ECRP).
La proforma ECRP STRM(P1) contenida en este anexo especifica la información que debe suministrarse.
Esta información es necesaria para la selección del caso de prueba. Los proveedores deben tener en cuenta que se realizarán pruebas para verificar que los servicios que aparecen como no aceptados, de hecho no estén presentes en vez de estar realizados incorrectamente.
El ECRP STRM(P1) se divide en dos partes:
-una parte que solicita información relativa a la aceptación de los elementos de servicio;
-una parte que solicita información relativa a la aceptación de los elementos de protocolo.
La información sobre la aceptación de los elementos de servicio se solicita en forma de cuadro en el que, para cada elemento de servicio:
-se indica, en las columnas
`STD'
la condición del elemento de
servicio como obligatorio (O), facultativo (F) o no aplicable (^-^);
-el proveedor indica, en las columnas
`IMP'
la aceptación real del
elemento de servicio por parte de la realización en el origen y el destino.
La información sobre la aceptación de los elementos de protocolo se solicita en forma de cuadro en el que, para cada elemento de protocolo:
-se indica, en las columnas
`STD'
, la condición del elemento de
protocolo en el origen y el destino como: obligatorio (O) o facultativo (F);
-se indica cualquier limitación a la realización en la columna
`CONST
STD'
, interpretándose las limitaciones como un mínimo para la recepción y
un máximo para el origen;
-el proveedor indica, en la columna
`STATUS IMP'
la aceptación real
del elemento de servicio por parte de la realización en el origen y en la
recepción;
-el proveedor indica en las columnas
`CONST IMP'
las limitaciones
reales de la realización en el origen y en el destino.
Las limitaciones pueden expresarse como una longitud o tamaño (octetos, bits, .^.^.), un valor (32k - 1) o el número de veces que ocurre el suceso (4), según el elemento que se limita.
C.2
Capacidad del originador/destinatario/relevo
Los proveedores de una implementación deben especificar las capacidades de originador/destinatario/relevo bajo la columna REALIZADO del cuadro C-1/X.403.
Cuadro C-1/X.403 [T28.403], p.
C.3
Proforma de elementos de servicio ECRP STRM(P1)
Los requisitos de la Recomendación X.400 se indican en las columnas STD de la proforma, utilizando las siguientes claves:
OElemento obligatorio (Recomendación X.401, básico o esencial facultativo)
FElemento facultativo (Recomendación X.401, adicional facultativo)
-Elemento de servicio no aplicable
Los proveedores de la realización deberán utilizar las columnas IMP de la
proforma para especificar la información sobre la aceptación de los elementos
de servicio. Se sugiere, para mayor conveniencia, que los proveedores indiquen
por medio de una
`X'
únicamente aquellos elementos de servicio que no
sean aceptados.
Cuadro C-2/X.403 [T29.403], p.
C.4
Proformas de los elementos de protocolo STRM(P1)
Los requisitos de la Recomendación X.400 aparecen bajo la columna STATUS STD de las proformas en los cuadros C-3/X.403 a C-6/X.403 utilizando las siguientes claves:
OElemento obligatorio (Recomendación X.401, básico o esencial facultativo)
FElemento facultativo (Recomendación X.401, adicional facultativo)
En los cuadros que siguen, los elementos de protocolo que corresponden directamente a los elementos de servicio se indican como obligatorios si sus elementos de servicio aparecen en la Recomendación X.401 (1984) como básico o esencial facultativo, y como facultativos si los elementos de servicio correspondientes aparecen en la Recomendación X.401 (1984) como adicional facultativo. Otros elementos del protocolo se indican como obligatorios o facultativos dependiendo de la asignación que se haya dado en las definiciones UDPM de la Recomendación X.411 (1984).
Para las funciones de relevo, los elementos de protocolo se indican como obligatorios o facultativos basándose únicamente en su condición dentro de la especificación del protocolo P1.
Las restricciones pragmáticas de la guía del realizador X.400 se indican en las columnas CONS STD de las proformas en los cuadros C-3/X.403 a C-6/X.403.
Los proveedores de la realización deberán utilizar:
-la columna STATUS IMP de cada proforma para especificar la información
relativa a la aceptación de los elementos de protocolo. Se sugiere, por
comodidad que los proveedores indiquen por medio de una
`X'
únicamente
aquellos elementos de protocolo que no sean aceptados;
-las columnas CONS IMP de cada proforma para especificar las limitaciones reales de la realización.
Tableau C-3/X.403 [T30.403], p.8
Tableau C-4/X.403 [1T31.403], p.9
Tableau C-4/X.403 [2T31.403], p.10
Tableau C-5/X.403 [1T32.403], p.11
Tableau C-5/X.403 [2T32.403], p.12
Tableau C-6/X.403 [T33.403], p.13
ANEXO D (a la Recomendación X.403)
Proformas ECRP de
STF
Generalidades
Como prerrequisito a las pruebas de conformidad de una realización STF, el proveedor debe proporcionar un enunciado de conformidad de realización de protocolo (ECRP).
La proforma ECRP STF en este anexo especifica la información que debe suministrarse.
Esta información es necesaria para la selección del caso de prueba. Los proveedores deberán tener en cuenta que las pruebas se realizan únicamente para verificar que los servicios que aparecen como no aceptados, de hecho no están presentes y no que están realizados de forma incorrecta.
El ECRP STF se presenta en tres partes:
-Dos partes que recaban información relativa a la aceptación de las primitivas de servicio STF.
Si las primitivas tienen únicamente parámetros obligatorios deben señalarse
como
`no aceptadas'
si cualquiera de sus parámetros no es aceptado.
-Una parte que solicita información relativa a la aceptación de elementos de protocolo.
La información sobre la aceptación de elementos de servicio se solicita en forma tabular en donde, para cada elemento:
-se indica en las columnas
`STD'
la condición del elemento de
servicio como obligatoria (O, facultativa (F), condicional (C) o no aplicable
(^-^);
-el proveedor indica, en las columnas
`IMP'
, la aceptación real del
elemento de servicio por parte de la realización como iniciador o receptor.
La información sobre la aceptación del elemento de protocolo se solicita en forma tabular en la que para cada elemento de protocolo:
-se indica en las columnas
`STD'
la condición del elemento de
protocolo en el que la RSP es iniciador o receptor como obligatorio (O) o
facultativo (F);
-se indica en las columnas
`CONS STD'
cualquier limitación de la
realización, las limitaciones se interpretan como un mínimo para la recepción y
un máximo para el origen;
-el proveedor indica, en la columna STATUS IMPÓ, la aceptación real del elemento de protocolo por parte de la realización como iniciador o receptor;
-el proveedor indica, en las columnas
`CONST IMP'
, las limitaciones
reales de la realización como iniciador o receptor.
Las limitaciones pueden expresarse como una longitud o tamaño (octetos, bit, .^.^.) o un valor (32) dependiendo del elemento que se está limitando.
D.2
Proforma de las primitivas de servicio ECRP STF
Los requisitos de las Recomendaciones X.400 se indican en las columnas STD de la proforma utilizando las siguientes claves:
OElemento obligatorio
FElemento facultativo
Los proveedores de la comodidad deberán utilizar las columnas IMP de la
proforma para especificar la información relativa a la aceptación de los
elementos de servicio. Se sugiere, por comodidad, que los proveedores indiquen
con una
`X'
únicamente las primitivas de servicio que no sean aceptadas.
D.3
Proforma de parámetros de servicio ECRP STF
Los parámetros de servicio STF se ponen en correspondencia con sesión y presentación como sigue:
-Los parámetros de Petición ABIERTO e Indicación ABIERTO se ponen en correspondencia con Petición S-CONEXIóN e Indicación S-CONEXIóN y con la P-Conexión correspondiente.
-Se hace corresponder Respondedor/Iniciador-dirección y turno inicial con S-CONEXIóN.
-El modo de diálogo, protocolo de aplicación y datos de usuario se hacen corresponder con P-Conexión.
-Los parámetros de Respuesta ABIERTO y Confirmación ABIERTO se hacen corresponder con P-Aceptación y R-Rechazo.
Cuadro D-1/X.403 [T34.403], p.
Puesto que todos los parámetros de servicio ABIERTO se hacen corresponder con
el elemento de protocolo P-Conexión (aparte de la dirección de respuesta y
turno inicial que son obligatorios), en los cuadros D-2/X.403 a D-5/X.403 se
solicita aparentemente información duplicada respecto a la solicitada en el
cuadro D-6/X.403.
Sin embargo, los cuadros D-2/X.403 a D-5/X.403 son útiles ya que aseguran que todos los parámetros obligatorios son realmente aceptados y porque facilitan la revisión de la conformidad estática.
Los requisitos de las Recomendaciones X.400 se muestran en las columnas STD de la proforma utilizando las siguientes claves:
OParámetros obligatorios
FParámetros facultativos
CParámetros condicionales
-Parámetros de servicio no aplicables.
Los proveedores de la realización deberán utilizar las columnas IMP de la
proforma para especificar la información relativa a la aceptación de elementos
de servicio. Se sugiere por comodidad, que los proveedores indiquen con una
`X'
únicamente los elementos de servicio que no estén aceptados.
D.4
Elementos de protocolo STF
Los requisitos de las Recomendaciones X.400 se indican en la columna STATUS STD de la proforma de los cuadros D-6/X.403 a D-9/X.403 utilizando las siguientes claves:
OElemento obligatorio
FElemento facultativo
Las restricciones pragmáticas de guía del realizador X.400 aparecen en las columnas CONST STD de la proforma en los cuadros D-6/X.403 a D-9/X.403.
Los proveedores de una realización deberán utilizar:
-la columna STATUS IMP de la proforma para especificar información relativa
a la aceptación de elementos de protocolo. Se sugiere que por comodidad los
proveedores indiquen con una
`X'
únicamente los elementos de protocolo
que no estén aceptados;
-las columnas CONST IMP de la proforma para especificar las limitaciones reales de la realización.
Tableaux D-2 à D.5/X.403 [T35.403] GARDER NP EN MEP, p.15 à
18
Para algunos parámetros resulta aplicable un solo valor (por ejemplo DataTransferSyntax: O). Existen otros parámetros (por ejemplo checkpointSize, RefuseReason) que pueden variar bajo diversas circunstancias y condiciones de tiempo de operación. Dicha información se encuentra en un ISRP y si el parámetro no ha sido fijado, se puede hacer referencia a dicho ISRP dentro del campo de limitaciones.
En una recuperación, se utiliza SessionConnectionId en P-Conexión y P-Aceptación. Este SessionConnectionId puede o no estar codificado de acuerdo con las especificaciones de la Recomendación X.409. Esta información no es importante para los ECRP puesto que no es un criterio para la revisión de conformidad estática o para la selección de caso de prueba y normalmente debe ser proporcionado en un ISRP.
Cuadro D-6/X.403 [T39.403], p.
Tableau D-7/X.403 [T40.403], p.20
Tableau D-8/X.403 [T41.403], p.21
Tableau D-9/X.403 [T42.403], p.22
SISTEMAS DE TRATAMIENTO DE
MENSAJES: CONVENIOS PARA LA DEFINICIóN DEL SERVICIO
ABSTRACTO
La Recomendación X.407 y la norma ISO 10021-3
[Information Processing Systems - Text Communication - MOTIS - Abstract Service
Definition Conventions] se elaboraron en estrecha colaboración y están
técnicamente armonizadas.
(Melbourne, 1988)
El establecimiento en diversos países de servicios telemáticos y de servicios
de mensajes con almacenamiento y retransmisión, controlados por computador, y
asociados a redes públicas de datos, crea la necesidad de establecer normas que
faciliten el intercambio internacional de mensajes entre los abonados a estos
servicios.
El CCITT,
considerando
(a)la necesidad de sistemas de tratamiento de mensajes;
(b)que el tratamiento de mensajes es una compleja tarea de procesamiento de información distribuido;
(c)que se necesita un medio para la definición abstracta de dichas tareas;
(d)que la Recomendación X.200 define el modelo de referencia de interconexión de sistemas abiertos para aplicaciones del CCITT;
(e)que las Recomendaciones X.208, X.217, X.218 y X.219 sirven de base para las aplicaciones del CCITT,
recomienda por unanimidad
(1)que los convenios para la definición de servicios abstractos sean los establecidos en la sección 2;
(2)que las técnicas para la realización de los servicios abstractos así definidos sean las estipuladas en la sección 3.
íNDICE
SECCIóN 1 -
Introducción
0Introducción
1Objeto
2Referencias
3Definiciones
4Abreviaturas
5Convenios
5.1NSA.1
5.2Términos
SECCIóN 2 -
Convenios para la definición
del servicio abstracto
6Visión de conjunto
7Modelos abstractos
7.1Objetos abstractos
7.2Puertos abstractos
7.3Servicios abstractos
7.4Perfeccionamientos abstractos
8Servicios abstractos
8.1Procedimientos abstractos
8.2Operaciones abstractas de vinculación
8.3Operaciones abstractas de desvinculación
8.4Operaciones abstractas
8.5Errores abstractos
SECCIóN 3 -
Realizaciones del servicio abstracto
9Visión de conjunto
10Realizaciones ISA
10.1Realizaciones SOD
10.2Realizaciones no SOD
11Realizaciones de propiedad
11.1Realizaciones distribuidas
11.2Realizaciones no distribuidas
Anexo A
-Ejemplo del uso de la notación de servicio
abstracto
Anexo B
-Definición de las referencias de
identificadores de objeto
Anexo C
-Definición de referencia de la notación
Anexo D
-Diferencias entre la Recomendación CCITT y la
norma de la ISO
Anexo E
-índice.
SECCIóN 1 - INTRODUCCIóN
0 Introducción
Esta Recomendación forma parte de un conjunto de Recomendaciones sobre el tratamiento de mensajes. Este conjunto constituye un esquema completo del sistema de tratamiento de mensajes (STM) realizado por cualquier número de sistemas abiertos cooperantes.
El sistema de tratamiento de mensajes que ofrecen estas Recomendaciones es un sistema complejo de procesamiento de información distribuido, muchos de cuyos componentes tienen estas mismas características.
Esta Recomendación especifica los convenios para definir las tareas de procesamiento de información distribuido del tratamiento de mensajes y también puede ser útil para otras aplicaciones.
El texto de esta Recomendación es objeto de un acuerdo entre el CCITT y la ISO. La especificación ISO correspondiente es ISO 10021-3.
1
Objeto
Esta Recomendación establece los convenios utilizados para especificar las tareas de procesamiento de información distribuido necesarias para el tratamiento de mensajes.
Esta Recomendación está estructurada de la siguiente manera. La presente sección 1 es la introducción. La sección 2 especifica los convenios para la definición abstracta de una tarea de procesamiento de información distribuido. La sección 3 establece los principios para realizar en forma concreta los aspectos de comunicación de dichas tareas, por ejemplo, los protocolos de interconexión de sistemas abiertos (ISA). Los anexos ofrecen información complementaria importante.
No hay requisitos en cuanto a la conformidad con esta Recomendación.
2
Referencias
Esta Recomendación menciona los siguientes documentos:
Recomendación X.200Modelo de referencia de interconexión de sistemas abiertos para aplicaciones del CCITT (véase también la Norma ISO 7498).
Recomendación X.208Especificación de la notación de sintaxis abstracta uno (NSA.1) (véase también la Norma ISO 8824).
Recomendación X.209Especificación de las reglas básicas de codificación para la notación de sintaxis abstracta uno (NSA.1) (véase también la Norma ISO 8825).
Recomendación X.217Definición de servicio de control de asociación para la interconexión de sistemas abiertos para aplicaciones del CCITT (véase también la Norma ISO 8649).
Recomendación X.219Operaciones a distancia: modelo, notación y definición del servicio (véase también la Norma ISO 9072-1).
3
Definiciones
Para los fines de esta Recomendación, se aplicarán las definiciones del anexo E y las mencionadas a continuación.
Esta Recomendación se basa en los conceptos expuestos en la Recomendación X.200 y utiliza los siguientes términos definidos en la misma:
a)sintaxis abstracta;
b)capa de aplicación;
c)@unidad de datos de protocolo de aplicación (UDPA)\;
d)protocolo de aplicación;
e)@elemento de servicio de aplicación (ESA)\;
f)sintaxis de transferencia concreta;
g)tarea de procesamiento de información distribuido;
h)servicio de capa;
i)capa;
j)sistema abierto;
k)interconexión de sistemas abiertos (ISA);
l)sistema abierto real.
Esta Recomendación utiliza los siguientes términos, definidos en la Recomendación X.208.
a)@notación de sintaxis abstracta uno (NSA.1)\;
b)tipo (de datos);
c)valor (de datos);
d)importación;
e)entero;
f)macro;
g)módulo;
h)identificador de objeto;
i)rótulo.
Esta Recomendación utiliza los siguientes términos definidos en la Recomendación X.209:
a)reglas básicas de codificación.
Esta Recomendación utiliza los siguientes términos definidos en la Recomendación X.217:
a)contexto de aplicación (CA).
Esta Recomendación utiliza los siguientes términos definidos en la Recomendación X.219:
a)operación de vinculación;
b)error;
c)enlazado;
d)operación;
e)@servicio de operación a distancia (SOD)\;
f)operaciones a distancia;
g)operación de desvinculación.
4
Abreviaturas
Para los fines de esta Recomendación, se aplican las abreviaturas del anexo E.
5
Convenios
Esta Recomendación utiliza los siguientes convenios descriptivos:
5.1
NSA.1
Esta Recomendación utiliza las convenciones descriptivas basadas en la NSA.1 para los fines indicados:
a)Para definir las macros OBJECT, PORT y REFINE, la notación macro NSA.1 de la Recomendación X.208.
b)Para definir las macros ABSTRACT-BIND, -UNBIND, -OPERATION y -ERROR, las macros BIND, UNBIND, OPERATION y ERROR de la Recomendación X.219.
c)Para especificar la sintaxis abstracta de los objetos de información en el ejemplo del anexo A, la propia NSA.1.
d)Para especificar diversos
modelos abstractos
del
ejemplo del anexo A, los macros OBJECT, PORT y REFINE del
7
.
e)Para especificar diversos
servicos abstractos
del
ejemplo del anexo A, los macros ABSTRACT-BIND, -OPERATION y -ERROR del
8
.
La NSA.1 aparece tanto en el cuerpo de esta Recomendación, para facilitar la exposición, como en los anexos como referencia, en una forma bastante redundante. Si se encuentran diferencias entre los dos, se indica un error de especificación.
Obsérvese que los rótulos NSA.1 son implícitos en todos los módulos NSA.1 de los anexos; los módulos son definitivos a este respecto.
5.2
Términos
En esta Recomendación, los términos definidos aparecen en
negrita
; en
bastardilla
cuando aparecen
antes de su definición, y de la manera normal en todos los demás casos.
Los nombres propios se escriben con mayúscula y los términos genéricos no.
SECCIóN 2 - CONVENIOS PARA LA DEFINICIóN DEL SERVICIO ABSTRACTO
6 Visión de conjunto
Cuando se debe describir y especificar una tarea compleja de procesamiento
de información distribuido es conveniente comenzar especificando la tarea en
términos abstractos, y no en términos concretos. Esto garantiza que los
requisitos funcionales de la tarea se establezcan en forma independiente de su
realización concreta. Dicha separación es importante, entre otras cosas, porque
cada aspecto de la tarea puede prestarse para
varias
realizaciones concretas. En un sistema de transferencia de mensajes que
comprende, por ejemplo, tres agentes de transferencia de mensajes, el primero y
el segundo pueden interactuar utilizando la comunicación ISA, y el segundo y el
tercero por medios patentados.
Esta sección especifica los convenios para la descripción abstracta de una
tarea de procesamiento de información distribuido, tanto macroscópica como
microscópicamente. La primera descripción se llama
modelo
abstracto
y la segunda
servicio abstracto
.
En esta sección se definen instrumentos formales para especificar
servicios
y
modelos abstractos
. En el
anexo A se ofrece un ejemplo completo de su utilización. Puede ser conveniente
que el lector consulte dicho anexo, por ejemplo, por sus ilustraciones al leer
la presente sección.
Esta sección comprende los siguientes temas:
a)
Modelos abstractos
b)
Servicios abstractos
Nota
- Los instrumentos formales mencionados más
arriba no son ni un lenguaje de descripción formal ni un sustituto del mismo.
Simplemente, son la notación NSA.1 que sirve de base a los convenios
descriptivos informales definidos en esta sección.
7 Modelos abstractos
La descripción macroscópica de una tarea de procesamiento de información
distribuido se llama
modelo abstracto (modelo)
de dicha
tarea y del entorno en el que se realiza. Se basa en los conceptos de
objetos
,
puertos
,
servicio
y
perfeccionamientos
abstractos
. (El concepto de servicio abstracto se elabora con más detalle
en el
8
.)
7.1
Objetos abstractos
Un @
objeto abstracto
(
objeto
)@ es
\una entidad funcional tal vez una de varias que interactúan entre sí. Los
objetos son de diferentes tipos, que determinan su función y comportamiento.
Por ejemplo, un objeto de un tipo puede representar un sistema, y múltiples
objetos de otro tipo sus usuarios. Los objetos interactúan por medio de
puertos abstractos
.
Un tipo de objeto se especifica por medio de la macro OBJECT. Dicha
especificación enumera los tipos de
puertos abstractos
que
dan accesso a dicho objeto. Por cada tipo de puerto
asimétrico
, la especificación indica si los puertos son
puertos
consumidores
o
suministradores
.
OBJECT MACRO ::= BEGIN
TYPE NOTATION::=
"PORTS"
"{"
PortList
"}"
^|^empty
VALUE NOTATION::=value (VALUE OBJECT IDENTIFIER)
PortList::=Port
","
PortList^|^Port
Port::=value (PORT) PortType
PortType::=Symmetric^|^Asymmetric
Symmetric::=empty Asymmetric::=Consumer^|^Supplier
Consumer::=
"[C]"
Supplier::=
"[S]"
END
Un valor de dato del tipo OBJECT es un identificador de objeto que identifica de forma única e inequívoca el tipo de objeto especificado.
Nota
- El uso de la palabra clave
"OBJECT"
se
limita a la NSA.1. Su sustitución por un vocablo adecuado en el presente
contexto requiere ulterior estudio.
7.2
Puertos abstractos
Un @
puerto abstracto
(
puerto
)@ es \un
punto en el que un objeto abstracto interactúa con otro objeto abstracto. Los
puertos son de diferentes tipos, lo que determina los tipos de interacciones
que permiten. Por ejemplo, los puertos de un tipo pueden representar los medios
por los cuales se accede a un sistema de guía, y los puertos de otro tipo, los
medios por los que el mismo se administra.
Los tipos de puertos son a su vez de las dos especies siguientes:
a)
simétrico
: todos los casos de un tipo de puerto
simétrico son idénticos;
b)
asimétrico
: cada caso de un tipo de puerto asimétrico
es de una de dos clases;
suministrador
o
consumidor
.
Nota
- Con frecuencia, la asignación de los términos
`suministrador'
y
`consumidor'
es intuitiva. Por ejemplo, se
puede considerar naturalmente que un sistema de archivo, presenta puertos
suministrados a sus usuarios y administradores. Sin embargo, en rigor, la
asignación de los dos términos es arbitraria.\
Dos objetos pueden interactuar entre sí por medio de un puerto en cada uno
de ellos, únicamente mientras dichos puertos estén en contacto o
unidos
. Las acciones por medio de las que se inicia y
termina este estado para uno o más pares de puertos, se llaman
vinculación
y
desvinculación
,
respectivamente.
Dos puertos pueden estar unidos únicamente si
concuerdan
. Dos puertos cualesquiera de un mismo tipo
simétrico, concuerdan. Dos puertos de un mismo tipo asimétrico concuerdan si, y
únicamente si, uno es suministrador y el otro consumidor.
Un tipo de puerto se especifica por medio del macro PORT. Tal
especificación identifica las
operaciones abstractas
que
representan las interacciones posibles mientras dos de dichos puertos están
unidos. Si no se indica ninguna, las
operaciones
abstractas
se consideran no especificadas.
PORT MACRO ::= BEGIN
TYPE NOTATION::=Operations^|^empty VALUE NOTATION::=value (VALUE OBJECT IDENTIFIER)
Operations::=Symmetrical^|^Asymmetrical
Symmetrical::=
"ABSTRACT"
"OPERATIONS"
"{"
OperationList
"}"
Asymmetrical::=OneSided^|^TwoSided
OneSided::=Consumer^|^Supplier TwoSided::=Consumer Supplier^|^Supplier Consumer
Consumer::=
"CONSUMER"
"INVOKES"
"{"
OperationList
"}"
Supplier::=
"SUPPLIER"
"INVOKES"
"{"
OperationListÑ}Ñ
OperationList::=Operation
","
OperationList^|^Operation
Operation::=value (ABSTRACT-OPERATION)^|^--
identifica la
operación abstracta
calue (ABSTRACT-OPERATION)^|^--
por valor de datos
type --
identifica la operación abstracta por tipo de datos
END
Si el tipo de puerto es simétrico, ambos objetos ofrecen todas las
operaciones abstractas
enumeradas. Si el tipo de puerto es
asimétrico, la macro diferencia entre las
operaciones
abstractas
que ofrecen un objeto con puerto consumidor y aquellas que
ofrecen un objeto con el puerto proveedor.
Un valor de datos del tipo PORT es un identificador de objeto que en forma única e inequívoca identifica el tipo de puerto especificado.
7.3
Servicios abstractos
Un
@servicio abstracto@
es \un conjunto de capacidades
que un objeto ofrece a otro por medio de uno o más de sus puertos. Al primer
objeto se le denomina
proveedor de servicio abstracto
(proveedor)
y al segundo,
usuario de servicio abstracto
(usuario)
. Cada puerto en cuestión puede ser simétrico o asimétrico y si
es lo segundo puede ser consumidor o suministrador.
Un servicio abstracto puede tener cualquier número de usuarios y proveedores.\
Cuando los puertos de servicio abstracto de un proveedor estén unidos a los
puertos concordantes de un usuario, se dice que entre los dos objetos existe
una
asociación abstracta (o asociación)
.
Un servicio abstracto se especifica como se indica en el 8 .
Nota
- Un servicio abstracto dentro de la capa de
aplicación tiene una finalidad muy similar a los servicios de capa de las capas
ISA inferiores.
7.4
Perfeccionamientos abstractos
Un objeto puede verse de diferentes maneras en diferentes momentos. Algunas veces es conveniente considerar un objeto como atómico. Esto ocurre, por ejemplo, cuando se describe la forma en que un objeto interactúa con otros objetos externos a él mismo, es decir, cuando se especifica su servicio abstracto. Otras veces es más adecuado considerar un objeto como compuesto, es decir constituido de otros objetos. Este podría ser el caso, por ejemplo, cuando se describe la forma en que se realiza un objeto.
Como cualquier objeto, los objetos componentes tienen puertos. Algunos de
estos son visibles en la
`superficie'
del objeto construido. Otros
permiten la interacción de los objetos componentes, admitiendo así la
disposición y uso de servicios menos abstractos entre los objetos componentes,
que cooperan para proporcionar el servicio abstracto general del objeto
construido.
La descomposición funcional de un objeto en varios objetos menores se
conoce como
perfeccionamiento abstracto (perfeccionamiento)
de dicho objeto.
La técnica de perfeccionamiento puede aplicarse en forma recurrente. Un
objeto componente puede perfeccionarse para revelar
su
estructura interna. Esto puede continuar hasta que se llega a los objetos
componentes, considerados como atómicos.
Un perfeccionamiento se especifica con la macro REFINE. Identifica el objeto cuya estructura interna se está revelando y los objetos componentes utilizados en su construcción. Cada objeto componente puede considerarse como único o como recurrente. La macro también indica cuáles puertos de los objetos componentes están unidos a puertos de otros objetos componentes y cuáles son visibles en la superficie del objeto compuesto.
REFINE MACRO ::= BEGIN
TYPE NOTATION::=Object
"AS"
ComponentList
VALUE NOTATION::=value (VALUE OBJECT IDENTIFIER)
ComponentList::=Component ComponentList^|^Component Component::=ObjectSpec Ports
ObjectSpec::=Object^|^Object
"RECURRING"
Ports::=PortSpecList^|^empty PortSpecList::=PortSpec PortSpecList^|^PortSpec PortSpec::=value (PORT) PortSide PortStatus
PortSide::=Consumer^|^Supplier^|^empty
Consumer::=
"[C]"
Supplier::=
"[S]"
PortStatus::=
"VISIBLE"
^|^
"PAIRED"
"WITH"
ObjectList
ObjectList::=Object
","
ObjectList^|^Object
Object::=value (OBJECT)
END
Un valor de datos del tipo REFINEMENT es un identificador de objeto.
Nota
- Al igual que con los objetos, en principio los
puertos, pueden considerarse de diferentes maneras en diferentes momentos. En
algunos casos es conveniente considerar un (par) puerto como atómico. Sin
embargo, se puede imaginar el perfeccionamiento de un puerto para examinar cómo
puede proporcionar comunicación de este tipo. En este contexto, un puerto par,
se considera como aceptado por una colección de objetos. Esto mejoraría la
especificación de las capacidades de comunicación. Este concepto de
`perfeccionamiento de puerto'
no se estudia más a fondo en esta versión
de la presente Recomendación.
8
Servicios abstractos
Una descripción microscópica de una tarea de procesamiento de información
distribuido es una especificación del servicio abstracto que define la forma en
que se inicia, controla y termina una tarea. Se basa en los conceptos de
operaciones abstractas vinculadas
,
operaciones desvinculadas
,
operaciones y
errores
, así como en el concepto promotor de
procedimientos abstractos
.
Nota
- Las macros definidas más abajo implican el uso
de NSA.1 para especificar argumentos, resultados y parámetros. Por ejemplo,
cualquier rótulo específico del contexto, asignado en el curso de las
especificaciones, si bien no tiene sentido en dicho contexto, desempeña un
papel importante en una realización SOD del servicio abstracto.
8.1
Procedimientos abstractos
Un
@procedimiento abstracto (procedimiento)@
es \una
tarea que realiza un objeto a solicitud de otro. El hacer la solicitud y llevar
a cabo la tarea se conoce como
invocación y ejecución
del
procedimiento. Los objetos que producen y actúan por dicha solicitud se conocen
respectivamente como
invocador y ejecutor
\.
Un procedimiento puede (pero no necesariamente) requerir que un invocador,
al hacer la invocación, suministre al ejecutor un objeto único de información
de un tipo específico, que se conoce como
argumento
del
procedimiento.
Cada ejecución del procedimiento tiene un resultado, éxito o fracaso. Se considera que un procedimiento tiene éxito si se ejecuta en su totalidad y que es un fracaso si se termina prematuramente.
Un procedimiento puede requerir (pero no necesariamente) que el ejecutor informe del éxito al invocador. Puede pedir (pero no necesariamente) además que suministre, cuando informa del éxito, un objeto único de información de un tipo prescrito, que se conoce como el resultado del procedimiento.
Un procedimiento puede (pero no necesariamente) requerir que el ejecutor informe al invocador del fracaso. Puede (pero no necesariamente) requerir además que le suministre cierta información cuando notifica el fracaso.
Nota
- En los puntos subsiguientes se utiliza la NSA.1
para especificar la sintaxis abstracta de los argumentos y resultados de los
procedimientos (así como de los parámetros de
errores
abstractos
). Estos usos de NSA.1 no implican que estos objetos de
información sean transportados
necesariamente
entre
sistemas abiertos. En especial, el que los objetos de información, por su
descripción en NSA.1 y sus reglas de codificación básica, tengan sintaxis de
transferencia concretas, no tiene importancia en el presente contexto. NSA.1 es
simplemente un instrumento cómodo para la descripción formal de la sintaxis
abstracta de los objetos de información.
8.2
Operaciones abstractas de vinculación
Una
@operación abstracta de vinculación@
es \un
procedimiento cuya realización satisfactoria une a uno o más pares de puertos
abstractos. El objeto que invoca una operación abstracta de vinculación se
conoce como
iniciador
y el que la realiza es el
respondedor
.\
Una operación abstracta de vinculación sirve para vincular un grupo especial de puertos del iniciador a un grupo concordante del respondedor. Cuando uno o más de los puertos son asimétricos, la operación abstracta de vinculación puede servir para unir únicamente el lado consumidor, el lado suministrador o cualquiera de ellos.
Una operación abstracta de vinculación es un procedimiento general
completo, salvo cuando la información se transmite al invocador luego de un
fracaso, se verá limitada a un solo objeto de información denominado
información de error
.
Una operación abstracta de vinculación se especifica por la macro ABSTRACT-BIND cuya definición es la siguiente:
ABSTRACT-BIND MACRO ::= BEGIN
TYPE NOTATION::=Ports Bind VALUE NOTATION::=value (VALUE BindType)
Ports::=
"TO"
"{"
PortList
"}"
^|^empty
PortList::=Port
","
PortList^|^Port
Port::=value (PORT) PortSide
PortSide::=Consumer^|^Supplier^|^empty
Consumer::=
"[C]"
Supplier::=
"[S]"
Bind::=type (BindType) --
ha de ser un tipo
BIND
|^empty &lab;BindType ::= BIND>
END
La cláusula
`Puertos'
introducida por la palabre clave
`TO'
,
enumera los puertos de un respondedor que se vincularán en esta operación
abstracta de vinculación. Si se lista un puerto asimétrico, sin haber sido
calificado por
`[S]'
o
`[C]'
, eso significa que la operación
abstracta de vinculación puede utilizarse en la unión de dicho puerto en
cualquier dirección.
Obsérvese que la especificación del argunemto, resultado y/o información de
error se logra por medio de la macro BIND de operaciones a distancia
(incrustada), definida en la Recomendación X.219 y la macro devolverá un valor
de ese tipo. Si no hay se devolverá el
`BIND'
normal.
Nota
- La relación ABSTRACT-BIND y -BIND puede hacer
trivial la realización del SOD en un servicio abstracto; véase el
10.1
.
Un servicio abstracto por lo común comprende una operación abstracta de vinculación para cada tipo de puerto involucrado en su provisión. Cuando hay varios tipos de puertos involucrados, sus operaciones abstractas de vinculación pueden, pero no necesariamente, ser diferentes.
8.3
Operaciones abstractas de desvinculación
Una
@operación abstracta de desvinculación@
es \un
procedimiento cuya realización, satisfactoria o no, desvincula dos puertos. Es
invocada por el objeto que invocó la vinculación abstracta correspondiente (es
decir el inciador) y ejecutada por el respondedor.\
Una operación abstracta de desvinculación sirve para desvincular un grupo especial de puertos del iniciador de un grupo concordante del respondedor. Cuando uno o más de los puertos del grupo son asimétricos, la operación abstracta de desvinculación puede servir para desvincular únicamente del lado consumidor, del lado suministrador o de cualquiera de ellos.
Una operación abstracta de desvinculación es un procedimiento general
completo, excepto, si la información se transmite al invocador en caso de
fracaso, estará limitada a un solo objeto de información denominado
información de error
.
Una operación abstracta de desvinculación se especifica por medio de la macro ABSTRACT-UNBIND, cuya definición es la siguiente:
ABSTRACT-UNBIND MACRO ::= BEGIN
TYPE NOTATION::=Ports Unbind VALUE NOTATION::=value (Value UnbindType)
Ports::=
"FROM"
"{"
PortList
"}"
PortList::=Port
","
PortList^|^Port
Port::=value (PORT) PortSide
PortSide::=Consumer^|^Supplier^|^empty
Consumer::=
"[C]"
Supplier::=
"[S]"
Unbind::=type (UnbindType)^|
--^
must be an UNBIND type
|^empty &lab;UnbindType ::= UNBIND>
END
La cláusula
`puertos'
introducida por la palabre clave
`FROM'
, enumera los puertos de un respondedor del que se desvinculará
esta operación abstracta de desvinculación. Si se enumera un puerto asimétrico,
sin haber especificado
`[S]'
o
`[C]'
, la operación abstracta de
desvinculación separará dicho puerto en cualquier dirección (si bien la
dirección real está determinada por la dirección en que se realizó la
vinculación.
Obsérvese que la especificación del argumento, resultado y/o información de
error va acompañada de una macro UNBIND de operaciones a distancia
(incrustada), definida en la Recomendación X.219; la macro devolverá un valor
de ese mismo tipo. Si no se proporciona, se devolverá el
`UNBIND'
por
defecto.
Nota
- La relación ABSTRACT-UNBIND y UNBIND hace
trivial la realización del SOD en un servicio abstracto; véase el
10.1
.
Un servicio abstracto por lo general, incluye una operación abstracta de desvinculación por cada tipo de puerto involucrado en esta disposición. Cuando hay participación de varios puertos, sus operaciones abstractas de desvinculación pueden, pero no obligatoriamente, ser diferentes.
8.4
Operaciones abstractas
Una
@operación abstracta@
es \un procedimiento que puede
invocarse en el contexto de dos puertos vinculados. Su fracaso no afecta la
vinculación. Si los puertos son asimétricos, el puerto prescribirá si el
invocador es el objeto que cuenta con el puerto consumidor, el objeto con el
puerto suministrador o cualquiera de éstos. Si los puertos son simétricos o
asimétricos, el objeto restante es el realizador.\
Una operación abstracta es un procedimiento general completo, excepto para
la información transmitida al invocador en cado de fracaso. Una operación
abstracta falla cuando encuentra un
error abstracto
,
entonces la información que transmite se limita a informar sobre dicho error
abstracto. Para cada operación abstracta se prescribe si se notifica el fallo y
de ser así, que errores abstractos pueden presentarse.
Una operación abstracta se especifica con la macro ABSTRACT-OPERATION. Su definición es idéntica a la de la macro OPERATION de operaciones a distancia, especificada en la Recomendación X.219.
MACRO ABSTRACT-OPERATION ::= OPERATION
Un servicio abstracto comprende cero o más operaciones abstractas para cada tipo de puerto involucrado en esta disposición. Cuando participan varios tipos de puertos, pueden, pero no necesariamente, tener operaciones abstractas en común.
Nota
- La equivalente de ABSTRACT-OPERATION y
OPERATION ayuda a hacer trivial la realización SOD de un servicio abstracto;
véase el
10.1
.
8.5
Errores abstractos
Un
@error abstracto@
es \una condición excepcional que
puede surgir durante la ejecución de una operación abstracta, provocando su
fracaso.\
Cuando se infoma de un error abstracto, el ejecutor transmite al invocador
la identidad del error abstracto y posiblemente un objeto de información único
denominado su
parámetro
. Para cada error abstracto se
prescribe si se devuelve un parámetro y de ser así, su tipo.
Un error abstracto se especifica con la macro ABSTRACT-ERROR. Su definición es idéntica a la de la macro ERROR de operaciones a distancia, especificada en la Recomendación X.219.
MACRO ABSTRACT-ERROR ::= ERROR
Un servicio abstracto comprende cero o más errores abstractos notificados por sus operaciones abstractas.
Nota
- La equivalencia de ABSTRACT-ERROR y ERROR
ayudan a hacer trivial la realización SOD de un servicio abstracto; véase el
10.1
.
SECCIóN 3 -
9 Visión de conjunto
Una vez que la tarea de procesamiento de información distribuido se ha descrito y especificado en términos abstractos, es necesario establecer la forma en que cada aspecto debe realizarse. Como se sugirió anteriormente, cada aspecto puede admitir varias realizaciones concretas.
Esta sección establece principios para la realización concreta de servicios
y modelos abstractos. Una
x real
es el
sistema o proceso de computador, o el sistema abierto real que realiza
concretamente, un objeto abstracto de tipo
x
.
Esta sección cubre los siguientes asuntos:
a)Realizaciones ISA
b)Realizaciones de concesión.
Nota
- Los aspectos de un modelo asbtracto que se
subrayan aquí, son puertos abstractos y sus vinculaciones. Esto se debe a que
los puertos abstractos marcan el límite, no sólo entre objetos abstractos, sino
también entre sistemas físicos que realizan concretamente dichos objetos
abstractos. Así, los puertos abstractos y las vinculaciones son las partes del
modelo abstracto que, si se desea que exista interfuncionamiento de los
sistemas abiertos, deben construirse o ser construibles con los instrumentos
ISA.
10
Realizaciones ISA
Un objetivo primordial de las Recomendaciones del CCITT y de las Normas de la ISO es especificar cómo se realizan las tareas de procesamiento de información distribuida cuando se llevan a cabo por varios sistemas abiertos reales cooperantes.
En el entorno ISA, los objetos se realizan por medio de procesos de aplicación, en general con unas relaciones de correspondencia de muchos objetos a muchos procesos de aplicación. La comunicación entre objetos, realizada por procesos de aplicación en diferentes sistemas abiertos, se logra por medio de los protocolos de aplicación ISA (consistentes en contextos de aplicación). Un contexto de aplicación realiza así la vinculación, uso y desvinculación de varios pares de puertos.
La especificación de un contexto de aplicación se hace en términos de la operación coordinada de varios elementos de servicio-aplicación. La realización resulta especialmente idónea para especificar si un elemento de servicio-aplicación está definido para corresponder a cada puerto cuya comunicación debe aceptarse.
A continuación se examina la realización de vinculaciones y puertos abstractos por medio de ESA y CA. Se tienen en cuenta tanto las realizaciones SOD como las que no son SOD.
10.1
Realizaciones SOD
La realización concreta de puertos y vinculaciones con frecuencia es trivial cuando se logra por medio de operaciones a distancia.
Esto es porque resulta inmediato definir un servicio abstracto en el que existe un protocolo de aplicación basado en SOD, que sea funcionalmente idéntico a él. Esto a su vez es cierto, porque el marco de especificación de servicios abstractos es isomorfo con la especificación de protocolos de aplicación basados en el SOD. En el cuadro 1/X.407 se enumeran las correspondencias inherentes al isomorfismo.
Cuadro 1/X.407 [T1.407], p.
Las correspondencias del cuadro se deben a que los aspectos correspondientes
se especifican formalmente utilizando macros estrechamente relacionadas o
equivalentes, como se resume en el cuadro 2/X.407:
Cuadro 2/X.407 [T2.407], p.
En el anexo A se analizan por medio de un ejemplo las definiciones de CA y
ESA basadas en SOD que realizan concretamente puertos abstractos.
Para que la realización sea trivial, es necesario que exista una operación abstracta de vinculación que una todos los puertos que deben acoplarse por pares.
Nota
- Cuando en un servicio abstracto involucrado hay
más de un puerto (par) es necesario diseñar la operación abstracta de
vinculación para los puertos específicamente involucrados. (Actualmente) no
existe ninguna disposición para la síntesis automática de una vinculación
abstracta adecuada, basada por ejemplo, en las definiciones de operaciones
abstractas de vinculación definidas para los puertos individuales.
10.2
Realizaciones no SOD
La realización concreta de vinculaciones y puertos es una tarea más sustancial cuando se intenta por otros medios que no son operaciones a distancia y se puede decir muy poco sobre la propuesta general.
A pesar de lo anterior, son importantes las dos observaciones siguientes:
a)La realización concreta de un servicio abstracto es un protocolo de aplicación que se simplifica mucho al utilizar NSA.1 para definir sus UDPA. Esto se debe a que la especificación del protocolo puede importar simplemente los tipos y valores pertinentes de la especificación del servicio abstracto.
b)La realización concreta de un servicio abstracto cuyas operaciones abstractas no informan de sus resultados es conceptualmente sencilla. Esto se debe a que cada una de dichas operaciones abstractas representa una interacción que comprende una sola UDPA. A partir de estas interacciones, las más simples posibles, se puede en forma arbitraria, construir otras complejas.
11 Realizaciones de propiedad
Un objetivo secundario de las Recomendaciones del CCITT y de las Normas de la ISO es garantizar que las partes de una tarea de procesamiento de información distribuido que son realizadas por medios propios, mantengan la funcionalidad general deseada del sistema.
A continuación se examina brevemente la realización de unión y puertos abstractos por medios propios. Se consideran tanto las realizaciones distribuidas, como las no distribuidas.
11.1
Realizaciones distribuidas
La realización concreta de puertos y vinculaciones por medio de concesiones de protocolos de comunicación computarizados es un asunto local. La especificación de la funcionalidad visible, incluida en el servicio abstracto proporciona una guía a los ejecutores de las realizaciones de propiedad para que cuando dichas realizaciones sean correcctas, pueden jugar el papel adecuado en la tarea general.
11.2
Realizaciones no distribuidas
La realización concreta de puertos y vinculaciones por medio de mecanismos dentro de un solo computador es un asunto local. Al igual que en el caso considerado en el 11.1 , la especificación de servicio abstracto sirve como guía al ejecutor para garantizar que la realización en propiedad pueda, de todas formas, desempeñar el papel adecuado en la tarea general.
ANEXO A (a la Recomendación X.407)
Ejemplo del uso de la
notación de servicio abstracto
Este anexo no forma parte de esta
Recomendación.
Este anexo ilustra el uso de la notación de servicio y modelo abstracto por
medio de un ejemplo. El ejemplo implica dos sistemas, los
sistemas verde
y
amarillo
y sus
entornos, los
entornos verde
y
amarillo
.
El ejemplo utiliza las notaciones de modelo abstracto para describir por separado los entornos (Î A.2 y A.4) y para mostrar cómo se relacionan sus sistemas: uno está construido a partir del otro (Î A.6). Para describir las capacidades de cada sistema (Î A.3 y A.5) se utiliza la notación de servicio abstracto. El ejemplo concluye realizando los puertos de los sistemas como CA y ESA utilizando la notación SOD de la Recomendación X.219 según sea adecuado para la comunicación ISA (Î A.7 y A.8).
A.1
Asignación de identificadores de objeto
Los módulos NSA.1 definidos en este anexo requieren la asignación de varios identificadores de objeto. Todos se definen a continuación utilizando NSA.1. Las asignaciones son definitivas, excepto las de los módulos NSA.1 y las referentes a los convenios de definición del servicio de aplicación. Las asignaciones definitivas de los primeros se presentan en los módulos mismos; otras referencias a ellas aparecen en las cláusulas IMPORT. La última es fija.
ExampleObjectIdentifiers {^joint-iso-ccitt
mhs-motis(6) asdc(2) example(1) modules(0) object-identifiers(0)^}
DEFINITIONS IMPLICIT TAGS ::=
BEGIN --
Prólogo
--
Exporta todo
.
IMPORTS --
nada
--;
ID ::= OBJECT IDENTIFIER
--
Ejemplo (no definitivo) de los convenios de definición
del servicio abstracto
id-asdc-ex ID ::= {^joint-iso-ccitt mhs-motis(6) asdc(2) example(1)^}
--
no definitivo
--
Categorías
id-mod ID ::= {^id-asdc-ex 0^} --
módulos; no
definitivo
id-ot ID ::= {^id-asdc-ex 1^} --
tipos objeto
id-pt ID ::= {^id-asdc-ex 2^} --
tipos puerto
id-ref ID ::= {^id-asdc-ex 3^} --
perfeccionamientos
id-ac ID ::= {^id-asdc-ex 4^} --
contextos de aplicación
id-ase ID ::= {^id-asdc-ex 5^} --
elementos del servicio
de aplicación
id-as ID ::= {^id-asdc-ex 6^} --
sintaxis abstractas
--
Módulos
id-mod-object-identifiers ID ::= {^id-mod 0^} --
no
definitivo
id-mod-ye-refinement ID ::= {^id-mod 1^} --
no
definitivo
id-mod-y-abstract-service ID ::= {^id-mod 2^} --
no
definitivo
id-mod-ge-refinement ID ::= {^id-mod 3^} --
no
definitivo
id-mod-g-abstract-service ID ::= {^id-mod 4^} --
no
definitivo
id-mod-ys-refinement ID ::= {^id-mod 5^} --
no
definitivo
id-mod-ys-realization ID ::= {^id-mod 6^} --
no
definitivo
id-mod-gs-realization ID ::= {^id-mod 7^} --
no
definitivo
--
Tipos objeto
id-ot-y-environment ID ::= {^id-ot 0^} id-ot-y-user ID ::= {^id-ot 1^} id-ot-y-system ID ::= {^id-ot 2^} id-ot-g-environment ID ::= {^id-ot 3^} id-ot-g-user ID ::= {^id-ot 4^} id-ot-g-manager ID ::= {^id-ot 5^} id-ot-g-system ID ::= {^id-ot 6^} id-ot-agent ID ::= {^id-ot 7^}
--
Tipos puerto
id-pt-y-use ID ::= {^id-pt 0^} id-pt-g-use ID ::= {^id-pt 1^} id-pt-g-management ID ::= {^id-pt 2^}
--
Perfeccionamientos
id-ref-y-environment ID ::= {^id-ref 0^} id-ref-g-environment ID ::= {^id-ref 1^} id-ref-y-system ID ::= {^id-ref 2^}
--
Contextos de aplicación
id-ac-y-use ID ::= {^id-ac 0^} id-ac-g-use ID ::= {^id-ac 1^} id-ac-g-management ID ::= {^id-ac 2^}
--
Elementos del servicio de aplicación
id-ase-y-use ID ::= {^id-ase 0^} id-ase-g-use ID ::= {^id-ase 1^} id-ase-g-management ID ::= {^id-ase 2^}
--
Sintaxis abstractas
id-as-y-use ID ::= {^id-as 0^} id-as-g-use ID ::= {^id-as 1^} id-as-g-management ID ::= {^id-as 2^}
END --
de
IdentificadoresObjetoEjemplo
A.2
Perfeccionamiento del entorno amarillo
El entorno amarillo, descrito en la figura A-1/X.407, se perfecciona formalmente más adelante, utilizando las macros OBJECT y REFINE.
Figura A-1/X.407, p.
Como lo indica la figura A-1/X.407 y lo confirma más adelante la
especificación NSA.1, el entorno amarillo puede modelarse como un objeto que
puede descomponerse en un objeto central, el
sistema
amarillo
, y un número cualquiera de otros objetos periféricos,
usuarios amarillos
. El sistema amarillo interactúa con los
usuarios amarillos por medio de sus puertos de
utilización
amarillos
.
YellowEnvironmentRefinement {^joint-iso-ccitt
mhs-motis(6) asdc(2) example(1) modules(0) ye-refinement(1)^}
DEFINITIONS IMPLICIT TAGS ::=
BEGIN --
Prólogo
EXPORTS yellow-environment, yellow-environment-refinement, yellow-system, yellow-user;
IMPORTS
--
Servicio abstracto amarillo
yellow-use
.^.^.^.
FROM YellowAbstractService {^joint-iso-ccitt
mhs-motis(6) asdc(2) example(1) modules(0) y-abstract-service(2)^}
--
Identificadores de objeto - ejemplo
id-ot-y-environment, id-ot-y-system, id-ot-y-user,
id-ref-y-environment
.^.^.^.
FROM ExampleObjectIdentifiers {^joint-iso-ccitt
mhs-motis(6) asdc(2) example(1) modules(0) object-identifiers(0)^}
--
Notación de servicio abstracto
OBJECT, REFINE
.^.^.^.
FROM AbstractServiceNotation {^joint-iso-ccitt
mhs-motis(6) asdc(2) modules(0) notation(1)^};
--
Entorno amarillo
yellow-environment OBJECT ::= id-ot-y-environment
--
Perfeccionamiento del entorno amarillo
yellow-environment-refinement REFINE yellow-environment AS yellow-user RECURRING yellow-system yellow-user [S] PAIRED WITH yellow-user ::= id-ref-y-environment
--
Tipos de objeto componente
yellow-user OBJECT PORTS^{ yellow-user [C]^} ::= id-ot-y-user
yellow-system OBJECT PORTS^{ yellow-user [S]^} ::= id-ot-y-system
END --
del perfeccionamiento del entorno amarillo
A.3
Definición del servicio abstracto amarillo
El servicio abstracto que proporciona el sistema amarillo a sus usuarios se define formalmente más adelante, utilizando las macros PORT y ABSTRACT-BIND, -OPERATION y -ERROR.
Como se indica en la especificación NSA.1, el servicio abstracto que
proporciona el sistema amarillo comprende puertos de un solo tipo: de usuario
amarillo. Cada puerto comprende un número de operaciones abstractas que
informan colectivamente sobre un número de errores abstractos. El sistema
amarillo protege sus puertos por medio de una operación abstracta de
vinculación,
vinculación amarilla
, que requiere que los
usuarios se identifiquen en forma convincente antes de que pueda haber una
interacción ulterior. Una operación abstracta de
desvinculación
amarilla
, constituye el paso final necesario para concluir una
interacción.
YellowAbstractService {^joint-iso-ccitt
mhs-motis(6) asdc(2) example(1) modules(0) y-abstract-service(2)^}
DEFINITIONS IMPLICIT TAGS ::=
BEGIN --
Prólogo
EXPORTS AuthenticateUser, Yellow-operation-1, .^.^. yellow-use;
IMPORTS
--
Ejemplo de identificadores de objeto
id-pt-y-use
.^.^.^.
FROM ExampleObjectIdentifiers {^joint-iso-ccitt
mhs-motis(6) asdc(2) example(1) modules(0) object-identifiers(0)^}
--
Notación de servicio abstracto
ABSTRACT-BIND, ABSTRACT-ERROR, ABSTRACT-OPERATION, PORT
.^.^.^.
FROM AbstractServiceNotation {^joint-iso-ccitt
mhs-motis(6) asdc(2) modules(0) notation(1)^};
--
Tipo de puerto
yellow-use PORT CONSUMER INVOKES^{ Yellow-operation-1, .^.^.^} ::= id-pt-y-use
--
Operación abstracta de vinculación
Credentials ::= SET^{ name [0] IA5String, password [1] IA5String^}
YellowBind ::= ABSTRACT-BIND TO {^yellow-use[S]^} BIND ARGUMENT credentials Credentials BIND-ERROR ENUMERATED^{ name-or-password-invalid(0)^}
--
Operación abstracta de desvinculación
YellowUnbind ::= ABSTRACT-UNBIND FROM {^yellow-use[S]^}
--
Operaciones abstractas
Yellow-operation-1 ::= ABSTRACT-OPERATION ARGUMENT .^.^. RESULT .^.^. ERRORS^{ yellow-error-1, .^.^.^} .^.^.
--
Errores abstractos
yellow-error-1 ABSTRACT-ERROR PARAMETER .^.^. ::= 1 .^.^.
END --
del servicio abstracto amarillo
A.4
Perfeccionamiento del
entorno verde
El entorno verde, descrito en la figura A-2/X.407, se perfecciona formalmente más adelante, utilizando las macros OBJECT y REFINE.
Figura A-2/X.407, p.
Como indica la figura A-2/X.407 y lo confirma la especificación NSA.1 que
sigue, el entorno verde puede modelarse como un objeto que puede descomponerse
en un objeto central, el
sistema verde
; un número cualquiera
de otros objetos periféricos,
usuarios verdes
; y cualquier
número de otros objetos adicionales,
gestores verdes
. El
sistema verde interactúa con los gestores y usuarios verdes por medio de sus
puertos de
usuarios verdes
y con los gestores verdes
(aislados) por medio de sus puertos de
gestión verdes
.
GreenEnvironmentRefinement {^joint-iso-ccitt
mhs-motis(6) asdc(2) example(1) modules(0) ge-refinement(3)^}
DEFINITIONS IMPLICIT TAGS ::=
BEGIN --
Prólogo
EXPORTS green-environment, green-environment-refinement, green-manager, green-system, green-user;
IMPORTS
--
Servicio abstracto verde
green-use, green-management
.^.^.^.
FROM GreenAbstractService {^joint-iso-ccitt
mhs-motis(6) asdc(2) example(1) modules(0) g-abstract-service(4)^}
- -
Ejemplo de identificadores de objeto
id-ot-g-environment, id-ot-g-manager, id-ref-g-environment
id-ot-g-user, id-ot-g-sytem,
.^.^.^.
FROM ExampleObjectIdentifiers {^joint-iso-ccitt
mhs-motis(6) asdc(2) example(1) modules(0) object-identifiers(0)^}
--
Notación de servicio abstracto
OBJECT, REFINE
.^.^.^.
FROM AbstractServiceNotation {^joint-iso-ccitt
mhs-motis(6) asdc(2) modules(0) notation(1)^};
--
Entorno verde
green-environment OBJECT ::= id-ot-g-environment
--
Perfeccionamiento del entorno verde
green-environment-refinement REFINE green-environment AS green-user RECURRING green-manager RECURRING green-system green-use [S] PAIRED WITH {^green-user, green-manager^} green-management [S] PAIRED WITH {^green-manager^} ::= id-ref-g-environment
--
Tipos de objeto componente
green-user OBJECT PORTS^{ green-use [C]^} ::= id-ot-g-user
green-manager OBJECT PORTS^{ green-use [C], green-management [C]^} ::= id-ot-g-manager
green-system OBJECT PORTS^{ green-use [S], green-management [S]^} ::= id-ot-g-system
END --
del perfeccionamiento del entorno verde
A.5
Definición del
servicio
abstracto verde
El servicio abstracto que proporciona el sistema verde a sus usuarios y gestores se define formalmente más adelante utilizando las macros PORT y ABSTRACT-BIND, -OPERATION y -ERROR.
Como se indica en la especificación NSA.1, el servicio abstracto que
proporciona el sistema verde comprende puertos de dos tipos, verde de usuario y
verde de gestión. Un puerto de cualquiera de los dos tipos comprende un número
de operaciones abstractas que notifican de forma colectiva un cierto número de
errores abstractos. El sistema verde protege sus puertos por medio de
operaciones abstractas de vinculación,
autenticación de
usuario
y
autenticación de gestor
, que requieren que
los usuarios y gestores se identifiquen en forma convincente antes de poder
continuar la interacción. No se especifica ninguna operación abstracta de
desvinculación, lo que indica que no se requiere un paso de finalización para
concluir una interacción.
GreenAbstractService {^joint-iso-ccitt
mhs-motis(6) asdc(2) example(1) modules(0) g-abstract-service(4)^}
DEFINITIONS IMPLICIT TAGS ::=
BEGIN --
Prólogo
EXPORTS AuthenticateManager, AuthenticateUser, green-management, Green-management-operation-1, .^.^. green-use, Green-use-operation-1, .^.^.;
IMPORTS
--
Ejemplo de identificadores de objeto
id-pt-g-use, id-pt-g-management
.^.^.^.
FROM ExampleObjectIdentifiers {^joint-iso-ccitt
mhs-motis(6) asdc(2) example(1) modules(0) object-identifiers(0)^}
--
Notación de servicio abstracto
PORT, ABSTRACT-BIND, ABSTRACT-OPERATION, ABSTRACT-ERROR
.^.^.^.
FROM AbstractServiceNotation {^joint-iso-ccitt
mhs-motis(6) asdc(2) modules(0) notation(1)^};
--
Tipos de puerto
green-use PORT CONSUMEER INVOKES^{ Green-use-operation-1, .^.^.^} ::= id-pt-g-use
green-management PORT CONSUMER INVOKES^{ Green-management-operation-1, .^.^.^} ::= id-pt-g-management
--
Operaciones abstractas - vinculación
Credentials ::= SET^{ name [0] IA5String, password [1] IA5String^}
AuthenticateUser ::= ABSTRACT-BIND ARGUMENT credentials Credentials BIND-ERROR ENUMERATED^{ name-or-password-invalid(0)^}
AuthenticateManager ::= ABSTRACT-BIND ARGUMENT credentials Credentials BIND-ERROR ENUMERATED^{ name-or-password-invalid(0), not-a-manager (1)^}
--
Operaciones abstractas
Green-use-operation-1 ::= ABSTRACT-OPERATION ARGUMENT .^.^. RESULT .^.^. ERRORS^{ green-error-1, .^.^.^} .^.^.
Green-management-operation-1 ::= ABSTRACT-OPERATION ARGUMENT .^.^. RESULT .^.^. ERRORS^{ green-error-1, .^.^.^} .^.^.
--
Errores abstractos
green-error-1 ABSTRACT-ERROR PARAMETER .^.^. ::= 1 .^.^.
END --
del servicio abstracto verde
A.6
Perfeccionamiento del sistema amarillo
El sistema amarillo, descrito en la figura A-3/X.407, se perfecciona formalmente más adelante utilizando las macros OBJECT y REFINE.
Figura A-3/X.407, p.
Como indica la figura A-3/X.407 y lo confirma la especificación NSA.1 el
sistema amarillo, cuando se examina de cerca, tiene componentes. En especial,
el sistema amarillo comprende el sistema verde y los gestores verdes, aumentado
por objetos de una variedad hasta ahora no vista, el
agente
. Un
agente
actúa como
intermediario entre el sistema verde y el usuario amarillo. Se podría decir que
es un valor añadido al sistema verde. En cualquier caso, es el proveedor de un
puerto de uso amarillo y el consumidor de un puerto de uso verde.
YellowSystemRefinement {^joint-iso-ccitt
mhs-motis(6) asdc(2) example(1) modules(0) ys-refinement(5)^}
DEFINITIONS IMPLICIT TAGS ::=
BEGIN --
Prólogo
EXPORTS agent, yellow-system-refinement;
IMPORTS
--
Perfeccionamiento del entorno amarillo
yellow-system, yellow-use
.^.^.^.
FROM YellowEnvironmentRefinement {^joint-iso-ccitt
mhs-motis(6) asdc(2) example(1) modules(0) ye-refinement(1)^}
--
Perfeccionamiento del entorno verde
green-management, green-manager, green-system,
green-use
.^.^.^.
FROM GreenEnvironmentRefinement {^joint-iso-ccitt
mhs-motis(6) asdc(2) example(1) modules(0) ge-refinement(3)^}
--
Ejemplo de identificadores de objeto
id-ot-agent, id-ref-y-system
.^.^.^.
FROM ExampleObjectIdentifiers {^joint-iso-ccitt
mhs-motis(6) asdc(2) example(1) modules(0) object-identifiers(0)^}
--
Notación de servicio abstracto
OBJECT REFINE
FROM AbstractServiceNotation {^joint-iso-ccitt
mhs-motis(6) asdc(2) modules(0) notation(1)^};
--
Perfeccionamiento del entorno amarillo
yellow-system-refinement REFINE yellow-system AS agent RECURRING yellow-use [S] VISIBLE green-manager RECURRING green-system green-use [S] PAIRED WITH agent, green-manager green-management [S] PAIRED WITH green-manager ::= id-ref-y-system
--
Tipo de objeto componente
agent OBJECT PORTS^{ yellow-use [S], green-use [C]^} ::= id-ot-agent
END --
del perfeccionamiento del sistema amarillo
A.7
Realización del sistema amarillo
El servicio abstracto del sistema amarillo se realiza formalmente a continuación, por medio del SOD, utilizando las macros APPLICATION-CONTEXT y APPLICATION-SERVICE-ELEMENT de la Recomendación X.219.
Como se indica en la especificación NSA.1, el servicio abstracto que
proporciona el sistema amarillo se realiza como una sola ESA, la
ESA-uso-amarillo
, y un solo CA con el correspondiente
CA-uso-amarillo
. Cada operación abstracta de vinculación,
operación abstracta o error abstracto en el servicio abstracto tiene una
operación correspondiente de unión, operación o error equivalente y en la
realización basada en el SOD respectivamente.
Obsérvese que las operaciones reciben asignación de valores enteros; las operaciones abstractas correspondientes ni requieren, ni reciben dichos valores.
YellowSystemRealization {^joint-iso-ccitt
mhs-motis(6) asdc(2) example(1) modules(0) ys-realization(6)^}
DEFINITIONS IMPLICIT TAGS ::=
BEGIN --
Prólogo
EXPORTS yellow-use-AC, yellow-use-ASE;
IMPORTS
--
Servicio abstracto amarillo
Yellow-operation-1, .^.^. yellow-use, YellowBind,
YellowUnbind
.^.^.^.
FROM YellowAbstractService {^joint-iso-ccitt
mhs-motis(6) asdc(2) example(1) modules(0) y-abstract-service(2)^}
--
Ejemplo identificadores de objeto
id-ac-y-use, id-as-y-use, id-ase-y-use
.^.^.^.
FROM ExampleObjectectIdentifiers {^joint-iso-ccitt
mhs-motis(6) asdc(2) example(1) modules(0) object-identifiers(0)^}
UDPA operaciones a distancia
rOSE
.^.^.^.
FROM Remote-Operations-APDUs {^joint-iso-ccitt
remote-operations(4) apdus(1)^}
--
Control de asociación
aCSE
.^.^.^.
FROM Remote-Operations-Notation-extension
{^joint-iso-ccitt remote-operations(4)
notation-extension(2)^}
--
Ampliación de notación de operaciones a
distancia
APPLICATION-CONTEXT, APPLICATION-SERVICE-ELEMENT
.^.^.^.
FROM Remote-Operations-Notation-extension {^joint-iso-ccitt
remote-operations(4) notation-extension(2)^};
aCSE-AS OBJECT INDENTIFIER ::= {^joint-iso-ccitt association-control(2) abstractSyntax(1) apdus(0) version1(1)^}
--
Contexto de aplicaciones
yellow-use-AC APPLICATION-CONTEXT APPLICATION SERVICE ELEMENTS {^aCSE^} BIND YellowBind UNBIND YellowUnbind REMOTE OPERATIONS {^rOSE^} INITIATOR CONSUMER OF {^yellow-use-ASE^} ABSTRACT SYNTAXES {^yellow-use-AS, aCSE-AS^} ::= id-ac-y-use
--
Elemento de servicio de aplicación
yellow-use-ASE APPLICATION-SERVICE-ELEMENT CONSUMER INVOKES^{ yellow-operation-1, .^.^.^} ::= id-ase-y-use
yellow-operation-1 Yellow-operation ::= 1 .^.^.
--
Sintaxis abstracta
yellow-use-AS OBJECT IDENTIFIER ::= id-as-y-use
END --
de realización del sistema amarillo
A.8
Realización del sistema verde
El servicio abstracto del sistema verde se realiza formalmente más adelante, por medio del SOD, utilizando las macros APPLICATION-CONTEXT y APPLICATION-SERVICE-ELEMENT de la Recomendación X.219.
Como se indica en la especificación NSA.1, el servicio abstracto que
proporciona el sistema verde se realiza como dos ESA, la
ESA-uso-verde
y la
ESA-gestión-verde
y
los dos CA correspondientes,
CA-uso-verde
y
CA-gestión-verde
. Cada operación abstracta de unión,
operación abstracta o error abstracto en el servicio abstracto tienen una
operación correspondiente y equivalente de vinculación, operación o error,
respectivamente en su realización basada en el SOD.
Obsérvese que estas operaciones reciben valores enteros, las operaciones abstractas correspondientes ni requieren, ni reciben dichos valores.
GreenSystemRealization {^joint-iso-ccitt
mhs-motis(6) asdc(2) example(1) modules(0) gs-realization(7)^}
DEFINITIONS IMPLICIT TAGS ::=
BEGIN --
Prólogo
EXPORTS green-management-AC, green-management-ASE, green-use-AC, green-use-ASE;
IMPORTS
--
Servicio abstracto verde
AuthenticateManager, AuthenticateUser,
green-management, Green-management-operation-1, .^.^.
green-use, Green-use-operation-1, .^.^.
.^.^.^.
FROM GreenAbstractService {^joint-iso-ccitt
mhs-motis(6) asdc(2) example(1) modules(0) g-abstract-service(4)^}
--
Ejemplo de identificadores de objeto
id-ac-g-use, id-ase-g-use, id-as-g-use,
id-ac-g-management, id-ase-g-management, id-as-g-management
.^.^.^.
FROM ExampleObjectIdentifiers {^joint-iso-ccitt
mhs-motis(6) asdc(2) example(1) modules(0) object-identifiers(0)^}
--
UDPA de operaciones a distancia
rOSE
.^.^.^.
FROM Remote-Operations-APDUs {^joint-iso-ccitt
remote-operations(4) apdus(1)^}
--
Control de asociación
aCSE
.^.^.^.
FROM Remote-Operations-Notation-extension {^joint-iso-ccitt
remote-operations(4) notation-extension(2)^}
--
Ampliación de notación de operaciones a
distancia
APPLICATION-CONTEXT, APPLICATION-SERVICE-ELEMENT
.^.^.^.
FROM Remote-Operations-Notation-extension {^joint-iso-ccitt
remote-operations(4) notation-extension(2)^};
aCSE-AS OBJECT IDENTIFIER ::= {^joint-iso-ccitt association-control(2) abstractSyntax(1) apdus(0) version(1)^}
--
Contexto de aplicación
green-use-AC APPLICATION-CONTEXT APPLICATION SERVICE ELEMENTS {^aCSE^} BIND AuthenticateUser UNBIND NoOperation REMOTE OPERATIONS {^rOSE^} INITIATOR CONSUMER OF {^green-use-ASE^} ABSTRACT SYNTAXES {^green-use-AS, aCSE-AS^} ::= id-ac-g-use
green-management-AC APPLICATION-CONTEXT APPLICATION SERVICE ELEMENTS {^aCSE^} BIND AuthenticateManager UNBIND NoOperation REMOTE OPERATIONS {^rOSE^} INITIATOR CONSUMER OF {^green-management-ASE^} ABSTRACT SYNTAXES {^green-management-AS, aCSE-AS^} ::= id-ac-g-management
NoOperation ::= UNBIND
--
Elementos de servicio de aplicación
green-use-ASE APPLICATION-SERVICE-ELEMENT CONSUMER INVOKES^{ green-use-operation-1, .^.^. } ::= id-ase-g-use
green-management-ASE APPLICATION-SERVICE-ELEMENT CONSUMER INVOKES^{ green-management-operation-1, .^.^.^} ::= id-ase-g-management
green-use-operation-1 Green-use-operation-1 ::= 1 .^.^.
green-management-operation-1 Green-management-operation-1 ::= 50 .^.^.
--
Sintaxis abstractas
green-use-AS OBJECT IDENTIFIER ::= id-as-g-use
green-management-AS OBJECT IDENTIFIER ::= id-as-g-management
END --
de realización del sistema verde
ANEXO B (a la Recomendación X.407)
Definición de las
referencias de identificadores de objeto
Este anexo define, con fines de referencia, varios de los identificadores de objeto citados en los módulos NSA.1 del anexo C. Utiliza la NSA.1.
Con excepción de los asignados en el anexo A, todos los identificadores de objeto que asigna esta Recomendación están considerados en este anexo. El anexo es definitivo, excepto para los propios módulos NSA.1 y el objeto de los convenios de definición de servicio de aplicación. Las asignaciones definitivas para los módulos se presentan en los módulos mismos; en la sección IMPORT aparecen otras referencias. La última es fija.
ASDCObjectIdentifiers {^joint-iso-ccitt
mhs-motis(6) asdc(2) modules(0) object-identifiers(0)^}
DEFINITIONS IMPLICIT TAGS ::=
BEGIN --
Prólogo
--
Exporta todo
.
IMPORTS --
nada
--;
ID ::= OBJECT IDENTIFIER
--
Convenios (no definitivos) de definición del servicio
abstracto
id-asdc ID ::= {^joint-iso-ccitt mhs-motis(6) asdc(2)^} --
no definitivo
--
Categorías
id-mod
ID ::= {^id-asdc 0^} --
módulos; no definitivo
id-ex ID ::= {^id-asdc 1^} --
ejemplo; no definitivo
--
Módulos
id-mod-object-identifiers ID ::= {^id-mod 0^} --
no
definitivo
id-mod-notation ID ::= {^id-mod 1^} --
no
definitivo
END --
de identificadores de objeto ASDC
ANEXO C (a la Recomendación X.407)
Definición de la
referencia de notación
Este anexo, complemento de la sección 2, define, con fines de referencia, la notación para especificar modelos y servicios abstractos. Utilizar la NSA.1.
AbstractServiceNotation {^joint-iso-ccitt
mhs-motis(6) asdc(2) modules(0) notation(1)^}
DEFINITIONS IMPLICIT TAGS ::=
BEGIN --
Prólogo
EXPORTS ABSTRACT-BIND, ABSTRACT-ERROR, ABSTRACT-OPERATION, ABSTRACT-UNBIND, OBJECT, PORT, REFINE;
IMPORTS
--
Notación de operaciones a distancia
BIND, ERROR, OPERATION, UNBIND
----
FROM Remote-Operations-Notation {^joint-iso-ccitt
remote-operations(4) notation(0)^};
--
Macro objeto
OBJECT MACRO ::= BEGIN
TYPE NOTATION
::=
"PORTS"
"{"
PortList
"}"
|
empty
VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER)
PortList
::= Port
"^,^"
PortList | Port
Port ::= value (PORT) PortType
PortType ::= Symmetric | Asymmetric
Symmetric ::= empty Asymmetric ::= Consumer | Supplier
Consumer
::=
"[C]"
Supplier ::=
"[S]"
END
--
Macro puerto
PORT MACRO ::= BEGIN
TYPE NOTATION ::= Operations | empty VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER)
Operations ::= Symmetrical | Asymmetrical
Symmetrical
::=
"ABSTRACT"
"OPERATIONS"
"{"
OperationList
"}"
Asymmetrical ::= OneSided | TwoSided
OneSided ::= Consumer | Supplier TwoSided ::= Consumer Supplier | Supplier Consumer
Consumer
::=
"CONSUMER"
"INVOKES"
"{"
OperationList
"}"
Supplier ::=
"SUPPLIER"
"INVOKES"
"{"
OperationList
"}"
OperationList
::= Operation
","
OperationList | Operation
Operation ::= value (ABSTRACT-OPERATION)
END
--
Macro perfeccionamiento
REFINE MACRO ::= BEGIN
TYPE NOTATION
::= Object
"AS"
ComponentList
VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER)
ComponentList ::= Component ComponentList | Component Component ::= ObjectSpec PortSpecList
ObjectSpec
::= Object | Object
"RECURRING"
PortSpecList ::= PortSpec PortSpecList | PortSpec PortSpec ::= value (PORT) PortType PortStatus
PortType
::= Consumer | Supplier | empty
Consumer ::=
"[C]"
Supplier ::=
"[S]"
PortStatus
::=
"VISIBLE"
|
"PAIRED"
"WITH"
ObjectList
ObjectList
::= Object
"^,^"
ObjectList | Object
Object ::= value (OBJECT)
END
--
Macros vinculación abstracta, desvinculación, operación
y error
ABSTRACT-BIND MACRO ::= BEGIN
TYPE NOTATION ::= Ports Bind VALUE NOTATION ::= value (VALUE BindType)
Ports
::=
"TO"
"{"
PortList
"}"
| empty
PortList ::= Port
"^,^"
PortList | Port
Port ::= value (PORT) PortSide
PortSide ::= Consumer | Supplier | empty
Consumer ::=
"[C]"
Supplier ::=
"[S]"
Bind
::= type (BindType) --
ha de ser un tipo BIND
| empty &lab;BindType ::= BIND>
END
ABSTRACT-UNBIND MACRO ::= BEGIN
TYPE NOTATION ::= Ports Unbind VALUE NOTATION ::= value (VALUE UnbindType)
Ports
::=
"FROM"
"{"
PortList
"}"
| empty
PortList ::= Port
"^,^"
PortList | Port
Port ::= value (PORT) PortSide
PortSide ::= Consumer | Supplier | empty
Consumer ::=
"[C]"
Supplier ::=
"[S]"
Unbind
::= type (UnbindType) --
ha de ser
un tipo UNBIND
| empty &lab;UnbindType ::= UNBIND>
END
ABSTRACT-OPERATION MACRO ::= OPERATION
ABSTRACT-ERROR MACRO ::= ERROR
END --
de notación de servicio abstracto
ANEXO D (a la Recomendación X.407)
Diferencias entre la
Recomendación del CCITT y la Norma de la ISO
Este
anexo no forma parte de esta Recomendación.
Este anexo enumera todas las diferencias, salvo las puramente estilísticas, entre esta Recomendación y la Norma internacional ISO correspondiente.
No existen diferencias entre las dos especificaciones.
ANEXO E (a la Recomendación X.407)
índice
Este anexo
constituye el índice de esta Recomendación. Proporciona el número o números de
apartado(s) en que se define cada elemento de las diferentes categorías. La
cobertura de cada categoría es exhaustiva.
Este anexo presenta un índice de los elementos (si los hay) en las siguientes categorías:
a) abreviaturas;
b) términos;
c) elementos de información;
d) módulos NSA.1;
e) macros NSA.1;
f) tipos NSA.1;
g) valores NSA.1;
h)
acuerdos bilaterales
;
i) elementos que requieren ulterior estudio;
j) elementos por preparar.
E.1
Abreviaturas
NSA.1 3
CA 3
ESA 3
ISA 3
SOD 3
UDPA 3
E.2
Términos
argumento 8.1
asociación 7.3
asociación abstracta 7.3
asimétrico 7.2
concordancia 7.2
consumidor 7.2
desvinculación 7.2
ejecución 8.1
ejecutador 8.1
error abstracto 8.5
información de error 8.3
iniciador 8.2
invocación 8.1
invocador 8.1
modelo 7
modelo abstracto 7
objeto 7.1
objeto abstracto 7.1
operación abstracta 8.4
operación abstracta de desvinculación 8.3
parámetro 8.5
perfeccionamiento 7.4
perfeccionamiento abstracto 7.4
procedimiento 8.1
procedimiento abstracto 8.1
proveedor 7.3
proveedor del servicio abstracto 7.3
puerto 7.2
puerto abstracto 7.2
real 9
realizador
respondedor 8.2
resultado 8.1
servicio abstracto 7.3
simétrico 7.2
suministrador 7.2
usuario 7.3
usuario de servicio abstracto 7.3
vinculación 7.2
vinculado 7.2
(H.T.=OUI)
TAB.???
FICHIER: H.T. =
(87.TA.100.S)
(SANS FORMULES) Tableaux: 14 - Tabulateurs: 0
(BT..) Disk ... NF../... (OPM = ..)
(87.TE.08.S)
(A1.23s) / [26s]
FOLIOS: 272 - 300 (DO
PRC.COSY.2)
MEP {TPS.NON.PHOTO "[PA1]"} : OK= [1]
Saisie diskettes 582-583 24.08.89 SJ/RM
ID + Vérif. + diskette MAJ + laser 02.10.89 PV
Corr. LASER (1re épreuve) = 3eme 23.10.89 YB
Espaces réservés + Transfert + Impr. 25.10.89 PC
AJOUTER (PA1) (CL1,0,0,0) pour MEP
MEP + LASER 2.11.89 GH/PC
Corr. MEP ........ ..
Insertion des tableaux (tabulateurs 0) 2.11.89 PC
BAT 20.11.89 AF
MAJ s/disquettes 7.12.89 CD
Recomendación X.411
SISTEMAS DE TRATAMIENTO DE MENSAJES:
SISTEMA DE TRANSFERENCIA DE MENSAJES:
DEFINICIóN DEL SERVICIO ABSTRACTO Y PROCEDIMIENTOS
(Málaga-Torremolinos, 1984; modificada en Melbourne, 1988)
El establecimiento en diversos países de servicios telemáticos y de servicios
de mensajes con almacenamiento y retransmisión, controlados por computador, y
asociados a redes públicas de datos, crea la necesidad de establecer normas que
faciliten el intercambio internacional de mensajes entre los abonados a estos
servicios.
El CCITT,
considerando
(a) la necesidad de sistemas de tratamiento de mensajes;
(b) la necesidad de transferir y almacenar mensajes de diferentes tipos;
(c) que la Recomendación X.200 define el modelo de referencia de interconexion de sistemas abiertos para aplicaciones del CCITT;
(d) que las Recomendaciones X.208, X.217, X.218 y X.219 sirven de base para las aplicaciones del CCITT;
(e) que las Recomendaciones de la serie X.500 definen los sistemas de guía;
(f)que los sistemas de tratamiento de mensajes se definen en una serie de Recomendaciones: X.400, X.402, X.403, X.407, X.408, X.411, X.413 y X.419; y
(g) que la mensajería interpersonal se define en las Recomendaciones X.420 y T.330,
recomienda por unanimidad
(1) que el servicio abstracto del sistema de transferencia de mensajes (STRM) se define en la sección 2;
(2) que el servicio abstracto del agente de transferencia de mensajes ATM se define en la sección 3;
(3) que los procedimientos ejecutados por los agentes de transferencia de mensajes (ATM) para garantizar el correcto funcionamiento distribuido del sistema de transferencia de mensajes se definen en la sección 4.
íNDICE
SECCIóN 1 -
Introducción
0Introducción
1Campo de aplicación
2Referencias
3Definiciones
4Abreviaturas
5Convenios
SECCIóN 2 -
Servicio abstracto del sistema de
transferencia de mensajes
6Modelo del sistema de transferencia de mensajes
7Visión de conjunto del servicio abstracto del sistema de transferencia de mensajes
8Definición del servicio abstracto del sistema de transferencia de mensajes
9Definición de la sintaxis abstracta del sistema de transferencia de mensajes
SECCIóN 3 -
Servicio abstracto de agente de transferencia
de mensajes
10Modelo perfeccionado del sistema de transferencia de mensajes
11Visión de conjunto del servicio abstracto del agente de transferencia de mensajes
12Definición del servicio abstracto de agente de transferencia de mensajes
13Definición de la sintaxis abstracta de agente de transferencia de mensajes
SECCIóN 4 -
Procedimientos de funcionamiento distribuido
del STRM
14Procedimientos de funcionamiento distribuido del STRM
Anexo A
-Definición de referencia de los
identificadores de objetos del STRM
Anexo B
-Definición de referencia de los límites
superiores de los parámetros del STRM
Anexo C
-Diferencias entre la Norma ISO/CEI y la
Recomendación del CCITT
SECCIóN 1 - INTRODUCCIóN
0 Introducción
Esta Recomendación forma parte de un conjunto de Recomendaciones que definen el tratamiento de mensajes en un entorno distribuido de sistemas abiertos.
El tratamiento de mensajes facilita el intercambio de mensajes entre
usuarios sobre la base de un almacenamiento y retransmisión. Un mensaje
remitido por un usuario (el
originador
) se transfiere a
través del sistema de transferencia de mensajes (STRM) y se entrega a uno o más
usuarios (los
destinatarios
).
El STRM consta de un cierto número de agentes de transferencia de mensajes (ATM), que transfieren mensajes y los entregan a los destinatarios deseados.
Esta Recomendación ha sido desarrollada conjuntamente por el CCITT y la ISO. El documento equivalente de ISO es el ISO 10021-4.
1 Campo de aplicación
Esta Recomendación define el servicio abstracto proporcionado por el STRM (servicio abstracto de STRM), y especifica los procedimientos que deben realizar los ATM para garantizar un funcionamiento distribuido correcto del STRM.
La Recomendación X.402 identifica otras Recomendaciones que definen otros aspectos de los sistemas de tratamiento de mensajes.
El acceso al servicio abstracto de STRM definido en esta Recomendación puede ser facilitado por el protocolo de acceso (P3) del STRM, definido en la Recomendación X.419. El funcionamiento distribuido del STRM definido en esta Recomendación puede garantizarse mediante la utilización del protocolo de transferencia del STRM (P1) también definido en la Recomendación X.419.
La sección 2 de esta Recomendación define el servicio abstracto del STRM. El 6 , describe el modelo de sistema de transferencia de mensajes. El 7 , proporciona una visión de conjunto del servicio abstracto del STRM. El 8 , define la semántica de los parámetros del servicio abstracto del STRM. El 9 define la sintaxis-abstracta del servicio abstracto del STRM.
La sección 3 de esta Recomendación define el servicio abstracto del ATM. El 10 , perfecciona el modelo de STRM, presentado inicialmente en el 6 , para mostrar que el STRM incluye un cierto número de ATM que interfuncionan entre sí para prestar el servicio abstracto del STRM. El 11 , proporciona una visión de conjunto del servicio abstracto de ATM. El 12 , define la semántica de los parámetros del servicio abstracto de ATM. El 13 , define la sintaxis abstracta del servicio abstracto de ATM.
La sección 4 de esta Recomendación especifica los procedimientos realizados por los ATM para garantizar el funcionamieno distribuido correcto del STRM.
El anexo A proporciona una definición de referencia de los identificadores de objetos del STRM citados en los módulos NSA.1 del texto de esta Recomendación.
El anexo B proporciona una definición de referencia de los límites superiores de las limitaciones de tamaño impuestas sobre los tipos de datos de longitud variable definidos en los módulos de NSA.1 del texto de esta Recomendación.
El anexo C identifica las diferencias técnicas entre las versiones ISO/CEI y del CCITT de la presente Recomendación y de la publicación 10021-4 de ISO/CEI.
2
Referencias
Las referencias se enumeran en la Recomendación X.402.
3
Definiciones
Las definiciones se encuentran en la Recomendación X.402.
4
Abreviaturas
Las abreviaturas se enumeran en la Recomendación X.402.
5
Convenios
Esta Recomendación utiliza los convenios descriptivos descritos a continuación.
5.1
Términos
A lo largo de esta Recomendación, la redacción de los términos definidos y los nombres y valores de los parámetros del servicio abstracto de STRM y del servicio abstracto de ATM, a menos que sean nombres propios, comienzan con una letra minúscula y se unen con un guión de la siguiente forma: término-definido. Los nombres propios comienzan con una letra mayúscula (en el texto inglés) y no se unen mediante guión. En los 8 y 12, los nombres y los valores de los parámetros del servicio abstracto de STRM y del servicio abstracto de ATM se escriben en negrita.
5.2
Presencia de parámetros
En los cuadros de los parámetros de los 8 y 12, la presencia de cada parámetro se califica de la siguiente forma:
-Obligatorio (O): Parámetro obligatorio que debe existir siempre.
-Facultativo (F): Argumento facultativo que debe existir a discreción del invocador de la operación-abstracta; un resultado faculativo existirá a discreción del ejecutor de la operación-abstracta.
-Condicional (C): Debe existir un parámetro condicional según se define en la [Recomendación»norma internacional].
Cuando existe un parámetro condicional, debido a una cierta acción del STRM sobre el mensaje, sonda o informe, éste se define explícitamente. La presencia de otros parámetros condicionales depende de la presencia de estos parámetros en otras operaciones-abstractas (por ejemplo, la presencia de un argumento condicional de la operación abstracta de transferencia-mensaje depende de la presencia del mismo argumento facultativo en la correspondiente operación-abstracta de remisión-mensaje).
5.3
Definiciones de sintaxis abstracta
Esta Recomendación define la sintaxis-abstracta del servicio abstracto de STRM y del servicio abstracto de ATM utilizando la notación de sintaxis abstracta (NSA.1) definida en la Recomendación X.208 y los convenios de definición del servicio abstracto definidos en la Recomendacion X.208 y los convenios de definición indicados en la Recomendación X.407.
Cuando se introducen cambios en los protocolos definidos en la
Recomendación X.411 (1984) del CCITT, éstos se señalan en las definiciones de
sintaxis abstracta
subrayándolos
.
SECCIóN 2 - SERVICIO ABSTRACTO DEL SISTEMA DE TRANSFERENCIA DE MENSAJES
6
Modelo del sistema de
transferencia de mensajes
El tratamiento de mensajes facilita el intercambio de mensajes entre
usuarios, sobre la base de un almacenamiento y retransmisión. A través de un
sistema de transferencia de mensajes se transfiere un mensaje remitido por un
usuario (el
originador
) y se entrega a uno o más usuarios
(los
destinatarios
).
Se describe el STRM utilizando un modelo abstracto - el servicio abstracto de STRM - para definir los servicios prestados por el STRM en su conjunto.
El STRM se modela como un
objeto
, cuyo comportamiento
global puede describirse sin hacer referencia a su estructura interna. Los
servicios prestados por el objeto del STRM se encuentran disponibles en los
puertos
. Un tipo de puerto representa una visión
particular de los servicios proporcionados por el objeto del STRM.
También se modela un usuario del STRM como un objeto que contiene los
servicios prestados por el STRM a través de un puerto
emparejado
con un puerto del STRM del mismo tipo.
Un tipo de puerto corresponde a un conjunto de
operaciones-abstractas
que pueden tener lugar en un
puerto; aquellas que puede realizar el objeto del STRM (invocado por el objeto
del usuario-STRM), y aquellas que puede invocar el objeto de STRM (realizados
por el objeto del usuario-STRM).
Un puerto puede ser simétrico, en cuyo caso el objeto del STRM puede
invocar igualmente el conjunto de operaciones realizadas por el objeto del
STRM, y viceversa. Por el contrario, el puerto puede ser asimétrico en cuyo
caso el objeto se denomina
suministrador
o
consumidor
en relación con el tipo de puerto. Los términos
suministrador
y
consumidor
se
utilizan únicamente para distinguir entre los papeles de un par de puertos que
invocan o realizan operaciones. La asignación de los términos es generalmente
intuitiva cuando un objeto proporciona un servicio utilizado por otro objeto;
el objeto del servicio (por ejemplo, STRM) se considera generalmente como el
suministrador
, y el objeto del usuario (por ejemplo, un
objeto del usuario-STRM) se considera generalmente como
consumidor
.
Antes de que los objetos puedan invocar operaciones sobre otros, deben
ligarse a una
asociación
abstracta. La ligazón de una
asociación entre objetos establece una relación entre los objetos que dura
hasta que se libera la asociación. El iniciador de la asociación es quien
libera siempre la asociación. La ligazón de una asociación establece las
credenciales
de los objetos que interaccionan, el
contexto-aplicación
y el
contexto-seguridad
de la asociación. El
contexto-aplicación
de una asociación puede ser uno o más
tipos del puerto emparejado entre los dos objetos.
El modelo presentado es abstracto. Es decir, un observador exterior no siempre puede identificar las fronteras entre los objetos, o decidir el momento o los medios para la realización de las operaciones. Sin embargo, en ciertos casos el modelo abstracto puede ser realizado. Por ejemplo, una pareja de objetos que comunican a través de puertos emparejados puede colocarse en diferentes sistemas abiertos. En este caso, la frontera entre los objetos resulta visible, se exponen los puertos, y las operaciones pueden proporcionarse como casos de comunicación ISA.
El objeto del STRM admite puertos de tres tipos diferentes: un puerto-remisión, un puerto-entrega y un puerto-administración.
Un puerto-remisión permite a un usuario-STRM remitir mensajes al STRM para su transferencia y entrega a uno o más usuarios-STRM destinatarios, y sondear la aptitud del STRM para entregar un mensaje-tema.
Un puerto-entrega permite a un usuario STRM aceptar la entrega de mensajes del STRM, y aceptar informes sobre la entrega o no-entrega de mensajes y de sondas.
Un puerto-administración permite a un usuario-STRM modificar los parámetros
a largo plazo contenidos en el STRM asociados con la entrega de mensajes, y
permite al STRM o al usuario-STRM cambiar las
credenciales
con otro.
Un mensaje remitido por un usuario-STRM a través de un puerto-remisión se entregará normalmente a uno o más usuarios-STRM destinatarios a través de puertos-entrega. Los usuarios-STRM originadores pueden elegir la posibilidad de recibir notificación de la entrega o no entrega de un mensaje a través de su puerto-entrega.
La figura 1»X.411 presenta un modelo del sistema de transferencia de mensajes (STRM).
El 7 proporciona una visión de conjunto del servicio abstracto de STRM.
Figura 1/X.411, (N), p.
7 Visión de conjunto del servicio abstracto
del sistema de transferencia de mensajes
Esta Recomendación define los servicios siguientes que componen el servicio abstracto de STRM:
Vinculación y desvinculación STRM
a)vinculación-STRM
b)desvinculación-STRM
Operaciones abstractas en el puerto de remisión
c)remisión-mensajes
d)remisión-sonda
e)cancelación-entrega-diferida
f)control-remisión
Operaciones abstractas en el puerto de entrega
g)entrega-mensajes
h)entrega-informes
i)control-entrega
Operaciones abstractas en el puerto de administración
j)registro
k)cambio-credenciales.
7.1
Vinculación y desvinculación al STRM
La
vinculación-STRM
permite al usuario-STRM establecer
una asociación con el STRM, o al STRM establecer una asociación con el usuario
STRM. Otras operaciones-abstractas distintas de las de vinculación-STRM pueden
invocarse únicamente en el contexto de una asociación establecida.
La
desvinculación-STRM
permite la liberación de una
asociación establecida por el iniciador de la asociación.
7.2
Puerta de remisión
La operación-abstracta
remisión-mensaje
La operación-abstracta
remisión-sonda
La operación-abstracta
cancelación-entrega-diferida
La operación-abstracta
control-remisión
Las operaciones-abstractas
remisión-mensaje
remisión-sonda
pueden provocar la invocación subsiguiente de
la operación-abstracta entrega-informe por parte del STRM.
7.3
Puerto de entrega
La operación-abstracta
entrega-mensaje
La operación-abstracta
entrega-Informe
La operación-abstracta
control-entrega
7.4
Puerto de administración
La operación-abstracta
registro
La operación abstracta
cambio-credenciales
credenciales
con el STRM y al STRM cambiar sus
credenciales
con el usuario-STRM.
8 Definición del servicio abstracto del
sistema de transferencia de mensajes
En este punto, se define la semántica de los parámetros del servicio abstracto del STRM.
El 8.1 define la vinculación-STRM y la desvinculación-STRM. El 8.2 define el puerto-remisión. El 8.3 define el puerto-entrega. El 8.4 define el puerto-administración. El 8.5 define algunos tipos de parámetros comunes.
La sintaxis-abstracta del servicio abstracto del STRM se define en el 9 .
8.1
Vinculación-STRM y desvinculación-STRM
En este punto se definen las operaciones vinculación-STRM y desvinculación-STRM utilizadas para establecer y liberar asociaciones entre un usuario-STRM y el STRM.
8.1.1
Vinculación-abstracta y desvinculación-abstracta
En este punto se definen las operaciones siguientes: vinculación-abstracta y desvinculación-abstracta;
a)vinculación-STRM
b)desvinculación-STRM.
8.1.1.1
Vinculación-STRM
La vinculación-STRM permite a un usuario-STRM establecer una asociación con el STRM, o al STRM establecer una asociación con un usuario-STRM.
La vinculación-STRM establece las
credenciales
de un
usuario-STRM y permite al usuario-STRM interaccionar, y establece el
contexto-aplicación
y el
contexto-seguridad
de la asociación. únicamente el iniciador
puede liberar esta asociación (utilizando la desvinculación-STRM).
Pueden invocarse otras operaciones-abstractas diferentes de la vinculación-STRM en el contexto de una asociación establecida.
La consecución con éxito de vinculación-STRM significa el establecimiento de una asociación.
La interrupción de vinculación-STRM debido a un error-vinculación indica que no se ha establecido una asociación.
8.1.1.1.1
Argumentos
El cuadro 1/X.411 enumera los argumentos de vinculación-STRM, y para cada argumento califica su presencia e indica el punto donde se define el argumento.
cuadro 1/X.411 [T1.411], p.
8.1.1.1.1.1
Nombre-iniciador
Este argumento contiene un nombre para el iniciador de la asociación. Debe ser generado por el iniciador de la asociación.
Si el iniciador es un usuario-STRM, el nombre es el
nombre-O»D
del usuario-STRM, que está inscrito en el STRM
(véase el
8.4.1.1.1.1
). El
nombre-iniciador
contiene la
dirección-O»D
y puede contener también
opcionalmente el
nombre-guía
, del usuario-STRM,
(
Dirección-O»D-y-nombre-guía- facultativo
). Para seguridad
en la mensajería, cuando interviene una MM el
nombre-iniciador
puede también indicar si el iniciador es un
AU o una MM.
Si el iniciador es el STRM (o un ATM - véase el
11
), el nombre
es un
nombre-ATM
, que conoce el usuario-STRM.
8.1.1.1.1.2
Credenciales-iniciador
Este argumento contiene las
credenciales
del iniciador
de la asociación. Debe ser generado por el iniciador de la asociación.
Las
credenciales-iniciador
pueden utilizarse por el
respondedor para autenticar la identidad del iniciador (véase Recomendación
X.509).
Si se utiliza únicamente una autenticación-simple, las
credenciales-iniciador
consisten en una
contraseña
simple asociada al
nombre-iniciador
.
Si se utiliza una autenticación-fuerte, las
credenciales-iniciador
comprenden un
testigo-vinculación-iniciador
y de forma opcional un
certificado-iniciador
.
El
testigo-vinculación-iniciador
testigo
generado por el iniciador de la asociación. Si el
testigo-vinculación-iniciador
es un
testigo-asimétrico
, los
datos-firmados
incluyen un
número-aleatorio
. Los
datos-cifrados
de un
testigo-asimétrico
pueden utilizarse para transportar información-sobre-seguridad secreta (por
ejemplo, una o más claves-cifrado-simétricas) utilizadas para proporcionar
seguridad a la asociación, o pueden estar ausentes del
testigo-vinculación-iniciador
.
El
certificado-iniciador
certificado
del iniciador de la asociación, generado por una
fuente de confianza (por ejemplo, autoridad-certificación). Puede suministrarse
por el iniciador de la asociación, si el
testigo-vinculación-iniciador
es un
testigo-asimétrico
. El
certificado-iniciador
puede utilizarse para transportar una
copia verificada de la clave-cifrado-pública-asimétrica
(
clave-pública-sujeto
) del iniciador de la asociación. La
clave-cifrado-pública-asimétrica puede utilizarse por el respondedor para
calcular el
testigo-vinculación-respondedor
. Si se sabe que
el respondedor dispone o tiene acceso al
certificado
del
iniciador (por ejemplo, a través de la operación-abstracta de
cambiar-credenciales, o a través de la guía), puede omitirse el
certificado-iniciador
.
8.1.1.1.1.3
Contexto-seguridad
Este argumento identifica el
contexto-seguridad
con el
que el iniciador de la asociación propone funcionar. Puede generarse por el
iniciador de la asociación.
El
contexto-seguridad
incluye una o más
etiquetas-seguridad
que definen la sensibilidad de las
interacciones que pueden producirse entre el usuario-STRM y el STRM a lo largo
de la duración de la asociación, en línea con la política- seguridad en vigor.
El
contexto-seguridad
debe ser uno entre los autorizados por
las
etiquetas-seguridad-usuario
registradas del usuario-STRM
y por las
etiquetas-seguridad
asociadas al ATM del STRM.
Una vez establecido, el
contexto-seguridad
del
puerto-remisión y del puerto-entrega puede restringirse transitoriamente
utilizando las operaciones-abstractas de control-remisión (véase el
8.2.1.4.5
) y de control-entrega (véase el
8.3.1.3.1.7
),
respectivamente.
Si no se establecen los
contextos-seguridad
entre el
usuario-STRM y el STRM, la sensibilidad de las interacciones que pueden
producirse entre el usuario-STRM y el STRM pueden dejarse a la discreción del
invocador de una operación-abstracta.
8.1.1.1.1.4
Mensajes-esperando
Este argumento indica el número de mensajes y el número total de octetos
que esperan para ser entregados por el STRM al usuario-STRM, para cada
prioridad
. Puede generarse por el iniciador de la
asociación.
Este argumento estará únicamente presente cuando el STRM inicie una asociación con un usuario-STRM, y cuando un usuario-STRM se abone al elemento-de-servicio retención de entrega (definido en la Recomendación X.400).
8.1.1.1.2
Resultados
El cuadro 2/X.411 enumera los resultados de vinculación-STRM, y para cada resultado califica su presencia e indica el punto donde se define el resultado.
Cuadro 2/X.411 [T2.411], p.
8.1.1.1.2.1
Nombre-respondedor
Este argumento contiene un nombre para el respondedor de la asociación. Puede ser generado por el respondedor de la asociación.
Si el respondedor es un usuario-SRTM, el nombre es el
nombre-O/D
del usuario-STRM, que se inscribe con el SRTM
(véase el
8.4.1.1.1.1
). El
nombre-respondedor
contendrá la
dirección-O/D
y puede contener también de forma
opcional el
nombre-guía
, del usuario-STRM
(
dirección-O/D-y-nombre-opcional-guía
). Para seguridad en la
mensajería, cuando interviene una MM el
nombre-respondedor
puede también indicar si el respondedor es un AU o una MM.
Si el respondedor es el STRM (o un ATM - véase el
11
), el nombre
es un
nombre-ATM
, que conoce el usuario-STRM.
8.1.1.1.2.2
Credenciales-respondedor
Este argumento contiene las
credenciales
del respondedor
de la asociación. Debe ser generado por el respondedor de la asociación.
Las
credenciales-respondedor
pueden utilizarse por el
iniciador para autenticar la identidad del respondedor (véase Recomendación
X.509).
Si se utiliza únicamente la autenticación-simple, las
credenciales-respondedor
incluyen una
contraseña
simple asociada al
nombre-respondedor
.
Si se utiliza una autenticación-fuerte, las
credenciales-respondedor
constan de un
testigo-vinculación-respondedor
testigo-vinculación-respondedor
es un testigo generado por
el respondedor de la asociación. El
testigo-vinculación-respondedor
debe ser del mismo tipo que
el
testigo-vinculación-iniciador
. Si el
testigo-vinculación-respondedor
es un
testigo-asimétrico
, los datos firmados constan de un
número-aleatorio
(que puede estar relacionado con el
número-aleatorio
suministrado en el
testigo-vinculación-iniciador
). Los
datos-cifrados
de un
testigo asimétrico
pueden utilizarse para transportar información-sobre-seguridad secreta (por
ejemplo, una o más claves-cifrado-simétricas) utilizadas para proporcionar
seguridad a la asociación, o pueden estar ausentes del
testigo-vinculación-respondedor
.
8.1.1.1.2.3
Mensajes esperando
Este argumento indica el número de mensajes y el número total de octetos
que esperan para ser entregados por el STRM al usuario-STRM, para cada
prioridad
. Puede generarse por el respondedor de la
asociación.
Este argumento debe estar únicamente presente cuando el STRM conteste a una asociación iniciada por un usuario-STRM, y cuando un usuario-STRM se abone al elemento-de-servicio retención de entrega (véase Recomendación X.400).
8.1.1.1.3
Errores-vinculación
Los errores-vinculación que pueden interrumpir la vinculación-STRM se definen en el 8.1.2 .
8.1.1.2
Desvinculación-STRM
La desvinculación-STRM permite liberar una asociación establecida por el iniciador de la asociación.
8.1.1.2.1
Argumentos
La desvinculación-STRM no tiene argumentos.
8.1.1.2.2
Resultados
La desvinculación-STRM devuelve un resultado vacío como indicación de la liberación de la asociación.
8.1.1.2.3
Errores-desvinculación
No existen errores-desvinculación que puedan interrumpir la desvinculación-STRM.
8.1.2
Errores-vinculación
En este punto se definen los siguientes errores-vinculación:
a)error-autenticación
b)ocupado
c)modo-diálogo-inaceptable
d)contexto-seguridad-inaceptable
8.1.2.1
Error-autenticación
El error-vinculación de error-autenticación notifica que no puede
establecerse una asociación debido a un error de autenticación; las
credenciales
del iniciador no son aceptables o están
indebidamente especificadas.
El error-vinculación de error-autenticación no tiene parámetros.
8.1.2.2
Ocupado
El error-vinculación ocupado notifica que una asociación no puede establecerse porque el respondedor está ocupado.
El error-vinculación-ocupado no tiene parámetros.
8.1.2.3
Modo-diálogo-inaceptable
Un error-vinculación de modo-diálogo-inaceptable notifica que el modo-diálogo propuesto por el iniciador de la asociación es inaceptable para el respondedor (véase Recomendación X.419).
El error-vinculación de diálogo-inaceptable no tiene parámetros.
8.1.2.4
Contexto-seguridad-inaceptable
Un error-vinculación de contexto-seguridad-inaceptable notifica que el
contexto-seguridad
propuesto por el iniciador de la
asociación resulta inaceptable para el respondedor.
El error-vinculación de contexto-seguridad-inaceptable no tiene parámetros.
8.2
Puerto de remisión
En este punto se definen las operaciones-abstractas y los errores abstractos que se producen en el puerto de remisión.
8.2.1
Operación abstracta
En este punto se definen las siguientes operaciones abstractas en el puerto de depósito:
a)remisión-mensaje
b)remisión-sonda
c)cancelación-entrega-diferida
d)control-remisión.
8.2.1.1
Remisión-mensaje
La operación abstracta remisión-mensaje permite al usuario-STRM remitir un mensaje al STRM para su transferencia y entrega a uno o más usuarios-STRM destinatarios.
La ejecución satisfactoria de la operación abstracta significa que el STRM ha aceptado la responsabilidad del mensaje (pero no que se haya entregado ya los destinatarios deseados).
La interrupción de la operación-abstracta por un error-abstracto indica que el STRM no puede asumir la responsabilidad del mensaje.
8.2.1.1.1
Argumentos
El cuadro 3/X.411 enumera los argumentos de la operación abstracta remisión-mensaje, y para cada argumento califica su presencia e identifica el punto donde se define el argumento.
8.2.1.1.1.1
Nombre-originador
Este argumento contiene el
nombre-O»D
del originador del
mensaje. Se debe generar por el usuario-STRM originador.
El
nombre-originador
contiene el
nombre-O»D
de un originador individual, es decir no debe
contener el
nombre-O»D
de una LD.
8.2.1.1.1.2
Nombre-destinatario
Este argumento contiene el
nombre-O»D
de un destinatario
del mensaje. Se debe generar por el originador del mensaje. Se debe especificar
un valor diferente de este argumento para cada destinatario del mensaje.
El
nombre-destinatario
contiene el
nombre-O»D
de un destinatario individual o de una LD.
8.2.1.1.1.3
Destinatario-alternativo-autorizado
Este argumento indica si puede entregarse el mensaje a un destinatario
alternativo asignado por el DG-destinatario, si el
nombre-destinatario
no identifica un usuario-STRM. Puede
generarse por el originador del mensaje.
Este argumento puede tener uno de los valores siguientes:
destinatario-alternativo-autorizado
o
destinatario- alternativo-prohibido
.
Tableau 3/X.411 [T3.411], p. 4
Si este argumento tiene el valor
destinatario-alternativo-autorizado
y el
nombre-destinatario
(especificado por el originador del
mensaje, o añadido por una ampliación-LD, o substituido mediante una nueva
dirección por el
destinatario-alternativo-asignado-destinatario
o por el
destinatario-alternativo-solicitado-originador
, o presente
mediante una combinación de una nueva dirección y una ampliación) no identifica
a un usuario STRM, el mensaje puede redirigirse hacia un destinatario
alternativo asignado por el DG-destinatario para recibir dichos mensajes. Si el
DG-destinatario no ha asignado ninguno de estos destinatarios-alternativos, o
si este argumento tiene el valor
destinatario-alternativo-prohibido
, se generará un informe
de no entrega.
En ausencia de este argumento se supondrá por defecto
destinatario-alternativo-prohibido
.
8.2.1.1.1.4
Reasignación-destinatario-prohibida
Este argumento indica si el mensaje puede reasignarse a un
destinatario-alternativo-asignado-destinatario
registrado
por el destinatario-deseado. Puede generarse por el originador del mensaje.
Este argumento puede tener uno de los siguientes valores:
reasignación-destinatario-prohibida
o
reasignación-destinatario-autorizada
.
Si este argumento tiene el valor
reasignación-destinatario-autorizada
y el
destinatario-deseado ha registrado un
destinatario-alternativo-asignado-destinatario
, el mensaje
se redireccionará hacia el
destinatario-alternativo-asignado-destinatario
.
Si este argumento tiene el valor
reasignación-destinatario-prohibida
y el
destinatario-deseado ha registrado un
destinatario-alternativo-asignado-destinatario
, entonces si
el originador del mensaje ha especificado
destinatario-alternativo-solicitado-originador
se redirigirá
el mensaje hacia el
destinatario-alternativo-solicitado-originador
, o si el
originador del mensaje no ha especificado un
destinatario-alternativo-solicitado-originador
, se generará
un informe de no-entrega.
En ausencia de este argumento, se supondrá por defecto
reasignación-destinatario-autorizada
.
8.2.1.1.1.5
Destinatario-alternativo-solicitado-originador
Este argumento contiene el
nombre-O»D
del destinatario
alternativo solicitado por el originador del mensaje. Puede generarse por el
originador del mensaje. Puede especificarse un valor distinto de este argumento
para cada destinatario del mensaje.
El
destinatario-alternativo-solicitado-originador
contiene el
nombre-O»D
de un destinatario-alternativo
individual o LD.
Si este argumento está presente y no resulta posible la entrega del mensaje
al
nombre-destinatario
(especificado por el originador del
mensaje, o añadido por una ampliación-LD, o substituido mediante una nueva
dirección por el
destinatario-alternativo-asignado-destinatario
), el mensaje
se debe redirigir al
destinatario-alternativo-solicitado-originador
especificado
por este argumento.
Si el originador del mensaje ha especificado un
destinatario-alternativo-solicitado-originador
, el mensaje
será redirigido a ese destinatario alternativo con preferencia a uno asignado
por el DG-destinatario.
8.2.1.1.1.6
Ampliación-LD prohibida
Este argumento indica si se producirá una ampliación-LD dentro del STRM
para cualquier
nombre-destinatario
que designe una LD. Puede
generarse por el originador del mensaje.
Este argumento puede tener uno de los valores siguientes:
ampliación-LD prohibida
o
ampliación-LD
autorizada
.
En ausencia de este argumento se supondrá por defecto
ampliación-LD autorizada
.
8.2.1.1.1.7
Revelación-de-destinatarios
Este argumento indica si debe indicarse el
nombre-destinatario
de todos los destinatarios a cada
usuario-STRM destinatario al entregar el mensaje. Puede generarse por el
originador del mensaje.
Este argumento puede tener uno de los siguientes valores:
revelación-de-destinatarios-autorizada
o
revelación-de-destinatarios-prohibida
.
En ausencia de este argumento se supondrá por defecto
revelación-de-destinatarios-prohibida
.
8.2.1.1.1.8
Prioridad
Este argumento especifica la prioridad relativa del mensaje:
normal
,
no-urgente
o
urgente
. Puede generarse por el originador del mensaje.
En ausencia de este argumento se supondrá por defecto una
prioridad normal
.
8.2.1.1.1.9
Conversión-implícita-prohibida
Este argumento indica si puede realizarse una conversión implícita del
contenido
del mensaje. Puede generarse por el originador del
mensaje.
Este argumento puede tener los siguientes valores:
conversión-implícita-prohibida
o
conversión-implícita-autorizada
.
En ausencia de este argumento, se supondrá por defecto
conversión-implícita-autorizada
.
Véase igualmente el 8.2.1.1.1.10 .
8.2.1.1.1.10
Conversión-con-pérdida-prohibida
Este argumento indica si puede realizarse una conversión o conversiones del
tipo-información-codificada
del
contenido
del mensaje, en el caso de que dicha conversión o conversiones pueden dar lugar
a una pérdida de información. La pérdida de información se define en la
Recomendación X.408. Puede generarse por el originador del mensaje.
Este argumento puede tener los siguientes valores:
conversión-con-pérdida-prohibida
o
conversión-con-pérdida-autorizada
.
En ausencia de este argumento se supondrá por defecto
conversión-con- pérdida-autorizada
.
El efecto combinado de los argumentos de
conversión-implícita-prohibida
y de
conversión-con-pérdida-prohibida
se refiere únicamente a las
conversiones-implícitas y se define en el cuadro 4/X.411.
Cuadro 4/X.411 [T4.411], p.
8.2.1.1.1.11
Conversión explícita
Este argumento indica el tipo de conversión del
contenido
del mensaje solicitado explícitamente por el
originador para el destinatario. Puede generarse por el originador del mensaje.
Puede especificarse un valor diferente de este argumento para cada uno de los
destinatarios del mensaje.
Este argumento puede tener uno de los valores siguientes:
no-conversión-explícita
,
ai5-texto-a-teletex
,
teletex-a-télex
,
télex-a-texto-ai5
,
télex-a-teletex
,
télex-a-g4-clase-1
,
télex-a-videotex
,
texto-ai5-a-télex
,
télex-a-facsímil-g3
,
texto-ai5-a-facsímil-g3
,
texto-ai5-a-g4-clase-1
,
texto-ai5-a-videotex
,
teletex-a-texto-ai5
,
teletex-a-facsímil-g3
,
teletex-a-g4-clase-1
,
teletex-a-videotex
,
videotex-a-télex
,
videotex-a-texto-ai5
o
videotex-a-télex
. Pueden definirse otros tipos de
conversión explícita
en versiones futuras de esta
Recomendación. La
conversión-explícita
se debe realizar
conforme a lo especificado en la Recomendación X.408.
En ausencia de este argumento se supondrá por defecto
no-conversión-explícita
.
Nota
- Cuando se especifica la
conversión-explícita
para una LD de destinatarios, ésta se
aplica a todos los miembros de la LD.
8.2.1.1.1.12
Tiempo-entrega-diferida
Este argumento especifica el
tiempo
antes del cual no
debería entregarse el mensaje al destinatario o destinatarios. Puede generarse
por el originador del mensaje.
8.2.1.1.1.13
último-tiempo-entrega
Este argumento contiene el
tiempo
después del cual no
debería entregarse el mensaje al destinatario o destinatarios. Puede generarse
por el originador del mensaje.
El tratamiento de la no entrega debido al
último-tiempo-entrega
se describe en el
14.3.2.4
.
8.2.1.1.1.14
Método-entrega-solicitado
Este argumento indica el método solicitado de entrega del mensaje al destinatario. Puede generarse por el originador del mensaje. Puede especificarse un valor diferente de este argumento para cada destinatario del mensaje.
Este argumento puede tener uno o más de los siguientes valores:
cualquier-método-entrega
,
entrega-STM
,
entrega-física
,
entrega-télex
,
entrega-teletex
,
entrega-facsímil-g3
,
entrega-facsímil-g4
,
entrega-terminal-ai5
,
entrega-videotex
, o
entrega telefónica
.
Si se especifica más de un valor de este argumento para un destinatario, se supondrá que la secuencia de valores implica un orden de preferencia del originador respecto de los métodos-entrega.
En ausencia de este argumento, se supondrá por defecto
cualquier-método-entrega
.
Si el
nombre-destinatario
generado por el originador del
mensaje contiene un
nombre-guía
pero omite una
dirección-O»D
, el STRM puede utilizar el
método-entrega-solicitado
como una indicación de la forma de
dirección O»D
en que el STRM debería transformar
el nombre-guía
(por ejemplo utilizando la guía). Si no puede
encontrarse una forma de
dirección-O»D
adecuada al
método-entrega-solicitado
, se debe devolver al originador
del mensaje un error-abstracto
destinatario-impropiamente-especificado
.
Si el
nombre-destinatario
generado por el originador del
mensaje contiene una
dirección-O»D
con una forma no adecuada
para el
método-entrega-solicitado
, se debe devolver al
originador del mensaje un informe-no-entrega.
Si el
método-entrega-solicitado
suministrado-originador
entra en conflicto con el método-entrega preferido del destinatario (por
ejemplo registrado en la guía en el atributo método-entrega-preferido-stm), el
método-entrega-solicitado
del originador tiene preferencia.
Si el
método-entrega-solicitado
entra en conflicto con los
requisitos de conversión del originador (véanse los
8.2.1.1.1.9
a
8.2.1.1.1.11) se debe devolver un informe de no-entrega al originador del
mensaje.
8.2.1.1.1.15
Envío-físico-prohibido
Este argumento indica si está prohibido el envío-físico de un mensaje.
Puede generarse por el originador del mensaje si el argumento
método-entrega-solicitado
especifica que se necesita una
entrega física al destinatario, o si el originador del mensaje proporcionó la
dirección-postal-O»D
del destinatario. Puede especificarse
un valor distinto de este argumento para cada uno de los destinatarios del
mensaje.
Este argumento puede tener uno de los siguientes valores:
envío-físico-autorizado
, o
envío-físico-prohibido
.
En ausencia de este argumento se supondrá por defecto
envío-físico-autorizado
.
8.2.1.1.1.16
Petición-dirección-envío-físico
Este argumento indica si debe devolverse en un informe la
dirección-envío-físico del destinatario. Puede generarse por el originador del
mensaje si el argumento
método-entrega-solicitado
especifica
que se necesita una entrega física al destinatario, o si el originador del
mensaje proporcionó la
dirección-postal-O»D
del
destinatario. Puede especificarse un valor distinto de este argumento para cada
uno de los destinatarios del mensaje.
Este argumento puede tener uno de los siguientes valores:
dirección-envío-físico-solicitada
, o
dirección-envío-físico-no-solicitada
.
En ausencia de este argumento se supondrá por defecto
dirección-envío-físico-no-solicitada
.
Se puede solicitar una dirección de envío físico cuando el envío físico esté prohibido o permitido (véase el 8.2.1.1.1.15 ).
8.2.1.1.1.17
Modos-entrega-física
Este argumento indica el modo de entrega-física al destinatario que ha de
utilizarse. Puede generarse por el originador del mensaje si el argumento
método-entrega-solicitado
especifica que se necesita una
entrega-física al destinatario, o si el originador del mensaje proporcionó la
dirección-postal-O»D
del destinatario. Puede especificarse
un valor distinto de este argumento para cada uno de los destinatarios del
mensaje.
Este argumento puede tener uno de los valores siguientes:
correo-ordinario
,
urgente
,
entrega-inmediata
,
retirada-ventanilla
,
retirada-ventanilla-con-aviso-telefónico
,
retirada-ventanilla-con-aviso-télex
,
retirada-ventanilla-con-aviso-teletex
, o
entrega-burofax
.
Obsérvese que la
entrega-burofax
comprende todos los
modos de entrega del A al H definidos en la Recomendación F.170, es decir A -
Entrega Regular, B - Urgente, C - Entrega Inmediata, D - Retirada en
ventanilla, E - Retirada en ventanilla con aviso telefónico, F - Telefax, G -
Retirada en ventanilla con aviso télex, y H - Retirada en ventanilla con aviso
teletex.
En ausencia de este argumento, se supondrá por defecto
correo-ordinario
.
8.2.1.1.1.18
Tipo-correo-certificado
Este argumento indica el tipo de correo certificado que ha de utilizarse
para entregar físicamente el mensaje al destinatario. Puede generarse por el
originador del mensaje si el argumento
método-entrega-solicitado
especifica que se necesita una
entrega física al destinatario, o si el originador del mensaje proporcionó la
dirección-postal-O»D
del destinatario. Puede especificarse
un valor distinto de este argumento para cada uno de los destinatarios del
mensaje.
Este argumento puede tener uno de los valores siguientes:
correo-no-certificado
,
correo-certificado
, o
correo-certificado-a-dirección-en-persona
.
En ausencia de este argumento se supondrá por defecto
correo-ordinario
.
8.2.1.1.1.19
Número-destinatario-para-aviso
Este argumento contiene el número de teléfono, télex o teletex del
destinatario, para utilizarlo en combinación con los modos
modo-entrega-física
,
modo-recogida-oficina-postal-con-aviso
y
modo-entrega-burofax
. Pueden generarse por el originador del
mensaje si el argumento
método-entrega-solicitado
especifica
que se necesita una
entrega-física
al destinatario, o si el
originador del mensaje proporcionó la
dirección-postal-O»D
del destinatario y el argumento de los
modos-entrega-física
especifica un
modo-entrega-física
, un
modo-recogida-oficina-postal-con-aviso
o un
modo-entrega-burofax
. Puede especificarse un valor distinto
de este argumento para cada uno de los destinatarios del mensaje.
8.2.1.1.1.20
Atributos-reproducción-física
Este argumento indica los
atributos-reproducción-física
del mensaje. Puede generarse por el originador del mensaje si el argumento
método-entrega-solicitado
especifica que se necesita una
entrega física al destinatario, o si el originador del mensaje proporcionó la
dirección-postal-O»D
del destinatario. Puede especificarse
un valor distinto de este argumento para cada uno de los destinatarios del
mensaje.
Este argumento puede tener uno de los valores siguientes:
básico
. Tal vez futuras versiones de esta Recomendación
definan otros valores de este argumento. Mediante acuerdos bilaterales entre
los DG pueden utilizarse otros valores de este argumento.
En ausencia de este argumento se supondrá el valor por defecto
básico
.
8.2.1.1.1.21
Dirección-devolución-originador
Este argumento contiene la
dirección-O»D-postal
del
originador del mensaje. Se debe generar por el originador del mensaje si el
argumento
método-entrega-solicitado
especifica que se
necesita una entrega física a uno o más destinatarios, o si el originador del
mensaje proporcionó una o más
direcciones-postales-O»D
de
los destinatarios. Puede generarse igualmente por el originador del mensaje si
una LD de destinatarios contiene o es probable que contenga uno o más miembros
para los cuales se solicita la entrega-física.
La
dirección-devolución-originador
contendrá la
dirección-postal-O»D
de cada originador
(
dirección-O»D
), es decir no contendrá ni el
nombre-guía
de un originador ni el
nombre-guía
de una LD.
8.2.1.1.1.22
Petición-informe-originador
Este argumento indica la categoría de informe solicitada por el originador del mensaje. Se debe generar por el originador del mensaje. Puede especificarse un valor distinto de este argumento para cada uno de los destinatarios del mensaje.
Este argumento puede tener uno de los valores siguientes:
-
no-informe
: el originador del mensaje solicita la
supresión de los informes de no-entrega;
-
informe-no-entrega
: se devuelve un informe únicamente en
el caso de no-entrega;
-
informe
: se devuelve un informe en el caso de entrega o
de no-entrega.
Obsérvese que el valor de este argumento puede cambiarse en un punto-ampliación de LD. Dicho cambio puede afectar al número y tipo de informe que el originador del mensaje puede recibir sobre la entrega a una LD.
8.2.1.1.1.23
Petición-devolución-contenido
Este argumento indica si el
contenido
del mensaje debe
devolverse con cualquier informe-no-entrega. Se puede generar por el originador
del mensaje.
Este argumento puede tener uno de los valores siguientes:
devolución-contenido-solicitada
o
devolución-contenido-no-solicitada
.
En ausencia de este argumento, se supondrá por defecto
devolución- contenido-no-solicitada
.
Obsérvese que la supresión de los informes-no-entrega por el originador del
mensaje (véase el
8.2.1.1.1.22
) tiene preferencia sobre una petición
de devolución del
contenido
.
Obsérvese que en el caso de informes-no-entrega entregados al propietario
de una LD (véase el
8.3.1.2.1.4
), el
contenido
del mensaje no estará presente.
8.2.1.1.1.24
Petición-informe-entrega-física
Este argumento indica el tipo de informe-entrega-física solicitado por el
originador del mensaje. Puede generarse por el originador del mensaje si el
argumento
método-entrega-solicitado
especifica que se
necesita una entrega-física al destinatario, o si el originador del mensaje
proporcionó
la dirección-postal-O»D
del destinatario. Puede
especificarse un valor distinto de este argumento para cada uno de los
destinatarios del mensaje.
Este argumento puede tener uno de los valores siguientes:
devolución-de-correo-inentregable-por-SEF
,
devolución-de-notificación-por-SEF
,
devolución-de-notificación-por-STM
o
devolución-de-notificación-por-STM-y-SEF
.
En ausencia de este argumento, se supondrá por defecto
devolución-de-correo-inentregable-por-SEF
.
8.2.1.1.1.25
Certificado-originador
Este argumento contiene el
certificado
del originador
del mensaje. Se debe generar por una fuente de confianza (por ejemplo autoridad
de certificación), y puede suministrarse por el originador del mensaje.
El
certificado-originador
puede utilizarse para
transportar una copia verificada de la clave-cifrado-pública-asimétrica
(
clave-pública-sujeto
) del originador del mensaje.
La clave-cifrado-pública-asimétrica puede ser utilizada por los
destinatarios del mensaje para validar el
distintivo-mensaje
, si se utiliza un
distintivo-asimétrico
.
La clave-encripción-pública-asimétrica puede igualmente utilizarse por los
destinatarios del mensaje, y cualquier ATM a través del cual se transfiere un
mensaje para validar la
comprobación-autenticación-origen-mensaje
.
8.2.1.1.1.26
Testigo-mensaje
Este argumento contiene el
testigo
asociado al mensaje.
Puede generarse por el originador del mensaje. Puede especificarse un valor
distinto de este argumento para cada destinatario del mensaje.
Si el
testigo-mensaje
es un
testigo-asimétrico
, los
datos-firmados
pueden incluir:
-cualquiera de los siguientes argumentos: el
identificador-algoritmo-confidencialidad-contenido
, la
verificación-integridad-contenido
, la
etiqueta-seguridad-mensaje
, y la
prueba-de-petición-entrega
; y
-
un número-secuencia-mensaje
, que identifique la posición
del mensaje en una secuencia de mensajes del originador al destinatario al que
se refiere el
testigo-mensaje
(para proporcionar el
elemento-de- servicio de integridad de secuencia de mensajes, definido en la
Recomendación X.400.)
Si el
testigo-mensaje
es un
testigo-asimétrico
, los
datos-cifrados
pueden incluir:
-una
clave-confidencialidad-contenido
: clave-encripción
simétrica utilizada con el
identificador-algoritmo-confidencialidad-contenido
por el
originador del mensaje para cifrar el
contenido
del mensaje
y por el destinatario del mensaje para descifrar el
contenido
del mensaje; y»o
-la
verificación-integridad-contenido
: puede incluirse en
los
datos-cifrados
, en vez de en los
datos-firmados
, si se requiere confidencialidad de la
verificación-integridad-contenido
y»o si la
etiqueta-seguridad-mensaje
se incluye en los
datos-cifrados
(para confidencialidad de la
etiqueta-seguridad-mensaje
) y debe mantenerse la asociación
entre la
verificación-integridad-contenido
y la
etiqueta-seguridad-mensaje
;
-la
etiqueta-seguridad-mensaje
: puede incluirse en los
datos-cifrados
, en vez de en los
datos-firmados
, si se requiere confidencialidad de la
etiqueta-seguridad-mensaje
;
-una
clave-integridad-contenido
:
clave-encripción-simétrica utilizada con el
identificador-algoritmo-integridad-contenido
, por el
originador del mensaje para calcular la
verificación-integridad-contenido
; y por el destinatario
para validar la
verificación-integridad-contenido
;
-un
número-secuencia-mensaje
: definido para los
datos-firmados
anteriormente, pero que puede incluirse en
los
datos-encriptados
si se requiere confidencialidad de la
secuencia.
Si el
testigo-mensaje
es un
testigo-asimétrico
y los
datos-firmados
del
testigo-mensaje
incluyen la
verificación-integridad-contenido
, el
testigo-mensaje
proporciona el no-repudio-del-origen del
contenido
del mensaje (elemento-de-servicio de no repudio
del origen, definido en la Recomendación X.400). Si los
datos-firmados
del
distintivo-mensaje
incluyen tanto la
integridad-verificación-contenido
como la
etiqueta-seguridad-mensaje
, el
testigo-mensaje
proporciona una prueba de la asociación
entre la
etiqueta-seguridad-mensaje
y el
contenido
del mensaje.
8.2.1.1.1.27
Identificador-algoritmo-confidencialidad-contenido
Este argumento contiene un
identificador-algoritmo
, que
identifica el algoritmo utilizado por el originador del mensaje para cifrar el
contenido
del mensaje (para proporcionar el
elemento-de-servicio confidencialidad de contenido definido en la Recomendación
X.400). Puede generarse por el originador del mensaje.
El algoritmo puede utilizarse por el destinatario o destinatarios del
mensaje para descifrar el
contenido
del mensaje.
El algoritmo de confidencialidad-contenido puede ser un algoritmo-cifrado-simétrico o asimétrico.
Si se utiliza un algoritmo-cifrado-simétrico, la
clave-confidencialidad-contenido
utilizada para cifrar el
contenido
del mensaje, y que el destinatario puede utilizar
para descifrar el
contenido
del mensaje, puede deducirse del
distintivo-mensaje
enviado con el mensaje. Como alternativa,
puede distribuirse por algún otro medio la
clave-confidencialidad-contenido
.
Si se utiliza un algoritmo-cifrado-asimétrico, la clave-cifrado-pública
asimétrica del destinatario deseado puede ser utilizada por el originador del
mensaje para descifrar el
contenido
del mensaje. El
destinatario puede utilizar la clave-cifrado-asimétrica-secreta del
destinatario para descifrar el
contenido
del mensaje.
Obsérvese que si se utiliza un algoritmo-cifrado-asimétrico, el mensaje puede
dirigirse únicamente a un único destinatario, o a un conjunto de destinatarios
que compartan la misma pareja de claves-cifrado-asimétricas.
8.2.1.1.1.28
Verificación-integridad-contenido
Este argumento proporciona al destinatario o destinatarios del mensaje los
medios para validar que no se ha modificado el
contenido
del
mensaje (para proporcionar el elemento-de-servicio integridad de contenido
definido en la Recomendación X.400). Puede ser generado por el originador del
mensaje. Puede especificarse un valor distinto de este argumento para cada
destinatario del mensaje.
La
verificación-integridad-contenido
permite validar la
integridad-contenido destinatario por cada destinatario utilizando un
algoritmo-cifrado-simétrico-asimétrico. Obsérvese que la
verificación-autenticación-origen-mensaje
proporciona los
medios para validar la integridad-contenido mensaje por mensaje utilizando un
algoritmo-cifrado-asimétrico.
La
verificación-integridad-contenido
puede incluirse en
los
datos-firmados
o en los
datos-cifrados
del
distintivo-mensaje
para permitir el no-repudio-del-origen del
contenido
del
mensaje, y la prueba de asociación entre la
etiqueta-seguridad-mensaje
y el
contenido
del mensaje.
La
verificación-integridad-contenido
se calcula
utilizando el algoritmo identificado por el
identificador-algoritmo-integridad-contenido
(un
identificador-algoritmo
).
La
verificación-integridad-contenido
contiene el
identificador-algoritmo-integridad-contenido
, y una función
cifrada (por ejemplo una versión resumida o desmenuzada) del
identificador-algoritmo-integridad-contenido
y del
contenido
del mensaje. Obsérvese que la
verificación-integridad-contenido
se calcula utilizando el
contenido
del mensaje claro (es decir sin cifrar).
El algoritmo-integridad-contenido puede ser un algoritmo-cifrado- simétrico
o asimétrico. Obsérvese que la utilización de un algoritmo-cifrado- simétrico
puede permitir una compresión y cifrado simultáneos del
contenido
del mensaje.
Si se utiliza un algoritmo-cifrado-simétrico, la
clave-integridad-contenido
utilizada para calcular la
verificación-integridad-contenido
, y que puede utilizar el
destinatario para validar la
verificación-integridad-
contenido
, puede deducirse del
distintivo-mensaje
enviado con el mensaje. Como alternativa, la
clave-integridad-contenido
puede distribuirse por varios
otros procedimientos.
Si se utiliza un algoritmo-cifrado-asimétrico, la
clave-cifrado-asimétrica-secreta del originador puede utilizarse por el
originador del mensaje para calcular la
verificación-integridad-contenido
. El destinatario puede
utilizar la clave-encripción-pública-asimétrica del originador
(
clave-pública-sujeto
) deducida del
certificado-originador
para validar la
verificación-integridad-contenido
.
8.2.1.1.1.29
Verificación-autenticación-origen-mensaje
Este argumento proporciona al destinatario o destinatarios del mensaje, y a cualquier ATM a través del cual se transfiera un mensaje, los medios para autenticar el origen del mensaje (para proporcionar el elemento-de-servicio autenticación de origen de mensaje definido en la Recomendación X.400). Puede generarse por el identificador del mensaje.
La
verificación-autenticación-origen-mensaje
proporciona
la prueba del origen del mensaje (autenticación del origen del mensaje),
garantía de que el
contenido
del mensaje no ha sido
modificado (el elemento-de-servicio integridad de contenido definido en la
Recomendación X.400), y la prueba de la asociación entre la
etiqueta-seguridad-mensaje
y el mensaje.
La
verificación-autenticación-origen-mensaje
se calcula
utilizando el algoritmo (algoritmo-cifrado-asimétrico y función-desmenuzar)
identificada por el
identificador-algoritmo-autenticación-origen-mensaje
(un
identificador-algoritmo
).
La
verificación-autenticación-origen-mensaje
contiene el
identificador-algoritmo-autenticación-origen-mensaje
, y una
versión cifrada, desmenuzada del
identificador-algoritmo-autenticación-origen-mensaje
, el
contenido
del mensaje, el
identificador-contenido
y la
etiqueta-seguridad-mensaje
. Se incluyen componentes
facultativos en la
verificación-autenticación-origen-mensaje
si están presentes en el mensaje.
Si se utiliza igualmente la confidencialidad-contenido (véase el
8.2.1.1.1.27
), se calcula
verificación-autenticación-origen-mensaje
utilizando la
versión cifrada del
cotenido
del mensaje (para permitir que
la
verificación-autenticación-origen-mensaje
sea validada
por otro que no sea el destinatario-deseado (por ejemplo por un ATM) sin
comprometer la confidencialidad del
contenido
del mensaje).
Obsérvese que si la versión clara (es decir sin cifrar) del
contenido
del mensaje se utiliza para calcular la
verificación-autenticación-origen-mensaje
, ésta facilita la
autenticación del origen del mensaje y el no repudio del origen del
contenido
del mensaje (firma), definidos en la Recomendación
X.400. Sin embargo, si se utiliza la versión cifrada del
contenido
del mensaje, la
verificación-autenticación-origen-mensaje
facilita la
autenticación del origen del mensaje, pero no el no repudio del origen del
contenido
del mensaje.
El originador del mensaje puede calcular
verificación-autentificación-origen-mensaje
utilizando la
clave-cifrado-secreta-asimétrica del originador. La
verificación-autenticación-origen-mensaje
puede validarse
por el destinatario o destinatarios del mensaje, y por cualquier ATM a través
del cual se transfiere el mensaje, utilizando la
clave-cifrado-pública-asimétrica (
clave-pública-sujeto
) del
originador del mensaje deducida a partir del
certificado-
originador
.
Futuras versiones de esta Recomendación pueden definir otras formas de
verificación-autenticación-origen-mensaje
(por ejemplo
basadas en técnicas-cifrado-simétricas) que pueden ser utilizadas por los ATM a
través de los cuales se transfiere el mensaje para autenticar el origen del
mensaje.
8.2.1.1.1.30
Etiqueta-seguridad-mensaje
Este argumento asocia una
etiqueta-seguridad
al mensaje
(o sonda). Puede ser generado por el originador del mensaje (o sonda), en línea
con la política-seguridad en vigor.
La
etiqueta-seguridad-mensaje
de un informe será la
misma que la
etiqueta-seguridad-mensaje
del mensaje sujeto
(o sonda-).
Si se asignan
etiquetas-seguridad
a los usuarios-STRM, a
los ATM y a otros objetos del STM, el tratamiento, por estos objetos, de
mensajes, sondas e informes que transportan
etiquetas-seguridad-mensaje
puede determinarse por la
política-seguridad en vigor. Si no se asignan
etiquetas-seguridad
a los usuarios STRM, a los ATM y a otros
objetos del STM, el tratamiento, por estos objetos, de los mensajes, sondas e
informes que transportan
etiquetas-seguridad-mensaje
puede
ser discrecional.
Si establecen
contextos-seguridad
entre el originador y
un ATM (el ATM-que-origina) del STRM (véanse los
8.1.1.1.1.3
y
8.2.1.4.1.5), la
etiqueta-seguridad-mensaje
que puede
asignar el originador a un mensaje (o sonda) puede determinarse por el
contexto-seguridad
(contexto-seguridad-remisión), en línea
con la política-seguridad en vigor. Si no se establecen
contextos-seguridad
entre el originador y el
ATM-que-origina, la asignación de una
etiqueta-seguridad-mensaje
a un mensaje (o sonda) puede
quedar a la discreción del originador.
Si se establecen
contextos-seguridad
entre dos ATM
(véase el
12.1.1.1.1.3
), la transferencia de mensajes, sondas o
informes entre los ATM puede determinarse por las
etiquetas-seguridad-mensaje
de los mensajes, sondas o
informes, y el
contexto-seguridad
, en línea con la
política-seguridad en vigor. Si no se establecen
contextos-seguridad
entre los ATM, la transferencia de
mensajes, sondas e informes puede quedar a la discreción del emisor.
Si se establecen
contextos-seguridad
entre un
usuario-STRM y un ATM (ATM-que-entrega) del STRM (véanse los
8.1.1.1.1.3
y 8.3.1.3.1.7), la entrega de mensajes e informes puede
determinarse por las
etiquetas-seguridad-mensaje
de los
mensajes e informes y el
contexto-seguridad
(contexto-seguridad-entrega), en línea con la política-seguridad en vigor. Si
las
etiquetas-seguridad-usuario
registradas del destinatario
autorizan la
etiqueta-seguridad-mensaje
de un mensaje o
informe, pero el
contexto-seguridad
corriente del
destinatario (contexto-seguridad-entrega) no la autoriza, entonces al
ATM-que-entrega puede retener-para-entrega. Si no se establecen los
contextos-seguridad
entre los usuarios STRM y el
ATM-que-entrega, la entrega de mensajes e informes puede realizarse a
discreción del ATM-que-entrega.
8.2.1.1.1.31
Petición-prueba-de-remisión
Este argumento indica si el originador del mensaje solicita la
prueba-de-remisión
(para proporcionar el
elemento-de-servicio prueba de remisión) definida en la Recomendación X.400 del
mensaje al STRM. Puede ser generado por el originador del mensaje.
Este argumento puede tener uno de los siguientes valores:
prueba-de-remisión-solicitada
o
prueba-de-remisión-no-solicitada
.
En ausencia de este argumento se supondrá que el valor por defecto es
prueba-de-remisión-no-solicitada
.
8.2.1.1.1.32
Petición de
prueba-de-entrega
Este argumento indica si el originador del mensaje solicita
prueba-de-entrega
(para proporcionar el elemento-de-servicio
prueba de entrega) definida en la Recomendación X.400 del mensaje al
destinatario. Puede ser generado por el originador del mensaje. Puede
especificarse un valor distinto de este argumento para cada destinatario del
mensaje.
Este argumento puede tener uno de los siguientes valores:
prueba-de-entrega-solicitada
o
prueba-de-entrega-no-solicitada
.
En ausencia de este argumento se supondrá que el valor por defecto es
prueba-de-entrega-no-solicitada
.
8.2.1.1.1.33
Tipos-información-codificada-originales
Este argumento identifica los
tipos-información-codificada
originales del
contenido
del mensaje. Puede generarse por el originador del
mensaje.
La ausencia de este argumento indica que los
tipos-de-información-codificada-originales
del
contenido
del mensaje están
sin
especificar
.
8.2.1.1.1.34
Tipo-contenido
Este argumento identifica el tipo de
contenido
del
mensaje. Será generado por el originador del mensaje. El
tipo-contenido
será o incorporado o ampliado.
Un
tipo-contenido
incorporado puede tener uno de los
siguientes valores:
-
sin identificar
: designa un
tipo-contenido
sin identificar y sin limitación; la
utilización de este
tipo-contenido sin identificar
constituye un acuerdo bilateral entre usuarios STRM;
-
externo
: designa un
tipo-contenido
que se reserva para el interfuncionamiento entre sistemas 1988 y sistemas 1984
(véase la Recomendación X.419);
-
mensajería-interpersonal-1984
: identifica el
tipo-contenido
de la
mensajería-interpersonal-1984
definido en la Recomendación
X.420;
-
mensajería-interpersonal-1988
: identifica el
tipo-contenido
de la
mensajería-interpersonal-1988
definido en la Recomendación
X.420;
-un valor específico de un
tipo-contenido
ampliado
definido en esta Recomendación es
sobre-interior
:
tipo-contenido-ampliado
que es un mensaje en sí mismo (sobre
y contenido), para ser enviado por el destinatario indicado en el
sobre-exterior a los indicados en el sobre-interior. El tipo del
contenido
OCTET STRING es una
UDPA-STRM
codificada utilizando las reglas de codificación básica de la NSA.1. [Obsérvese
que el sobre-interior y el contenido pueden protegerse introduciendo seguridad
en el
contenido
del sobre-exterior utilizando los argumentos
de seguridad (véanse los
8.2.1.1.1.25
y 8.2.1.1.1.32).]
Pueden definirse otros
tipos-contenido-ampliado
normalizados en futuras versiones de esta Recomendación. Pueden utilizarse
otros valores de este argumento mediante acuerdos bilaterales entre
usuarios-STRM.
8.2.1.1.1.35
Identificador-contenido
Este argumento contiene un identificador del
contenido
del mensaje. Puede generarse por el originador del mensaje.
El
identificador-contenido
puede ser entregado al
destinatario o destinatarios del mensaje, y devuelto al originador con algún
informe o informes. Este argumento no es alterado por el STRM.
8.2.1.1.1.36
Correlador-contenido
Este argumento contiene información que permite al originador del mensaje
efectuar la correlación del
contenido
del mensaje. Puede
generarse por el originador del mensaje.
El
correlador-contenido
no puede ser entregado al
destinatario o destinatarios del mensaje, pero se devuelve al originador con
algún informe o informes. Este argumento no debe ser modificado o suprimido por
otro que no sea el originador del mensaje.
8.2.1.1.1.37
Contenido
Este argumento contiene la información del mensaje que se pretende transportar al destinatario o destinatarios. Será generado por el originador del mensaje.
Excepto cuando se realiza una conversión, el STRM no modifica el
contenido
del mensaje; al contrario éste pasa de forma
transparente a través de él.
El
contenido
puede ser cifrado para asegurar su
confidencialidad (véase el
8.2.1.1.1.27
).
El
contenido
puede ser un
contenido-externo
. El
contenido
es un
contenido-externo
cuando el argumento del
tipo-contenido
tiene el valor
externo
.
Cuando el
contenido
es un
contenido-externo
, se especifica el
tipo-contenido- externo
mediante el identificador del objeto
de
contenido-externo
. Un
contenido-externo
puede utilizarse para transportar un
sobre-interior
(véase el
8.2.1.1.1.34
), o para el
interfuncionamiento entre sistemas 1988 y sistemas 1984 (véase la Recomendación
X.419).
8.2.1.1.2
Resultados
El cuadro 5/X.411 enumera los resultados de la operación-abstracta remisión-mensaje, y para cada resultado califica su presencia e identifica el punto en la que se define el resultado.
Cuadro 5/X.411 [T5.411], p.
8.2.1.1.2.1
Identificador-remisión-mensaje
Este resultado contiene un
identificador-STRM
que
identifica inequívocamente la remisión-mensaje. Debe ser generado por el STRM.
El STRM proporciona el
identificador-remisión-mensaje
al
notificar, al usuario-STRM, la entrega o la no-entrega del mensaje, a través de
la operación abstracta entrega-informe.
El usuario-STRM proporciona el
identificador-remisión-mensaje
al cancelar un mensaje cuya
entrega estaba diferida, a través de la operación-abstracta
cancelación-entrega-diferida.
8.2.1.1.2.2
Tiempo-remisión-mensaje
Este resultado indica el
tiempo
en que el STRM acepta la
responsabilidad del mensaje. Debe ser generado por el STRM.
8.2.1.1.2.3
Certificado-ATM-que-origina
Este resultado contiene el
certificado
del ATM en el que
se ha depositado el mensaje (ATM-que-origina). Debe ser generado por una fuente
de confianza (por ejemplo una autoridad-certificación), y puede suministrarse
por el ATM-que-origina, si el originador del mensaje solicitó una
prueba-de-remisión
(véase el
8.2.1.1.1.31
) y se
utiliza un algoritmo-cifrado-asimétrico para calcular la
prueba-de-remisión
.
Puede utilizarse el
certificado-ATM-que-origina
para
enviar al originador del mensaje una copia verificada de la
clave-cifrado-pública-asimétrica (
clave-pública-sujeto
) del
ATM-que-origina.
El originador del mensaje puede utilizar la
clave-cifrado-pública-asimétrica de los ATM-que-originan para validar la
prueba-de-remisión
.
8.2.1.1.2.4
Prueba-de-remisión
Este resultado proporciona al originador del mensaje la prueba de remisión
del mensaje al STRM (para proporcionar el elemento-de-servicio prueba de
remisión definido en la Recomendación X.400). En función del algoritmo-cifrado
utilizado y de la política de seguridad en vigor, este argumento puede
proporcionar igualmente el elemento-de-servicio no Repudio de remisión
(definido en la Recomendación X.400). Debe ser generado por el ATM-que- origina
del STRM, si el originador del mensaje solicitó la
prueba-de-remisión
(véase el
8.2.1.1.1.31
).
Se calcula la
prueba-de-remisión
utilizando el algoritmo
identificado por el
identificador-algoritmo-prueba-de-remisión
(un
algoritmo-identificador
).
La
prueba-de-remisión
contiene el
identificador-algoritmo-prueba-de-remisión
, y una función
cifrada (por ejemplo una versión comprimida o desmenuzada) del
identificador-algoritmo-prueba-de-remisión
, los argumentos
del mensaje remitido (véase el
8.2.1.1.1
), y el
identificador-remisión-mensaje
y el
tiempo-remisión-mensaje
. En la
prueba-de-remisión
se incluyen los componentes facultativos
si están presentes en el mensaje.
Obsérvese que la recepción de este resultado proporciona al originador del mensaje la prueba de remisión del mensaje. La no-recepción de este resultado no proporciona ni la prueba de remisión ni la prueba de no-remisión (a menos que se utilicen un enlace seguro y una funcionalidad de confianza).
Si se utiliza un algoritmo-cifrado-asimétrico, el ATM-que-origina puede
calcular la
prueba-de-remisión
, utilizando la
clave-cifrado-asimétrica-secreta del ATM-que-origina. El originador del mensaje
puede validar la
prueba-de-remisión
utilizando la
clave-cifrado-pública-asimétrica del ATM-que-origina
(
clave-pública-sujeto
) deducida del
certificado-ATM-que-origina
. Puede proporcionarse igualmente
una
prueba-de-remisión
para el no-Repudio de remisión.
Si se utiliza un algoritmo-cifrado-simétrico, la clave cifrado-simétrica
que el ATM-que-origina utilizó para calcular la
prueba-de-remisión
, y que el originador puede utilizar para
validar la
prueba-de-remisión
, puede deducirse a partir de
los
testigos-vinculación
(véanse los
8.1.1.1.1.3
y 8.1.1.1.2.2) intercambiados al iniciar la asociación. Como alternativa, la
clave-cifrado-simétrica utilizada para la
prueba-de-remisión
puede intercambiarse por algún otro procedimiento. Obsérvese que si se utiliza
un algoritmo-cifrado-simétrico, la
prueba-de-remisión
únicamente puede proporcionar el no Repudio de la remisión si la
política-seguridad en vigor proporciona la intervención de una tercera parte
que actúe como notario.
8.2.1.1.3
Errores-abstractos
El cuadro 6/X.411 enumera los errores abstractos que pueden interrumpir la operación-abstracta remisión-mensaje, y para cada error abstracto identifica el punto donde se define el error-abstracto.
Cuadro 6/X.411 [T6.411], p.
8.2.1.2
Remisión-sonda
La operación-abstracta remisión-sonda permite a un usuario-STRM remitir una sonda para determinar si podría transferirse y entregarse un mensaje (mensaje-sujeto) a uno o más usuarios-STRM destinatarios, si éste se presentara.
El éxito de una sonda no garantiza que un mensaje remitido posteriormente pueda ser realmente entregado, sino más bien que en el momento actual el destinatario es válido y el mensaje no tropezaría con obstáculos importantes para la entrega.
Para cualesquiera
nombres-destinatarios
que designe una
LD, la operación-abstracta remisión-sonda determina si se produciría una
ampliación de la LD especificada (pero no LD anidadas).
Para cualesquiera
nombres-destinatarios
para los cuales
se produciría un redireccionamiento, la operación-abstracta remisión-sonda
determina si podría transferirse y entregarse el mensaje al
destinatario-alternativo.
El usuario-STRM suministra la mayoría de los argumentos utilizados para la remisión-mensaje y la longitud del contenido del mensaje-sujeto. La operación abstracta remisión-sonda no culmina con la entrega a los destinatarios deseados del mensaje-sujeto, sino que establece si probablemente lo haría la operación-abstracta remisión-mensaje.
La ejecución satisfactoria de la operación-abstracta significa que el STRM ha aceptado hacerse cargo de la sonda (pero no que la haya llevado a cabo todavía).
La interrupción de la operación-abstracta por un error-abstracto indica que el STRM no puede hacerse cargo de la sonda.
8.2.1.2.1
Argumentos
El cuadro 7/X.411 enumera los argumentos de la operación-abstracta remisión-sonda, y para cada argumento califica su presencia e identifica el punto donde se define el argumento.
8.2.1.2.1.1
Verificación-autenticación-origen-sonda
Este argumento proporciona a cualquier ATM a través del cual se transfiere la sonda, los medios para autenticar el origen de la sonda (proporcionar el elemento-de-servicio autenticación del origen de la sonda definido en la Recomendación X.400). Puede generarse por el originador de la sonda.
La
verificación-autenticación-origen-sonda
proporciona
la prueba del origen de la sonda (autenticación del origen de la sonda), y la
prueba de la asociación entre la
etiqueta-seguridad-mensaje
y el
identificador-contenido
del mensaje-sujeto.
La
verificación-autenticación-origen-sonda
se calcula
utilizando el algoritmo identificado por el
identificador-algoritmo-autenticación-origen-sonda
(un
identificador-algoritmo
).
Cuadro 7/X.411 [T7.411], p.
La
verificación-autenticación-origen-sonda
contiene el
identificador-algoritmo-autenticación-origen-sonda
, y una
versión cifrada asimétricamente, desmenuzada del
identificador-algoritmo-autenticación-origen-sonda
, el
identificador-contenido
y la
etiqueta-seguridad-mensaje
del mensaje-sujeto. En la
verificación-autenticación-origen-sonda
se incluyen
componentes facultativos si éstos están presentes en la sonda.
El originador de la sonda puede calcular la
verificación-autenticación-origen-sonda
utilizando la
clave-cifrado-secreta-asimétrica del originador. La
verificación-autenticación-origen-sonda
puede validarse por
cualquier ATM a través del cual se transfiere el mensaje, utilizando la
clave-cifrado-pública-asimétrica (
clave-pública-sujeto
) del
originador del mensaje deducida a partir del
certificado-originador
.
Futuras versiones de esta Recomendación pueden definir otras formas de
verificación-autenticación-origen-sonda
(por ejemplo,
basadas en técnicas-cifrado-simétricas) que pueden ser utilizadas por los ATM a
través de los cuales se transfiere el mensaje para autenticar el origen de la
sonda.
8.2.1.2.1.2
Longitud-contenido
Este argumento especifica la longitud, en octetos, del
contenido
del mensaje-sujeto. Puede generarse por el
originador de la sonda.
8.2.1.2.2
Resultados
El cuadro 8/X.411 enumera los resultados de la operación-abstracta remisión-sonda, y para cada resultado califica su presencia e identifica el punto donde se define el resultado.
Cuadro 8/X.411 [T8.411], p.
8.2.1.2.2.1
Identificador-remisión-sonda
Este resultado contiene un
identificador-STRM
que
identifica de forma inequívoca la remisión-sonda. Debe ser generado por el
STRM.
El STRM proporciona el
identificador-remisión-sonda
, al
notificar al usuario-STRM, de su capacidad o incapacidad para entregar el
mensaje-sujeto, a través de la operación-abstracta de entrega-informe.
8.2.1.2.2.2
Tiempo-remisión-sonda
Este resultado indica el
tiempo
en que el STRM acepta la
responsabilidad de la sonda. Debe ser generado por el STRM.
8.2.1.2.3
Errores abstractos
El cuadro 9/X.411 enumera los errores abstractos que pueden interrumpir la operación-abstracta remisión-sonda, y para cada error-abstracto identifica el punto donde se define el error-abstracto.
Cuadro 9/X.411 [T9.411], p.
8.2.1.3
Cancelación-entrega-diferida
La operación-abstracta cancelación-entrega-diferida permite a un usuario-STRM abortar la entrega-diferida de un mensaje previamente remitido a través de la operación-abstracta remisión-mensaje.
El usuario-STRM identifica el mensaje cuya entrega debe cancelarse mediante
el
identificador-remisión-mensaje
devuelto por el STRM como
resultado de una invocación previa de la operación-abstracta remisión-mensaje.
La ejecución satisfactoria de la operación-abstracta significa que el STRM ha cancelado la entrega-diferida del mensaje.
La interrupción de la operación-abstracta por un error-abstracto indica que
la entrega-diferida del mensaje no puede cancelarse. La entrega-diferida de un
mensaje no puede cancelarse si el mensaje ya ha progresado para su entrega y»o
transferencia dentro del STRM. El STRM puede rehusar el cancelar la
entrega-diferida de un mensaje, si el STRM proporcionó al originador del
mensaje la
prueba-de-remisión
.
8.2.1.3.1
Argumentos
El cuadro 10/X.411 enumera los argumentos de la operación-abstracta cancelación-entrega-diferida y, para cada argumento califica la presencia e identifica el punto donde se define el argumento.
Cuadro 10/X.411 [T10.411], p.
8.2.1.3.1.1
Identificador-remisión-mensaje
Este argumento contiene el
identificador-remisión-mensaje
del mensaje cuya entrega
diferida debe ser cancelada. Debe ser suministrado por el usuario-STRM.
El STRM devuelve el
identificador-remisión-mensaje
(un
identificador-STRM
) como resultado de una invocación previa
de la operación-abstracta remisión-mensaje (véase el
8.2.1.1.2.1
),
cuando se presentó el mensaje para entrega-diferida.
8.2.1.3.2
Resultados
La operación-abstracta cancelación-entrega-diferida devuelve un resultado vacío como indicación de éxito.
8.2.1.3.3
Errores-abstractos
El cuadro 11/X.411 enumera los errores abstractos que pueden interrumpir la operación-abstracta cancelación-entrega-diferida, y para cada error-abstracto identifica el punto donde se define el error-abstracto.
Cuadro 11/X.411 [T11.411], p.
8.2.1.4
Control-remisión
La operación-abstracta control-remisión permite al STRM limitar transitoriamente las operaciones-abstractas puerto-remisión que puede invocar el usuario-STRM, y los mensajes que el usuario-STRM puede remitir al STRM a través de la operación-abstracta remisión-mensaje.
El usuario-STRM debe retener hasta un tiempo posterior, en vez de abandonar, las operaciones-abstractas y los mensajes prohibidos actualmente.
La ejecución satisfactoria de la operación-abstracta significa que los controles especificados están actualmente en vigor. Estos controles sobreseen cualquier otro en vigor, y permanecen vigentes hasta que se libera la asociación o el STRM reinvoca la operación-abstracta control-remisión.
La operación-abstracta devuelve una indicación de cualquier operación-abstracta que pudiera invocar el usuario-STRM, o cualquier tipo de mensaje que el usuario-STRM pudiera remitir, a no ser por los controles que prevalecen.
8.2.1.4.1
Argumentos
El cuadro 12/X.411 enumera los argumentos de la operación-abstracta control-remisión, y para cada argumento califica su presencia e identifica el punto donde se define el argumento.
Cuadro 12/X.411 [T12.411], p.
8.2.1.4.1.1
Limitación
Este argumento indica si los controles sobre las operaciones puerto-remisión deben actualizarse o suprimirse. Puede generarse por el STRM.
Este argumento puede tener uno de los siguientes valores:
-
actualización
: los otros argumentos actualizan los
controles que prevalecen;
-
supresión
: todos los controles deben suprimirse; los
otros argumentos deben ignorarse.
En ausencia de este argumento, se supondrá el valor por defecto de
actualización
.
8.2.1.4.1.2
Operaciones-admisibles
Este argumento indica las operaciones-abstractas que el usuario-STRM puede invocar sobre el STRM. Puede generarse por el STRM.
Este argumento puede tener el valor
autorizado
o
prohibido
para cada uno de los siguientes:
-
remisión-mensaje
: el usuario-STRM puede»no puede invocar
la operación-abstracta remisión-mensaje; y
-
remisión-sonda
: el usuario-STRM puede»no puede invocar
la operación-abstracta remisión-sonda.
Otras operaciones-abstractas de puerto-remisión no están sujetas a controles, y pueden invocarse en cualquier momento.
En ausencia de este argumento, las operaciones-abstractas que puede invocar el usuario-STRM permanecen sin cambios. Si no estaba en vigor ningún control previo, el usuario-STRM puede invocar tanto la operación-abstracta remisión-mensaje como la operación-abstracta remisión-sonda.
8.2.1.4.1.3
Prioridad-inferior-admisible
Este argumento contiene la
prioridad
del mensaje de
prioridad más baja que el usuario-STRM debe remitir al STRM a través de la
operación-abstracta remisión-mensaje. Puede generarse por el STRM.
Este argumento puede tener uno de los siguientes valores del argumento de
prioridad
de la operación-abstracta de remisión-mensaje:
normal
,
no urgente
o
urgente
.
En ausencia de este argumento, la
prioridad
del mensaje
de prioridad más baja que debe remitir el usuario-STRM al STRM permanece sin
modificar. Si no está ningún control previo en vigor, el usuario-STRM puede
presentar mensajes de cualquier prioridad.
8.2.1.4.1.4
Longitud-contenido-máxima-admisible
Este argumento contiene la
longitud-contenido
, en
octetos, del mensaje de contenido más largo que el usuario-STRM debe remitir al
STRM a través de la operación-abstracta remisión-mensaje. Puede generarse por
el STRM.
En ausencia de este argumento, la
longitud-contenido-máxima-admisible
de un mensaje que el
usuario-STRM puede remitir al STRM permanece sin modificar. Si no está en vigor
ningún control previo, la longitud del contenido no está explícitamente
limitada.
8.2.1.4.1.5
Contexto-seguridad-admisible
Este argumento limita de forma transitoria la sensibilidad de las
operaciones-abstractas de puerto-remisión (contexto-seguridad-remisión) que el
usuario-STRM puede invocar en el STRM. Es una limitación transitoria del
contexto-seguridad
establecido al iniciarse la asociación
(véase el
8.1.1.1.1.3
). Puede generarse por el STRM.
El
contexto-seguridad-admisible
consta de una o más
etiquetas-seguridad
del conjunto de
etiquetas-seguridad
establecidas como
contexto-seguridad
al establecerse la asociación.
En ausencia de este argumento, el
contexto-seguridad
de las operaciones-abstractas de puerto-remisión permanence sin modificar.
8.2.1.4.2
Resultados
El cuadro 13/X.411 enumera los resultados de la operación-abstracta control-remisión, y para cada resultado califica su presencia e identifica el punto donde se define el resultado.
Cuadro 13/X.411 [T13.411], p.
8.2.1.4.2.1
Operaciones-esperando
Este resultado indica las operaciones-abstractas que retiene el usuario-STRM y que el usuario-STRM invocaría en el STRM si no fuera por los controles que prevalecen. Puede generarse por el usuario-STRM.
Este resultado puede tener el valor
reteniendo
o
no-reteniendo
para cada uno de los siguientes:
-
remisión-mensaje
: el usuario-STRM está»no está
reteniendo mensajes, e invocaría la operación-abstracta remisión-mensaje en el
STRM si no fuera por los controles que prevalecen; y
-
remisión-sonda
: el usuario-STRM está»no está reteniendo
sondas, e invocaría la operación-abstracta remisión-sonda en el STRM si no
fuera por los controles que prevalecen.
En ausencia de este resultado, puede suponerse que el usuario-STRM no está reteniendo ningún mensaje ni ninguna sonda para su remisión al STRM debido a los controles que prevalecen.
8.2.1.4.2.2
Mensajes-esperando
Este resultado indica la categoría de los mensajes que el usuario-STRM está reteniendo para su remisión al STRM, y que remitiría a través de la operación-abstracta remisión-mensaje, si no fuera por los controles que prevalecen.
Este resultado puede adoptar uno de los siguientes valores:
-
contenido-largo
: el usuario-STRM ha retenido mensajes
para su remisión al STRM que exceden el control de
longitud-contenido-máxima-admisible
actualmente en vigor;
-
baja prioridad
: el usuario-STRM ha retenido mensajes
para su remisión al STRM de una
prioridad
inferior al
control de
prioridad-inferior-admisible
actualmente en
vigor;
-
otras-etiquetas-seguridad
: el usuario-STRM ha retenido
mensajes para su remisión al STRM, que transportan
etiquetas-seguridad-mensaje
diferentes de las permitidas por
el contexto-seguridad actual.
En ausencia de este resultado, puede suponerse que el usuario-STRM no está
reteniendo ningún mensaje ni ninguna sonda para su remisión al STRM debido a
los controles de
longitud-contenido-máxima-admisible
,
prioridad-inferior-admisible
o
contexto-seguridad-admisible
actualmente en vigor.
8.2.1.4.2.3
Tipos-información-codificada-esperando
Este resultado indica los
tipos-información-codificada
del
contenido
de cualquier mensaje retenido por el
usuario-STRM para su remisión al STRM debido a los controles que prevalecen.
Puede generarse por el usuario-STRM.
En ausencia de este resultado, los
tipos-información-codificada
de cualquier mensaje retenido
por el usuario-STRM para su remisión al STRM están
sin-especificar
.
8.2.1.4.2.4
Tipos-contenido-esperando
Este resultado indica los
tipos-contenido
de cualquier
mensaje retenido por el usuario-STRM para su remisión al STRM debido a los
controles que prevalecen. Puede generarse por el usuario-STRM.
En ausencia de este resultado, los
tipos-contenido
de
cualquier mensaje retenido por el usuario-STRM para su remisión al STRM están
sin-especificar
.
8.2.1.4.3
Errores-abstractos
El cuadro 14/X.411 enumera los errores-abstractos que pueden interrumpir la operación-abstracta control-remisión, y para cada error-abstracto identifica el punto donde se define el error-abstracto.
Cuadro 14/X.411 [T14.411], p.
8.2.2
Errores-abstractos
En este punto se definen los siguientes errores-abstractos de puerto-remisión:
a)control-remisión-violado
b)elemento-de-servicio-no-abonado
c)cancelación-entrega-diferida-rechazada
d)originador-inválido
e)destinatario-indebidamente-especificado
f)identificador-remisión-mensaje-inválido
g)petición-incoherente
h)error-seguridad
i)función-crítica-no-admitida
j)error-vinculación-distante
8.2.2.1
Control-remisión-violado
El error-abstracto de control-remisión-violado informa de la violación, por el usuario-STRM, de un control sobre los servicios de puerto-remisión impuestos por el STRM a través del servicio de control-remisión.
El error-abstracto de control-remisión violado no tiene parámetros.
8.2.2.2
Elemento-de-servicio-no-abonado
El servicio de elemento-de-servicio-no-abonado informa que la operación-abstracta solicitada no puede ser proporcionada por el STRM porque el usuario-STRM no está abonado a uno de los elementos-de-servicio que la petición requiere.
El error-abstracto de elemento-de-servicio-no-abonado no tiene parámetros.
8.2.2.3
Cancelación-entrega-diferida-rechazada
El error-abstracto de cancelación-entrega-diferida-rechazada informa que el
STRM no puede cancelar la entrega-diferida de un mensaje, porque el mensaje ya
ha progresado para su transferencia y»o entrega o porque el STRM ha
proporcionado al originador una
prueba-de-remisión
.
El error-abstracto de cancelación-entrega-diferida-rechazada no tiene parámetros.
8.2.2.4
Originador-inválido
El error-abstracto originador-inválido informa que no puede remitirse el mensaje o la sonda porque el originador está incorrectamente identificado.
El error-abstracto originador-inválido no tiene parámetros.
8.2.2.5
Destinatario-indebidamente-especificado
El error-abstracto destinatario-indebidamente-especificado informa que no puede remitirse el mensaje o la sonda porque el destinatario o destinatarios están indebidamente especificados.
El error-abstracto destinatario-indebidamente-especificado tiene los siguientes parámetros generados por el STRM:
-
destinatarios-indebidamente-especificados
:
nombres-destinatarios
indebidamente especificados.
8.2.2.6
Identificador-remisión-mensaje-inválido
El error-abstracto identificador-remisión-mensaje-inválido informa que no
puede cancelarse una entrega-diferida de un mensaje porque el
identificador-remisión-mensaje
es inválido.
El error-abstracto identificador-remisión-mensaje-inválido no tiene parámetros.
8.2.2.7
Petición-incoherente
El error-abstracto petición-incoherente informa que la operación-abstracta solicitada no puede ser proporcionada por el STRM porque el usuario-STRM ha realizado una petición-incoherente.
El error-abstracto petición-incoherente no tiene parámetros.
8.2.2.8
Error-seguridad
El error-abstracto error-seguridad informa que la operación-abstracta solicitada no puede ser proporcionada por el STRM porque se violaría la política-seguridad en vigor.
El error-abstracto error-seguridad tiene los siguientes parámetros, generados por el STRM:
-
problema-seguridad
: identificador de la causa de
violación de la política-seguridad.
8.2.2.9
Función-crítica-no-admitida
El error-abstracto función-crítica-no-admitida informa que un argumento de
la operación-abstracta ha sido marcado como
crítico-para-remisión
(véase el
9.1
) pero que no
está admitido por el STRM.
El error-abstracto función-crítica-no-admitido no tiene parámetros.
8.2.2.10
Error-vinculación-distante
El error-abstracto error-vinculación-distante informa que la operación abstracta solicitada no puede ser proporcionada por la MM debido a que ésta no puede vincularse al STRM. Obsérvese que este error-abstracto sólo se produce en casos de remisión indirecta al STRM a través de una MM.
El error-abstracto error-vinculación-distante no tiene parámetros.