Concepto de Integración de Servicios

Grupo de Ingeniería TelemáticaDepartamento de Ingeniería de Comunicaciones

Universidad de Cantabria

Arquitecturas de Red para la Integración de Servicios

Alberto Eloy García Gutiérrezalberto.garcia@unican.es

Master en Ingeniería de Telecomunicación

Contenidos

EvoluciónEstructuraConvergenciaIntegración

… tecnología… unificada… de redes… de servicios

La EVOLUCION de la “RED”

DesdeDatosUnicastConexiones dedicadasFijoServicios aisladosRouters (SW)Todo vale

HastaMultimedia-multiservicioMulticastADSL, HFC, WLL, Wi-Fi, FTTx, PLC,satellites

MóvilServicios unificados(integrados)

Routers (HW only)Ingeniería de Tráfico

Evolución en las tecnologías

Tecnologías de Cobre

xDSLVectoring <= 100MbpsBondingPhantoming<=200Mbps

------------------------------------Combinado <= 300 Mbps

- G.fast <= 500 Mbps- (1 Gbps - FTTB)

Tecnologías de Cable

DOCSIS 3.0 HFCDown: 400 Mbps (8 canales)Upload: 120 Mbps (4 canales)

PacketCableServicios multimediaHFC + PSTN + TCP/IPSIP + IMS

Tecnologías ópticas

FTTXHome, Building, Curb, Node

PONBroadband, Gigabit-capable,Ethernet

pWDM / WDM-PONEl primer TODO-OPTICO

Tema I: Concepto de Integración de Servicios - 7

(FTTN)

https://www.adslzone.net/foro/fibra-optica.94/analisis-pon-que-es-olt-onu-ont-odn.461996/

Tecnologías WIFI (“Wireless Fixed”) (1)

Tema I: Concepto de Integración de Servicios - 8

Tecnologías WIFI (“Wireless Fixed”) (2)

Tema I: Concepto de Integración de Servicios - 9

Community WIFI HOTSPOT

Bussiness HOTSPOT Operator HOTSPOT

Tema I: Concepto de Integración de Servicios - 10

Evolución en las tecnologíasTema I: Concepto de Integración de Servicios - 11

Evolución de la estructura de la redTema I: Concepto de Integración de Servicios - 12

Tema I: Concepto de Integración de Servicios - 13

Evolución de la red de acceso

Branch and TreeRing and SpurWLD (Wireless Local Drop)

802.11nTDD LTEWIMAXFDD LTE60 GHz

Tema I: Concepto de Integración de Servicios - 14

Evolución de la red de agregaciónTema I: Concepto de Integración de Servicios - 15

Evolución de la red dorsal

Customer Premises

Carrier’s Network

Customer Premises

O / EE / O

10Gbps

Incrementar la capacidad: WDM

Customer Premises

Carrier’s Network

Customer Premises

O / EO / EE / O

E / O

10Gbps

10Gbps Actualmente : 1 Tbps, ADM

Mañana : decenas de Tbps, soliton, optical packet/burst switching

La única limitación: Add Dropping

WDM

Transparent vs. opaque optical networks

Overlay Networks

WDM

SDH

R2

R3

R1

IP

ATMC1

C2C3

C4

Transporte IP, Opción I: IP over ATM

Customer Premises

R

R

R

IP

ATM

SDH

Transporte IP, Opción II: IP over SONET (SDH)

Customer Premises

R

R

R

IP

SDH

Transporte IP, opción III: MPLS

Customer Premises

LSR

LSR

LSR

MPLS

SDH

oher

LSR LSR

MPLS… Hasta cuándo?

Customer Premises

LSR

LSR

LSR

MPLS

SDH (??)

• Quality of Service

• Evolved VPN

• Traffic Engineering, Protection

• Multicast

G-MPLS

La integración no está tan clara!!!

IP and ATM integrationLabel Swapping Paradigm

MPLS

10Gbps

10Gbps

OCX OCX

10Gbps

10Gbps10Gbps

10Gbps

Increasing Capacity Requirements

DWDM Dync Allocation and Control?

ATMC1

C2C3

C4

R2

R3

R1

IP

ATMC1

C2C3

C4

R2

R3

R1

IP

LSR

SDHSDH

Rapid and Predictable RestorationStandard Time Division Multiplexing

SONET/SDHDynamic Allocation and Control?

¿Y qué ocurre en las redes móviles?

Basadas en configuraciones “Backhaul”:MPLS en AccesoRNC / BNC en agregación – LTE en dorsalLTE en dorsal

Tema I: Concepto de Integración de Servicios - 25

Cell Site Gateway Mobile Aggregation Site Gateway

Backhaul vs. FronthaulTema I: Concepto de Integración de Servicios - 26

2G/3G/4GTema I: Concepto de Integración de Servicios - 27

xGTema I: Concepto de Integración de Servicios - 28

IP based core network

IMT-2000UMTS

WLANcellular

GSM

short rangeconnectivity

WirelinexDSL

otherentities

DABDVB

Return channel:

Download channel

Services and Applications

New air interface

Bluetooth, IR, UWB

Eg Hyperlan

Visto en conjuntoTema I: Concepto de Integración de Servicios - 29

Movil /Fijo: se diluyen las fronterasTema I: Concepto de Integración de Servicios - 30

Todo apunta a una misma direcciónTema I: Concepto de Integración de Servicios - 31

4G /

Multi-Hop

CPSeNode

B UTRAN-Evolution (3GPlus)

WLAN

AP

WiMAX

BS

Legacy CS domain

Unified IP Multimedia Network

Common Data Repository Policy

Directory

User Profiles

Service Delivery Framework

eGSN – enhanced GPRS Support Node

PLMN - Public Land Mobile Network

PSTN - Public Switched Telephony Network

xDSL

PSTN

PLMN

other

PLMN

Internet

Intranet

IMS

Common

Session Control

MGW

eGSN

CS – Circuit Switched

IMS – IP based Multimedia Subsystem

MGW – Media Gateway

AP – Access Point

BS – Base Station

CPS – Control Plane Server

Broadband Wireless Access

GERANUTRAN

Convergencia “Fijo-Móvil”: La visión clásica

Convergencia “Fijo-Móvil”: Pre-4G

Source: Telcordia Technologies

¿Convergencia o Evolución?

Convergencia “Fijo-Móvil”: ¿Resultado?

Modelo “aceptado” de “convergencia”

LD

Voi

ce

Cen

trex

Loc

al V

oice

800

CDMA

WiFi

IP TDM

MPLSIMS

Security

Voicemail

Storage

Presence

Messaging

VoIPHosting Call Center

Network

ServicesFr

ame

ATM

TD

M

DeviceDesk phone/

Terminal

LimitedRegulatedDisparate

NumerousNon-regulatedConverged

MobileSIP Phone

PDAPCLimited

Single functionNumerous Multi-function

Wireless Wired

StovepipedVertical

Low Value

ModularHorizontalHigh-value

Source: Verizon, 2007„Layering“ in telecommunications industries

Convergencia vs. Evolución: El punto de vista de las TIC

WPAN radio

Low-tier services

IP

802.11 Radio

Ethernet

Mobile ServiceMiddleware

IP

WLAN Services

3G/4GRadio

WLANradio

WPAN/low-tier radio

2.5G/3G Radio

GSM/GPRS

2.5G/3G Services

3G AccessNetwork

PSTN IP

WPAN networklayer (e.g. Bluetooth)

Generic Radio Access Network

Radio-specific vertically integrated systems withcomplex intetworking gateways

Security QoS VPN ContentDelivery

B3G Services

Radio Independent modular system architecturefor heterogeneous networks

uniformradio API’s

genericnetwork API

uniform serviceAPI (Internet+)

Unified IP-based mobile network

incl supportfor multihop,mcast, etc,

servicefeaturemodules

Convergencia: La importancia de llamarse IP

El negocio de las TIC converge arrastrado

…como consecuencia… los servicios también convergen!

El usuario final como agente activo

El modelo de roles en las TIC está sufriendo también una evoluciónLos usuarios toman el control de determinados servicios:El mercado USA define al usuario como “PROSUMER”El papel activo delos usuarios modifica a todos los niveles:

Los mecanismos de provisión de servicioLos mecanismos de interconexión

Resultado:

Servicios inteligentes

Servicios asistidos (y selfassisted!)

Servicios semánticos : Interfaces para los “Smart Users”

Consecuencia:

El usuario final exige la convergencia de los servicios

Objetivo:

Integración: Todos a IP / WEB

Beneficios de la Convergencia de Servicios

Se mantienen ocultas la heterogeneidad y la complejidadLa variedad de servicios se globaliza/universaliza

(…y las redes… y los dispositivos)

Se da posibilidades a generar plataformas abiertasSe da soporte a nuevas tecnologías / servicios / mercados

Proliferación de Middleware como alternativa a productos finales cerrados

El ciclo de vida de los servicios se ve alterado en positivo:Creación, puesta en valor y entrega en tiempos mínimosLas web/aplicaciones semánticas facilitan el reuso/compartición de templates

42

Integración de servicios (aplicaciones)

Hacer colaborar entre sí a servicios distribuidos, heterogéneosy posiblemente autónomos.Distribución: los diferentes servicios(aplicaciones) pueden (ysuelen) ejecutarse en máquinas conectadas a través de unared:

LAN/VPNInternetCloud

Autonomía: El sistema de integración no puede esperar que elservicio cambie su forma de actuar para facilitar la integración

Servicios heredadosServicios de otros departamentosServicios de otras empresas (B2B)

HeterogeneidadMáquinas: mainframes, servidores (Sun, IBM, HP, etc.), estaciones detrabajo (Compatibles PC, Apple Macintosh, Sun, IBM, HP, etc.)Sistemas operativos: Solaris, HP-UX, AIX, Linux, MacOS, MSWindows(9x, NT, 2000, XP), etc.Redes: TCP/IP, Novell Netware, lenguajes .NET (Visual C# .NET, VisualBasic .NET, Visual C++ .NET), etc.Aplicaciones en distintos lenguajes: Java, C++, Visual Basic, Visual C++,Delphi, COBOL, etc.Distintas arquitecturas de datos: ficheros, bases de datos de distintosmodelos y fabricantes, sitios web,…Distintos esquemas y formatos de datos. Ejemplo:

App A: DIRECCION=“C\ Alcala, 32, 28080 Madrid”.App B: CALLE=“Calle Alcalá” NUM=“32”, CP=“28080”, CIUDAD=“Madrid”.

Integración de servicios (problemas)

Heterogeneidad: RazonesDecisiones de ingeniería

Diferentes personas eligen diferentes soluciones a un mismo problemaRazones de coste

Se compra el tipo de software/hardware que cumpla los requisitos y tenga unprecio razonable

Aplicaciones antiguasNo es posible desecharlas y rehacerlas con las tecnologías más modernasEs preciso seguir utilizándolas hasta amortizar su coste de desarrollo yobtener beneficio

Integración de servicios (problemas)

Integración de Servicios: Modelo de referencia

Integración de PlataformaComunicación de servicios implementados en diferentes máquinas.Independencia de localización, hardware, SO y lenguaje deprogramación.

Integración de DatosIndependencia de arquitectura de almacenamiento.Independencia de heterogeneidades de esquema/formato.

Integración de Aplicaciones / ProcesosCreación rápida de aplicaciones basadas en aplicaciones existentes.Procesos de negocio modelados como flujos.

Integración B2B¿Qué debemos considerar cuando las aplicaciones que se comunicanpertenecen a organizaciones diferentes?

Seguridad, minimizar acoplamiento, estándares sectoriales,…

Integración de Plataforma

70’s: Comunicación de procesos en redSockets

80’s: Tecnologías de invocación de procedimientos remotosSun RPC (Remote Procedure Call)DCE (Distributed Computing Environment)

90’s: Tecnologías de objetos distribuidosCORBA (Common Object Request Broker Architecture)JAVA RMI (Remote Method Invocation)Microsoft DCOM (Distributed Component Object Model).

00’s: Tecnologías de Servicios WebREST (REpresentional State Transfer)SOAP (Simple Object Access Protocol)

10’s: Tecnologías CLOUD

Ejemplo: Integración de Plataforma

Ejemplo: para determinar la prioridad de una incidencia de uncliente, quiero saber cuánto se le factura al cliente.

Comunicación de procesos en redProcesos en diferentes nodos de la red pueden intercambiar datosutilizando APIs de red (e.g. sockets TCP/IP).No importa topología de la red, plataforma hardware, SO o lenguaje deprogramación.Visión de muy bajo nivel. Utilizar desde un programa serviciosproporcionados por programas que se ejecutan en otro nodo es unproceso costoso y “poco amigable”.

Invocación de procedimientos remotosUn proceso expone una serie de operaciones (procedimientos) quepueden ser invocados desde cualquier programa de la red.Las operaciones y sus parámetros se describen en un fichero dedefinición utilizando un lenguaje especial.Para hacer un programa cliente que invoque a un procedimiento remoto,un compilador especial genera un programa llamado “stub” partiendo delfichero de definición.Con el “stub”, el programador del cliente puede invocar el procedimientoremoto de forma muy parecida a la de un procedimiento local(transparencia).El stub es el que realmente recibe la llamada del cliente, envía unmensaje al servidor y recibe la respuesta del mismo.Visión orientada a programación estructurada (paradigma dominante enlos 80), no a programación OO.Tecnología dominante: SUN RPC

Tecnologías de objetos distribuidosConceptualmente muy similar a RPC.Cada nodo de la red puede exponer una serie de objetos.Permiten la invocación de métodos de objetos remotos.Utiliza el paradigma de programación OO (dominante en los 90 y hasta laactualidad).

JAVA RMI. No proporciona independencia del lenguaje de programación(debe utilizarse JAVA).

Por su facilidad de uso ganó gran aceptación en la comunidad JAVA.Sigue siendo un “building block” importante en la arquitectura JEE (Java PlatformEnterprise Edition).

DCOM. Solución propietaria de Microsoft.Muy utilizado en la comunidad Microsoft.Difícil la interoperabilidad con el “resto del mundo” (JAVA).

Tecnologías de objetos distribuidosCORBA

Estandarizado por el OMG (http://www.omg.org). Consorcio constituido por ungran número de empresas (Iona, Borland, HP, IBM, Oracle, Sun, etc.)Las APIs están estandarizadas -> El desarrollador no depende de unfabricante.Existen múltiples implementaciones de distintos fabricantes para lasplataformas y lenguajes más usuales (C++, Java, Ada, COBOL, C, Smalltalk,etc.).El OMG ha estandarizado numerosos servicios CORBA útiles para cualquieraplicación:

Servicio de nombresSeguridadTransacciones

CORBA ha sido y continúa siendo una buena tecnología paraabordar integraciones complejas en intranets

Eficiente y probadoBuen soporte para seguridad, transacciones, comunicación basada eneventos, etc.

Uso en InternetIIOP: Protocolo para permitir que diferentes sistemas que utilicenCORBA se comuniquen a través de TCP/IP.Existen firewalls que no reconocen IIOP

Hay fabricantes que venden proxies de IIOP, pero no todas las empresas quehan adoptado las tecnologías de Microsoft los tienenExisten túneles IIOP sobre HTTP, pero no son óptimos

Microsoft no fabrica implementaciones de CORBAHay terceros que sí lo hacen (ej.: Iona, Borland, etc.), pero no se puedeesperar que todas las empresas que han adoptado las tecnologías deMicrosoft usen CORBA

Servicios Web (1)La Web proporciona un mecanismo de transporte universal, eficiente,robusto, escalable y probado tanto en aplicaciones inter-organizacióncomo intraorganización.Muchas de las tecnologías comentadas hasta el momento fuerondiseñadas antes de la emergencia de la Web o no fueronespecíficamente diseñadas para aprovecharse de ella.Un Servicio Web expone un conjunto de puntos de acceso(endpoints) que pueden ser invocados por procesos externos.Un endpoint puede ser visto normalmente como una operación querecibe ciertos parámetros y devuelve un resultado, quizás efectuandoalguna acción por el camino.Están basados en tecnologías surgidas alrededor de la Web:

Típicamente, los puntos de acceso son accedidos mediante HTTP y susdirecciones se expresan mediante URLs.Las invocaciones y las respuestas de las mismas se codifican típicamentemediante XML.

Suele distinguirse entre dos estilos de servicios web:Servicios web SOAP.

Añaden un nuevo conjunto de protocolos (SOAP) y lenguajes para permitirRPCs y envío de mensajes entre aplicaciones a través de la web.Estandarizados por el W3C.Suelen utilizar HTTP como mecanismo de transporte, pero noobligatoriamente.

Servicios web REST.No añaden nuevos protocolos ni lenguajes: utilizan solamente HTTP 1.1 yformatos como XML para especificar mensajes.Pueden utilizarse para implementar RPCs, pero también dan soporte a unnuevo estilo arquitectónico para diseñar aplicaciones distribuidas (ServiciosWeb REST “puros” o “RESTful Web Services”.