Redes de Próxima Generación

ORGANIZACIÓN DE LOS ESTADOS AMERICANOS COMISION INTERAMERICANA DE TELECOMUNICACIONES

COMITÉ CONSULTIVO PERMANENTE I: NORMALIZACION DE TELECOMUNICACIONES

CARPETA TECNICA:

REDES DE PROXIMA GENERACION Visión general de normas

Redes de Próxima Generación – Visión general de normas

ii

CARPETA TECNICA-1 (2004)

Referencia: P1!T-0363/04

CITEL Comisión Interamericana de Telecomunicaciones

1889 F St.NW #1020 Washington, DC Estados Unidos

http://citel.oas.org

Por consultas adicionales dirigirse a:

Oscar Avellaneda Tel: +1 613 765 4997 Fax: +1 613 763 2697

Correo electrónico: [email protected]

o

Secretario Ejecutivo de la CITEL Tel: +1 202 458 3004 Fax: +1 202 458 6854

Correo electrónico: [email protected]

CITEL, Marzo 2004 Reservados todos los derechos. No podrá reproducirse o utilizarse el presente documento ni parte del mismo de cualquier forma ni por cualquier procedimiento, electrónico o mecánico, comprendidas la fotocopia y la grabación en micropelícula, sin autorización escrita de la CITEL.


ii

CARPETA TECNICA1 Una Carpeta Técnica proveerá una manera formal de mantener una ficha sobre la información técnica de proyectos que será puesta a disposición de la industria de las telecomunicaciones en los Estados miembros.

Se utilizan dichas Carpetas Técnicas para:

a) Publicar información técnica para la caracterización de redes o funcionalidad de servicios para servicios nuevos o existentes.

b) Describir o reportar la situación de un proyecto en estudio para el uso presente y futuro de

un Grupo de Trabajo.

c) Publicar los hallazgos de un estudio, una revisión o de una encuesta.

d) Procedimientos de documentación, asuntos relacionados a trabajos realizados en conjunto o asuntos de interconexión, que beneficiarían la industria pero que no son adaptables ni prácticos como Documentos sobre Normas Coordinadas (CSD).

e) Normas de documentación, completos o en progreso, para servicios nuevos o existentes,

que puedan ser considerados para futuro desarrollo en un CSD, de acuerdo con los procedimientos de aprobación del GTCN.

Los miembros de CITEL no han aprobado el contenido de este documento.

1 CCP..I/RES. 142 (XV-01)


iii

INDICE Resumen....................................................................................................................................... 1 1 Introducción .......................................................................................................................... 2 2. Normas de señalización.......................................................................................................... 5

2.1 SIGTRAN (SIGnaling TRANsport = transmisión de señalización) .................................... 5 2.2 BICC........................................................................................................................... 6 2.3 Megaco/H.248.............................................................................................................. 6 2.4 SIP .............................................................................................................................. 7

2.4.1 Funcionamiento del SIP............................................................................................. 8 2.5 SIP-T..........................................................................................................................10 2.6 Q.1912.sip ...................................................................................................................10 2.7 H.323..........................................................................................................................11

3 Normas de acceso................................................................................................................13 3.1 Normas de acceso de abonado de línea digital (DSL) .....................................................13

3.1.1 Foro DSL................................................................................................................14 3.1.1.1 Requisitos de acceso IP...................................................................................14 3.1.1.2 ATM sobre ADSL..........................................................................................16 3.1.1.3 AAL5 sobre ATM..........................................................................................16 3.1.1.4 Protocolo “x” sobre AAL5 ..............................................................................16 3.1.1.5 PPP (protocolo de punto a punto) .....................................................................16 3.1.1.6 PPP sobre ALL5 ............................................................................................16 3.1.1.7 PPP sobre Ethernet.........................................................................................17 3.1.1.8 IP sobre AAL5...............................................................................................17 3.1.1.9 IP sobre Ethernet............................................................................................17 3.1.1.10 Protocolo de Capa 2 para creación de túneles (L2TP).......................................17 3.1.1.11 Consideraciones relativas al IP.........................................................................17

3.2 Normas de acceso por cable .........................................................................................18 3.3 Normas de acceso inalámbrico .....................................................................................18

4 Normas de gestión ................................................................................................................19 5 Normas de creación de servicios............................................................................................20

5.1 Conjunto de capacidades de red inteligente (IN CS-4) ....................................................20 5.2 Normas de entorno de programabilidad abierta...............................................................23

5.2.1 RMI .......................................................................................................................23 5.2.2 XML ......................................................................................................................23 5.2.3 API........................................................................................................................24

6 Normas de seguridad ............................................................................................................25 6.1 Seguridad IP (IPSec) ...................................................................................................25

6.1.1 Asociaciones de seguridad (SAs)..............................................................................25 6.1.2 Encabezamiento de autenticación (AH).....................................................................25 6.1.3 Carga útil de protección de encapsulado (Encapsulation Security Payload: ESP)......26 6.1.4 Gestión de claves.....................................................................................................27 6.1.5 Intercambio manual de claves...................................................................................27

6.2 Intercambio de claves Internet (IKE) ............................................................................28 6.2.1 Modo principal.........................................................................................................28 6.2.2 Modo dinámico........................................................................................................28 6.2.3 Modo rápido............................................................................................................28

6.3 Para mayor estudio ......................................................................................................29 7 Normas de desempeño y calidad del servicio (QoS) ................................................................30


iv

7.1 QoS en redes basadas en el IP .....................................................................................31 7.1.1 Obtención de una calidad de servicio RTPC tradicional en las redes IP .......................31 7.1.2 Características y expectativas del servicio VoIP ........................................................31 7.1.3 Estrategia para la QoS en redes IP ...........................................................................34 7.1.4 Tecnologías para la QoS de redes IP ........................................................................34

7.1.4.1 Servicios integrados (Integrated Services = Int-Serv) .....................................34 7.1.4.2 Servicios diferenciados (Differentiated Services = Diff-Serv)........................35 7.1.4.3 Normativa de calidad del servicio (QoS) ...........................................................36 7.1.4.4 Conmutación por etiquetas multiprotocolo (Multi-Protocol Label Switching = MPLS) 36

7.2 Objetivos de calidad del funcionamiento de la red...........................................................37 7.2.1 Y.1540....................................................................................................................37 7.2.2 Y.1541....................................................................................................................38

7.2 Para mayor studio ........................................................................................................39 8 Normas en evolución.............................................................................................................41

8.1 Protocolo Internet versión 6 (IPv6) ...............................................................................41 8.1.1 Atajos en el Ipv4 .....................................................................................................42 8.1.2 Seguimiento de ubicaciones ......................................................................................43 8.1.3 Direccionamiento Ipv6.............................................................................................44 8.1.4 Representación de la dirección Ipv6..........................................................................44 8.1.5 Tipos de dirección Ipv6 ............................................................................................45 8.1.6 Direcciones unidifusión Ipv6.....................................................................................45 8.1.7 Direcciones de difusión a cualquier punto Ipv6...........................................................45 8.1.8 Direcciones de multidifusión.....................................................................................46

8.2 Para mayor estudio ......................................................................................................47 9 Conclusión............................................................................................................................48 10 Referencias ......................................................................................................................49 11 Acrónimos y abreviaciones ................................................................................................50


1

REDES DE PROXIMA GENERACION UNA VISION GENERAL

Resumen Las redes de próxima generación (Next Generation Networks = NGN) son redes convergentes multiservicios de voz/datos que funcionan en un mercado con una multiplicidad de proveedores. Las NGN requieren una arquitectura que permita la integración sin solución de continuidad con servicios de telecomunicaciones tanto nuevos como tradicionales en redes de paquetes de alta velocidad, interfuncionando con clientes que poseen capacidades heterogéneas. Dicha arquitectura generalmente está estructurada alrededor de cuatro capas principales de tecnología. La capa núcleo de conectividad incluye el encaminamiento y la conmutación, pasarelas de red y acceso. La capa de acceso y de equipo del local del cliente (customer-premises equipment = CPE) incluye las diversas tecnologías usadas para llegar a los clientes. La capa de servidor de aplicaciones contiene servicios mejorados y aplicaciones de valor añadido. La capa de gestión proporciona funciones de dirección empresarial, de los servicios y de la red. Cada una de estas capas se basa en una serie de normas que son esenciales para la introducción con buen éxito de una NGN. En el documento “Redes de próxima generación – Reseña de las normas” se identifican las normas relacionadas con las NGN que el Grupo de Trabajo sobre Coordinación de Normas está estudiando, entre ellas los protocolos pertinentes y la telefonía Internet. Esta contribución contiene actualizaciones editoriales de dicho documento [7]. Se estima que, a medida que se presenten las contribuciones del caso y que trate sobre las mismas el grupo de trabajo, se seguirá actualizando el presente documento.


2

1 Introducción La arquitectura y la ejecución de la red de próxima generación (NGN) deberán partir de interfaces y protocolos abiertos basados en normas. Ello es esencial para obtener el interfuncionamiento de productos de distintos proveedores, y para acelerar el ritmo de las innovaciones. También es generalmente aceptado que la NGN debe basarse en una arquitectura distribuida que ayude considerablemente a reducir los costos de ejecución, al mismo tiempo que flexibilice su introducción. Las NGN deberán poder trabajar con servicios sumamente adaptables, que puedan crearse fácil y rápidamente, así como establecerse económicamente en toda la red. Si bien es importante habilitar nuevos servicios, también es importante preservar los servicios existentes provenientes de las redes anteriores. En la Figura 1 se muestra una arquitectura de NGN acorde en general con la visión de la mayoría de las empresas explotadoras. La arquitectura puede descomponerse en varias capas: conectividad de núcleo, acceso y equipo del local del cliente (Access and Customer Premise Equipment = CPE), y gestión.

Figura 1 – Arquitectura de red de próxima generación

Services: Servicios Voice Services: Servicios de voz Multimedia Services: Servicios de multimedios Data Services: Servicios de datos

Management

Access

Premise Customer Premise Portfolio

ATM/IPCore

ATM/IPCore

New Access

En

dE

nd--toto--en

d N

etwo

rk Man

agem

ent

end Netw

ork Managem

ent

Internet

ISP

Services

MG

MG

MG

MGMG

VoiceServices

MultimediaServices

DataServices

OtherCarriers

TDMEquipment

Management

Access

Premise Customer Premise Portfolio

ATM/IPCore

ATM/IPCore

New Access

En

dE

nd--toto--en

d N

etwo

rk Man

agem

ent

end Netw

ork Managem

entE

nd

End

--toto--end

Netw

ork M

anag

emen

tend N

etwork M

anagement

InternetInternet

ISPISP

Services

MGMG

MGMG

MGMG

MGMGMGMG

VoiceServices

VoiceServices

MultimediaServices

MultimediaServices

DataServices

DataServices

OtherCarriers

OtherCarriers

TDMEquipment

TDMEquipment


3

Management: Gestión MG: Media Gateway (pasarela de medios) End-to-End Network Management: Gestión de red de extremo a extremo ATM/IP Core: Núcleo ATM/IP Other Carriers: Otras empresas de comunicaciones TDM Equipment: Equipo TDM New Access: Nuevo acceso Access: Acceso Premise: Local (del cliente) Customer Premise Portfolio: Cartera del local del cliente Capa de conectividad primaria La capa de conectividad de núcleo proporciona el encaminamiento y conmutación general del tráfico de la red de un extremo de ésta al otro. Está basada en la tecnología de paquetes, ya sea ATM o IP, y ofrece un máximo de flexibilidad. La tecnología que se elija dependerá de las consideraciones comerciales, pero la transparencia y la calidad del servicio (QoS) deben garantizarse en cualquier caso, ya que el tráfico de los clientes no debe ser afectado por perturbaciones de la calidad, tales como las demoras, las fluctuaciones y los ecos. Al borde de la ruta principal de paquetes están las pasarelas: su función principal es adaptar el tráfico del cliente y de control a la tecnología de la NGN. Las pasarelas se interconectan con otras redes, en cuyo caso son llamadas pasarelas de red, o directamente con los equipos de usuarios finales, en cuyo caso se las denomina pasarelas de acceso. Las pasarelas interfuncionan con los componentes de la capa de servicio, usando protocolos abiertos para suministrar servicios existentes y nuevos. Capa de acceso La capa de acceso incluye las diversas tecnologías usadas para llegar a los clientes. En el pasado, el acceso estaba generalmente limitado a líneas de cobre o al DS1/E1. Ahora vemos una proliferación de tecnologías que han surgido para resolver la necesidad de un ancho de banda más alto, y para brindar a las empresas competidoras de comunicaciones un medio para llegar directamente a los clientes. Los sistemas de cable, xDSL e inalámbricos se cuentan entre las soluciones más prometedoras que están creciendo e introduciendo innovaciones rápidamente. El equipo del local del cliente, ya sea de su propiedad o arrendado, proporciona la adaptación entre la red de la empresa explotadora y la red o equipo del cliente. Puede tratarse de un simple teléfono, pero podemos apreciar una migración progresiva hacia dispositivos inteligentes que pueden trabajar con servicios tanto de voz como de datos. Capa de servicio Esta capa consiste en el equipo que proporciona los servicios y aplicaciones disponibles a la red. Los servicios se ofrecerán a toda la red, sin importar la ubicación del usuario. Dichos servicios serán tan independientes como sea posible de la tecnología de acceso que se use. El carácter distribuido de la NGN hará posible consolidar gran parte del equipo que suministra servicios en puntos situados centralmente, en los que pueda lograrse una mayor eficiencia. Además, hace posible distribuir los servicios en los equipos de los usuarios finales, en vez de distribuirlos en la red. Los tipos de servicio que se ofrecerán abarcarán todos los de voz existentes, y también una gama de servicios de datos y otros servicios nuevos de medios múltiples. Capa de gestión


4

Esta capa, esencial para minimizar los costos de explotar una NGN, proporciona las funciones de dirección empresarial, de los servicios y de la red. Permite la provisión, supervisión, recuperación y análisis del desempeño de extremo a extremo necesarios para dirigir la red. Condiciones para la definición de normas Las organizaciones normalizadoras (SDO) deben cumplir una serie de condiciones al especificar las normas para las redes de próxima generación. Algunas de esas condiciones son las siguientes:

• interfuncionamiento sin transiciones difíciles de la red IP con la RTPC; • niveles de desempeño del servicio como los ofrecidos actualmente por la infraestructura

telefónica tradicional (p. ej., en la espera para el establecimiento de llamadas); • interfuncionamiento de dominios administrativos múltiples teniendo en cuenta los diferentes

protocolos de señalización; • variación a escala para trabajar con un gran número de clientes; • simplicidad; y • la capacidad para trabajar con nuevos servicios.

Debe tenerse en cuenta que muchas de las normas usadas para interfaces y aplicaciones de la NGN están evolucionando y cambiando rápidamente. En las secciones siguientes se delinean las normas pertinentes de la NGN. Dichas normas abarcan aspectos de la red tales como la señalización, el acceso, la creación de servicios, la gestión, la seguridad y la calidad del servicio.

*****

Redes de Próxima Generación

2. Normas de señalización Esta sección está basada en la contribución de la CITEL CCP.1/doc.957/00 (Normas en evolución para la telefonía Internet) [1, 2]. Algunas secciones de ese documento han sido ampliadas, pero otras permanecen tal como figuran en la contribución original CCP.I/doc.957/00 de la CITEL. Las Comisiones de Estudio (SG) 11 y 16 del UIT-T han estado trabajando en la señalización telefónica IP. El SG 16 elaboró la Recomendación H.323 (Sistemas de comunicación multimedios basados en paquetes). Más recientemente, la comisión de Estudio 11 ha formulado otro método para la telefonía por redes de paquetes, consistente en introducir una red de paquetes primaria en las redes existentes de conmutación de circuitos. El protocolo formulado para las comunicaciones entre centrales telefónicas es conocido como protocolo de control de llamada de portador independiente (Bearer Independent Call Control: BICC). Además, el SG 11 también ha estado trabajando en cuestiones relacionadas con el SIP, y en el proyecto de Recomendación Q.1912.sip se define el interfuncionamiento de señalización entre los protocolos BICC o ISUP y el SIP con su protocolo de descripción de sesiones (SDP) correspondiente en una unidad de interfuncionamiento (IWU). Los grupos de trabajo del Grupo de Tareas sobre Ingeniería de Internet (IETF) tales como el iptel (telefonía IP), pint (Internet RTPC), sigtran (transmisión de señalización), megaco (control de pasarelas de medios) y mmusic (control de sesiones de medios y partes múltiples) también han estado trabajando en varios protocolos relacionados con la Internet, tales como el protocolo de iniciación de sesiones (Session Initiation Protocol = SIP), el protocolo de iniciación de sesiones para telefonía (Session Initiation Protocol for Telephony = SIP-T), el protocolo de transporte de control de tren (Stream Control Transport Protocol = SCTP), y el control de pasarela de medios (Media Gateway Control = Megaco). Merece mencionarse que el protocolo H.248/Megaco, usado para coordinar pasarelas de medios desde un controlador de tales pasarelas, ha sido elaborado conjuntamente por la Comisión de Estudio 16 del UIT-T y el grupo de trabajo Megaco del IETF.

2.1 SIGTRAN (SIGnaling TRANsport = transmisión de señalización)

El mandato del grupo de trabajo Sigtran del IETF es crear protocolos relativos a la transmisión de la señalización de la RTPC basadas en de paquetes por redes IP, teniendo en cuenta los requisitos funcionales y de desempeño de tal señalización. Dichos protocolos son compatibles con las comunicaciones entre el controlador de pasarelas de medios y la pasarela de señalización. El grupo de trabajo Sigtran ha especificado el SCTP (Stream Control Transport Protocol = protocolo de transporte de control de tren), RFC 2960 (norma propuesta) y varias capas de adaptación para la transmisión de SS7 por redes basadas en el IP. Algunas capas de adaptación son las siguientes: • SS7 MTP2 – Capa de adaptación del usuario, RFC 3331 (norma propuesta), que

transporta información de señalización del usuario entre el SG y el MGC; • SS7 MTP3 – Capa de adaptación del usuario, RFC 3332 (norma propuesta), que

transporta mensajes ISUP y SCCP entre el SG y el MGC. • ISDN Q.921 – Capa de adaptación del usuario, RFC 3057 (norma propuesta), que define

un protocolo para el retroceso de los mensajes del usuario de RDSI Q.921 sobre IP usando SCTP.


6

Todavía se está trabajando en el protocolo Sigtran. La RFC 2719 (informativo) proporciona el marco arquitectónico para la transmisión de la señalización, y en la RFC 3257 (informativo) se describe la aplicabilidad del protocolo de transmisión de control de tren.

2.2 BICC

El protocolo de control de llamada de portador independiente (Bearer Independent Call Control = BICC), que está preparando la Comisión de Estudio 11 del UIT-T, ofrece un medio para que los explotadores actuales de la RTPC, basándose en la tecnología de circuitos conmutados, hagan evolucionar sus redes hacia la compatibilidad con los servicios de voz por paquetes con un efecto mínimo en sus operaciones. Aunque existe cierta duplicación en la funcionalidad entre la especificación BICC del SG 11 y la H.323 del SG 16, la especificación H.323 se concentra en empresas pequeñas y nuevas de telecomunicaciones, mientras que la BICC es para las necesidades de las actuales empresas operadoras de redes que han instalado redes ISUP y desean postergar su migración a SIP / SIP-T. El protocolo BICC está basado en el protocolo de parte usuario de RDSI (ISUP) CCS7, y se especifica en la Recomendación Q.1901 del UIT-T. El BICC se transmite usando el mecanismo de transporte de aplicación (Application Transport Mechanism = APM). El protocolo BICC es una aplicación de la definición del protocolo ISUP, pero no es compatible entre pares con ISUP. Dicho protocolo recibía antes la denominación de ISUP+. El conjunto de capacidades uno (CS1) del BICC, compatible con las comunicaciones entre controladores de pasarelas de medios, fue decidido (aprobado) por el SG 11 el 15 de junio de 2000. El BICC CS2 (Recomendación Q.1902 del UIT-T) se refiere a otras redes portadoras, entre ellas las redes IP. Trata sobre las interfaces e interacciones del controlador de pasarela de medios con la pasarela de medios. El BICC CS2 se determinó en noviembre de 2000. El SG 11 continúa trabajando en el BICC CS3.

2.3 Megaco/H.248

El Grupo de Trabajo Megaco (MEdia GAteway COntrol = control de pasarela de medios) del IETF y el Grupo de Estudio 16 del UIT-T colaboraron en la definición del protocolo Megaco/H.248. La tarea se originó en el grupo de trabajo Megaco del IETF, y la mayoría de las discusiones técnicas y ultimación de las cuestiones tuvieron lugar en ese entorno. El Megaco/H.248 es un protocolo de control de pasarela con muchas aplicaciones. Puede usarse para una gran variedad de aplicaciones de pasarela trasladando trenes de información de redes IP RTPC, ATM, y otros sistemas. La norma emplea un modelo amo-esclavo en el que la terminal de origen y/o la pasarela son esclavas del controlador de pasarela de medios. El UIT-T aprobó la Recomendación H.248 el 15 de junio de 2000, y poco después el IETF emitió un protocolo Megaco RFC 2885. En la RFC 2886 (fe de erratas) se registran los errores hallados en el documento del protocolo Megaco/H.248 [RFC 2885], junto con los cambios propuestos en el texto de ese documento para resolverlos. La RFC 3015 (norma propuesta) es el resultado de aplicar los cambios de la RFC 2886 al texto de la RFC 2885. RFC 3015 obsoletas RFC 2885 y RFC 2886. En la guía de paquetes H.248 versión 1 del UIT-T se resumen los paquetes que han sido normalizados en el período del 6/2000 al 6/2001.


7

La RFC 3525 – Protocolo de Control de Pasarela Versión 1 reemplaza a la RFC 3015. La RFC 3525 incorpora el texto original de RFC 3015, modificado mediante correcciones y aclaraciones discutidas en la lista de correo electrónico de Megaco. La versión 2 de la H.248 fue finalizada en la reunión del SG 16 en febrero de 2002. La RFC 3525/H.248v2 contiene correcciones actualizadas al RFC 3015/H.248v1 que estaban en la guía de implementadores, además de otros cambios tales como la depreciación del descriptor del módem, aclaración del texto de auditoría, y adición de auditorías dirigidas; mejora de la recolección de dígitos; y adición de multiplaje Nx64 al descriptor del múltiplex. El H248 fue renumerado cuando se revisó el 29-03-2002. El cuerpo principal del H.248, Anexos A a E y el Apéndice I se incluyeron en el H.248.1, “Protocolo de Control de Pasarela Versión 1”. Los anexos siguientes fueron numerados en consecuencia en las series, por ejemplo, H.248 Anexo F se volvió H.248.2. El 22 de mayo de 2002, se aprobó el H.248.1, “Protocolo de Control de Pasarela Versión 1”. La Versión 2 incluye algunas mejoras a la Versión 1, tales como la auditoría individual de la propiedad, señal, evento y estadística; un mejor manejo de multiplexación; la topología para tren de bits; una mejor descripción de los perfiles; y la capacidad de modificar ServiceChange. Actualmente el último anexo incluido es H.248.27 (Paquete de Tonos Suplementales”).

2.4 SIP

El protocolo de iniciación de sesiones (SIP) [3], creado por el grupo de trabajo de control de sesiones de medios y partes múltiples (MMUSIC) del IETF, y especificado actualmente como norma propuesta (RFC 3261), está fundamentado en una arquitectura simple textual de respuesta a pedidos, similar a otros protocolos Internet tales como el HTTP. La norma propuesta se publicó en junio de 2002. El trabajo relativo al SIP atrajo suficiente atención como para crear un grupo de trabajo del SIP por separado para continuar su perfeccionamiento. Desde su publicación, se ha reconocido que el SIP requiere extensiones para ofrecer aplicaciones telefónicas con la calidad de las comunicaciones públicas y el grupo de trabajo del SIP está considerando propuestas para lograr esto. Dichas propuestas suman una nueva funcionalidad al protocolo SIP básico, tal como el uso de MCU para conferencias de partes múltiples, la funcionalidad de la transferencia de llamadas, respuestas provisionales confiables (“llamada en curso”) y abertura del paso en los medios para una llamada previa. El protocolo de descripción de sesiones (Session Description Protocol = SDP) (norma propuesta) se usa en el SIP para comunicar parámetros de la sesión, tales como la codificación de medios. El grupo MMUSIC está trabajando para mejorar la funcionalidad del SDP. La adopción por PacketCable, un proyecto de CableLabs y sus miembros, constituye la más significativa entre las primeras adopciones del SIP. En la iniciativa de PacketCable se reconoció también que el SIP debe extenderse para que ofrezca servicios de calidad de comunicaciones públicas. El resultado de esto es la especificación de la señalización de llamadas distribuida (Distributed Call Signaling = DCS) de PacketCable. Algunas de las ideas presentadas en la especificación DCS han sido publicadas como borradores de Internet. El protocolo Servidor de Gestión de Llamadas a CMS de PacketCable utiliza la especificación del protocolo de iniciación de sesiones (Session Initiation Protocol: SIP) 2.0 con extensiones y reglas de uso compatibles con los servicios locales y CLASS disponibles comúnmente. Su denominación es protocolo de señalización de servidor de gestión de llamadas (Call Management Server Signaling: CMSS).


8

El SIP es un protocolo de control de la señalización entre pares para crear, modificar y finalizar sesiones (p. ej., conferencias, llamadas telefónicas y distribución de multimedios) con uno o más participantes. Entre dichas sesiones se cuentan conferencias por multimedios en la Internet, llamadas telefónicas por ésta y distribución de multimedios. Los miembros de una sesión pueden comunicarse vía multidistribución o vía una malla de relaciones unidifusión, o mediante una combinación de éstas. Las invitaciones SIP usadas para crear sesiones portan descripciones de la sesión, que permiten a los participantes convenir en un conjunto de tipos de medios compatibles. El SIP permite la movilidad de los usuarios, representando y redirigiendo los pedidos a la ubicación en ese momento del usuario. Los usuarios pueden registrar su ubicación vigente. El SIP no está ligado a ningún protocolo determinado de control de conferencias. Está diseñado para ser independiente del protocolo de transporte de capa inferior, y puede extenderse con capacidades adicionales. La RFC 3261 abarca la funcionalidad básica, y hay varios borradores de Internet conexos que cubren los servicios. El SIP está cobrando un rápido impulso en la industria, a nivel de sistema y de dispositivo. Se han realizado varias pruebas, demostrando diferentes proveedores el interfuncionamiento de las llamadas básicas. Hay actualmente varias propuestas para extensiones, aguardando para ser debatidas en el grupo de trabajo.

2.4.1 Funcionamiento del SIP

Las personas llamantes y las llamadas se identifican mediante direcciones SIP. Los “objetos” direccionados por el SIP son usuarios en anfitriones, identificados por una URL SIP, lo cual adquiere una forma similar a una URL “mailto” o “telnet”, o sea, usuario@anfitrión. La parte usuario es el nombre del usuario o un número telefónico. La parte anfitrión es el nombre de un dominio o una dirección numérica de red. Al hacer una llamada SIP, el llamante primero halla el servidor apropiado (A) y luego envía un pedido SIP (B). La operación SIP más común es la invitación (C). En vez de llegar directamente a la persona que se llama, un pedido SIP puede ser redirigido o puede causar una cadena de nuevos pedidos SIP mediante apoderados o representantes (D). Los usuarios pueden inscribir sus ubicaciones con servidores SIP (E).


9

A. Para hallar un servidor SIP Cuando un cliente desea enviar un pedido, lo envía a un servidor alterno SIP configurado localmente (como en HTTP), o a la dirección SIP y puerto correspondiente al “Request-URL”. B. Pedido SIP Una vez que la parte anfitrión se ha resuelto en un servidor SIP, el cliente envía uno o más pedidos SIP a ese servidor, y recibe una o más respuestas del mismo. Un pedido (y sus retransmisiones), junto con las respuestas provocadas por dicho pedido, componen una transacción SIP. Todas las respuestas a un pedido contienen los mismos valores en los campos Call-ID (ID llamada), CSeq, to (a) y from (de). Eso permite equiparar las respuestas a los pedidos. El pedido ACK (acuse de recibo) después de una INVITE (invitación) no forma parte de la transacción, ya que puede atravesar una serie diferente de anfitriones. C. Invitación SIP Una invitación SIP lograda consiste en dos pedidos, INVITE (invitación) seguida por ACK. El pedido INVITE solicita a la persona llamada que participe en una conferencia determinada o que establezca una conversación entre dos partes. Una vez que la persona llamada ha convenido en participar en la llamada, el llamante confirma que ha recibido esa respuesta enviando un pedido ACK. Si el llamante ya no desea participar en la llamada, envía un pedido BYE (adiós) en vez de un ACK. D. Localización de un usuario Una persona llamada puede, dentro de un cierto período, desplazarse entre varios sistemas extremos diferentes. Dichas ubicaciones pueden inscribirse dinámicamente en el servidor SIP. Un servidor de ubicación puede usar un protocolo multidistribución para determinar activamente adónde puede alcanzarse un usuario. Si un servidor apoderado retransmite un pedido SIP, dicho servidor debe añadirse al comienzo de la lista de retransmisores indicada en el encabezamiento. La opción RegistroRuta hace que las contestaciones sigan el mismo trayecto de vuelta, asegurando un funcionamiento correcto a través de cortafuegos con las características debidas y evitando bucles de pedidos. E. REGISTRO Un cliente usa el método REGISTER (registro) para registrar o inscribir la dirección indicada en el campo de encabezamiento To con un servidor SIP. Un agente usuario puede registrarse con un servidor local al comienzo, enviando un pedido REGISTER a la dirección bien conocida "sip.mcast.net" (224.0.1.75) de “todos los servidores SIP” de multidistribución, dependiendo de lo que se haya ejecutado en la red. Los agentes usuarios SIP pueden oír esa dirección y usarla para estar al tanto de la ubicación de otros usuarios locales; sin embargo, no responden al pedido. Un agente usuario PODRÍA también estar configurado con la dirección de un servidor registro al cual envía un pedido REGISTER al comenzar la transmisión.


10

2.5 SIP-T

Se ha encargado al grupo de trabajo de investigación del proyecto de protocolo de iniciación de sesiones (Session Initiation Protocol Project INvestiGation = SIPPING) del IETF documentar el uso del SIP (protocolo de iniciación de sesiones) para varias aplicaciones relativas a la telefonía y medios múltiples, y formular los requisitos para las extensiones del SIP que sean necesarias para tales aplicaciones. Una de esas extensiones es para trabajar con el control de llamadas/sesiones. El SIP-T (SIP-Telefonía), antes conocido como SIP-BCP-T (SIP Best Current Practice for Telephony interworking = mejores prácticas actuales SIP para el interfuncionamiento telefónico), es un mecanismo que usa el SIP para facilitar la interconexión de la RTPC con redes SIP. El SIP-T es más bien un convenio de interfaces sobre una serie de normas, que un protocolo separado. Los mensajes SIP-T portan otros submensajes, tales como el mensaje de parte usuario RTPC completo para la información de señalización, y mensajes SDP (protocolo de descripción de sesiones) para comunicar información de conectividad de punto extremo y características del trayecto de medios. Como en el caso del SIP, el SIP-T negocia directamente una conexión de medios entre pasarelas. La información de punto extremo es cursada en SDP, con lo que pueden describirse los puntos extremos IP y ATM. En el IETF todavía se sigue trabajando en el SIP-T. La RFC 3372 (la mejor práctica actual) proporciona una descripción de los usos de las pasarelas RTPC-SIP, emplea casos, e identifica mecanismos necesarios para el interfuncionamiento.

2.6 Q.1912.5 La SG del UIT-T 11 también ha estado trabajando sobre asuntos relacionados con SIP y proyectos de recomendación Q.1912.5 define el interfuncionamiento de señales entre los protocolos ISUYP y BSICC y SIP con su Protocolo de Descripción asociado en una Unidad de Interfuncionamiento. TRQ.BICC-ISUP-SIP especifica el juego de capacidades comunes requeridas para el interfuncionamiento entre SIP y BICC.ISUP para tres perfiles diferentes. El perfil A se definió para satisfacer la demanda representada por 3GPP en Ta 24.229 V5.1.0n (2002-06). El trabajo de este protocolo fue dirigido por operadores y distribuidores móviles. El Perfil B complementa el Perfil A y ambos tienen por objeto apoyar el tráfico que termina dentro de la red SIP. El Perfil C apoya el enlace del tráfico vía redes SIP utilizando MIME codificado encapsulado ISUP (SIP-I). En la Figura 2 se describe el principal ámbito de cada perfil definido en TRQ, BICC-ISUP-SIP. No se ha logrado un acuerdo entre el IETF y el UIT-T sobre la forma de alinear estos esfuerzos (SIP-T y Q.1912.5). La Q.1912.5 fue aprobada en la última reunión de la SG 11, el 12 de septiembre de 2003.


11

2.7 H.323

En la Recomendación H.323 del UIT-T (Sistemas de comunicación multimedios basados en paquetes) [4], se trata sobre la manera en que los teléfonos PC o los teléfonos existentes pueden conectarse mediante adaptadores a redes de paquetes e interfuncionar con redes telefónicas públicas conmutadas a través de pasarelas. La H.323 forma parte de una serie mayor de normas que facilitan las videoconferencias a través de una variedad de redes. Conocida como H.32X, dicha serie incluye la H.320 para la RDSI de banda estrecha (RDSI-BE), La H.321 para la RDSI de banda ancha (RDSI-BA) y la H.324 para la red telefónica general conmutada (RTGC). En el diagrama siguiente se ilustra la serie H.323 de protocolos.

Figura 3 – Serie de protocolos H.323

Las comunicaciones conforme a la H.323 son una combinación de señales de audio, video, datos y control. La H.323 incluye lo siguiente: • H.245 para el control, • H.225.0 para el establecimiento de conexiones, • H.332 para grandes conferencias, • H.450.1, H450.2 y H.450.3 para servicios suplementarios, • H.235 para la seguridad, y • H.246 para el interfuncionamiento con servicios conmutados. Las capacidades de audio, el transporte de medios RTP/RTCP, el establecimiento de llamadas, la inscripción, control de admisión y situación (RAS), y la señalización H.245 son componentes requeridos; las demás capacidades, incluido el video y los datos, son optativas. La norma H.323 emplea un modelo entre pares en el que la terminal de origen y/o la pasarela es una entidad par de la terminal y/o pasarela destinataria. Optativamente, requiere una función de controlador de acceso de puerta análoga a un gestor de conexiones. La H.323 tiene su mayor aplicación en los puntos extremos que poseen potencia procesadora integrada. Éstos incluyen los clientes de telefonía Internet con PC y las pasarelas VoIP integradas con centralitas privadas y sistemas esenciales con potencia inherente de procesamiento de

Interfaz usuario control del sistema

Data Video Audio

Las capas inferiores varían

UDP o TCP UDP

RTP/RTCP

Control llamadas

RAS

Control H.245

H.225

T.120

H.261 H.263

G.711 G.722 G.723 G.728 G.729

IP


12

llamadas. La H.323 es la norma más usada entre las soluciones de la primera generación de telefonía Internet. La H.323 es un conjunto de normas relativamente maduras. La primera versión fue aprobada en 1996 por el Grupo de Estudio 16 del UIT-T. La versión 2 se aprobó en enero de 1998, y la 3 en septiembre de 1999. El SG 16 aprobó la versión 4 en noviembre de 2000, y la versión 5 se aprobó en julio de 2003.

Una de las ventajas de usar un protocolo más maduro como el H.323 es que ya se han hecho muchas pruebas de interfuncionamiento, con lo que se ha obtenido el interfuncionamiento de equipos de diferentes proveedores. Desde octubre de 1996, el Consorcio Internacional de Teleconferencias por Multimedios (IMTC) lleva a cabo todos los años varios eventos de interfuncionamiento H.323. En dichos eventos para proveedores solamente se permite a los realizadores efectuar pruebas de a pares con otros proveedores, lo cual da como resultado el interfuncionamiento entre los productos de diferentes proveedores, permitiendo además corregir incongruencias de la norma. Más de 50 proveedores han participado en dichos eventos. Una de las mayores ventajas de la H.323 es su madurez y el alto grado de interfuncionamiento de los equipos de diversos proveedores. Expandiendo aún más los alcances de la H.323, el IMTC y el grupo de trabajo iNOW! han estado preparando perfiles de dicha norma para aplicaciones específicas. Las pruebas de interfuncionamiento de los perfiles de iNOW! Se están actualmente incluyendo en los eventos de interfuncionamiento de IMTC.

*****


3 Normas de acceso

3.1 Normas de acceso de abonado de línea digital (DSL)

Los servicios DSL [10] de diversos tipos (HDSL, SDSL, ADSL y VDSL) pueden proporcionarse a través de la NGN si se crean las tarjetas correspondientes en las pasarelas de acceso. La DSL de alta velocidad de datos (High Data Rate DSL: HDSL) es otra forma de T1, usando técnicas más avanzadas que la T1 original2, y extendiendo el alcance a 12.000 pies, pero requiere dos pares de cobre. La HDSL no es muy adecuada para aplicaciones de acceso residencial en banda ancha. A veces es instalada para el acceso de PBX, y dentro de la red de conexión para la agregación de líneas BRI de RDSI. La DSL de línea única (SDSL) es la versión de una sola línea de HDSL. SDSL es algo más adecuada para aplicaciones residenciales, ya que sólo requiere un par de cobre. Sin embargo, como se pueden obtener velocidades en sentido descendente con ADSL, es poco probable que se la use para el acceso residencial. La DSL asimétrica (ADSL) es la tecnología más adecuada para el acceso residencial, con velocidades de hasta 6 Mbit/s en sentido descendente, y de hasta 640 kbit/s en sentido ascendente, dependiendo de la distancia y de las opciones en materia de configuración. La ADSL funciona en una banda de frecuencia por encima de POTS, dejando al servicio POTS independiente y sin perturbaciones, aun si fallara el módem ADSL de un local. La mayoría de los sistemas ADSL todavía están concentrados en oficinas centrales, en donde se hallan instalados los multiplejadores de acceso de línea de abonado digital (ADSLAM). El uso de ADSLAM remotos permitiría una mayor penetración de los sistemas DSL en las zonas rurales. Pero la longitud de la línea no es la única consideración o impedimento para el suministro de las ADSL. Otra consideración es el número de pares usados para la ADSL en un cable determinado debido a los factores de la interferencia. Por ello, los cables de pares más grandes no cursan necesariamente un mayor número de circuitos DSL. Los límites siguientes de distancia son típicos en circunstancias favorables: 1,5 Mbit/s hasta 18.000 pies y seis Mbit/s hasta 9.000 pies. Los requisitos para sistemas ADSL están especificados en ANSI T1.413-1998 Interfaces de instalación de redes y clientes – Interfaz metálica de línea de abonado digital asimétrica (ADSL). Las Recomendaciones G.992 del UIT-T parecen ser las más apropiadas para el acceso residencial de banda ancha. Se estima que la G.992.2 será la norma elegida para el futuro inmediato, ya que es la solución más simple capas de cumplir el requisito a corto plazo de 1,5 Mbit/s. Se entiende que las recomendaciones G.922 del UIT-T son compatibles con la ANSI T1.413-1998.

2 T1 trabaja a 1,544 Mbit/s y requiere repetidores aproximadamente a cada milla.


14

3.1.1 Foro DSL

El Foro DSL ha producido una serie de informes técnicos (TR), que contienen requisitos para la ADSL y respaldo para el acceso IP por la DSL. Los requisitos de cumplimiento tanto para la ANSI T1.413 como para la G.992.2 están especificados en TR-026 y TR-033, respectivamente. Las pruebas requeridas están especificadas en TR-023, TR-029 y TR-031.

3.1.1.1 Requisitos de acceso IP

En la TR-043, Protocolos en la interfaz U para el acceso a redes de datos usando la ATM/DSL, se describen cinco protocolos superpuestos diferentes para el acceso, que se muestran en la Figura 4 abajo.

PPPoA

PPP

DSL

ATM

AAL5

LLC o VC Mux

Ethernet Ethernet

PPPoE

PPP

L2TP

PPP

IP

PPPoA IP/ Eth PPPoE IP/AAL5 L2TPoA

Figura 4 – Pilas de protocolos de acceso a redes IP

Las cinco pilas utilizan AAL5 corriendo sobre ATM y sobre DSL. El uso de ATM sobre el segmento DSL tiene la ventaja de ser compatible con las redes ATM. Es por ello que, en algunos casos, la


15

porción DSL del acceso puede entrar en una red ATM y conectarse a un punto de presencia ISP. En otros casos, el POP del ISP puede conectarse al punto terminal de la DSL, ya sea directa o indirectamente, sin la intervención de la red ATM. Hay tres pilas que utilizan el PPP (Protocolo Punto a Punto). Una vez que se establece la conexión de la capa ATM entre las instalaciones del cliente y la red que provee el servicio, las fases de configuración y liberación a nivel de transmisión y de red pueden establecerse mediante el uso del PPP. Hay dos pilas que comprimen Ethernet sobre AAL5, permitiendo que la Ethernet utilizada dentro de las instalaciones del cliente se conecte a la red de acceso. El Informe Técnico TR-044 del Foro DSL especifica procedimientos de auto-configuración. En lo que respecta a IP, en tres casos se ejecuta en PPP. En uno de los casos se ejecuta en Ethernet y en el otro se ejecuta directamente sobre AAL5. En lo que respecta a ATM, los requisitos son los especificados por el Foro ATM. El servicio ATM puede ser SVC o PVC. Para el servicio SVC en ATM, el uso de UNI 3.1 es obligatorio (Foro ATMaf-uni-0010.002, 1994), pudiendo requerirse, como se recomienda firmemente, el uso de UNI 4.0 (Foro ATM af-sig-0061.000, julio de 1996). Notas: (1) En las instalaciones del usuario, los mismos módems pueden incluir opciones que les permitan abarcar distintas pilas, y aún así producir un IP simple en la interfaz T ejecutada sobre Ethernet. Las Tarjetas de Interfaz de Red (NIC) también pueden insertarse directamente en la PC. Las soluciones específicas no solamente varían entre una red y otra, sino también en la configuración de paquetes de funciones de transmisión y protocolo, entre el módem, el encaminador y/o los componentes de la PC. (2) En el punto de concentración se utilizarán los Multiplexores de Acceso ADSL (ADSLAM o simplemente DSLAM). También en este caso, la agregación o conformación de paquetes de funciones de transmisión y protocolo puede variar, y ello puede afectar la naturaleza de las soluciones de interconexión de redes pares adoptadas por terceros.


16

3.1.1.2 ATM sobre ADSL

Las recomendaciones relativas a las capacidades de ATM se describen en el informe TR-017 del Foro DSL. Este informe considera los planos de control y gestión, así como el plano del usuario de ATM (datos). Incluye referencias al soporte PVC para ATM, así como su señalización y las funciones de operación y mantenimiento que soportan ATM corriendo sobre DSL Nota: según la información obtenida del Foro DSL, la mayor parte de las aplicaciones de DSL que utilizan ATM, usan PVC con Velocidad no Especificada (UBR). Se prevé una amplia aplicación de SVC con OoS específicos.

El alcance del informe TR-017 consiste en brindar una especificación para el arrastre de ATM sobre ADSL que resulte compatible con las Recomendaciones ANSI T1.413, y G.992.1 y G.992.2 de la UIT-T sobre ADSL PHY.

3.1.1.3 AAL5 sobre ATM

La Capa 5 de Adaptación ATM (AAL5) se define en I.363.5, Tipo 5 AAL, y contempla un mecanismo de arrastre delimitado.

3.1.1.4 Protocolo “x” sobre AAL5

La RFC 2684, (Norma Propuesta) Compresión de Protocolos Múltiples sobre AAL5, constituye la norma para la compresión de protocolos sobre AAL5. Nota: cuando el PPP se ejecuta sobre ATM, se aplica la RFC 2364 (ver sección 3.1.1.6).

3.1.1.5 PPP (protocolo de punto a punto)

El PPP permite iniciar y cancelar sesiones específicas. Ello significa que no es necesario que una sesión deba estar permanentemente “en funcionamiento”, dado que el PPP proporciona el medio necesario en materia de seguridad, autenticación, autorización y contabilidad. Ello resulta de particular utilidad en las conexiones de “discado”, y en este caso en los SVC de ATM, pero también puede ser utilizado en otras situaciones.

El PPP se especifica en la RFC 1661. (Norma). La RFC 2153 – Extensiones de proveedores PPP, contiene actualizaciones de la RFC 1661.

3.1.1.6 PPP sobre ALL5


17

Esto se encuentra especificado en la RFC 2364, (Norma propuesta) PPP sobre AAL5. Este criterio se aplica cuando la red ATM se usa como conexión punto a punto y se requieren funciones PPP.

El Foro DSL exige que se aplique por defecto la forma de compresión nula (multiplaje VC).

3.1.1.7 PPP sobre Ethernet Se especifica en la RFC 2516, (Informativo) Método para la Transmisión de PPP sobre Ethernet (PPPoE). PPPoE permite el uso de propiedades de sesión PPP (ver 3.1.1.5).

3.1.1.8 IP sobre AAL5

El IP puede comprimirse directamente sobre AAL5 sin la intervención de Ethernet o PPP, de acuerdo a lo especificado en la RFC 2684. En este caso no hay demarcación de sesiones.

3.1.1.9 IP sobre Ethernet

Se trata de una solución ya establecida, especificada en la RFC 1042.

3.1.1.10 Protocolo de Capa 2 para creación de túneles (L2TP)

Definido en la RFC 2661. Este protocolo permite la inserción de un Concentrador de Acceso L2TP entre el usuario y el servidor de la red para la ejecución del PPP.

3.1.1.11 Consideraciones relativas al IP

El protocolo PPP ofrece varias funciones IP “de ayuda”, según lo descrito en 3.1.1.5. Entre otras consideraciones se incluyen la asignación/resolución de direcciones. El Protocolo de Configuración Dinámica Central (DHCP), especificado en la RFC 2131, (Proyecto de norma) se utiliza habitualmente para la configuración de direcciones. En aquellos sistemas que no aplican DHCP, puede resultar necesario realizar la asignación y configuración en forma manual. En algunos casos, puede requerirse el Protocolo de Resolución de Direcciones definido en la RFC 826. La RFC 3396 – Codificación de opciones largas en el protocolo de configuración dinámica del anfitrión (DHCPv4), contiene actualizaciones de la RFC 826.

Nota: el PPP puede transformarse en la opción de preferencia debido a su capacidad para el manejo de sesiones.


18

3.2 Normas de acceso por cable

La iniciativa PacketCable de CableLabs tiene el objeto de formular especificaciones de interfaces interfuncionantes para transmitir servicios de multimedios en tiempo real a través de plantas de cable bidireccionales. Construidas sobre una infraestructura de módem de cable, las redes PacketCable usarán la tecnología IP para establecer una gran variedad de servicios multimedios, tales como telefonía IP, conferencias multimedios, juegos interactivos y aplicaciones generales de multimedios. CableLabs ha decidido definir las especificaciones relacionadas con la arquitectura VoIP de forma que el único tipo de acceso de línea considerado sea por cable HFC. Dichas especificaciones se están sometiendo a cierto mantenimiento, pero son relativamente estables. Se prevén ciertos cambios, ya que CableLabs está tratando de obtener la aprobación por el UIT-T en su SG-9 de las normas PacketCable. 3.3 Normas de acceso inalámbrico

Para mayor estudio

• MOBILEIP • 3GPP • 3GPP2

*****


4 Normas de gestión El protocolo simple de gestión de red (Simple Network Management Protocol = SNMP) consiste en un conjunto de especificaciones compuesto simplemente de comunicaciones por la red que abarca los principios básicos de gestión de la red en un método que no impone mayores dificultades a una red existente. La ventaja principal de usar el SNMP es que su diseño es simple, por lo que es fácil introducirlo en una red grande, ya que no toma mucho tiempo establecerlo ni causa grandes dificultades en la red. El SNMP permite una supervisión y control eficaces de dispositivos heterogéneos en redes de área tanto local como amplia. El protocolo está compuesto de 3 elementos: el MIB, el gestor y el agente. En el IETF RFC 3410 (informativo) se describe el SNMPv3.

*****


5 Normas de creación de servicios

5.1 Conjunto de capacidades de red inteligente (IN CS-4)

El conjunto de capacidades 4 IN del UT-T (IN CS-4) [5], representa una evolución del IN CS-3 (1997) y del IN CS-3 (2000). Las recomendaciones del UIT-T sobre el IN CS- 4 (serie Q.124x) fueron congeladas en diciembre de 2000 y recibieron la aprobación de consentimiento (segunda etapa de la aprobación conforme al trámite tradicional de aprobación) en mayo de 2001. Las recomendaciones específicamente relacionadas con el IN CS-4 son las siguientes: • Q.1241, Introducción al conjunto de capacidades 4 de red inteligente; • Q.1244, Plano funcional distribuido para el conjunto de capacidades 4 de red inteligente; y • Q.1248, Especificaciones de interfaces para el conjunto de capacidades 4. Las características principales identificadas para el IN CS-4 incluyen mejoras en las capacidades de IN CS-2 e IN CS-3, puntos múltiples de control, interacción de características, interfuncionamiento RDSI-IN (incluso servicios suplementarios), portabilidad de números, compatibilidad con servicios de empresa explotadora (p. ej., llamada prepaga, llamada gratuita), apoyo para movilidad (p. ej., entorno propio virtual), interfuncionamiento con redes privadas, y compatibilidad con redes IP. En particular, la compatibilidad de IN CS-4 con redes IP incluye muchos aspectos de interfuncionamiento de servicios/aplicaciones de red IP con servicios/características de red inteligente. Esto incluye un apoyo total del acceso a la IN desde un apoderado SIP para ejecutar servicios que no requieran un manejo explícito de la configuración de la llamada, apoyo total para que la IN interfuncione con servidores de llamadas, en base a la arquitectura H.248 para todos los tipos de servicios, y un apoyo mínimo para el acceso de la IN desde los guardianes de puerta H.323/servidor apoderado SIP para ejecutar servicios que no requieran un manejo explícito de la configuración de la llamada.

En el proyecto de recomendación Q.1244 se describe en detalle la arquitectura funcional distribuida para IN CS-4. El modelo funcional de IN CS-4 es una extensión del modelo IN CS-2, que trabaja con los servicios de referencia mencionados más arriba. Una gran parte de la Q.1244 trata sobre hipótesis de interfuncionamiento IN/IP para una variedad de sistemas, incluidos los SIP, los H.323, los sistemas basados en PINT, y los basados en SPIRITS. Los servidores lógicos de servicio distribuido también son compatibles mediante plataformas API normalizadas (p. ej., CORBA, JAIN). Para cada conjunto de hipótesis de interfuncionamiento, se definen entidades funcionales, se crean modelos funcionales, se enumeran los requisitos, y se trata sobre las cuestiones que afectan a la ejecución. Más abajo se muestra, como ejemplo de dichas hipótesis, la arquitectura funcional definida para que el interfuncionamiento IN/IP pueda trabajar con sistemas SIP (protocolo de iniciación de sesiones):


21

IF4

IF5

Service/ApplicationLayer

Call/BearerLayer

Legend: SignallingService ControlBearer

SCF

Intelligent Network IP Network

CCF

SSF

SDF

IF12

IF7

IF10

SRF

IF13

SignallingTransportGateway

Media Gateway

IntelligentSIP Proxy and

Bearer Controller

CCF

MG

SIPTE UA

RTP/RTCP

IF4: INAP IF10: ISUP User Plane

IF5: ISUP/BICC/SIP IF13: H.ISUP Use plane

IF7: Extended INAP IF12: H.248/H.225 (ffs)

SIP

SM

SSF

Figura 5: Configuración de control de llamadas SIP que emplea un apoderado SIP inteligente

y una función de control de portador Intelligent Network: Red inteligente IP Network: Red IP Service/Application Layer: Capa de servicio/aplicación Call/Bearer Layer: Capa de llamada/portador Signalling Transport Gateway: Pasarela de transporte de señalización Intelligent SIP Proxy and Bearer Controller: Controlador de apoderado SIP inteligente y portador Signalling: Señalización Service Control: Control de servicio Media Gateway: Pasarela de medios Bearer: Portador

Cada interfaz entre la entidad funcional de una red IN y la de una red basada en el IP se define con propiedades específicas. Una vez definidas esas relaciones genéricas, se pueden definir los servicios específicos que interfuncionan entre redes. Para ilustrar el interfuncionamiento de servicios, es instructivo ver el modelo PINT y SPIRITS. Se introducen entidades funcionales para apoyar el interfuncionamiento RTPC/IN (PSTN/IN Interworking = PINT) y para un servicio en la RTPC/IN que solicita servicio Internet (Service in the PSTN/IN Requesting InTernet Service = SPIRITS). El grupo de trabajo PINT del IETF ha formulado un conjunto de extensiones de protocolo basadas en los protocolos de iniciación de sesiones y de descripción de sesiones (SIP y SDP). Un servidor PINT acepta pedidos PINT de clientes PINT. Procesa los pedidos y devuelve respuestas a los clientes. Además, dicha función transfiere datos entre redes IP y la IN, y asocia las entidades de redes IP con las entidades conexas de la función de pasarela. Dicha


22

función está situada en el borde del dominio de la red IP, en donde la asociación de aplicación con el cliente/servidor PINT es el tema de la normalización del IETF, y la asociación de aplicación con SCF en el dominio IN es el tema de la normalización del UIT-T. El grupo de trabajo SPIRITS del IETF define los servicios que se originan en la RTPC que requieren interacciones de ésta con una red IP. Este trabajo está relacionado estrechamente con PINT. Para trabajar con esos servicios (p. ej., llamada en espera de Internet, transmisión de ID del llamante en la Internet, y reenvío de llamadas en la Internet) se ha creado el siguiente modelo funcional:

IF1

IF2IF4

IF3


Call/BearerLayer

Legend: ManagementSignallingBearer

SCF


CCF

SSF

SDF

SRF

PINTClient

PINTServer

PINTGateway

SPIRITSServer

SPIRITSClient

IF15

IF16

SPIRITSProxy

IF17

Figura 6: Ejemplo de configuración PINT/SPIRITS

El respaldo a la creación de aplicaciones por terceros es un componente esencial de las redes de próxima generación, y un aspecto importante del IN CS-4. Para trabajar con servidores de lógica distribuida es necesaria la creación de la función de pasarela de aplicación de servicio. Eso permite el interfuncionamiento: (1) entre la capa de control de servicios en aplicaciones inteligentes y de lógica de servicio

distribuido (esas son funciones de interfaz de programación de aplicaciones basadas en API), y

(2) entre la función del gestor de llamadas y la lógica de servicio distribuido.

En el caso del IN CS-4, a nivel de aplicación, los tipos de funcionalidad API podrán incluir las plataformas CORBA, JAVA, JAIN y otras plataformas tipo API. Además, esta funcionalidad podrá proporcionar la correspondencia de protocolos/mediación de servicios. Dada la interfaz entre “API para el acceso a aplicaciones de proveedores de servicios” y el control de llamadas IP, la siguiente arquitectura de la red ilustra la distribución de la inteligencia de la red. La


23

función de pasarela (Gateway Function = GF) proporciona las funciones de cortafuegos/seguridad necesarias para la plataforma lógica de servicio distribuido.


Call/BearerLayer

Legend: Management

Signalling

Bearer

SA GF DistributedService Logic

IF8

IF9

SCF


CCF

SSF CCF

GF

SA GF

IF9

Figure 7: Ejecución SA-GF para trabajar con lógica de servicio distribuido

5.2 Normas de entorno de programabilidad abierta

El entorno de programabilidad abierta (open programmability environment = OPE) proporciona interfaces de programación de aplicaciones (API) y los instrumentos de integración necesarios para crear y entregar nuevos servicios de aplicaciones. El OPE debe basarse en normas abiertas, para que pueda extenderse y adaptarse fácilmente según sea necesario.

5.2.1 RMI

El método de invocación remota (Remote Method Invocation = RMI) es un protocolo Java que permite métodos con un objeto que exista en otro espacio de dirección a invocarse remotamente. El RMI se usa entre el MGC y los servidores de aplicaciones.

5.2.2 XML

El lenguaje de etiquetado extendido es un subconjunto del lenguaje de etiquetado generalizado normal (Standard Generalized Markup Language


24

= SGML) definido en ISO 8879. El XML se usa entre componentes del OPE, así como en servidores de usuario/programador y el OPE.

5.2.3 API

Las API son interfaces abiertas para la ejecución de sistemas distribuidos. Las siguientes son dos API populares:

• JAIN (API Java para redes integradas) – es un conjunto de API de red integrada para la plataforma Java que proporciona una estructura para construir e integrar que abarca paquetes (p. ej., IP o ATM), redes inalámbricas y RTPC. Los adaptadores Java permiten que el OPE interfuncione con una gran variedad de tecnologías de comunicaciones, tales como sistemas de correo electrónico, sistemas de correo vocal, servidores de fax, servidores de video, y servidores de Red.

• Parlay – el grupo Parlay se formó en abril de 1998 con el mandato de producir una API para permitir el acceso y control de una gran variedad de capacidades de red, desde una estructura común que no tuviera necesariamente que formar parte de la red.

*****


6 Normas de seguridad Para proteger la información en una red [11] es necesario tener en cuenta tres componentes críticos. La autenticación valida la identidad de la parte o partes que participan en el intercambio de información. La confidencialidad protege contra quienes estén escuchando subrepticiamente o vigilando tal intercambio. La integridad garantiza que la información no haya sido alterada durante la transmisión. La naturaleza del IP hace que sea difícil verificar de dónde procede la información, y fácil para un “atacante” aprovecharse de ese punto débil simulando la dirección IP. La simulación ocurre cuando un atacante cambia la dirección de origen en el paquete IP; es muy difícil determinar de dónde viene el ataque, ya que el atacante sigue cambiando la dirección de origen. La importancia de la seguridad es reconocida tanto por el IETF como por el UIT-T. Es necesario entender todas las cuestiones e implicaciones. Para tratar sobre los asuntos de seguridad, el IETF creó el área de seguridad, subdividiéndola además en grupos de trabajo. El SG 17 (Redes de datos y programas informáticos de telecomunicaciones) del UIT-T tiene un grupo de estudio de la seguridad que enfoca tales cuestiones a todos los niveles. Cada organización cumple una función un tanto diferente; la función primaria del Grupo Consultivo del Área de Seguridad del IETF es ayudar a los grupos de trabajo del IETF sobre la manera de proveer a la seguridad en los protocolos que preparan. El UIT-T está atento a la necesidad de un enfoque mundial en cuanto a la diseminación de información relativa a la seguridad de infraestructuras críticas de redes, y a las maneras de estimular la cooperación internacional o regional con respecto a tales infraestructuras.

6.1 Seguridad IP (IPSec)

La IPSec se refiere a una sucesión de protocolos de seguridad del IETF (RFC 2401) (Norma propuesta) que protegen a las comunicaciones de la Internet por medio del cifrado, la autenticación, confidencialidad, integridad de los datos, la protección antirrepetición, y la protección contra el análisis del flujo de tráfico. El IPSec trabaja con métodos de cifrado populares en la capa de la red—tales como Diffie -Hellman, DES, 3DES, MD5, y SHA1—y puede adaptarse a nuevos algoritmos y normas que aparezcan. La sucesión de protocolos proporciona los cinco componentes descritos más abajo.

6.1.1 Asociaciones de seguridad (SAs)

La función del sistema SAs es proporcionar un método para que dos partes intercambien información protegida, debiendo ambas partes ponerse de acuerdo sobre los parámetros de seguridad. Las "SAs" se definen para el tráfico en una dirección solamente, por lo que en el caso del tráfico bidireccional es necesario definir dos "SAs". En el IPSec SA se especifican los siguientes parámetros:

• Modo de autenticación AH (algoritmo y claves) • Algoritmo de cifrado ESP • Cómo intercambiar claves • Con cuánta frecuencia se cambian las claves • Duración de SA • Dirección de origen SA

6.1.2 Encabezamiento de autenticación (AH)


26

El AH, definido en el IEFT RFC 2402, permite que las partes que se comunican mediante el IP verifiquen que los datos no se hayan modificado durante la transmisión, y que proceden de la fuente original de la información. El AH proporciona una integridad de los datos sin conexión, la autenticación de los datos, y brinda protección contra ataques con repetición. El AH añade un bloque de código al paquete de datos que es el resultado de una función de “troceo” aplicada a todo el paquete. Hay 2 campos importantes en el encabezamiento AH:

• El índice de parámetro de seguridad (SPI) especifica al dispositivo receptor qué grupo de protocolos de seguridad está usando el que transmite.

• El número de secuencia se usa para impedir ataques de repetición, al impedir el reprocesamiento múltiple de un paquete. El campo autenticador en el AH tiene sólo 96 bits de longitud, el “emisor” ejecuta las funciones de “troceo”, trunca el número resultante para que quepa en el campo autenticador AH, y lo envía. En el otro extremo, el receptor ejecuta el mismo algoritmo de “troceo” (como se especifica en el SPI), y trunca en consecuencia el número resultante. El receptor compara entonces el número calculado con el número del AH en el campo autenticador. Si los números corresponden al número del paquete, se acepta como no modificado. Los dos algoritmos de “troceo” AH más usados son el digesto de mensaje 5 (Message Digest 5: MD5), definido por el IETF RFC 2403, (Norma propuesta) que produce un autenticador de 128 bits, y el algoritmo de troceo seguro (Secure Hashing Algorithm: SHA-1), definido por la RFC 2404, que produce un autenticador de 160 bits. El AH que no mantiene confidenciales los datos es para ocasiones cuando solamente se necesita autenticación.

6.1.3 Carga útil de protección de encapsulado

(Encapsulation Security Payload : ESP)

La ESP, definida en el IETF RFC 2406, cifra la información para evitar que sea observada por una entidad que no sea digna de confianza. La ESP también puede usarse para la autenticación. El campo de autenticación ESP contiene la suma de prueba criptográfica que se computa sobre la parte restante de la ESP (menos el campo de autenticación ESP mismo). La autenticación AH difiere de la versión ESP en que esta última no protege el encabezamiento IP que precede al encabezamiento ESP. La autenticación ESP puede usarse en vez de la AH para reducir el procesamiento de paquetes, y efectúa una operación de “transformación” en vez de dos pasos. También impide los ataques de repetición siguiendo el número de la secuencia de forma muy parecida a la del AH, pero esto comprometería la validez del encabezamiento. Hay dos tipos de modo túnel en ambas maneras de cifrado de la información del encabezamiento IP original; la desventaja es que no funciona por NAT (traducción de dirección de red). En el modo transporte, el encabezamiento IP original no esta cifrado y puede funcionar por NAT.

Los esquemas de cifrado ESP más usados son los siguientes:


27

• La norma de cifrado de datos (Data-Encryption Standard: DES) usa un cifrado de 56 bits - IETF RFC 2405 (Norma propuesta)

• La triple DES (3DES) usa un cifrado de 168 bits pasando los datos a través del algoritmo DES tres veces - IETF RFC 2405

6.1.4 Gestión de claves

Los dos métodos de uso más común para el intercambio de claves son, el primero, la codificación manual, apropiada para un número pequeño de sitios, y el segundo es mediante un protocolo definido por el IETF RFC 2409 (Norma propuesta), “Intercambio de claves Internet” (Internet Key Exchange: IKE). El “IKE” es una combinación de “ISAKMP” y de “Oakley”; el Internet Security Association and Key Management Protocol (ISAKMP), definido por el IETF RFC 2408 (Norma propuesta), proporciona el marco para la autenticación y el intercambio de claves, y en el protocolo Oakley definido por el IETF RFC 2412 (informativo) se describen varios modos de intercambio de claves.

6.1.5 Intercambio manual de claves

El intercambio manual es la forma más fácil de gestión de claves para un número pequeño de sitios. Ambos extremos del túnel IPSec deben configurarse manualmente con las claves correspondientes. Pero la codificación manual tiene muchas desventajas:

• Es necesaria la intervención manual para actualizar o cambiar las claves.

• Como el cambio manual de claves es por lo general poco frecuente, el atacante tiene más tiempo para descifrarlas y descodificar datos.

• Hay una probabilidad de error en la configuración, dado que la misma clave debe configurarse en los dos extremos distintos del túnel IPSec.

• Si la persona con acceso a las claves se va, o deja de merecer confianza, es necesario efectuar cambios extensos de configuración.

• Las claves de la configuración deben protegerse de alguna manera contra ataques externos.


28

6.2 Intercambio de claves Internet (IKE)

El “IKE” es definido en el IETF RFC 2409 (norma propuesta), ya ha sido concebido para proporcionar cuatro capacidades básicas.

• Un método para que las partes se pongan de acuerdo sobre los protocolos, algoritmos y claves que se usarán.

• Seguridades desde el principio en cuanto al intercambio de la identidad de las partes. • Gestión de las claves • Seguridad de que el intercambio de claves se haga de forma protegida.

El “IKE” funciona en dos fases; en la fase uno los pares establecen canales seguros para efectuar operaciones de claves, y negociar “SAs” (asociaciones de seguridad) en la fase dos. Hay tres modos de intercambio de información sobre claves. El “modo principal” establece un canal seguro con protección de identidad en la fase uno; el “modo dinámico” establece un canal seguro sin protección de identidad en la fase uno; y el “modo rápido” negocia simplemente “SAs” de aplicación general en la fase dos.

6.2.1 Modo principal

El “modo principal” ofrece un método para establecer la primera fase de “IKE SA”, que se usa para negociar comunicaciones futuras; en el primer intercambio las dos partes llegan a un acuerdo sobre algoritmos y troceos básicos, y en el segundo intercambian claves públicas para un intercambio “Diffie-Hellman” y se pasan mutuamente un “nonce”. El nonce es un número aleatorio empleado por cualquiera de las dos partes para efectos de la verificación, o para añadir aleatoriedad a un intercambio criptográfico de claves. En los intercambios “IKE”, una de las partes envía un “nonce” a la otra, la cual lo debe firmar digitalmente y devolverlo para confirmar su identidad.

6.2.2 Modo dinámico

En el “modo dinámico”, la parte proponente genera un par “Diffie -Hellman” al comienzo del intercambio, proponiendo una “SA” y pasando el valor público “Diffie-Hellman”, enviando luego un “nonce” para que lo firme la otra parte, y transmitiendo un paquete ID que el respondedor puede usar para confirmar la identidad con un tercero. El respondedor entonces devuelve toda la información necesaria para completar el intercambio, y el resultado final es que se logra lo mismo que con el modo principal, pero sin protección de identidad para las partes comunicantes.

6.2.3 Modo rápido

El “modo rápido” se emplea una vez que las dos partes en comunicación han establecido una “IKE SA” usando un “modo dinámico” o “principal”. El objeto básico del “modo rápido” es negociar servicios “IPSec” de aplicación general, y la generación de nuevas claves. El “modo rápido” trabaja dentro de un túnel protegido, y es menos complejo porque todos los paquetes están cifrados comenzando con una carga útil de troceo compuesta por una función


29

pseudoaleatoria (Pseudo Random Function: PRF) y la clave de autenticación derivada para la “IKE SA”. La carga útil de troceo se usa para autenticar el resto del paquete. La renovación de claves puede efectuarse intercambiando “nonces” a través del canal protegido, usándolos para trocear las nuevas claves, o para pedir un nuevo intercambio “Diffie -Hellman” a través del canal protegido existente (SA) y cambiar la clave por el canal protegido recién creado.

6.3 Para mayor estudio • Kerberos (RFC1510) • PKINIT (PKT-SP-SEC-I01-991201) • SNMPv3 Security (RFC3414/15) • SSL (draft-freir-ssl-version3-02) • RC4 (PKT-SP-SEC-I01-991201) • MMH MAC (PKT-SP-SEC-I01-991201) • DNS Security Extensions (RFC 2535) • BPI+ (DOCSIS)

*****


7 Normas de desempeño y calidad del servicio (QoS) Una de las tareas más difíciles que enfrenta una red de próxima generación (NGN) es suministrar un sistema o técnica para las transmisiones de voz por IP (Voice over IP = VoIP) que ofrezca un desempeño y calidad del servicio (QoS) superiores a los ofrecidos por las redes IP actuales de mejor calidad. En el caso del VoIP, el objetivo es proporcionar una calidad del servicio equivalente a la de la red telefónica pública conmutada (RTPC) actual. Hay dos versiones de NGN: una se centra en la ATM mientras que la otra se centra en el IP. Aunque ambas imponen exigencias a una red núcleo, el tema principal de esta contribución es el sistema IP ofrecido para las NGN. Es posible (y probable) que por último ambas versiones lleguen a convergir en el futuro, especialmente con respecto a la red núcleo. La arquitectura de las NGN basada en el IP puede subdividirse en varios dominios. Esa segmentación facilita la conceptualización de la QoS, la planificación estratégica y la partición funcional sobre las que típicamente se basan las redes. Los dominios siguientes forman parte de una arquitectura IP de la NGN: • Centralización del control:

contiene el controlador de pasarela de medios junto con ciertos nodos de servicio centralizados (por razones de mantenimiento) y elementos de operaciones y mantenimiento (OAM);

• Pasarela de medios / puntos extremos / acceso: contiene las diversas pasarelas usadas para el acceso a la red IP;

• Agregación IP: contiene los dispositivos usados para combinar flujos e interfaces físicas en un número manejable de interfaces o nodos junto con cualquier partición o límite (cortafuegos, apoyo de LAN de oficina central);

• Red núcleo IP / interconexión: contiene los dispositivos usados para cursar tráfico IP a través de la red, junto con la interconexión de los dominios / redes.

Una solución NGN IP ofrece básicamente dos posibilidades, una que contiene abonados "del lado de la línea" y otra que contiene clientes "de enlace solamente". Desde el punto de vista de la red IP de núcleo, la diferencia entre ambas es relativamente pequeña. Pero desde el punto de vista de la QoS de extremo a extremo, es importante tener en cuenta los requerimientos diferentes que imponen las dos a la red y sus componentes. Cabe señalar que esta sección se refiere solamente a los dominios de empresas que ofrecen el mismo servicio. Acá no se hace referencia al interfuncionamiento de dominios múltiples (abarcando a diferentes empresas explotadoras) a un nivel IP, por lo que no se consideran los nodos límite. Es probable que esos nodos tengan ciertos requisitos especiales en cuanto a la QoS, y la cuestión deberá postergarse para su estudio en el futuro. Además, esta sección tiene el objeto de describir opciones en materia de la QoS para NGN centradas en el IP. Por cierto, hay otras opciones para lograr la calidad del servicio en las redes de datos, particularmente basadas en el ATM, pero la consideración de esas otras soluciones se deja para su estudio futuro.


31

7.1 QoS en redes basadas en el IP

7.1.1 Obtención de una calidad de servicio RTPC tradicional en las redes IP

Primero, debe notarse que la RTPC es una red que cursa eficazmente una variedad de servicios, además de un simple servicio de "voz". En realidad, la RTPC tradicional proporciona no sólo el servicio básico que todos usan para la comunicación vocal elemental con otras personas, sino también servicios auxiliares "en banda" que típicamente se emplean para comunicaciones no humanas (p. ej., fax, módems de acceso por discado, tonos digitales, etc.). La mayoría de dichos servicios "en banda" dependen en sumo grado de las características de voz básicas de la RTPC con multiplaje por distribución en el tiempo para obtener una buena calidad del servicio. Típicamente, esas características están relacionadas con el ancho de banda, la frecuencia, la propagación, técnicas de modulación y armónicos, entre otras cosas. Cuando suministran transmisiones de voz a través de una red de transmisión IP, las empresas explotadoras pueden usar códecs de alta velocidad (p. ej., UIT-T G.711), siempre que la demora y las fluctuaciones sean limitadas en la red IP conectora, para que la calidad suministrada a los usuarios sea equivalente a la de la RTPC. Sin embargo, como las posibilidades de lograr condiciones comparables de demora y fluctuación en la red IP general (o sea, en la Internet) son muy pocas, se han propuesto diversas normas y otros mecanismos para poder trabajar con esos tipos de servicios cuando un número de servicios de voz y datos se cursan juntos. Por lo general, dichos mecanismos suponen el uso de determinados códecs de voz de velocidad más baja junto con técnicas para convertir bits/bytes en trenes de información ASCII equivalentes, y enviar la información convertida como flujos de datos IP "fuera de banda" o paralelos. Por ejemplo, las transmisiones de facsímil se convierten en las pasarelas y se envían como trenes de datos ASCII a través de una red IP a la pasarela del extremo lejano, que convierte la información nuevamente en tonos de módem de fax para su recepción final por el módem fax terminal extremo. Se han propuesto otras técnicas similares para diversos tonos (p. ej., DTMF, MF) que normalmente atraviesan la RTPC TDM usando la "banda de voz" del servicio vocal. Es probable que una NGN IP tendrá que ser compatible con técnicas tanto "en banda" como "fuera de banda".

7.1.2 Características y expectativas del servicio VoIP

En general, el servicio VoIP puede dividirse en tres componentes de flujos de datos: • los paquetes de portador/voz (normalmente cursados como paquetes RTP), • señalización/control (éstos pueden incluir H.323, H.248, SIP, SIP-T, BICC), y


32

• operaciones y mantenimiento (OAM) (éstos incluyen, entre otros, SNMP, TFTP, COPS). Nótese que los flujos de paquetes RTCP no se usan actualmente, pero deberán considerarse en los trabajos evolucionarios futuros. Cuando se trata con la QoS para el servicio de voz, el interés principal tiende a ser en el tren de portadores, ya que esto es lo que generalmente afectará a un abonado (y, más concretamente, su impresión de la calidad de la voz). Los demás componentes son igualmente importantes en lo que toca a la QoS general del servicio. Sin una QoS adecuada para la señalización/control, las llamadas podrán no establecerse o tomar mucho tiempo para hacerlo. De la misma manera, desde un punto de vista operacional, sin QoS para OAM, el aprovisionamiento podrá fallar o ser muy demorado, las fallas de la red podrán pasar inadvertidas, el mantenimiento preventivo podrá no ser posible o demorarse considerablemente, etc. Todo esto se reflejaría por último en la impresión que el abonado tenga del servicio ofrecido. Además, no todos estos componentes del servicio requieren la misma QoS, por lo que es probable que cada uno tenga diferentes necesidades de servicio de datos. Esto parecería ajustarse muy bien al paradigma de "servicios diferenciados" enunciado en el marco IP Diff-Serv ((IETF RFC 2475) (Informativo). Por consiguiente, el método recomendado es entender las características esenciales de cada componente y determinar cuantitativamente los niveles de desempeño que puede suministrar la estructura IP Diff-Serv correspondiente. Sin embargo, para complicar esto un tanto, las "expectativas" del usuario final (más precisamente, las "expectativas cambiantes" de los usuarios) confunden las cosas de tal manera que las características no son necesariamente estáticas o fácilmente cuantificables para todos los usuarios y proveedores de servicios. A diferencia del servicio vocal RTPC, ubicuo y maduro, que en general ofrece una calidad del servicio constante (y un tanto singular), la red IP y el servicio VoIP resultante posee afortunadamente la capacidad de poder manejarse más flexiblemente. Además, las reglamentaciones del desempeño cumplen una función importante, en la medida en que expresan las "expectativas públicas últimas" o los requisitos formales de los usuarios. Algunas de las que tienen relación con la calidad del servicio vocal, incluidos los aspectos de la señalización, se enumeran más abajo. Otros objetivos pueden deducirse o han sido recomendados por varios organismos normalizadores/reguladores. - Demora del tono para marcar: no más del 1,5% de las llamadas (durante la hora cargada) recibirán una demora del tono para marcar de más de 3 segundos - Atenuación de adaptación para el eco (línea): mas de 20 dB - Pérdida: 3,0 dB en la línea del abonado (nivel de transmisión de 0 dB) - Ruido: menos de 20 dBrnC (nivel de enlace) y menos de 23 dBrnC (95% de las líneas)


33

- Demora: - para comunicaciones nacionales – menos de 150 ms en una dirección, - para comunicaciones internacionales con conexiones por satélite – menos de 400 ms en una dirección, - para cables submarinos – menos de 170 ms en una dirección, - Demora después de marcar: nominalmente, - para llamadas locales – menos de 3 s, - para llamadas interurbanas – menos de 5 s, - para llamadas internacionales – menos de 8 s - Pérdida de bloqueo/concordancia: red - 2% durante hora cargada media - Disponibilidad del servicio: 99,999% Nota: Lo que antecede contiene descripciones esquemáticas de algunos objetivos, y se incluyen aquí simplemente como ilustración. Los detalles relativos a situaciones concretas deben obtenerse de las diversas normas aplicables. Viendo los objetivos anteriores, puede verse que no siempre se identifican los atributos de QoS para cada uno de los "componentes". No obstante, pueden deducirse o implicarse. Por ejemplo, la demora después de marcar (el tiempo desde el recibo del último dígito marcado hasta que la parte del extremo lejano es notificada) provee un límite de tiempo por el cual los mensajes de control son procesados y propagados a través de una red para establecer una conexión entre partes. De esa forma, hay un límite implicado a la QoS de demora que los mensajes de control podrán encontrar al atravesar la red IP. Nótese que éste no es un valor absoluto totalmente reflejado en la QoS de la red de transmisión IP, porque también incluye los tiempos de procesamiento en los diversos puntos extremos y nodos a lo largo de la ruta. Existen interpretaciones similares para aquellos objetivos que afectan a las características del tráfico portador. El modelo E (Recomendación G-107 del UIT-T) se usa para caracterizar las "interpretaciones" de paquetes portadores de voz. En general, las características de voz (lo que uno escucha en el teléfono) son afectadas por diversos factores cuando hay una red de paquetes en el "trayecto" del habla. La figura siguiente ilustra dichos deterioros en el caso de un ejemplo de red de acceso DSL.

DSL CPE EO

Red trans. núcleo de paquetes

Encam. núcleo

Encam. núcleo

- Carga datos voz - Demora en cola - Fluctuación origen

- Paquete de datos de voz - Demora proces. y conmut. - Códec

- Carga datos voz - Demora propag. - Demora en cola - Fluctuación red - Pérdida paquete

Memoria desfluct.

Transcodificación

Velocidad enlace acceso

MG MG TO

RTPC RTPC


34

Figura 8: Deterioros de la voz en una red IP

Por la figura anterior, se aprecia que puede ser muy difícil determinar la calidad prevista de la voz de una llamada VoIP mediante la inspección de valores concretos. Además, también pueden influir otros factores fuera del dominio IP. Por ello, el modelo E cumple la función analítica de poder combinar todo lo anterior y producir los resultados esperados de calidad teórica del habla. Cuando se compara con los ejemplos existentes de RTPC, se puede determinar un nivel relativo de calidad.

7.1.3 Estrategia para la QoS en redes IP

La estrategia básica para resolver la cuestión de la QoS en las redes IP de la próxima generación debe ser simple y uniforme, pero capaz de satisfacer las necesidades de una gran variedad de servicios y modelos empresariales. Sin embargo, incluso el servicio de voz, que es relativamente simple, es complejo y contiene o requiere varios componentes auxiliares de datos para tener buen éxito. Además de los datos portadores (basados en paquetes de protocolo de tiempo real [RTP]), hay paquetes de señalización/control (p. ej., H.248, SIP-T) y flujos/paquetes OAM. Si todos éstos se tratan y marcan de la misma manera, es probable que pudieran "conspirar" entre ellos para causar un conflicto tal que la calidad del servicio VoIP no sería aceptable. De la misma manera, si no se los fusiona para formar un servicio funcional administrado, es probable un resultado similar (o sea, una calidad de servicio inaceptable). Además de los "conflictos de servicio internos" mencionados, existe la necesidad de que el servic io VoIP coexista con otros servicios que trabajan con la misma red IP administrada unificada. El IETF ha propuesto que el QoS cuente con el respaldo de un sistema de ingeniería de tráfico IP (IP Traffic Engineering = IP TE). Dicho sistema permite que todos los servicios y la red administrada funcionen y existan juntos. El grupo de trabajo de ingeniería del tráfico (tewg) de la Internet del IETF ha producido pautas generales para un sistema IP TE.

7.1.4 Tecnologías para la QoS de redes IP

7.1.4.1 Servicios integrados (Integrated Services = Int-Serv)

Proporcionan un método de señalización y estados flexibles de la red para la reserva de recursos de ésta. Ofrece la posibilidad de proporcionar garantías rígidas de QoS mediante la reserva de recursos. En los Int-Serv, las aplicaciones indican explícitamente sus necesidades de QoS para un flujo que use el protocolo de señalización de reserva de recursos (RSVP). Cada encaminador a lo largo de la ruta examina dicho pedido y proporciona un trayecto fijado para la transacción (flujo); los encaminadores a lo largo de este trayecto verifican la solicitud de QoS RSVP en comparación con la normativa aplicable y los recursos disponibles de la red. Si el


35

pedido está dentro de la normativa y hay recursos, se concede el pedido; entonces los recursos son reservados por los nodos que intervienen durante el lapso de la transacción. Aunque maduros en cuanto a su especificación, los Int-Serv nunca se han introducido en gran escala a causa de las que se consideran sus desventajas relativas a varios aspectos: ajustabilidad, tara, fijación de ruta, y orientación de anfitriones.

7.1.4.2 Servicios diferenciados (Differentiated Services = Diff-Serv)

El método de los Diff-Serv (IETF RFC 2474 (Norma propuesta)) y RFC 2475 (Informativo) es más pragmático y proporciona sólo garantías flexibles marcando los paquetes o flujos para una prioridad relativa de reenvío. Los problemas de ajustabilidad a escala se resuelven evitando cualquier forma de reserva de recursos en la red. Además, el método Diff-Serv se basa en la premisa de que la red IP básica es encaminada, ya que esta recomendación se refiere principalmente a la capa 3 del modelo de protocolo de comunicaciones. Para complementar dicha capacidad, la estrategia de QoS general puede reforzarse con capacidades de la capa 2 (p. ej., IEEE 802.1p, DOCSIS 1.0 / 1.1) que pueden aplicarse a dominios de subred dentro de la red NGN IP mayor.

En el método Diff-Serv, la funcionalidad complicada es transferida al borde de la red, y la funcionalidad simple en el núcleo trabaja con agregados de tráfico. Los dispositivos del borde clasifican y marcan paquetes en el campo DS del encabezamiento de paquete (basándose en información provista por la gestión de normativas), y los dispositivos del núcleo reenvían paquetes con cierto comportamiento por salto (Per Hop Behavior = PHB) de acuerdo con las marcas del paquete. Las combinaciones debidamente elegidas de PHB y reglas normativas dan como resultado un servicio IP con mejoras apreciables de la calidad según puede notar el usuario final—logrando un desempeño mucho mejor que el obtenido en las mejores redes existentes. Los Diff-Serv incluyen tres componentes esenciales: gestión normativa/red, funcionalidad de dispositivos del borde y funcionalidad de dispositivos del núcleo. El IETF ha estado trabajando con un conjunto mínimo de PHB, RFC 3246 (Norma propuesta) y RFC 3247 (Informativo) y mecanismos de límite relacionados con los dispositivos del borde y del núcleo. Los aspectos normativos y de gestión de la red se dejan a los proveedores de redes. El servidor de normativa es un punto centralizado para la gestión de normativas de Diff-Serv, que determinan el perfil y clase del tráfico en que se agruparán los flujos de tráfico. Las normativas Diff-Serv


36

serán distribuidas por el servidor de normativas a dispositivos del borde y encaminadores del margen, de modo que dichos dispositivos puedan supervisar los flujos y "rotular" los paquetes con un "punto de código" que represente el comportamiento por salto a aplicarse en el nodo vigente y en cada nodo corriente abajo.

7.1.4.3 Normativa de calidad del servicio (QoS)

Las normativas de QoS definen los niveles de servicio de diferentes grupos de usuarios para los efectos del control de costos, la facturación de servicios a los clientes del proveedor, y el control del tráfico de la red. Por ejemplo, los usuarios pueden adquirir normativas de los proveedores de servicios que garanticen su prioridad y niveles de servicio según la hora del día, y controlen los costos del servicio. La normativa de QoS puede también incluir normas de admisión y del servicio/gestión de la red, ya que ambos factores afectan a la calidad del servicio. Dentro de estos alcances, un servidor de normativas QoS (QoS Policy Server = QPS) podría administrar la calidad de las normativas del servicio y mantener mapas lógicos para relacionar normas específicas con encaminadores, pasarelas, controladores y agentes de gestión de servicios. Las normativas de QoS, ejecutadas como filtros de paquetes de datos, se descargan a los encaminadores y las pasarelas aplicables. Al comunicarse con los encaminadores, se estima que el servidor de normativas QoS emplea el protocolo de normativa abierta común (Common Open Policy Service = COPS) normal del IETF (IETF RFC 2748) (Norma propuesta). El servidor de normativas QoS probablemente use una interfaz de línea de mandos ASCII (CLI) para comunicar la información normativa a otros encaminadores. Con otras normativas (admisión, gestión), por lo general se recomienda el COPS, pero son posibles otras interfaces.

7.1.4.4 Conmutación por etiquetas multiprotocolo (Multi -Protocol Label Switching = MPLS)

La MPLS (IETF RFC 3031) (Norma propuesta) es una manera simple de reenviar información a través de redes instalando y luego examinando marcas ID cortas de longitud fija, denominadas etiquetas, en los paquetes. Usando etiquetas para reenviar información, la MPLS usualmente no usa un encabezamiento IP de paquete, a menos que esté entrando en la MPLS o saliendo. Para el tren IP que pasa a través de una red MPLS, toda la red parece un solo salto—la MPLS en efecto establece un túnel a través de la red, en donde la ruta es preplaneada y atravesada mecánicamente.


37

La MPLS puede usarse para crear trayectos por los cuales parámetros de la QoS tales como el retardo, la pérdida y la fluctuación han sido 'puestos a punto' y el trayecto de la MPLS puede garantizar dichos parámetros QoS exactamente como en un circuito virtual ATM proyectado para el tráfico. La MPLS puede usarse en conjunto con los Diff-Serv para proporcionar trayecto proyectados para el tráfico para servicios críticos. Los Diff-Serv siguen proporcionando la arquitectura QoS general de extremo a extremo. La ventaja de su uso consiste en su simplicidad. En una red de funcionamiento normal, los Diff-Serv proporcionan un comportamiento QoS uniforme en toda la red, pero no ofrecen garantías, o sea que proporcionan una buena QoS la mayor parte del tiempo, pero sin ninguna garantía. En cambio, la MPLS puede usarse para proyectar ciertos trayectos de modo de obtener garantías explícitas, similares a las que pueden conseguirse en redes ATM o con cualquier tipo de tecnología de redes "dirigida a la conexión". En el UIT-T, el IETF y en otros foros se está trabajando para formular y refinar normas para el rendimiento y calidad del servicio (QoS) de las redes de próxima generación (NGN). Esas normas nuevas y perfeccionadas son importantes para que las NGN puedan trabajar con una gran variedad de servicios en evolución de QoS habilitada (de banda ancha y estrecha), entre los que se cuentan los de voz por IP (Voice over IP = VoIP) así como los servicios de multimedios con diversas combinaciones de voz, video y datos.

7.2 Objetivos de calidad del funcionamiento de la red

Es importante que los proveedores de servicios trabajen de forma conjunta para asegurar el funcionamiento extremo a extremo de las comunicaciones y que cada proveedor entienda su justa asignación en cuanto a los objetivos de funcionamiento extremo a extremo. Esas asignaciones deben ser adecuadas para el servicio que se ofrece y viables en cuanto a las técnicas de red disponibles. A efectos de satisfacer los factores de calidad de servicio (QoS) para todas las transacciones y tipos de clientes, un proveedor de servicio debe examinar y planificar detenidamente los requisitos de calidad de servicio y las expectativas de los clientes conforme a un número manejable de clases de calidad de servicio únicas y bien definidas. Estas clases representan los parámetros de calidad de funcionamiento del servicio que quieren lograrse para diferentes tipos de transacciones de telecomunicaciones [12].

7.2.1 Y.1540

La Recomendación Y.1540 del UIT-T, “Servicio de comunicación de datos con Protocolo Internet – Parámetros de calidad de funcionamiento relativos a la disponibilidad y la transferencia de paquetes de Protocolo Internet” define los parámetros que se pueden utilizar para especificar y evaluar la calidad de funcionamiento en cuanto a velocidad, exactitud, seguridad de funcionamiento y disponibilidad de la transferencia de paquetes IP del servicio de comunicación de datos con Protocolo Internet (IP) internacional.


38

Los parámetros definidos se aplican al servicio IP de extremo a extremo, punto a punto y a tramos de la red que proporcionan o contribuyen a la prestación de ese servicio. La Y.1540 define los siguientes parámetros de funcionamiento para la transferencia de paquetes IP: • Retardo de transferencia de paquetes IP (IPTD): El retardo de un datagrama IP entre dos puntos de referencia. Normalmente, un retardo de extremo a extremo o un retardo dentro de una red. • Retardo medio de transferencia de paquetes IP: La media aritmética de los retardos de la transferencia de paquetes IP de una población de interés. • Variación del retardo de paquetes IP (IPDV): Las variaciones del retardo de la transferencia de paquetes IP. • Tasa de errores en los paquetes IP (IPER): La tasa de paquetes con errores del total de los paquetes recibidos. • Tasa de pérdida de paquetes IP (IPLR): La tasa de paquetes perdidos del total de los paquetes transmitidos en una población de interés. • Tasa de paquetes IP espurios (SPR): El total de paquetes IP espurios observados en ese punto de medición de egreso durante un intervalo de tiempo especificado dividido por la duración del intervalo de tiempo. • Porcentaje de indisponibilidad del servicio IP (PIU): El porcentaje del tiempo de servicio IP programado total que se clasifica como período indisponible utilizando la función de disponibilidad de servicio IP. La función de disponibilidad de un servicio IP se basa en un umbral de la característica IPLR.

7.2.2 Y.1541 En la Recomendación Y.1541 del UIT-T, “Network Performance Objectives for IP-Based Services” (Objetivos de calidad de funcionamiento para servicios IP), se propone agrupar las transacciones de telecomunicaciones IP en seis clases especiales de QoS de red definidas de acuerdo con los objetivos de QoS deseados. Dichas clases sirven de base para acuerdos entre los usuarios finales y proveedores de servicios. Son compatibles con una gran variedad de aplicaciones de tráfico, entre ellas la telefonía de punto a punto, la transferencia de datos, y las conferencias con multimedios—aplicaciones que exigen una calidad de funcionamiento mayor que otras (es posible que se necesite una clasificación nueva o revisada para las aplicaciones futuras). El número limitado de clases coincide con la condición requerida de una implementación viable, particularmente con respecto a la escala de las redes mundiales. De acuerdo con la recomendación mencionada, “un flujo de paquetes es el tráfico asociado con un flujo con o sin conexión determinado que tiene el mismo computador principal de origen, computador principal de destino, clase de servicio e identificación de sesión”. Por lo tanto, un proveedor de servicio y un usuario final habrán llegado a un acuerdo sobre la capacidad máxima necesaria para la clase de servicio requerida del flujo de paquetes según la defina una de esas seis clases. Los objetivos de QoS son aplicables cuando


39

las velocidades de enlaces de acceso se hallen al nivel T1 o E1, y a niveles más altos. A continuación se presentan unos breves comentarios sobre cada clase: • Clase 0: Aplicaciones de tiempo real, muy interactivas, sensibles a variación de retardo Retardo medio en el límite superior es 100 ms, la variación de retardo es inferior a 50 ms y la tasa de pérdida es inferior a 10-3. Ejemplos de aplicaciones incluyen Voz sobre IP (VoIP), Video Teleconferencia (VTC). • Clase 1: Aplicaciones de tiempo real, interactivas, sensible s a variación de retardo Retardo medio en el límite superior es 400 ms, la variación de retardo es inferior a 50 ms y la tasa de pérdida es inferior a 10-3. Ejemplos de aplicaciones incluyen VoIP, VTC. • Clase 2: Transacciones de datos muy interactivas. Retardo medio en el límite superior es 100 ms, la variación de retardo está sin especificar y la tasa de pérdida es inferior a 10-3. Ejemplos de aplicaciones incluyen señalización. • Clase 3: Transacciones de datos interactivas Retardo medio en el límite superior es 400 ms, la variación de retardo está sin especificar y la tasa de pérdida es inferior a 10-3. • Clase 4: Exclusivo para aplicaciones de bajas pérdidas. Retardo medio en el límite superior es 1 s, la variación de retardo está sin especificar y la tasa de pérdida es inferior a 10-3. Ejemplos de aplicaciones incluyen Transacciones de breve duración, datos en gran volumen, y video en flujo. • Clase 5: Sin especificar Aplicaciones con un retardo medio, variación de retardo y tasa de pérdida sin especificar. Ejemplos de aplicaciones incluyen las aplicaciones tradicionales de Redes IP típicas. Estas seis clases permiten Acuerdos de Nivel de Servicio (SLA) entre los clientes y los proveedores del servicio de red con respecto a los requisitos de los parámetros de calidad de servicio. El proveedor de servicio debe entonces asegurar que los requisitos de clase de servicio para cada cliente son reconocidos y que éste recibe el trato apropiado en las capas de la red. Todos los valores son PROVISIONALES y las redes no deben cumplirlos hasta que hayan sido revisados (superiores o inferiores) conforme a la experiencia real de funcionamiento.

7.2 Para mayor studio • DQoS (PKT-SP-SEC-I01-991201) • SQoS


40


8 Normas en evolución

8.1 Protocolo Internet versión 6 (IPv6)

El Protocolo Internet versión 6 (Ipv6), [6], inició la normalización como reemplazo de la actual versión IP 4 (Ipv4), descrita en la RFC 791, (Norma) debido al agotamiento del número limitado de direcciones Ipv4, ya previsto en la década de 1990. Hasta ahora, mediante diversas técnicas, tales como Classless Inter-Domain Routing (CIDR), Network Address Translation (NAT), y Multi Protocol Label switching (MPLS), se ha podido postergar ese agotamiento. El grupo de trabajo del IETF para la próxima generación de Internet (IPNG) creó el Ipv6 (RFC 2460) (Proyecto de norma). El actual protocolo Internet Ipv4 trabaja con hasta 4.000 millones de direcciones con un espacio de direcciones de 32 bits. Si bien 4.000 millones es mucho más que el número actual estimado de 2.500 millones de direcciones en uso por varios cientos de millones de usuarios de la Internet, en la práctica el Ipv4 trabaja con un número mucho menor. Eso se debe a que las direcciones no se usan muy eficientemente. Son atribuidas en bloques regionales, y hay un exceso de oferta en ciertas regiones del mundo, mientras que otras (Asia, Europa y Latinoamérica) están próximas a quedarse sin direcciones. Al índice actual de eficiencia del 60%, las direcciones IP se acabarán en algún momento en el futuro. El formato de direcciones de 128 bits del Ipv6 admite 340.232.366.920.938.463.374.607.431.768.211.456 direcciones IP, cantidad suficiente para asignar una a cada grano de arena de la Tierra. La Figura 8 muestra el formato del encabezamiento del Ipv6.

Long i t ud ca rga ú t i l

D i recc ión fuen te 128 b i t

4 by tes (32 b i t s )

Próx . encabez . L ím i te de sa l to V e r

Carga ú t i l ( i nc luye encabez . op ta t i vos y pa r te de da tos )

Encabez . b á s i c o

Clase de t r á f i co Et ique ta f lu jo

D i r e c c i ó n d es t i no 128 - bit

Figura 9 – Formato del encabezamiento del Ipv6

Además de una gama de direcciones de 128 bits, el conjunto de protocolo TCP-UDP/Ipv6 ofrece otras características, tales como seguridad obligatoria y movilidad, facilidad de administración y funciones de autoconfiguración, QoS integral, y un encaminamiento más variable, así como mayor solidez, para mencionar unas pocas. Muchas de éstas han sido retroincorporadas en el Ipv4 con varias limitaciones y una menor funcionalidad.

Los sistemas inalámbricos tendrán el mayor efecto en el IP; la 3G de próxima aparición utilizará mucho más el IP que las generaciones anteriores de radio celular. Hasta ahora, el IP


42

se ha usado como un añadido a las redes celulares; en un futuro no muy lejano los sistemas celulares estarán orientados a los datos, ya que la voz será tratada como otra sesión IP en la red. La elaboración de nuevos protocolos de radio tales como el 802.11B (Ethernet inalámbrica) además de nuevas interfaces en serie alambradas como la IEEE 1394 (Firewire) brindará la oportunidad para que los productos de consumo requieran una dirección IP para conectarse a la red.

8.1.1 Atajos en el Ipv4

La industria de la Internet ha podido estirar el espacio de direcciones del Ipv4, usando una combinación de las técnicas indicadas seguidamente: • DHCP – protocolo dinámico de configuración del anfitrión (Dynamic Host Configuration Protocol) (RFC 2132) (Proyecto de norma) El DHCP permite asignar las direcciones IP de tres maneras: 1. Atribución manual: El administrador de la red mantiene un control completo de las direcciones, asignándolas específicamente a los clientes. El servidor DHCP usa esa base de datos para asignar una dirección IP, que fue asignada a una dirección MAC (Media Access Control = control de acceso a los medios) determinadas. 2. Atribución automática: El servidor DHCP asigna permanentemente una dirección de un grupo de direcciones. El administrador no interviene en los detalles de asignar una dirección a un cliente. 3. Atribución dinámica: El servidor DHCP asigna una dirección a un cliente DHCP por un período limitado. El servidor reclama automáticamente la dirección cuando expira el alquiler, o cuando el cliente se desconecta. • NAT – Traducción de direcciones de la red (Network Address Translation) (RFC 2663) (Informativo) El NAT es un método mediante el cual las direcciones IP son correlacionadas de un dominio a otro, tratando de que el encaminamiento sea transparente para los anfitriones. Tradicionalmente, los dispositivos NAT se usan para conectar un dominio aislado de dirección con direcciones privadas no registradas a un dominio externo con direcciones registradas que son mundialmente únicas. Si un proveedor de servicios posee una cantidad limitada de direcciones IP válidas (registradas), ese proveedor atribuirá direcciones IP privadas al usuario de la red vía DHP para permitir la navegación dentro de la red o dentro de una VPN (red privada virtual). Una vez que el usuario necesite el acceso a recursos fuera de la red del proveedor o de la VPN, el dispositivo de egreso hará la traducción NAT a una dirección IP válida (registrada), de modo que el datagrama pueda llegar al destino final. El NAT también ha sido considerado como uno de los métodos para efectuar la transición de Ipv4 a Ipv6 (RFC 2766) (Norma propuesta). Eso puede hacerse realizando la traducción de direcciones de la red en un dispositivo del borde situado entre un dominio Ipv6 y un dominio Ipv4; el dispositivo del borde correlacionaría las direcciones IP de una red de un dominio Ipv4 a una


43

red Ipv6 y viceversa, para tratar de suministrar un encaminamiento transparente entre ambos. • MPLS – Conmutación por etiquetas multiprotocolo (Multi Protocol Label Switching) (RFC 3031) (Norma propuesta) Cuando un paquete del protocolo de una capa de red sin conexiones se desplaza de un encaminador al siguiente, cada encaminador toma una decisión independiente de reenvío para ese paquete. Esto significa que cada encaminador analiza el encabezamiento del paquete, y ejecuta un algoritmo de encaminamiento de capa de red. Cada encaminador elige independientemente un próximo salto para el paquete, basándose en su análisis del encabezamiento del paquete y los resultados de ejecutar el algoritmo de encaminamiento. Los encabezamientos de paquetes contienen considerablemente más información que la necesaria simplemente para elegir el salto siguiente. La elección del salto siguiente puede entonces considerarse la composición de dos funciones. La primera función divide todo el conjunto de paquetes posibles en un conjunto de “clases de equivalencia de reenvío” ("Forwarding Equivalence Classes” = FEC). La segunda correlaciona cada FEC a un salto siguiente. En lo que toca a la decisión de reenvío, los diferentes paquetes que son correlacionados en la misma FEC son indistinguibles. Todos los paquetes que pertenecen a una FEC determinada y que se desplazan desde un nodo determinado seguirán el mismo trayecto (o, si se emplean ciertas clases de encaminamiento multitrayecto, todos seguirán uno de los trayectos de un conjunto de trayectos relacionado con la FEC). En el reenvío IP convencional, un encaminador determinado considerará por lo general que dos paquetes corresponden a la misma FEC si hay algún prefijo X de la dirección en las tablas de encaminamiento de ese encaminador, siendo esa X la “pareja más larga” para la dirección de destino de cada paquete. A medida que el paquete atraviesa la red, cada salto lo reexamina a su vez y lo asigna a una FEC. En la MPLS, la asignación de un paquete determinado a una FEC determinada se hace sólo una vez, al entrar el paquete en la red. La FEC a la cual se asigna el paquete es codificada como un valor fijo corto de longitud denominado “etiqueta”. Cuando un paquete es reenviado a su próximo salto, la etiqueta se manda junto con el paquete, o sea que los paquetes son “etiquetados” antes de ser reenviados. En los saltos subsiguientes, ya no se analiza más el encabezamiento de capa de red del paquete. En cambio, la etiqueta se usa como índice para una tabla, que especifica el salto siguiente, y una nueva etiqueta. La etiqueta vieja es reemplazada con la nueva, y el paquete es reenviado a su salto siguiente. En el paradigma de reenvío MPLS, una vez que un paquete es asignado a una FEC, los encaminadores subsiguientes no hacen más análisis del encabezamiento; las etiquetas impulsan todo el reenvío. Eso ofrece varias ventajas respecto del reenvío convencional de capas de la red. Mediante el uso de etiquetas en vez de direcciones IP, se reduce el número de direcciones que pueden usarse.

8.1.2 Seguimiento de ubicaciones


44

El VLR (Visitor Location Register = registro de ubicación de visitantes) es una tecnología esencial usada por la red celular para encaminar llamadas hacia y desde un usuario móvil. En las actuales redes celulares 2G, las llamadas a un usuario se posibilitan mediante el rastreo de su paradero en una base de datos denominada VLR. Cuando alguien marca un número, la información del VLR se usa para encaminar la llamada a la estación base más cercana a la ubicación del llamante en ese momento, y luego al teléfono móvil. Éste es un procedimiento complicado y tan sólo mantener la VLR al día representa una carga considerable para la red celular. Con el Ipv6, será posible asignar no sólo una dirección IP a cada dispositivo, sino a la ubicación potencial de cada dispositivo. Darle a cada ubicación potencial su propia dirección simplifica el rastreo y encaminamiento de las llamadas. Una llamada podría manejarse de la misma manera en que hoy día se maneja un número telefónico, excepto que en vez de usar tal número, la red usaría direcciones IP. Una parte de la dirección IP cambiaría constantemente de acuerdo con el paradero del dispositivo móvil. La industria de la Internet ha podido enfrentar el problema de las ubicaciones cambiantes utilizando el IP móvil (RFC 2794) (Norma propuesta) como solución improvisada del Ipv4. El IP móvil especifica mejoras al protocolo que permiten el encaminamiento transparente de datagramas IP a nodos móviles de la Internet. Cada nodo móvil se identifica siempre por su dirección de base, sea cual fuere su punto de conexión en determinado momento con la Internet. Mientras se halle fuera de su base, un nodo móvil también está relacionado con una dirección “a cargo de”, que informa sobre su punto de conexión vigente a la Internet. El protocolo permite registrar la dirección “a cargo de” con un agente de base. Éste envía datagramas destinados al nodo móvil a través de un túnel a dicha dirección “a cargo de”, Después de llegar al final del túnel, cada datagrama se entrega entonces al nodo móvil. Pero cuando la solución improvisada descrita arriba tiene problemas, especialmente en el caso de aplicaciones que requieran que el usuario o punto extremo usen una dirección IP válida, el IP móvil no podrá enfrentar la mayor demanda.

8.1.3 Direccionamiento Ipv6

La arquitectura del direccionamiento Ipv6 se describe en el IETF RFC 2373, “Arquitectura de direccionamiento IP Versión 6”. La diferencia más obvia entre el Ipv4 y el Ipv6 es la longitud, siendo el Ipv4 de direcciones de 32 bits y el Ipv6, de 128 bits. Si bien las direcciones del Ipv4 sólo pueden dividirse en dos o tres partes variables (el identificador de red, el identificador de nodo y a veces el identificador de subred), en el Ipv6 las direcciones son lo suficientemente largas como para tener campos dentro de la dirección.

8.1.4 Representación de la dirección Ipv6

Hay tres formas convencionales de representar las direcciones Ipv6 como cadenas de texto. La forma preferida es x:x:x:x:x:x:x:x, siendo las ‘x’ valores


45

hexadecimales de las ocho piezas de 16 bits de la dirección, pero ciertos estilos de direcciones Ipv6 pueden contener largas cadenas de bits cero que pueden representarse con “::”. La tercera opción es una situación mixta de Ipv4 e Ipv6 tal como x:x:x:x:x:x:d.d.d.d, en donde las ‘x’ son los valores hexadecimales de las seis piezas de 16 bits de orden superior de la dirección, y las ‘d’ son los valores decimales de las cuatro piezas de 8 bits de orden inferior de la dirección (representación Ipv4 normal).

8.1.5 Tipos de dirección Ipv6

Hay cuatro tipos de dirección en el Ipv6: Unicast (unidifusión) (un identificador para una sola interfaz), Anycast (difusión a cualquier punto) (un identificador para un conjunto de interfaces; perteneciente típicamente a diferentes nodos) y Multicast (multidifusión) (un identificador para un conjunto de interfaces; perteneciente típicamente a diferentes nodos).

8.1.6 Direcciones unidifusión Ipv6

Las direcciones unidifusión especifican una sola interfaz Ipv6. Un nodo puede tener más de una interfaz de red Ipv6. Las direcciones unidifusión pueden considerarse un campo de 128 bits que identifica una interfaz determinada. Sin embargo, los datos del campo de direcciones pueden resolverse en piezas más pequeñas de información, aunque toda esa información al ser reunida tendrá como resultado un campo de 128 bits que identifica la interfaz de un nodo. Una dirección unidifusión Ipv6 puede considerarse una entidad de dos campos, con un campo para la red y el otro para un identificador de la interfaz del nodo en esa red. Hay varias formas de asignación de direcciones unidifusión en el Ipv6, incluidas la dirección unidifusión global agregable, la dirección NSAP, la dirección jerárquica IPX, la dirección local de sitio, la dirección local de enlace, y la dirección de anfitrión capaz de Ipv4. En el futuro podrán definirse otros tipos de dirección. Los nodos Ipv6 pueden tener un conocimiento considerable o ningún conocimiento de la estructura interna de la dirección Ipv6, dependiendo de la función que cumpla el nodo (por ejemplo, anfitrión en vez de encaminador). Los anfitriones más sofisticados podrán saber de otros límites jerárquicos en la dirección unidifusión. Aunque un encaminador muy simple puede no conocer la estructura interna de la dirección unidifusión Ipv6, generalmente los encaminadores tendrán conocimiento de uno o más límites jerárquicos para el funcionamiento de los protocolos de encaminamiento. Los límites conocidos variarán de un encaminador a otro, dependiendo de las posiciones que el encaminador tenga en la jerarquía del encaminamiento.

8.1.7 Direcciones de difusión a cualquier punto Ipv6


46

La RFC 2373 define una dirección de “difusión a cualquier punto” (“anycast”) como una dirección Ipv6 que es asignada a una o más interfaces de la red (típicamente pertenecientes a diferentes nodos), con la propiedad de que un paquete enviado a una dirección de difusión a cualquier punto es encaminada a la interfaz “más cercana” que tenga esa dirección, de acuerdo con la medida de la distancia de los protocolos de encaminamiento. Varios nodos pueden compartir la misma dirección de difusión a cualquier punto, como una dirección multidifusión, pero sólo uno de esos nodos puede recibir un datagrama enviado a la dirección de difusión a cualquier punto. La difusión a cualquier punto es útil para suministrar ciertos tipos de servicios, en particular los que no requieren una relación determinada entre el cliente y el servidor. Por ejemplo, un servidor de nombres de dominio y un servidor de tiempo. El servidor de nombres más cercano puede suministrar el mismo servicio que el más alejado, pero el servidor más cercano proporciona una indicación de hora más precisa que el más alejado. Las direcciones de difusión a cualquier punto se atribuyen del espacio normal de direcciones de unidifusión Ipv6. Como las direcciones de difusión a cualquier punto no pueden diferenciarse en su propia forma de una dirección de unidifusión, los miembros de la dirección de difusión a cualquier punto deben ser configurados explícitamente para reconocer la dirección como de difusión a cualquier punto. En el IETF RFC 2526, (Norma propuesta) Reserved Ipv6 Subnet Anycast Addresses (Direcciones reservadas de difusión a cualquier punto Ipv6 de subred) se define un conjunto de tales direcciones reservadas dentro de cada prefijo de la subred, y se indica la atribución inicial de dichas direcciones reservadas de subred. En otro IETF RFC 3068 (Norma propuesta) An Anycast Prefix for 6to4 Relay Routers (Un prefijo de difusión a cualquier punto para encaminadores de retransmisión 6 a 4), se introduce una “dirección de difusión a cualquier punto Ipv6 a Ipv4”, a fin de simplificar la configuración de encaminadores de IPv6 a IPv4. También se define cómo usarán esta dirección los encaminadores de retransmisión IPv6 a IPv4, cómo se anunciará el "prefijo de difusión a cualquier punto IPv6 a IPv4" correspondiente en el IGP y el EGP. La asignación de direcciones se basa en el IETF RFC 3056 (norma propuesta), Connection of Ipv6 Domains via Ipv4 Clouds, en particular la definición de un encaminador de 6 a 4 y un encaminador de retransmisión de 6 a 4. Se añade la definición del prefijo de difusión a cualquier punto de retransmisión 6 a 4, la dirección de difusión a cualquier punto de 6 a 4, y la dirección de unidifusión equivalente Ipv4.

8.1.8 Direcciones de multidifusión

Como las direcciones de difusión, las de mutidifusión se usan en redes locales como la Ethernet, en las que los nodos pueden detectar las transmisiones en un cable. Pero la multidifusión IP es más complicada porque todos los paquetes no son retransmitidos a todos los nodos de la red, enviándoselos en cambio a miembros del grupo de multidifusión. Cuando un nodo se suscribe a


47

una dirección de multidifusión, anuncia que quiere convertirse en miembro, y cualquier encaminador local hará la suscripción en nombre de ese nodo. Las direcciones de multidifusión no deben usarse como direcciones de origen en paquetes Ipv6 ni aparecer en ningún encabezamiento de encaminamiento. Las direcciones de multidifusión predefinidas aparecen en el IETF RFC 2375, (Informativo) “ Ipv6 Multicast Address Assignments (Asignaciones de direcciones multidifusión Ipv6). El trabajo continúa en el IETF RFC 3019, (Norma propuesta) IP Version 6 Management Information Base for The Multicast (Base de información para la gestión del IP versión 6 para la multidifusión), y el IETF RFC 2908, The Internet Multicast Address Allocation Architecture (Arquitectura de atribución de direcciones multidifusión de la Internet).

8.2 Para mayor estudio

• MALLOC (Multicast-Address Allocation = atribución de direcciones de multidifusión)

*****


9 Conclusión En el UIT-T, el IETF y otros foros se sigue trabajando para formular y refinar normas para las NGN. Esas nuevas normas son importantes para que las redes existentes puedan integrarse con las que incluyen servicios de voz por paquetes en una sola red de nueva generación. Teniendo en cuenta la importancia de dichas normas y su efecto potencial en la región, El Grupo de Trabajo sobre Coordinación e Normas ha estado estudiando estas normas que continúan en evolución y los siguientes documentos coordinados de normas (CSD) se han aprobado por el CCP.I.

*****


49

10 Referencias 1. CCP.I/doc.957/00, “Normas en evolución para la telefonía Internet” 2. CCP.I/fdoc.1107/00, “Actualizaciones a la contribución CCP.I/doc.957/00” 3. CCP.I/doc.1112/01, “Breve explicación del SIP” 4. CCP.I/doc.1111/01, “Redes de voz y protocolos de próxima generación” 5. CCP.I/doc.1258/01, “IN CS-4 Overview” [Reseña del IN CS-4] 6. CCP.I/doc.1262/01, “El protocolo etiquetado IPv6” 7. CCP.I-TEL/doc.0202/03, “Redes de próxima generación – Reseña de las normas (septiembre

2003)” 8. CCP.I/doc.1344/01, “Redes de próxima generación – Normas de rendimiento/QoS” 9. CCP.I/doc.1382/01, “Direccionamiento IPv6” 10. CCP.1/doc.1472/02, “Guía de normas – Sistemas de línea digital asimétrica para abonados

(ADSL)” 11. CCP.I/doc. 1518/02, “Security on the Internet” (La seguridad en la Internet) 12. CCP.1/doc. 1477/02, “Objetivos de calidad de funcionamiento de las redes de próxima generación”

*****


11 Acrónimos y abreviaciones 3GPP Third Generation Partnership Project (proyecto de asociación de tercera generación ADSL Asymmetric Digital Subscriber Line (línea de abonado digital asimétrica) ADSLAM Asymmetric Digital Subscriber Line Access Multiplexor (multiplejador de acceso de línea

de abonado digital asimétrica) API Application Programming Interface (interfaz de programación de aplicaciones) APM Application Transport Mechanism (mecanismo de transporte de aplicación) ATM Asynchronous Transfer Mode (modo de transferencia asincrónico) BICC Bearer Independent Call Control (control de llamada de portador independiente) B-ISDN Broadband ISDN (RDSI de banda ancha [RDSI-BA]) BLES Broadband Loop Emulation Services (servicios de emulación de bucle de banda ancha BPI+ Base Privacy Interface + CCS7 Common Channel Signaling #7 (señalización por canal común #7) CPE Customer Premises Equipment (equipo en las instalaciones del cliente) CS1 Capability Set One (conjunto de capacidades uno) DiffServ Differentiated Services (servicios diferenciados) DNSSEC Domain Name System Security DOCSIS Data Over Cable Service Interface Specification DqoS Dynamic Quality of Service (calidad de servicio dinámica) DSL Digital Subscriber Line (línea de abonado digital) GSTN General Switched Telephone Network (red telefónica general conmutada) HDSL High-bit-rate DSL (DSL de alta velocidad de bits) HFC Hybrid Fiber-Coax Cable (configuración híbrida óptica-cable coaxial) HTTP HyperText Transfer Protocol (protocolo de transporte hipertexto) IETF Internet Engineering Task Force (Grupo de tareas sobre ingeniería de Internet) IKE Internet Key Exchange IP Internet Protocol (protocolo de Internet) IPDC Internet Protocol Device Control IPSec IP Security protocol (protocolo de seguridad Internet) IPv6 IP Version 6 protocol (protocolo Internet versión 6) ISUP ISDN User Part (parte usuario RDSI) UIT Unión Internacional de Telecomunicaciones JAIN Java API for Integrated Networks (API Java para redes integradas) Kerberos Un protocolo de autenticación de red de clave secreta M3UA MTP3 User Adaptation (adaptación de usuario MTP3) MALLOC Multicast-Address Allocation (atribución de direcciones de multidifusión) MANET Mobile Ad-hoc Networks (redes ad hoc móviles) MDCP Media Device Control Protocol (protocolo de control de dispositivos de medios) MEGACO Media Gateway Control Protocol (protocolo de control de pasarelas de medios) MG Media Gateway (pasarela de medios) MGC Media Gateway Controller (control de pasarela de medios, también conocido como

Softswitch, Call Agent o Call Server MGCP Media Gateway Control Protocol (protocolo de control de pasarela de medios) MOBILEIP Mobile IP (IP móvil) (grupo de trabajo del IETF) MPLS Multi-Protocol Label Switching (conmutación por etiquetas multiprotocolo) MTP Message Transfer Part (parte [de] transferencia de mensajes, PTM) NCS Network-Based Call Signalling (señalización de llamadas en red) NGN Next Generation Network (red de próxima generación)


51

OPE Open Programmability Environment (entorno de programabilidad abierta) PKINIT Public Key Initialization PSTN Public-Switched Telephone Network (red telefónica pública conmutada, RTPC) QoS Quality of Service (calidad del servicio) RMI Remote Method Invocation (método de invocación remota) RSVP Resource Reservation Setup Protocol (protocolo de reserva de recursos) RTP Real-time Transport Protocol (protocolo de transporte en tiempo real) RTSP Real-Time Streaming Protocol (protocolo de transmisión de flujo continuo en tiempo real) SAP Session Announcement Protocol (protocolo de anuncio de sesiones) SCTP Stream Control Transmission Protocol (protocolo de transmisión de control de tren) SDO Standards Development Organization (organización normalizadora) SDP Session Description Protocol (protocolo de descripción de sesiones) SDSL Single-line Digital Subscriber Line (línea única de abonado digital) SGCP Simple Gateway Control Protocol (protocolo simple de control de pasarela) SGML Standard Generalized Markup Language (lenguaje de etiquetado generalizado normal) SIP Session Initiation Protocol (protocolo de iniciación de sesiones) SIP-T SIP-Telephony (telefonía SIP) SNMP Simple Network Management Protocol (protocolo simple de gestión de red) SqoS Survivability quality of service (calidad de servicio de capacidad de supervivencia) SSL Secure Sockets Layer (capa de zócalos seguros) VMOA Voice and Multimedia over ATM (voz y multimedios por ATM) VoDSL Voice over DSL (transmisión de la voz por DSL) VoIP Voice over IP (protocolo de transmisión de la voz por la Internet) VoMSDN Voice over Multi-Service Data Networks (transmisión de voz por redes de datos

multiservicios) VoP Voice over Packet XDSL Placeholder for any one of a family of Digital Subscriber Line technologies XML Extended Markup Language (lenguaje de etiquetado extendido)

*****

Redes de Próxima Generación

Documents

Transcript of Redes de Próxima Generación