Redes de Próxima Generación

ORGANIZACIN DE LOS ESTADOS AMERICANOS
COMISION INTERAMERICANA DE TELECOMUNICACIONES
COMIT CONSULTIVO PERMANENTE I:

NORMALIZACION DE TELECOMUNICACIONES
CARPETA TECNICA:
REDES DE PROXIMA GENERACION
Visin general de normas
Redes de Prxima Generacin Visin general de normas
CARPETA TECNICA-1 (2004)
Referencia: P1!T-0363/04
CITEL
Comisin 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 electrnico: oscar@nortelnetworks.com
o
Secretario Ejecutivo de la CITEL
Tel: +1 202 458 3004
Fax: +1 202 458 6854
Correo electrnico: citel@oas.org
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, electrnico o mecnico, comprendidas la
fotocopia y la grabacin en micropelcula, sin autorizacin escrita de la CITEL.
ii
CARPETA TECNICA1
Una Carpeta Tcnica proveer una manera formal de mantener una ficha sobre la informacin tcnica
de proyectos que ser puesta a disposicin de la industria de las telecomunicaciones en los Estados
miembros.
Se utilizan dichas Carpetas Tcnic as para:
a) Publicar informacin tcnica para la caracterizacin de redes o funcionalidad de servicios
para servicios nuevos o existentes.
b) Describir o reportar la situacin de un proyecto en estudio para el uso presente y futuro de
un Grupo de Trabajo.
c) Publicar los hallazgos de un estudio, una revisin o de una encuesta.
d) Procedimientos de documentacin, asuntos relacionados a trabajos realizados en conjunto
o asuntos de interconexin, que beneficiaran la industria pero que no son adaptables ni
prcticos como Documentos sobre Normas Coordinadas (CSD).
e) Normas de documentacin, 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 aprobacin del GTCN.
Los miembros de CITEL no han aprobado el contenido de este documento.
CCP..I/RES. 142 (XV-01)
ii
INDICE
Resumen....................................................................................................................................... 1
1
Introduccin .......................................................................................................................... 2
2. Normas de sealizacin.......................................................................................................... 5
2.1
SIGTRAN (SIGnaling TRANsport = transmisin de sealizacin) .................................... 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 lnea 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 creacin de tneles (L2TP).......................................17
3.1.1.11
Consideraciones relativas al IP.........................................................................17
3.2
Normas de acceso por cable .........................................................................................18
3.3
Normas de acceso inalmbrico .....................................................................................18
4
Normas de gestin ................................................................................................................19
5
Normas de creacin 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 autenticacin (AH).....................................................................25
6.1.3
Carga til de proteccin de encapsulado (Encapsulation Security Payload: ESP)......26
6.1.4
Gestin 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 dinmico........................................................................................................28
6.2.3
Modo rpido............................................................................................................28
6.3
Para mayor estudio ......................................................................................................29
7
Normas de desempeo y calidad del servicio (QoS) ................................................................30
iii
7.1
QoS en redes basadas en el IP .....................................................................................31
7.1.1
Obtencin de una calidad de servicio RTPC tradicional en las redes IP .......................31
7.1.2
Caractersticas y expectativas del servicio VoIP ........................................................31
7.1.3
Estrategia para la QoS en redes IP ...........................................................................34
7.1.4
Tecnologas 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
Conmutacin 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 evolucin.............................................................................................................41
8.1
Protocolo Internet versin 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
Representacin de la direccin Ipv6..........................................................................44
8.1.5
Tipos de direccin Ipv6 ............................................................................................45
8.1.6
Direcciones unidifusin Ipv6.....................................................................................45
8.1.7
Direcciones de difusin a cualquier punto Ipv6...........................................................45
8.1.8
Direcciones de multidifusin .....................................................................................46
8.2
Para mayor estudio ......................................................................................................47
9
Conclusin............................................................................................................................48
10
Referencias ......................................................................................................................49
11
Acrnimos y abreviaciones ................................................................................................50
iv
REDES DE PROXIMA GENERACION

UNA VISION GENERAL
Resumen
Las redes de prxima generacin (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 integracin sin solucin de continuidad con servicios de
telecomunicaciones tanto nuevos como tradicionales en redes de paquetes de alta velocidad,
interfuncionando con clientes que poseen capacidades heterogneas. Dicha arquitectura generalmente
est estructurada alrededor de cuatro capas principales de tecnologa. La capa ncleo de conectividad
incluye el encaminamiento y la conmutacin, pasarelas de red y acceso. La capa de acceso y de equipo
del local del cliente (customer-premises equipment = CPE) incluye las diversas tecnologas usadas
para llegar a los clientes. La capa de servidor de aplicaciones contiene servicios mejorados y
aplicaciones de valor aadido. La capa de gestin proporciona funciones de direccin 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 introduccin con buen xito de una NGN.
En el documento Redes de prxima generacin Resea de las normas se identifican las normas
relacionadas con las NGN que el Grupo de Trabajo sobre Coordinacin de Normas est estudiando,
entre ellas los protocolos pertinentes y la telefona Internet. Esta contribucin 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.
Introduccin
La arquitectura y la ejecucin de la red de prxima generacin (NGN) debern 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. Tambin es
generalmente aceptado que la NGN debe basarse en una arquitectura distribuida que ayude
considerablemente a reducir los costos de ejecucin, al mismo tiempo que flexibilic e su introduccin.
Las NGN debern poder trabajar con servicios sumamente adaptables, que puedan crearse fcil y
rpidamente, as como establecerse econmicamente en toda la red. Si bien es importante habilitar
nuevos servicios, tambin 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 visin de la mayora de
las empresas explotadoras. La arquitectura puede descomponerse en varias capas: conectividad de
ncleo, acceso y equipo del local del cliente (Access and Customer Premise Equipment = CPE), y
gestin.
Services
Voice
Services
Internet
Multimedia
Services
Data
Services
ATM/IP
Core
MG
Other
Carriers
MG
Access
TDM
Equipment
Premise
MG
MG
New Access
End--to
End
to--end Network Management
Management
MG
ISP
Management
Customer Premise Portfolio
Figura 1 Arquitectura de red de prxima generacin

Services: Servicios
Voice Services: Servicios de voz
Multimedia Services: Servicios de multimedios
Data Services: Servicios de datos
Management: Gestin
MG: Media Gateway (pasarela de medios)
End-to-End Network Management: Gestin de red de extremo a extremo
ATM/IP Core: Ncleo 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 ncleo proporciona el encaminamiento y conmutacin general del trfico de
la red de un extremo de sta al otro. Est basada en la tecnologa de paquetes, ya sea ATM o IP, y
ofrece un mximo de flexibilidad. La tecnologa 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 trfico 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 estn las pasarelas: su funcin principal es adaptar el trfico
del cliente y de control a la tecnologa 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 tecnologas usadas para llegar a los clientes. En el pasado, el
acceso estaba generalmente limitado a lneas de cobre o al DS1/E1. Ahora vemos una proliferacin de
tecnologas que han surgido para resolver la necesidad de un ancho de banda ms alto, y para brindar a
las empresas competidoras de comunicaciones un medio para llegar directamente a los clientes. Los
sistemas de cable, xDSL e inalmbricos se cuentan entre las soluciones ms prometedoras que estn
creciendo e introduciendo innovaciones rpidamente.
El equipo del local del cliente, ya sea de su propiedad o arrendado, proporciona la adaptacin entre la
red de la empresa explotadora y la red o equipo del cliente. Puede tratarse de un simple telfono, pero
podemos apreciar una migracin 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 ofrecern a toda la red, sin importar la ubicacin del usuario. Dichos servicios sern tan
independientes como sea posible de la tecnologa de acceso que se use. El carcter 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. Adems, 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 ofrecern abarcarn todos los de voz existentes, y tambin una gama de servicios de datos y
otros servicios nuevos de medios mltiples.
Capa de gestin
Esta capa, esencial para minimizar los costos de explotar una NGN, proporciona las funciones de
direccin empresarial, de los servicios y de la red. Permite la provisin, supervisin, recuperacin y
anlisis del desempeo de extremo a extremo necesarios para dirigir la red.
Condiciones para la definicin de normas
Las organizaciones normalizadoras (SDO) deben cumplir una serie de condiciones al especificar las
normas para las redes de prxima generacin. Algunas de esas condiciones son las siguientes:
interfuncionamiento sin transiciones difciles de la red IP con la RTPC;
niveles de desempeo del servicio como los ofrecidos actualmente por la infraestructura
telefnica tradicional (p. ej., en la espera para el establecimiento de llamadas);
interfuncionamiento de dominios administrativos mltiples teniendo en cuenta los diferentes
protocolos de sealizacin;
variacin a escala para trabajar con un gran nmero 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
estn evolucionando y cambiando rpidamente.
En las secciones siguientes se delinean las normas pertinentes de la NGN. Dichas normas abarcan
aspectos de la red tales como la sealizacin, el acceso, la creacin de servicios, la gestin, la seguridad
y la calidad del servicio.
*****
Redes de Prxima Generacin
2.
Normas de sealizacin
Esta seccin est basada en la contribucin de la CITEL CCP.1/doc.957/00 (Normas en evolucin

para la telefona Internet) [1, 2]. Algunas secciones de ese documento han sido ampliadas, pero otras
permanecen tal como figuran en la contribucin 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 sealizacin telefnica
IP. El SG 16 elabor la Recomendacin H.323 (Sistemas de comunicacin multimedios basados en
paquetes). Ms recientemente, la comisin de Estudio 11 ha formulado otro mtodo para la telefona
por redes de paquetes, consistente en introducir una red de paquetes primaria en las redes existentes de
conmutacin de circuitos. El protocolo formulado para las comunicaciones entre centrales telefnicas
es conocido como protocolo de control de llamada de portador independiente (Bearer Independent
Call Control: BICC). Adems, el SG 11 tambin ha estado trabajando en cuestiones relacionadas con
el SIP, y en el proyecto de Recomendacin Q.1912.sip se define el interfuncionamiento de sealizacin
entre los protocolos BICC o ISUP y el SIP con su protocolo de descripcin de sesiones (SDP)
correspondiente en una unidad de interfuncionamiento (IWU).
Los grupos de trabajo del Grupo de Tareas sobre Ingeniera de Internet (IETF) tales como el iptel
(telefona IP), pint (Internet RTPC), sigtran (transmisin de sealizacin), megaco (control de pasarelas
de medios) y mmusic (control de sesiones de medios y partes mltiples) tambin han estado trabajando
en varios protocolos relacionados con la Internet, tales como el protocolo de iniciacin de sesiones
(Session Initiation Protocol = SIP), el protocolo de iniciacin de sesiones para telefona (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 Comisin de
Estudio 16 del UIT-T y el grupo de trabajo Megaco del IETF.
2.1
SIGTRAN (SIGnaling TRANsport = transmisin de sealizacin)
El mandato del grupo de trabajo Sigtran del IETF es crear protocolos relativos a la transmisin
de la sealizacin de la RTPC basadas en de paquetes por redes IP, teniendo en cuenta los
requisitos funcionales y de desempeo de tal sealizacin. Dichos protocolos son compatibles
con las comunicaciones entre el controlador de pasarelas de medios y la pasarela de
sealizacin.
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
adaptacin para la transmisin de SS7 por redes basadas en el IP. Algunas capas de
adaptacin son las siguientes:
SS7 MTP2 Capa de adaptacin del usuario, RFC 3331 (norma propuesta), que
transporta informacin de sealizacin del usuario entre el SG y el MGC;
SS7 MTP3 Capa de adaptacin del usuario, RFC 3332 (norma propuesta), que
transporta mensajes ISUP y SCCP entre el SG y el MGC.
ISDN Q.921 Capa de adaptacin 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.
Todava se est trabajando en el protocolo Sigtran. La RFC 2719 (informativo) proporciona el

marco arquitectnico para la transmisin de la sealizacin, y en la RFC 3257 (informativo) se
describe la aplicabilidad del protocolo de transmisin 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 Comisin de Estudio 11 del UIT-T, ofrece un medio
para que los explotadores actuales de la RTPC, basndose en la tecnologa de circuitos
conmutados, hagan evolucionar sus redes hacia la compatibilidad con los servicios de voz por
paquetes con un efecto mnimo en sus operaciones. Aunque existe cierta duplicacin en la
funcionalidad entre la especificacin BICC del SG 11 y la H.323 del SG 16, la especificacin
H.323 se concentra en empresas pequeas 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 migracin a SIP / SIP-T.
El protocolo BICC est basado en el protocolo de parte usuario de RDSI (ISUP) CCS7, y se
especifica en la Recomendacin Q.1901 del UIT-T. El BICC se transmite usando el
mecanismo de transporte de aplicacin (Application Transport Mechanism = APM). El
protocolo BICC es una aplicacin de la definicin del protocolo ISUP, pero no es compatible
entre pares con ISUP. Dicho protocolo reciba antes la denominacin 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 (Recomendacin 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 contina 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 definicin del protocolo
Megaco/H.248. La tarea se origin en el grupo de trabajo Megaco del IETF, y la mayora de
las discusiones tcnicas y ultimacin 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 informacin
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 Recomendacin H.248 el 15 de junio de 2000, y poco despus 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 gua de paquetes H.248 versin 1 del UIT-T se
resumen los paquetes que han sido normalizados en el perodo del 6/2000 al 6/2001.
La RFC 3525 Protocolo de Control de Pasarela Versin 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 electrnico de Megaco. La versin 2 de la H.248
fue finalizada en la reunin del SG 16 en febrero de 2002. La RFC 3525/H.248v2 contiene
correcciones actualizadas al RFC 3015/H.248v1 que estaban en la gua de implementadores,
adems de otros cambios tales como la depreciacin del descriptor del mdem, aclaracin del
texto de auditora, y adicin de auditoras dirigidas; mejora de la recoleccin de dgitos; y
adicin de multiplaje Nx64 al descriptor del mltiplex.
El H248 fue renumerado cuando se revis el 29-03-2002. El cuerpo principal del H.248,
Anexos A a E y el Apndice I se incluyeron en el H.248.1, Protocolo de Control de Pasarela
Versin 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 Versin 1.
La Versin 2 incluye algunas mejoras a la Versin 1, tales como la auditora individual de la
propiedad, seal, evento y estadstica; un mejor manejo de multiplexacin; la topologa para
tren de bits; una mejor descripcin 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 iniciacin de sesiones (SIP) [3], creado por el grupo de trabajo de control de
sesiones de medios y partes mltiples (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 atencin como
para crear un grupo de trabajo del SIP por separado para continuar su perfeccionamiento.
Desde su publicacin, se ha reconocido que el SIP requiere extensiones para ofrecer
aplicaciones telefnicas con la calidad de las comunicaciones pblicas y el grupo de trabajo del
SIP est considerando propuestas para lograr esto. Dichas propuestas suman una nueva
funcionalidad al protocolo SIP bsico, tal como el uso de MCU para conferencias de partes
mltiples, 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 descripcin de sesiones (Session Description Protocol = SDP) (norma
propuesta) se usa en el SIP para comunicar parmetros de la sesin, tales como la codificacin
de medios. El grupo MMUSIC est trabajando para mejorar la funcionalidad del SDP.
La adopcin por PacketCable, un proyecto de CableLabs y sus miembros, constituye la ms
significativa entre las primeras adopciones del SIP. En la iniciativa de PacketCable se
reconoci tambin que el SIP debe extenderse para que ofrezca servicios de calidad de
comunicaciones pblicas. El resultado de esto es la especificacin de la sealizacin de
llamadas distribuida (Distributed Call Signaling = DCS) de PacketCable. Algunas de las
ideas presentadas en la especificacin DCS han sido publicadas como borradores de Internet.
El protocolo Servidor de Gestin de Llamadas a CMS de PacketCable utiliza la especificacin
del protocolo de iniciacin de sesiones (Session Initiation Protocol: SIP) 2.0 con extensiones
y reglas de uso compatibles con los servicios locales y CLASS disponibles comnmente. Su
denominacin es protocolo de sealizacin de servidor de gestin de llamadas (Call
Management Server Signaling: CMSS).
El SIP es un protocolo de control de la sealizacin entre pares para crear, modificar y

finalizar sesiones (p. ej., conferencias, llamadas telefnicas y distribucin de multimedios) con
uno o ms participantes. Entre dichas sesiones se cuentan conferencias por multimedios en la
Internet, llamadas telefnicas por sta y distribucin de multimedios. Los miembros de una
sesin pueden comunicarse va multidistribucin o va una malla de relaciones unidifusin, o
mediante una combinacin de stas. Las invitaciones SIP usadas para crear sesiones portan
descripciones de la sesin, 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 ubicacin en ese momento del usuario. Los usuarios pueden registrar su
ubicacin vigente. El SIP no est ligado a ningn protocolo determinado de control de
conferencias. Est diseado para ser independiente del protocolo de transporte de capa
inferior, y puede extenderse con capacidades adicionales.
La RFC 3261 abarca la funcionalidad bsica, y hay varios borradores de Internet conexos que
cubren los servicios. El SIP est cobrando un rpido impulso en la industria, a nivel de sistema
y de dispositivo. Se han realizado varias pruebas, demostrando diferentes proveedores el
interfuncionamiento de las llamadas bsicas. 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@anfitrin. La parte usuario es el nombre
del usuario o un nmero telefnico. La parte anfitrin es el nombre de un
dominio o una direccin numrica de red.
Al hacer una llamada SIP, el llamante primero halla el servidor apropiado (A)
y luego enva un pedido SIP (B). La operacin SIP ms comn es la
invitacin (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).
A. Para hallar un servidor SIP

Cuando un cliente desea enviar un pedido, lo enva a un servidor alterno SIP
configurado localmente (como en HTTP), o a la direccin SIP y puerto
correspondiente al Request-URL.
B. Pedido SIP
Una vez que la parte anfitrin se ha resuelto en un servidor SIP, el cliente
enva uno o ms pedidos SIP a ese servidor, y recibe una o ms respuestas
del mismo. Un pedido (y sus retransmisiones), junto con las respuestas
provocadas por dicho pedido, componen una transaccin 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) despus de una INVITE
(invitacin) no forma parte de la transaccin, ya que puede atravesar una
serie diferente de anfitriones.
C. Invitacin SIP
Una invitacin SIP lograda consiste en dos pedidos, INVITE (invitacin)
seguida por ACK. El pedido INVITE solicita a la persona llamada que
participe en una conferencia determinada o que establezca una conversacin
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, enva un
pedido BYE (adis) en vez de un ACK.
D. Localizacin de un usuario
Una persona llamada puede, dentro de un cierto perodo, desplazarse entre
varios sistemas extremos diferentes. Dichas ubicaciones pueden inscribirse
dinmicamente en el servidor SIP. Un servidor de ubicacin puede usar un
protocolo multidistribucin para determinar activamente adnde puede
alcanzarse un usuario. Si un servidor apoderado retransmite un pedido SIP,
dicho servidor debe aadirse al comienzo de la lista de retransmisores
indicada en el encabezamiento. La opcin RegistroRuta hace que las
contestaciones sigan el mismo trayecto de vuelta, asegurando un
funcionamiento correcto a travs de cortafuegos con las caractersticas
debidas y evitando bucles de pedidos.
E. REGISTRO
Un cliente usa el mtodo REGISTER (registro) para registrar o inscribir la
direccin 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 direccin bien conocida "sip.mcast.net"
(224.0.1.75) de todos los servidores SIP de multidistribucin, dependiendo
de lo que se haya ejecutado en la red. Los agentes usuarios SIP pueden or
esa direccin y usarla para estar al tanto de la ubicacin de otros usuarios
locales; sin embargo, no responden al pedido. Un agente usuario PODRA
tambin estar configurado con la direccin de un servidor registro al cual
enva un pedido REGISTER al comenzar la transmisin.
2.5
SIP-T
Se ha encargado al grupo de trabajo de investigacin del proyecto de protocolo de iniciacin de

sesiones (Session Initiation Protocol Project INvestiGation = SIPPING) del IETF
documentar el uso del SIP (protocolo de iniciacin de sesiones) para varias aplicaciones
relativas a la telefona y medios mltiples, y formular los requisitos para la s 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-Telefona), antes conocido como SIP-BCP-T
(SIP Best Current Practice for Telephony interworking = mejores prcticas actuales SIP
para el interfuncionamiento telefnico), es un mecanismo que usa el SIP para facilitar la
interconexin de la RTPC con redes SIP. El SIP-T es ms 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 informacin de
sealizacin, y mensajes SDP (protocolo de descripcin de sesiones) para comunicar
informacin de conectividad de punto extremo y caractersticas del trayecto de medios.
Como en el caso del SIP, el SIP-T negocia directamente una conexin de medios entre
pasarelas. La informacin de punto extremo es cursada en SDP, con lo que pueden describirse
los puntos extremos IP y ATM. En el IETF todava se sigue trabajando en el SIP-T. La RFC
3372 (la mejor prctica actual) proporciona una descripcin 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 tambin ha estado trabajando sobre asuntos relacionados con SIP y
proyectos de recomendacin Q.1912.5 define el interfuncionamiento de seales entre los
protocolos ISUYP y BSICC y SIP con su Protocolo de Descripcin 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
mviles. El Perfil B complementa el Perfil A y ambos tienen por objeto apoyar el trfico que
termina dentro de la red SIP. El Perfil C apoya el enlace del trfico va 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 reunin de la SG 11, el
12 de septiembre de 2003.
10
2.7
H.323
En la Recomendacin H.323 del UIT-T (Sistemas de comunicacin multimedios basados en

paquetes) [4], se trata sobre la manera en que los telfonos PC o los telfonos existentes
pueden conectarse mediante adaptadores a redes de paquetes e interfuncionar con redes
telefnicas pblicas conmutadas a travs de pasarelas. La H.323 forma parte de una serie
mayor de normas que facilitan las videoconferencias a travs de una variedad de redes.
Conocida como H.32X, dicha serie incluye la H.320 para la RDSI de banda estrecha (RDSIBE), La H.321 para la RDSI de banda ancha (RDSI-BA) y la H.324 para la red telefnica
general conmutada (RTGC). En el diagrama siguiente se ilustra la serie H.323 de protocolos.
Audio
Video
G.711
H.261
G.722
H.263
G.723
G.728
G.729
RTP/RTCP
Interfaz usuario control del

sistema
Data
H.225
Control
llamadas
T.120
RAS
UDP
Control
H.245
UDP o TCP
IP
Las capas inferiores varan
Figura 3 Serie de protocolos H.323
Las comunicaciones conforme a la H.323 son una combinacin de seales 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 inscripcin, control de admisin y situacin (RAS), y la sealizacin H.245 son componentes
requeridos; las dems 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
funcin de controlador de acceso de puerta anloga a un gestor de conexiones. La H.323 tiene
su mayor aplicacin en los puntos extremos que poseen potencia procesadora integrada. stos
incluyen los clientes de telefona Internet con PC y las pasarelas VoIP integradas con
centralitas privadas y sistemas esenciales con potencia inherente de procesamiento de
11
llamadas. La H.323 es la norma ms usada entre las soluciones de la primera generacin de

telefona Internet.
La H.323 es un conjunto de normas relativamente maduras. La primera versin fue aprobada
en 1996 por el Grupo de Estudio 16 del UIT-T. La versin 2 se aprob en enero de 1998, y la
3 en septiembre de 1999. El SG 16 aprob la versin 4 en noviembre de 2000, y la versin 5 se
aprob en julio de 2003.
Una de las ventajas de usar un protocolo ms 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 aos 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 adems
corregir incongruencias de la norma. Ms 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 an ms los alcances de la H.323, el IMTC y el grupo de trabajo iNOW! han
estado preparando perfiles de dicha norma para aplicaciones especficas. Las pruebas de
interfuncionamiento de los perfiles de iNOW! Se estn actualmente incluyendo en los eventos
de interfuncionamiento de IMTC.
*****
12
Normas de acceso
3.1
Normas de acceso de abonado de lnea digital (DSL)
Los servicios DSL [10] de diversos tipos (HDSL, SDSL, ADSL y VDSL) pueden
proporcionarse a travs 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 tcnicas ms 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
conexin para la agregacin de lneas BRI de RDSI.
La DSL de lnea nica (SDSL) es la versin de una sola lnea de HDSL. SDSL es algo ms
adecuada para aplicaciones residenciales, ya que slo 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 asimtrica (ADSL) es la tecnologa ms 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 configuracin.
La ADSL funciona en una banda de frecuencia por encima de POTS, dejando al servicio
POTS independiente y sin perturbaciones, aun si fallara el mdem ADSL de un local.
La mayora de los sistemas ADSL todava estn concentrados en oficinas centrales, en donde
se hallan instalados los multiplejadores de acceso de lnea de abonado digital (ADSLAM). El
uso de ADSLAM remotos permitira una mayor penetracin de los sistemas DSL en las zonas
rurales. Pero la longitud de la lnea no es la nica consideracin o impedimento para el
suministro de las ADSL. Otra consideracin es el nmero de pares usados para la ADSL en
un cable determinado debido a los factores de la interferencia. Por ello, los cables de pares
ms grandes no cursan necesariamente un mayor nmero de circuitos DSL. Los lmites
siguientes de distancia son tpicos en circunstancias favorables: 1,5 Mbit/s hasta 18.000 pies y
seis Mbit/s hasta 9.000 pies.
Los requisitos para sistemas ADSL estn especificados en ANSI T1.413-1998 Interfaces de
instalacin de redes y clientes Interfaz metlica de lnea de abonado digital asimtrica
(ADSL). Las Recomendaciones G.992 del UIT-T parecen ser las ms 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 solucin ms 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.
T1 trabaja a 1,544 Mbit/s y requiere repetidores aproximadamente a cada milla.
3.1.1 Foro DSL

El Foro DSL ha producido una serie de informes tcnicos (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
estn especificados en TR-026 y TR-033, respectivamente. Las pruebas
requeridas estn 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
IP/Eth
PPPoE
IP/AAL5
L2TPoA
IP
PPP
PPP
PPPoA
Ethernet
PPPoE
PPP
Ethernet
L2TP
LLC o VC Mux
AAL5
ATM
DSL
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
14
porcin 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 intervencin de la red ATM.
Hay tres pilas que utilizan el PPP (Protocolo Punto a Punto). Una
vez que se establece la conexin de la capa ATM entre las
instalaciones del cliente y la red que provee el servicio, las fases de
configuracin y liberacin a nivel de transmisin 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 Tcnico TR-044 del Foro DSL especifica procedimientos
de auto-configuracin.
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-sig0061.000, julio de 1996).
Notas:
(1)
En las instalaciones del usuario, los mismos mdems pueden
incluir opciones que les permitan abarcar distintas pilas, y an as
producir un IP simple en la interfaz T ejecutada sobre Ethernet. Las
Tarjetas de Interfaz de Red (NIC) tambin pueden insertarse
directamente en la PC. Las soluciones especficas no solamente
varan entre una red y otra, sino tambin en la configuracin de
paquetes de funciones de transmisin y protocolo, entre el mdem, el
encaminador y/o los componentes de la PC.
(2)
En el punto de concentracin se utilizarn los Multiplexores
de Acceso ADSL (ADSLAM o simplemente DSLAM). Tambin en
este caso, la agregacin o conformacin de paquetes de funciones de
transmisin y protocolo puede variar, y ello puede afectar la
naturaleza de las soluciones de interconexin de redes pares
adoptadas por terceros.
15
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 gestin, as como el plano del
usuario de ATM (datos). Incluye referencias al soporte PVC para
ATM, as como su sealizacin y las funciones de operacin y
mantenimiento que soportan ATM corriendo sobre DSL
Nota: segn la informacin 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 aplicacin de SVC con
OoS especficos.
El alcance del informe TR-017 consiste en brindar una especificacin
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 Adaptacin 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) Compresin de Protocolos

Mltiples sobre AAL5, constituye la norma para la compresin de
protocolos sobre AAL5.
Nota: cuando el PPP se ejecuta sobre ATM, se aplica la RFC 2364
(ver seccin 3.1.1.6).
3.1.1.5
PPP (protocolo de punto a punto)
El PPP permite iniciar y cancelar sesiones especficas. Ello significa

que no es necesario que una sesin deba estar permanentemente en
funcionamiento, dado que el PPP proporciona el medio necesario en
materia de seguridad, autenticacin, autorizacin y contabilidad. Ello
resulta de particular utilidad en las conexiones de discado, y en este
caso en los SVC de ATM, pero tambin 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
16
Esto se encuentra especificado en la RFC 2364, (Norma propuesta)

PPP sobre AAL5. Este criterio se aplica cuando la red ATM se usa
como conexin punto a punto y se requieren funciones PPP.
El Foro DSL exige que se aplique por defecto la forma de
compresin nula (multiplaje VC).
3.1.1.7
PPP sobre Ethernet
Se especifica en la RFC 2516, (Informativo) Mtodo para la

Transmisin de PPP sobre Ethernet (PPPoE). PPPoE permite el uso
de propiedades de sesin PPP (ver 3.1.1.5).
3.1.1.8
IP sobre AAL5
El IP puede comprimirse directamente sobre AAL5 sin la

intervencin de Ethernet o PPP, de acuerdo a lo especificado en la
RFC 2684. En este caso no hay demarcacin de sesiones.
3.1.1.9
IP sobre Ethernet
Se trata de una solucin ya establecida, especificada en la RFC 1042.
3.1.1.10
Protocolo de Capa 2 para creacin de
tneles (L2TP)
Definido en la RFC 2661. Este protocolo permite la insercin de un
Concentrador de Acceso L2TP entre el usuario y el servidor de la
red para la ejecucin del PPP.
3.1.1.11
Consideraciones relativas al IP
El protocolo PPP ofrece varias funciones IP de ayuda, segn lo

descrito en 3.1.1.5.
Entre otras consideraciones se incluyen la asignacin/resolucin de
direcciones. El Protocolo de Configuracin Dinmica Central
(DHCP), especificado en la RFC 2131, (Proyecto de norma) se
utiliza habitualmente para la configuracin de direcciones.
En aquellos sistemas que no aplican DHCP, puede resultar necesario
realizar la asignacin y configuracin en forma manual. En algunos
casos, puede requerirse el Protocolo de Resolucin de Direcciones
definido en la RFC 826. La RFC 3396 Codificacin de opciones
largas en el protocolo de configuracin dinmica del anfitrin
(DHCPv4), contiene actualizaciones de la RFC 826.
Nota: el PPP puede transformarse en la opcin de preferencia debido
a su capacidad para el manejo de sesiones.
17
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 travs de
plantas de cable bidireccionales. Construidas sobre una infraestructura de mdem de cable, las
redes PacketCable usarn la tecnologa IP para establecer una gran variedad de servicios
multimedios, tales como telefona 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 lnea considerado sea por cable HFC. Dichas
especificaciones se estn sometiendo a cierto mantenimiento, pero son relativamente estables.
Se prevn ciertos cambios, ya que CableLabs est tratando de obtener la aprobacin por el
UIT-T en su SG-9 de las normas PacketCable.
3.3
Normas de acceso inalmbrico
Para mayor estudio

MOBILEIP
3GPP
3GPP2
*****
18
Normas de gestin
El protocolo simple de gestin de red (Simple Network Management Protocol = SNMP) consiste en
un conjunto de especificaciones compuesto simplemente de comunicaciones por la red que abarca los
principios bsicos de gestin de la red en un mtodo que no impone mayores dificultades a una red
existente.
La ventaja principal de usar el SNMP es que su diseo es simple, por lo que es fcil introducirlo en una
red grande, ya que no toma mucho tiempo establecerlo ni causa grandes dificultades en la red. El
SNMP permite una supervisin y control eficaces de dispositivos heterogneos 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.
*****
Normas de creacin 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 evolucin del IN CS3 (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 aprobacin de consentimiento
(segunda etapa de la aprobacin conforme al trmite tradicional de aprobacin) en mayo de
2001. Las recomendaciones especficamente relacionadas con el IN CS-4 son las siguientes:
Q.1241, Introduccin 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 caractersticas principales identificadas para el IN CS-4 incluyen mejoras en las

capacidades de IN CS-2 e IN CS-3, puntos mltiples de control, interaccin de caractersticas,
interfuncionamiento RDSI-IN (incluso servicios suplementarios), portabilidad de nmeros,
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/caractersticas 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 explcito de la configuracin 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 mnimo para el acceso de la IN desde los
guardianes de puerta H.323/servidor apoderado SIP para ejecutar servicios que no requieran
un manejo explcito de la configuracin de la llamada.
En el proyecto de recomendacin Q.1244 se describe en detalle la arquitectura funcional
distribuida para IN CS-4. El modelo funcional de IN CS-4 es una extensin del modelo IN CS2, que trabaja con los servicios de referencia mencionados ms arriba. Una gran parte de la
Q.1244 trata sobre hiptesis 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 lgicos de servicio distribuido tambin son compatibles mediante plataformas API
normalizadas (p. ej., CORBA, JAIN). Para cada conjunto de hiptesis de interfuncionamiento,
se definen entidades funcionales, se crean modelos funcionales, se enumeran los requisitos, y
se trata sobre las cuestiones que afectan a la ejecucin.
Ms abajo se muestra, como ejemplo de dichas hiptesis, la arquitectura funcional definida
para que el interfuncionamiento IN/IP pueda trabajar con sistemas SIP (protocolo de iniciacin
de sesiones):
Intelligent Network
IP Network
SDF
Signalling
Transport
Gateway
Service/Application
Layer
SCF
Intelligent
SIP Proxy and
Bearer Controller
IF7
IF4
SRF
SSF
CCF
IF5
SSF
IF13
IF10
Call/Bearer
Layer
SIP
SM
CCF
SIP
TE UA
IF12
MG
RTP/RTCP
Media Gateway
Legend:
Signalling
Service Control
Bearer
IF4: INAP
IF10: ISUP User Plane
IF5: ISUP/BICC/SIP
IF13: H.ISUP Use plane
IF7: Extended INAP
IF12: H.248/H.225 (ffs)
Figura 5: Configuracin de control de llamadas SIP que emplea un apoderado SIP inteligente
y una funcin de control de portador
Intelligent Network: Red inteligente
IP Network: Red IP
Service/Application Layer: Capa de servicio/aplicacin
Call/Bearer Layer: Capa de llamada/portador
Signalling Transport Gateway: Pasarela de transporte de sealizacin
Intelligent SIP Proxy and Bearer Controller: Controlador de apoderado SIP inteligente y portador
Signalling: Sealizacin
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 especficas. Una vez definidas esas relaciones genricas, se pueden
definir los servicios especficos 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 iniciacin de sesiones y de descripcin de sesiones (SIP y SDP).
Un servidor PINT acepta pedidos PINT de clientes PINT. Procesa los pedidos y devuelve
respuestas a los clientes. Adems, dicha funcin transfiere datos entre redes IP y la IN, y
asocia las entidades de redes IP con las entidades conexas de la funcin de pasarela. Dicha
21
funcin est situada en el borde del dominio de la red IP, en donde la asociacin de aplicacin
con el cliente/servidor PINT es el tema de la normalizacin del IETF, y la asociacin de
aplicacin con SCF en el dominio IN es el tema de la normalizacin 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, transmisin
de ID del llamante en la Internet, y reenvo de llamadas en la Internet) se ha creado el
siguiente modelo funcional:
Intelligent Network
IP Network
SDF
IF16
IF17
SPIRITS
Proxy
SPIRITS
Client
IF1
IF15
Service/Application
Layer
SPIRITS
Server
PINT
Client
PINT
Server
PINT
Gateway
IF3
SCF
IF2
IF4
SRF
Call/Bearer
Layer
SSF
CCF
Legend:
Management
Signalling
Bearer
Figura 6: Ejemplo de configuracin PINT/SPIRITS

El respaldo a la creacin de aplicaciones por terceros es un componente esencial de las redes
de prxima generacin, y un aspecto importante del IN CS-4. Para trabajar con servidores de
lgica distribuida es necesaria la creacin de la funcin de pasarela de aplicacin de servicio.
Eso permite el interfuncionamiento:
(1) entre la capa de control de servicios en aplicaciones inteligentes y de lgica de servicio
distribuido (esas son funciones de interfaz de programacin de aplicaciones basadas en
API), y
(2) entre la funcin del gestor de llamadas y la lgica de servicio distribuido.
En el caso del IN CS-4, a nivel de aplicacin, los tipos de funcionalidad API podrn incluir las
plataformas CORBA, JAVA, JAIN y otras plataformas tipo API. Adems, esta funcionalidad
podr proporcionar la correspondencia de protocolos/mediacin 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 distribucin de la inteligencia de la red. La
22
funcin de pasarela (Gateway Function = GF) proporciona las funciones de

cortafuegos/seguridad necesarias para la plataforma lgica de servicio distribuido.
Intelligent Network
IP Network
IF9
SA GF
GF
Distributed
Service Logic
IF8
Service/Application
Layer
IF9
SCF
SA GF
SSF
Call/Bearer
Layer
Legend:
CCF
CCF
Management
Signalling
Bearer
Figure 7: Ejecucin SA-GF para trabajar con lgica de servicio distribuido
5.2
Normas de entorno de programabilidad abierta
El entorno de programabilidad abierta (open programmability environment = OPE)

proporciona interfaces de programacin de aplicaciones (API) y los instrumentos de
integracin necesarios para crear y entregar nuevos servicios de aplicaciones. El OPE debe
basarse en normas abiertas, para que pueda extenderse y adaptarse fcilmente segn sea
necesario.
5.2.1 RMI
El mtodo de invocacin remota (Remote Method Invocation = RMI) es un
protocolo Java que permite mtodos con un objeto que exista en otro espacio
de direccin 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
23
= 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 ejecucin 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 inalmbricas y RTPC. Los adaptadores Java permiten que el
OPE interfuncione con una gran variedad de tecnologas de
comunicaciones, tales como sistemas de correo electrnico, 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 comn que no
tuviera necesariamente que formar parte de la red.
*****
24
Normas de seguridad
Para proteger la informacin en una red [11] es necesario tener en cuenta tres componentes crticos.
La autenticacin valida la identidad de la parte o partes que participan en el intercambio de
informacin. La confidencialidad protege contra quienes estn escuchando subrepticiamente o vigilando
tal intercambio. La integridad garantiza que la informacin no haya sido alterada durante la transmisin.
La naturaleza del IP hace que sea difcil verificar de dnde procede la informacin, y fcil para un
atacante aprovecharse de ese punto dbil simulando la direccin IP. La simulacin ocurre cuando un
atacante cambia la direccin de origen en el paquete IP; es muy difcil determinar de dnde viene el
ataque, ya que el atacante sigue cambiando la direccin 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, subdividindola adems en grupos de trabajo. El SG 17 (Redes de datos y
programas informticos de telecomunicaciones) del UIT-T tiene un grupo de estudio de la seguridad
que enfoca tales cuestiones a todos los niveles. Cada organizacin cumple una funcin un tanto
diferente; la funcin 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 diseminacin de informacin
relativa a la seguridad de infraestructuras crticas de redes, y a las maneras de estimular la cooperacin
internacional o regional con respecto a tales infraestructuras.
6.1
Seguridad IP (IPSec)
La IPSec se refiere a una sucesin de protocolos de seguridad del IETF (RFC 2401) (Norma
propuesta) que protegen a las comunicaciones de la Internet por medio del cifrado, la
autenticacin, confidencialidad, integridad de los datos, la proteccin antirrepeticin, y la
proteccin contra el anlisis del flujo de trfico. El IPSec trabaja con mtodos de cifrado
populares en la capa de la redtales como Diffie -Hellman, DES, 3DES, MD5, y SHA1y
puede adaptarse a nuevos algoritmos y normas que aparezcan. La sucesin de protocolos
proporciona los cinco componentes descritos ms abajo.
6.1.1 Asociaciones de seguridad (SAs)

La funcin del sistema SAs es proporcionar un mtodo para que dos partes
intercambien informacin protegida, debiendo ambas partes ponerse de
acuerdo sobre los parmetros de seguridad. Las "SAs" se definen para el
trfico en una direccin solamente, por lo que en el caso del trfico
bidireccional es necesario definir dos "SAs". En el IPSec SA se especifican
los siguientes parmetros:
Modo de autenticacin AH (algoritmo y claves)
Algoritmo de cifrado ESP
Cmo intercambiar claves
Con cunta frecuencia se cambian las claves
Duracin de SA
Direccin de origen SA
6.1.2 Encabezamiento de autenticacin (AH)
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 transmisin, y que proceden de la fuente original de la informacin.
El AH proporciona una integridad de los datos sin conexin, la autenticacin
de los datos, y brinda proteccin contra ataques con repeticin. El AH aade
un bloque de cdigo al paquete de datos que es el resultado de una funcin de
troceo aplicada a todo el paquete. Hay 2 campos importantes en el
encabezamiento AH:
El ndice de parmetro de seguridad (SPI) especifica al dispositivo receptor
qu grupo de protocolos de seguridad est usando el que transmite.
El nmero de secuencia se usa para impedir ataques de repeticin, al impedir
el reprocesamiento mltiple de un paquete.
El campo autenticador en el AH tiene slo 96 bits de longitud, el emisor
ejecuta las funciones de troceo, trunca el nmero resultante para que
quepa en el campo autenticador AH, y lo enva. En el otro extremo, el
receptor ejecuta el mismo algoritmo de troceo (como se especifica en el
SPI), y trunca en consecuencia el nmero resultante. El receptor compara
entonces el nmero calculado con el nmero del AH en el campo
autenticador. Si los nmeros corresponden al nmero del paquete, se acepta
como no modificado. Los dos algoritmos de troceo AH ms 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 autenticacin.
6.1.3 Carga til de proteccin de encapsulado

(Encapsulation Security Payload : ESP)
La ESP, definida en el IETF RFC 2406, cifra la informacin para evitar que
sea observada por una entidad que no sea digna de confianza. La ESP
tambin puede usarse para la autenticacin. El campo de autenticacin ESP
contiene la suma de prueba criptogrfica que se computa sobre la parte
restante de la ESP (menos el campo de autenticacin ESP mismo). La
autenticacin AH difiere de la versin ESP en que esta ltima no protege el
encabezamiento IP que precede al encabezamiento ESP.
La autenticacin ESP puede usarse en vez de la AH para reducir el
procesamiento de paquetes, y efecta una operacin de transformacin en
vez de dos pasos. Tambin impide los ataques de repeticin siguiendo el
nmero de la secuencia de forma muy parecida a la del AH, pero esto
comprometera la validez del encabezamiento. Hay dos tipos de modo tnel en
ambas maneras de cifrado de la informacin del encabezamiento IP original;
la desventaja es que no funciona por NAT (traduccin de direccin de red).
En el modo transporte, el encabezamiento IP original no esta cifrado y puede
funcionar por NAT.
Los esquemas de cifrado ESP ms usados son los siguientes:
26
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
travs del algoritmo DES tres veces - IETF RFC 2405
6.1.4 Gestin de claves

Los dos mtodos de uso ms comn para el intercambio de claves son, el
primero, la codificacin manual, apropiada para un nmero pequeo 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 combinacin 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 autenticacin 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 ms fcil de gestin de claves para un
nmero pequeo de sitios. Ambos extremos del tnel IPSec deben
configurarse manualmente con las claves correspondientes. Pero la
codificacin manual tiene muchas desventajas:
Es necesaria la intervencin manual para actualizar o cambiar las
claves.
Como el cambio manual de claves es por lo general poco frecuente,
el atacante tiene ms tiempo para descifrarlas y descodificar datos.
Hay una probabilidad de error en la configuracin, dado que la misma
clave debe configurarse en los dos extremos distintos del tnel
IPSec.
Si la persona con acceso a las claves se va, o deja de merecer
confianza, es necesario efectuar cambios extensos de configuracin.
Las claves de la configuracin deben protegerse de alguna manera
contra ataques externos.
27
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 bsicas.
Un mtodo para que las partes se pongan de acuerdo sobre los protocolos, algoritmos
y claves que se usarn.
Seguridades desde el principio en cuanto al intercambio de la identidad de las partes.
Gestin 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 informacin sobre claves. El modo principal establece un
canal seguro con proteccin de identidad en la fase uno; el modo dinmico establece un
canal seguro sin proteccin de identidad en la fase uno; y el modo rpido negocia
simplemente SAs de aplicacin general en la fase dos.
6.2.1 Modo principal

El modo principal ofrece un mtodo 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
bsicos, y en el segundo intercambian claves pblicas para un intercambio
Diffie-Hellman y se pasan mutuamente un nonce. El nonce es un
nmero aleatorio empleado por cualquiera de las dos partes para efectos de
la verificacin, o para aadir aleatoriedad a un intercambio criptogrfico de
claves. En los intercambios IKE, una de las partes enva un nonce a la
otra, la cual lo debe firmar digitalmente y devolverlo para confirmar su
identidad.
6.2.2 Modo dinmico

En el modo dinmico, la parte proponente genera un par Diffie -Hellman
al comienzo del intercambio, proponiendo una SA y pasando el valor
pblico 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 informacin necesaria para completar el intercambio, y el resultado final es
que se logra lo mismo que con el modo principal, pero sin proteccin de
identidad para las partes comunicantes.
6.2.3 Modo rpido

El modo rpido se emplea una vez que las dos partes en comunicacin han
establecido una IKE SA usando un modo dinmico o principal. El
objeto bsico del modo rpido es negociar servicios IPSec de aplicacin
general, y la generacin de nuevas claves. El modo rpido trabaja dentro
de un tnel protegido, y es menos complejo porque todos los paquetes estn
cifrados comenzando con una carga til de troceo compuesta por una funcin
28
pseudoaleatoria (Pseudo Random Function: PRF) y la clave de

autenticacin derivada para la IKE SA. La carga til de troceo se usa para
autenticar el resto del paquete. La renovacin de claves puede efectuarse
intercambiando nonces a travs del canal protegido, usndolos para trocear
las nuevas claves, o para pedir un nuevo intercambio Diffie -Hellman a
travs del canal protegido existente (SA) y cambiar la clave por el canal
protegido recin 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)
*****
29
Normas de desempeo y calidad del servicio (QoS)
Una de las tareas ms difciles que enfrenta una red de prxima generacin (NGN) es suministrar un
sistema o tcnica para las transmisiones de voz por IP (Voice over IP = VoIP) que ofrezca un
desempeo 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 telefnica pblica 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 ncleo, el tema principal de esta contribucin 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 ncleo.
La arquitectura de las NGN basada en el IP puede subdividirse en varios dominios. Esa segmentacin
facilita la conceptualizacin de la QoS, la planificacin estratgica y la particin funcional sobre las que
tpicamente se basan las redes. Los dominios siguientes forman parte de una arquitectura IP de la
NGN:
Centralizacin 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;
Agregacin IP:
contiene los dispositivos usados para combinar flujos e interfaces fsicas en un nmero manejable
de interfaces o nodos junto con cualquier particin o lmite (cortafuegos, apoyo de LAN de oficina
central);
Red ncleo IP / interconexin:
contiene los dispositivos usados para cursar trfico IP a travs de la red, junto con la interconexin
de los dominios / redes.
Una solucin NGN IP ofrece bsicamente dos posibilidades, una que contiene abonados "del lado de la
lnea" y otra que contiene clientes "de enlace solamente". Desde el punto de vista de la red IP de
ncleo, la diferencia entre ambas es relativamente pequea. 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 sealar que esta seccin se refiere solamente a los dominios de empresas que ofrecen el mismo
servicio. Ac no se hace referencia al interfuncionamiento de dominios mltiples (abarcando a
diferentes empresas explotadoras) a un nivel IP, por lo que no se consideran los nodos lmite. Es
probable que esos nodos tengan ciertos requisitos especiales en cuanto a la QoS, y la cuestin deber
postergarse para su estudio en el futuro. Adems, esta seccin 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 consideracin de esas
otras soluciones se deja para su estudio futuro.
7.1
QoS en redes basadas en el IP

7.1.1 Obtencin 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, adems de un simple servicio de "voz". En realidad, la
RTPC tradicional proporciona no slo el servicio bsico que todos usan para
la comunicacin vocal elemental con otras personas, sino tambin servicios
auxiliares "en banda" que tpicamente se emplean para comunicaciones no
humanas (p. ej., fax, mdems de acceso por discado, tonos digitales, etc.). La
mayora de dichos servicios "en banda" dependen en sumo grado de las
caractersticas de voz bsicas de la RTPC con multiplaje por distribucin en
el tiempo para obtener una buena calidad del servicio. Tpicamente, esas
caractersticas estn relacionadas con el ancho de banda, la frecuencia, la
propagacin, tcnicas de modulacin y armnicos, entre otras cosas.
Cuando suministran transmisiones de voz a travs de una red de transmisin
IP, las empresas explotadoras pueden usar cdecs 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 fluctuacin 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 nmero de servicios de voz y
datos se cursan juntos. Por lo general, dichos mecanismos suponen el uso de
determinados cdecs de voz de velocidad ms baja junto con tcnicas para
convertir bits/bytes en trenes de informacin ASCII equivalentes, y enviar la
informacin convertida como flujos de datos IP "fuera de banda" o paralelos.
Por ejemplo, las transmisiones de facsmil se convierten en las pasarelas y se
envan como trenes de datos ASCII a travs de una red IP a la pasarela del
extremo lejano, que convierte la informacin nuevamente en tonos de mdem
de fax para su recepcin final por el mdem fax terminal extremo. Se han
propuesto otras tcnicas 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
tcnicas tanto "en banda" como "fuera de banda".
7.1.2 Caractersticas 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),
sealizacin/control (stos pueden incluir H.323, H.248, SIP, SIP-T,
BICC), y
31

operaciones y mantenimiento (OAM) (stos incluyen, entre otros,
SNMP, TFTP, COPS).
Ntese que los flujos de paquetes RTCP no se usan actualmente, pero
debern considerarse en los trabajos evolucionarios futuros.
Cuando se trata con la QoS para el servicio de voz, el inters principal tiende
a ser en el tren de portadores, ya que esto es lo que generalmente afectar a
un abonado (y, ms concretamente, su impresin de la calidad de la voz). Los
dems componentes son igualmente importantes en lo que toca a la QoS
general del servicio. Sin una QoS adecuada para la sealizacin/control, las
llamadas podrn 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
podrn pasar inadvertidas, el mantenimiento preventivo podr no ser posible o
demorarse considerablemente, etc. Todo esto se reflejara por ltimo en la
impresin que el abonado tenga del servicio ofrecido.
Adems, 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 parecera ajustarse muy bien al paradigma de "servicios
diferenciados" enunciado en el marco IP Diff-Serv ((IETF RFC 2475)
(Informativo). Por consiguiente, el mtodo recomendado es entender las
caractersticas esenciales de cada componente y determinar
cuantitativamente los niveles de desempeo que puede suministrar la
estructura IP Diff-Serv correspondiente.
Sin embargo, para complicar esto un tanto, las "expectativas" del usuario final
(ms precisamente, las "expectativas cambiantes" de los usuarios) confunden
las cosas de tal manera que las caractersticas no son necesariamente
estticas o fcilmente 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 ms flexiblemente.
Adems, las reglamentaciones del desempeo cumplen una funcin
importante, en la medida en que expresan las "expectativas pblicas ltimas"
o los requisitos formales de los usuarios. Algunas de las que tienen relacin
con la calidad del servicio vocal, incluidos los aspectos de la sealizacin, se
enumeran ms abajo. Otros objetivos pueden deducirse o han sido
recomendados por varios organismos normalizadores/reguladores.
- Demora del tono para marcar: no ms del 1,5% de las llamadas
(durante la hora cargada) recibirn una demora del tono para marcar de ms
de 3 segundos
- Atenuacin de adaptacin para el eco (lnea): mas de 20 dB
- Prdida: 3,0 dB en la lnea del abonado (nivel de transmisin de 0 dB)
- Ruido: menos de 20 dBrnC (nivel de enlace) y menos de 23 dBrnC
(95% de las lneas)
32
- Demora:
- para comunicaciones nacionales menos de 150 ms en una direccin,
- para comunicaciones internacionales con conexiones por satlite
menos de 400 ms en una direccin,
- para cables submarinos menos de 170 ms en una direccin,
- Demora despus de marcar: nominalmente,
- para llamadas locales menos de 3 s,
- para llamadas interurbanas menos de 5 s,
- para llamadas internacionales menos de 8 s
- Prdida de bloqueo/concordancia: red - 2% durante hora cargada
media
- Disponibilidad del servicio: 99,999%
Nota: Lo que antecede contiene descripciones esquemticas de algunos
objetivos, y se incluyen aqu simplemente como ilustracin. 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 despus de marcar (el tiempo
desde el recibo del ltimo dgito marcado hasta que la parte del extremo
lejano es notificada) provee un lmite de tiempo por el cual los mensajes de
control son procesados y propagados a travs de una red para establecer una
conexin entre partes. De esa forma, hay un lmite implicado a la QoS de
demora que los mensajes de control podrn encontrar al atravesar la red IP.
Ntese que ste no es un valor absoluto totalmente reflejado en la QoS de la
red de transmisin IP, porque tambin 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
caractersticas del trfico portador. El modelo E (Recomendacin G-107 del
UIT-T) se usa para caracterizar las "interpretaciones" de paquetes
portadores de voz. En general, las caractersticas de voz (lo que uno escucha
en el telfono) 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.
- Paquete de datos de voz

- Demora proces. y conmut.
- Cdec
Encam.
ncleo
DSL
CPE
MG
- Carga datos voz

- Demora propag.
- Demora en cola
- Fluctuacin red
- Prdida paquete
Red trans.
ncleo de
paquetes
RTPC
- Carga datos voz

- Demora en cola
- Fluctuacin origen
Velocidad enlace
acceso
Transcodificacin
MG
TO
Encam.
ncleo
EO
RTPC
Memoria desfluct.
33
Figura 8: Deterioros de la voz en una red IP

Por la figura anterior, se aprecia que puede ser muy difcil determinar la
calidad prevista de la voz de una llamada VoIP mediante la inspeccin de
valores concretos. Adems, tambin pueden influir otros factores fuera del
dominio IP. Por ello, el modelo E cumple la funcin analtica de poder
combinar todo lo anterior y producir los resultados esperados de calidad
terica 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 bsica para resolver la cuestin de la QoS en las redes IP de la
prxima generacin 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. Adems de los datos portadores (basados en paquetes de protocolo de
tiempo real [RTP]), hay paquetes de sealizacin/control (p. ej., H.248, SIPT) 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 sera 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). Adems 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 ingeniera de trfico 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 ingeniera del trfico (tewg) de la Internet del IETF ha producido pautas
generales para un sistema IP TE.
7.1.4 Tecnologas para la QoS de redes IP

7.1.4.1
=
Servicios integrados (Integrated Services

Int-Serv)
Proporcionan un mtodo de sealizacin y estados flexibles de la red

para la reserva de recursos de sta. Ofrece la posibilidad de
proporcionar garantas rgidas de QoS mediante la reserva de
recursos. En los Int-Serv, las aplicaciones indican explcitamente sus
necesidades de QoS para un flujo que use el protocolo de
sealizacin de reserva de recursos (RSVP). Cada encaminador a lo
largo de la ruta examina dicho pedido y proporciona un trayecto
fijado para la transaccin (flujo); los encaminadores a lo largo de
este trayecto verifican la solicitud de QoS RSVP en comparacin
con la normativa aplicable y los recursos disponibles de la red. Si el
34
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 transaccin.
Aunque maduros en cuanto a su especificacin, 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,
fijacin de ruta, y orientacin de anfitriones.
7.1.4.2
Servicios diferenciados (Differentiated

Services = Diff-Serv)
El mtodo de los Diff-Serv (IETF RFC 2474 (Norma propuesta)) y

RFC 2475 (Informativo) es ms pragmtico y proporciona slo
garantas flexibles marcando los paquetes o flujos para una prioridad
relativa de reenvo. Los problemas de ajustabilidad a escala se
resuelven evitando cualquier forma de reserva de recursos en la red.
Adems, el mtodo Diff-Serv se basa en la premisa de que la red IP
bsica es encaminada, ya que esta recomendacin 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 mtodo Diff-Serv, la funcionalidad complicada es transferida al
borde de la red, y la funcionalidad simple en el ncleo trabaja con
agregados de trfico. Los dispositivos del borde clasifican y marcan
paquetes en el campo DS del encabezamiento de paquete (basndose
en informacin provista por la gestin de normativas), y los
dispositivos del ncleo reenvan 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 segn puede notar el usuario finallogrando
un desempeo mucho mejor que el obtenido en las mejores redes
existentes.
Los Diff-Serv incluyen tres componentes esenciales: gestin
normativa/red, funcionalidad de dispositivos del borde y funcionalidad
de dispositivos del ncleo. El IETF ha estado trabajando con un
conjunto mnimo de PHB, RFC 3246 (Norma propuesta) y RFC 3247
(Informativo) y mecanismos de lmite relacionados con los dispositivos
del borde y del ncleo. Los aspectos normativos y de gestin de la red
se dejan a los proveedores de redes.
El servidor de normativa es un punto centralizado para la gestin de
normativas de Diff-Serv, que determinan el perfil y clase del trfico
en que se agruparn los flujos de trfico. Las normativas Diff-Serv
35
sern 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
cdigo" 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
facturacin de servicios a los clientes del proveedor, y el control del
trfico de la red. Por ejemplo, los usuarios pueden adquirir
normativas de los proveedores de servicios que garanticen su
prioridad y niveles de servicio segn la hora del da, y controlen los
costos del servicio.
La normativa de QoS puede tambin incluir normas de admisin y
del servicio/gestin 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) podra administrar la
calidad de las normativas del servicio y mantener mapas lgicos para
relacionar normas especficas con encaminadores, pasarelas,
controladores y agentes de gestin 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 comn
(Common Open Policy Service = COPS) normal del IETF (IETF
RFC 2748) (Norma propuesta). El servidor de normativas QoS
probablemente use una interfaz de lnea de mandos ASCII (CLI)
para comunicar la informacin normativa a otros encaminadores.
Con otras normativas (admisin, gestin), por lo general se
recomienda el COPS, pero son posibles otras interfaces.
7.1.4.4
Conmutacin
por
multiprotocolo
(Multi -Protocol
Switching = MPLS)
etiquetas
Label
La MPLS (IETF RFC 3031) (Norma propuesta) es una manera

simple de reenviar informacin a travs de redes instalando y luego
examinando marcas ID cortas de longitud fija, denominadas
etiquetas, en los paquetes. Usando etiquetas para reenviar
informacin, 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 travs de una red MPLS, toda la red parece un
solo saltola MPLS en efecto establece un tnel a travs de la red,
en donde la ruta es preplaneada y atravesada mecnicamente.
36
La MPLS puede usarse para crear trayectos por los cuales

parmetros de la QoS tales como el retardo, la prdida y la
fluctuacin han sido 'puestos a punto' y el trayecto de la MPLS
puede garantizar dichos parmetros QoS exactamente como en un
circuito virtual ATM proyectado para el trfico.
La MPLS puede usarse en conjunto con los Diff-Serv para
proporcionar trayecto proyectados para el trfico para servicios
crticos. 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 garantas, o sea que proporcionan una buena QoS la
mayor parte del tiempo, pero sin ninguna garanta. En cambio, la
MPLS puede usarse para proyectar ciertos trayectos de modo de
obtener garantas explcitas, similares a las que pueden conseguirse
en redes ATM o con cualquier tipo de tecnologa de redes "dirigida a
la conexin".
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 prxima generacin (NGN). Esas normas
nuevas y perfeccionadas son importantes para que las NGN puedan
trabajar con una gran variedad de servicios en evolucin 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 asignacin 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
tcnicas 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 nmero manejable de clases de calidad de servicio nicas y bien definidas.
Estas clases representan los parmetros de calidad de funcionamiento del servicio que quieren
lograrse para diferentes tipos de transacciones de telecomunicaciones [12].
7.2.1 Y.1540
La Recomendacin Y.1540 del UIT-T, Servicio de comunicacin de datos
con Protocolo Internet Parmetros de calidad de funcionamie nto relativos a
la disponibilidad y la transferencia de paquetes de Protocolo Internet define
los parmetros 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
comunicacin de datos con Protocolo Internet (IP) internacional.
37
Los parmetros 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
prestacin de ese servicio. La Y.1540 define los siguientes parmetros 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 aritmtica de los retardos de la transferencia de paquetes IP de
una poblacin de inters.
Variacin 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 prdida de paquetes IP (IPLR):
La tasa de paquetes perdidos del total de los paquetes transmitidos en una
poblacin de inters.
Tasa de paquetes IP espurios (SPR):
El total de paquetes IP espurios observados en ese punto de medicin de
egreso durante un intervalo de tiempo especificado dividido por la duracin
del intervalo de tiempo.
Porcentaje de indisponibilidad del servicio IP (PIU):
El porcentaje del tiempo de servicio IP programado total que se clasifica
como perodo indisponible utilizando la funcin de disponibilidad de servicio
IP. La funcin de disponibilidad de un servicio IP se basa en un umbral de la
caracterstica IPLR.
7.2.2 Y.1541
En la Recomendacin 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 trfico, entre ellas la
telefona de punto a punto, la transferencia de datos, y las conferencias con
multimediosaplicaciones que exigen una calidad de funcionamiento mayor
que otras (es posible que se necesite una clasificacin nueva o revisada para
las aplicaciones futuras). El nmero limitado de clases coincide con la
condicin requerida de una implementacin viable, particularmente con
respecto a la escala de las redes mundiales.
De acuerdo con la recomendacin mencionada, un flujo de paquetes es el
trfico asociado con un flujo con o sin conexin determinado que tiene el
mismo computador principal de origen, computador principal de destino, clase
de servicio e identificacin de sesin. Por lo tanto, un proveedor de servicio
y un usuario final habrn llegado a un acuerdo sobre la capacidad mxima
necesaria para la clase de servicio requerida del flujo de paquetes segn la
defina una de esas seis clases. Los objetivos de QoS son aplicables cuando
38
las velocidades de enlaces de acceso se hallen al nivel T1 o E1, y a niveles

ms altos. A continuacin se presentan unos breves comentarios sobre cada
clase:
Clase 0: Aplicaciones de tiempo real, muy interactivas, sensibles
a variacin de retardo
Retardo medio en el lmite superior es 100 ms, la variacin de retardo es
inferior a 50 ms y la tasa de prdida 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
variacin de retardo
Retardo medio en el lmite superior es 400 ms, la variacin de retardo es
inferior a 50 ms y la tasa de prdida es inferior a 10-3. Ejemplos de
aplicaciones incluyen VoIP, VTC.
Clase 2: Transacciones de datos muy interactivas.
Retardo medio en el lmite superior es 100 ms, la variacin de retardo est sin
especificar y la tasa de prdida es inferior a 10-3. Ejemplos de aplicaciones
incluyen sealizacin.
Clase 3: Transacciones de datos interactivas
Retardo medio en el lmite superior es 400 ms, la variacin de retardo est sin
especificar y la tasa de prdida es inferior a 10-3.
Clase 4: Exclusivo para aplicaciones de bajas prdidas.
Retardo medio en el lmite superior es 1 s, la variacin de retardo est sin
especificar y la tasa de prdida es inferior a 10-3. Ejemplos de aplicaciones
incluyen Transacciones de breve duracin, datos en gran volumen, y video en
flujo.
Clase 5: Sin especificar
Aplicaciones con un retardo medio, variacin de retardo y tasa de prdida sin
especificar. Ejemplos de aplicaciones incluyen las aplicaciones tradicionales
de Redes IP tpicas.
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 parmetros 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
39
40
Normas en evolucin
8.1
Protocolo Internet versin 6 (IPv6)
El Protocolo Internet versin 6 (Ipv6), [6], inici la normalizacin como reemplazo de la actual
versin IP 4 (Ipv4), descrita en la RFC 791, (Norma) debido al agotamiento del nmero
limitado de direcciones Ipv4, ya previsto en la dcada de 1990. Hasta ahora, mediante diversas
tcnicas, 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 prxima generacin 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 ms que el nmero actual
estimado de 2.500 millones de direcciones en uso por varios cientos de millones de usuarios de
la Internet, en la prctica el Ipv4 trabaja con un nmero 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
Latinoamrica) estn prximas a quedarse sin direcciones. Al ndice actual de eficiencia del
60%, las direcciones IP se acabarn en algn 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.
4 bytes (32 bits)
Ver
Clase de trfico
Longitud carga til
Etiqueta flujo
Prx. encabez.
Lmite de salto
Direccin fuente 128 bit
Encabez.
bsico
D i r e c c i n d es t i n o 1 2 8 - bit
Carga til (incluye encabez. optativos y parte de datos)
Figura 9 Formato del encabezamiento del Ipv6

Adems de una gama de direcciones de 128 bits, el conjunto de protocolo TCP-UDP/Ipv6
ofrece otras caractersticas, tales como seguridad obligatoria y movilidad, facilidad de
administracin y funciones de autoconfiguracin, QoS integral, y un encaminamiento ms
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 inalmbricos tendrn el mayor efecto en el IP; la 3G de prxima aparicin
utilizar mucho ms el IP que las generaciones anteriores de radio celular. Hasta ahora, el IP
se ha usado como un aadido a las redes celulares; en un futuro no muy lejano los sistemas
celulares estarn orientados a los datos, ya que la voz ser tratada como otra sesin IP en la
red. La elaboracin de nuevos protocolos de radio tales como el 802.11B (Ethernet
inalmbrica) adems de nuevas interfaces en serie alambradas como la IEEE 1394 (Firewire)
brindar la oportunidad para que los productos de consumo requieran una direccin 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 combinacin de las tcnicas indicadas seguidamente:
DHCP protocolo dinmico de configuracin del anfitrin

(Dynamic Host Configuration Protocol) (RFC 2132) (Proyecto de
norma)
El DHCP permite asignar las direcciones IP de tres maneras:
1.
Atribucin manual: El administrador de al red mantiene un control
completo de las direcciones, asignndolas especficamente a los clientes. El
servidor DHCP usa esa base de datos para asignar una direccin IP, que fue
asignada a una direccin MAC (Media Access Control = control de acceso
a los medios) determinadas.
2.
Atribucin automtica: El servidor DHCP asigna permanentemente
una direccin de un grupo de direcciones. El administrador no interviene en
los detalles de asignar una direccin a un cliente.
3.
Atribucin dinmica: El servidor DHCP asigna una direccin a un
cliente DHCP por un perodo limitado. El servidor reclama automticamente
la direccin cuando expira el alquiler, o cuando el cliente se desconecta.
NAT Traduccin de direcciones de la red (Network Address

Translation) (RFC 2663) (Informativo)
El NAT es un mtodo 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 direccin 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
vlidas (registradas), ese proveedor atribuir direcciones IP privadas al
usuario de la red va DHP para permitir la navegacin 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 traduccin NAT a una direccin IP vlida (registrada), de
modo que el datagrama pueda llegar al destino final.
El NAT tambin ha sido considerado como uno de los mtodos para efectuar
la transicin de Ipv4 a Ipv6 (RFC 2766) (Norma propuesta). Eso puede
hacerse realizando la traduccin de direcciones de la red en un dispositivo del
borde situado entre un dominio Ipv6 y un dominio Ipv4; el dispositivo del
borde correlacionara las direcciones IP de una red de un dominio Ipv4 a una
42
red Ipv6 y viceversa, para tratar de suministrar un encaminamiento

transparente entre ambos.
MPLS Conmutacin 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
decisin independiente de reenvo 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 prximo salto para el paquete, basndose en su
anlisis del encabezamiento del paquete y los resultados de ejecutar el
algoritmo de encaminamiento. Los encabezamientos de paquetes contienen
considerablemente ms informacin que la necesaria simplemente para elegir
el salto siguiente. La eleccin del salto siguiente puede entonces considerarse
la composicin de dos funciones. La primera funcin divide todo el conjunto
de paquetes posibles en un conjunto de clases de equivalencia de reenvo
("Forwarding Equivalence Classes = FEC). La segunda correlaciona
cada FEC a un salto siguiente. En lo que toca a la decisin de reenvo, 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 seguirn el mismo trayecto (o,
si se emplean ciertas clases de encaminamiento multitrayecto, todos seguirn
uno de los trayectos de un conjunto de trayectos relacionado con la FEC).
En el reenvo IP convencional, un encaminador determinado considerar por
lo general que dos paquetes corresponden a la misma FEC si hay algn
prefijo X de la direccin en las tablas de encaminamiento de ese
encaminador, siendo esa X la pareja ms larga para la direccin 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 asignacin de un
paquete determinado a una FEC determinada se hace slo 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 prximo 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 ms 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 reenvo MPLS, una vez que un paquete es asignado a
una FEC, los encaminadores subsiguientes no hacen ms anlisis del
encabezamie nto; las etiquetas impulsan todo el reenvo. Eso ofrece varias
ventajas respecto del reenvo convencional de capas de la red. Mediante el
uso de etiquetas en vez de direcciones IP, se reduce el nmero de
direcciones que pueden usarse.
8.1.2 Seguimiento de ubicaciones
43
El VLR (Visitor Location Register = registro de ubicacin de visitantes) es

una tecnologa esencial usada por la red celular para encaminar llamadas
hacia y desde un usuario mvil. 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 nmero, la
informacin del VLR se usa para encaminar la llamada a la estacin base
ms cercana a la ubicacin del llamante en ese momento, y luego al telfono
mvil. ste es un procedimiento complicado y tan slo mantener la VLR al
da representa una carga considerable para la red celular.
Con el Ipv6, ser posible asignar no slo una direccin IP a cada dispositivo,
sino a la ubicacin potencial de cada dispositivo. Darle a cada ubicacin
potencial su propia direccin simplifica el rastreo y encaminamiento de las
llamadas. Una llamada podra manejarse de la misma manera en que hoy da
se maneja un nmero telefnico, excepto que en vez de usar tal nmero, la
red usara direcciones IP. Una parte de la direccin IP cambiara
constantemente de acuerdo con el paradero del dispositivo mvil.
La industria de la Internet ha podido enfrentar el problema de las ubicaciones
cambiantes utilizando el IP mvil (RFC 2794) (Norma propuesta) como
solucin improvisada del Ipv4. El IP mvil especifica mejoras al protocolo
que permiten el encaminamiento transparente de datagramas IP a nodos
mviles de la Internet. Cada nodo mvil se identifica siempre por su direccin
de base, sea cual fuere su punto de conexin en determinado momento con la
Internet. Mientras se halle fuera de su base, un nodo mvil tambin est
relacionado con una direccin a cargo de, que informa sobre su punto de
conexin vigente a la Internet. El protocolo permite registrar la direccin a
cargo de con un agente de base. ste enva datagramas destinados al nodo
mvil a travs de un tnel a dicha direccin a cargo de, Despus de llegar
al final del tnel, cada datagrama se entrega entonces al nodo mvil.
Pero cuando la solucin improvisada descrita arriba tiene problemas,
especialmente en el caso de aplicaciones que requieran que el usuario o
punto extremo usen una direccin IP vlida, el IP mvil 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 Versin 6. La diferencia ms 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 slo 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 direccin.
8.1.4 Representacin de la direccin 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
44
hexadecimales de las ocho piezas de 16 bits de la direccin, pero ciertos

estilos de direcciones Ipv6 pueden contener largas cadenas de bits cero que
pueden representarse con ::. La tercera opcin es una situacin 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 direccin,
y las d son los valores decimales de las cuatro piezas de 8 bits de orden
inferior de la direccin (representacin Ipv4 normal).
8.1.5 Tipos de direccin Ipv6

Hay cuatro tipos de direccin en el Ipv6: Unicast (unidifusin) (un
identificador para una sola interfaz), Anycast (difusin a cualquier punto) (un
identificador para un conjunto de interfaces; perteneciente tpicamente a
diferentes nodos) y Multicast (multidifusin) (un identificador para un
conjunto de interfaces; perteneciente tpicamente a diferentes nodos).
8.1.6 Direcciones unidifusin Ipv6

Las direcciones unidifusin especifican una sola interfaz Ipv6. Un nodo
puede tener ms de una interfaz de red Ipv6. Las direcciones unidifusin
pueden considerarse un campo de 128 bits que identifica una interfaz
determinada. Sin embargo, los datos del campo de direcciones pueden
resolverse en piezas ms pequeas de informacin, aunque toda esa
informacin al ser reunida tendr como resultado un campo de 128 bits que
identifica la interfaz de un nodo.
Una direccin unidifusin 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 asignacin de direcciones unidifusin en el Ipv6,
incluidas la direccin unidifusin global agregable, la direccin NSAP, la
direccin jerrquica IPX, la direccin local de sitio, la direccin local de
enlace, y la direccin de anfitrin capaz de Ipv4. En el futuro podrn definirse
otros tipos de direccin. Los nodos Ipv6 pueden tener un conocimiento
considerable o ningn conocimiento de la estructura interna de la direccin
Ipv6, dependiendo de la funcin que cumpla el nodo (por ejemplo, anfitrin en
vez de encaminador).
Los anfitriones ms sofisticados podrn saber de otros lmites jerrquicos en
la direccin unidifusin. Aunque un encaminador muy simple puede no
conocer la estructura interna de la direccin unidifusin Ipv6, generalmente
los encaminadores tendrn conocimiento de uno o ms lmites jerrquicos
para el funcionamiento de los protocolos de encaminamiento. Los lmites
conocidos variarn de un encaminador a otro, dependiendo de las posiciones
que el encaminador tenga en la jerarqua del encaminamiento.
8.1.7 Direcciones de difusin a cualquier punto Ipv6
45
La RFC 2373 define una direccin de difusin a cualquier punto

(anycast) como una direccin Ipv6 que es asignada a una o ms interfaces
de la red (tpicamente pertenecientes a diferentes nodos), con la propiedad de
que un paquete enviado a una direccin de difusin a cualquier punto es
encaminada a la interfaz ms cercana que tenga esa direccin, de acuerdo
con la medida de la distancia de los protocolos de encaminamiento. Varios
nodos pueden compartir la misma direccin de difusin a cualquier punto,
como una direccin multidifusin, pero slo uno de esos nodos puede recibir
un datagrama enviado a la direccin de difusin a cualquier punto.
La difusin a cualquier punto es til para suministrar ciertos tipos de
servicios, en particular los que no requieren una relacin determinada entre el
cliente y el servidor. Por ejemplo, un servidor de nombres de dominio y un
servidor de tiempo. El servidor de nombres ms cercano puede suministrar el
mismo servicio que el ms alejado, pero el servidor ms cercano proporciona
una indicacin de hora ms precisa que el ms alejado.
Las direcciones de difusin a cualquier punto se atribuyen del espacio normal
de direcciones de unidifusin Ipv6. Como las direcciones de difusin a
cualquier punto no pueden diferenciarse en su propia forma de una direccin
de unidifusin, los miembros de la direccin de difusin a cualquier punto
deben ser configurados explcitamente para reconocer la direccin como de
difusin a cualquier punto.
En el IETF RFC 2526, (Norma propuesta) Reserved Ipv6 Subnet Anycast
Addresses (Direcciones reservadas de difusin 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 atribucin inicial de dichas direcciones
reservadas de subred. En otro IETF RFC 3068 (Norma propuesta) An
Anycast Prefix for 6to4 Relay Routers (Un prefijo de difusin a cualquier
punto para encaminadores de retransmisin 6 a 4), se introduce una
direccin de difusin a cualquier punto Ipv6 a Ipv4, a fin de simplificar la
configuracin de encaminadores de IPv6 a IPv4. Tambin se define cmo
usarn esta direccin los encaminadores de retransmisin IPv6 a IPv4, cmo
se anunciar el "prefijo de difusin a cualquier punto IPv6 a IPv4"
correspondiente en el IGP y el EGP. La asignacin de direcciones se basa en
el IETF RFC 3056 (norma propuesta), Connection of Ipv6 Domains via
Ipv4 Clouds, en particular la definicin de un encaminador de 6 a 4 y un
encaminador de retransmisin de 6 a 4. Se aade la definicin del prefijo de
difusin a cualquier punto de retransmisin 6 a 4, la direccin de difusin a
cualquier punto de 6 a 4, y la direccin de unidifusin equivalente Ipv4.
8.1.8 Direcciones de multidifusin

Como las direcciones de difusin, las de mutidifusin se usan en redes locales
como la Ethernet, en las que los nodos pueden detectar las transmisiones en
un cable. Pero la multidifusin IP es ms complicada porque todos los
paquetes no son retransmitidos a todos los nodos de la red, envindoselos en
cambio a miembros del grupo de multidifusin. Cuando un nodo se suscribe a
46
una direccin de multidifusin, anuncia que quiere convertirse en miembro, y

cualquier encaminador local har la suscripcin en nombre de ese nodo.
Las direcciones de multidifusin no deben usarse como direcciones de origen
en paquetes Ipv6 ni aparecer en ningn encabezamiento de encaminamiento.
Las direcciones de multidifusin predefinidas aparecen en el IETF RFC 2375,
(Informativo) Ipv6 Multicast Address Assignments (Asignaciones de
direcciones multidifusin Ipv6). El trabajo contina en el IETF RFC 3019,
(Norma propuesta) IP Version 6 Management Information Base for The
Multicast (Base de informacin para la gestin del IP versin 6 para la
multidifusin), y el IETF RFC 2908, The Internet Multicast Address
Allocation Architecture (Arquitectura de atribucin de direcciones
multidifusin de la Internet).
8.2
Para mayor estudio

MALLOC (Multicast-Address Allocation = atribucin de direcciones de multidifusin)
*****
47
Conclusin
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 generacin. Teniendo en cuenta la
importancia de dichas normas y su efecto potencial en la regin, El Grupo de Trabajo sobre
Coordinacin e Normas ha estado estudiando estas normas que continan en evolucin y los siguientes
documentos coordinados de normas (CSD) se han aprobado por el CCP.I.
*****
10
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
Referencias
CCP.I/doc.957/00, Normas en evolucin para la telefona Internet
CCP.I/fdoc.1107/00, Actualizaciones a la contribucin CCP.I/doc.957/00
CCP.I/doc.1112/01, Breve explicacin del SIP
CCP.I/doc.1111/01, Redes de voz y protocolos de prxima generacin
CCP.I/doc.1258/01, IN CS-4 Overview [Resea del IN CS-4]
CCP.I/doc.1262/01, El protocolo etiquetado IPv6
CCP.I-TEL/doc.0202/03, Redes de prxima generacin Resea de las normas (septiembre
2003)
CCP.I/doc.1344/01, Redes de prxima generacin Normas de rendimiento/QoS
CCP.I/doc.1382/01, Direccionamiento IPv6
CCP.1/doc.1472/02, Gua de normas Sistemas de lnea digital asimtrica para abonados
(ADSL)
CCP.I/doc. 1518/02, Security on the Internet (La seguridad en la Internet)
CCP.1/doc. 1477/02, Objetivos de calidad de funcionamiento de las redes de prxima generacin
*****
49
11
Acrnimos y abreviaciones
3GPP
Third Generation Partnership Project (proyecto de asociacin de tercera generacin
ADSL
Asymmetric Digital Subscriber Line (lnea de abonado digital asimtrica)
ADSLAM Asymmetric Digital Subscriber Line Access Multiplexor (multiplejador de acceso de lnea
de abonado digital asimtrica)
API
Application Programming Interface (interfaz de programacin de aplicaciones)
APM
Application Transport Mechanism (mecanismo de transporte de aplicacin)
ATM
Asynchronous Transfer Mode (modo de transferencia asincrnico)
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 emulacin de bucle de banda ancha
BPI+
Base Privacy Interface +
CCS7
Common Channel Signaling #7 (sealizacin por canal comn #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 dinmica)
DSL
Digital Subscriber Line (lnea de abonado digital)
GSTN
General Switched Telephone Network (red telefnica general conmutada)
HDSL
High-bit-rate DSL (DSL de alta velocidad de bits)
HFC
Hybrid Fiber-Coax Cable (configuracin hbrida ptica-cable coaxial)
HTTP
HyperText Transfer Protocol (protocolo de transporte hipertexto)
IETF
Internet Engineering Task Force (Grupo de tareas sobre ingeniera 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 versin 6)
ISUP
ISDN User Part (parte usuario RDSI)
UIT
Unin Internacional de Telecomunicaciones
JAIN
Java API for Integrated Networks (API Java para redes integradas)
Kerberos Un protocolo de autenticacin de red de clave secreta
M3UA
MTP3 User Adaptation (adaptacin de usuario MTP3)
MALLOC Multicast-Address Allocation (atribucin de direcciones de multidifusin)
MANET
Mobile Ad-hoc Networks (redes ad hoc mviles)
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, tambin conocido como
Softswitch, Call Agent o Call Server
MGCP
Media Gateway Control Protocol (protocolo de control de pasarela de medios)
MOBILEIP Mobile IP (IP mvil) (grupo de trabajo del IETF)
MPLS
Multi-Protocol Label Switching (conmutacin por etiquetas multiprotocolo)
MTP
Message Transfer Part (parte [de] transferencia de mensajes, PTM)
NCS
Network-Based Call Signalling (sealizacin de llamadas en red)
NGN
Next Generation Network (red de prxima generacin)
OPE
PKINIT
PSTN
QoS
RMI
RSVP
RTP
RTSP
SAP
SCTP
SDO
SDP
SDSL
SGCP
SGML
SIP
SIP-T
SNMP
SqoS
SSL
VMOA
VoDSL
VoIP
VoMSDN
VoP
XDSL
XML
Open Programmability Environment (entorno de programabilidad abierta)

Public Key Initialization
Public-Switched Telephone Network (red telefnica pblica conmutada, RTPC)
Quality of Service (calidad del servicio)
Remote Method Invocation (mtodo de invocacin remota)
Resource Reservation Setup Protocol (protocolo de reserva de recursos)
Real-time Transport Protocol (protocolo de transporte en tiempo real)
Real-Time Streaming Protocol (protocolo de transmisin de flujo continuo en tiempo real)
Session Announcement Protocol (protocolo de anuncio de sesiones)
Stream Control Transmission Protocol (protocolo de transmisin de control de tren)
Standards Development Organization (organizacin normalizadora)
Session Description Protocol (protocolo de descripcin de sesiones)
Single-line Digital Subscriber Line (lnea nica de abonado digital)
Simple Gateway Control Protocol (protocolo simple de control de pasarela)
Standard Generalized Markup Language (lenguaje de etiquetado generalizado normal)
Session Initiation Protocol (protocolo de iniciacin de sesiones)
SIP-Telephony (telefona SIP)
Simple Network Management Protocol (protocolo simple de gestin de red)
Survivability quality of service (calidad de servicio de capacidad de supervivencia)
Secure Sockets Layer (capa de zcalos seguros)
Voice and Multimedia over ATM (voz y multimedios por ATM)
Voice over DSL (transmisin de la voz por DSL)
Voice over IP (protocolo de transmisin de la voz por la Internet)
Voice over Multi-Service Data Networks (transmisin de voz por redes de datos
multiservicios)
Voice over Packet
Placeholder for any one of a family of Digital Subscriber Line technologies
Extended Markup Language (lenguaje de etiquetado extendido)
*****
51

Redes de Próxima Generación

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Redes de Próxima Generación

Transféré par

Droits d'auteur :

Formats disponibles

ORGANIZACIN DE LOS ESTADOS AMERICANOS

COMISION INTERAMERICANA DE TELECOMUNICACIONES

COMIT CONSULTIVO PERMANENTE I:

Redes de Prxima Generacin Visin general de normas

CARPETA TECNICA-1 (2004)

Por consultas adicionales dirigirse a:

CITEL, Marzo 2004

Redes de Prxima Generacin Visin general de normas

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

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

Redes de Prxima Generacin Visin general de normas

Redes de Prxima Generacin Visin general de normas

Redes de Prxima Generacin Visin general de normas

REDES DE PROXIMA GENERACION

Redes de Prxima Generacin Visin general de normas

La arquitectura y la ejecucin de la red de prxima generacin (NGN) debern partir de interfaces y

Customer Premise Portfolio

Figura 1 Arquitectura de red de prxima generacin

Redes de Prxima Generacin Visin general de normas

Redes de Prxima Generacin Visin general de normas

Redes de Prxima Generacin

Esta seccin est basada en la contribucin de la CITEL CCP.1/doc.957/00 (Normas en evolucin

SIGTRAN (SIGnaling TRANsport = transmisin de sealizacin)

Redes de Prxima Generacin Visin general de normas

Todava se est trabajando en el protocolo Sigtran. La RFC 2719 (informativo) proporciona el

El protocolo de control de llamada de portador independiente (Bearer Independent Call

Redes de Prxima Generacin Visin general de normas

La RFC 3525 Protocolo de Control de Pasarela Versin 1 reemplaza a la RFC 3015. La

Redes de Prxima Generacin Visin general de normas

El SIP es un protocolo de control de la sealizacin entre pares para crear, modificar y

2.4.1 Funcionamiento del SIP

Redes de Prxima Generacin Visin general de normas

A. Para hallar un servidor SIP

Redes de Prxima Generacin Visin general de normas

Se ha encargado al grupo de trabajo de investigacin del proyecto de protocolo de iniciacin de

Redes de Prxima Generacin Visin general de normas

En la Recomendacin H.323 del UIT-T (Sistemas de comunicacin multimedios basados en

Interfaz usuario control del

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.

Redes de Prxima Generacin Visin general de normas

llamadas. La H.323 es la norma ms usada entre las soluciones de la primera generacin de

Redes de Prxima Generacin

Normas de acceso de abonado de lnea digital (DSL)

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

Redes de Prxima Generacin Visin general de normas

3.1.1 Foro DSL

En la TR-043, Protocolos en la interfaz U para el acceso a redes de

Redes de Prxima Generacin Visin general de normas

Redes de Prxima Generacin Visin general de normas

ATM sobre ADSL

Las recomendaciones relativas a las capacidades de ATM se

AAL5 sobre ATM

La Capa 5 de Adaptacin ATM (AAL5) se define en I.363.5, Tipo 5

Protocolo x sobre AAL5

La RFC 2684, (Norma Propuesta) Compresin de Protocolos

PPP (protocolo de punto a punto)

El PPP permite iniciar y cancelar sesiones especficas. Ello significa

PPP sobre ALL5

Redes de Prxima Generacin Visin general de normas