06 Service Discovery e Gestione di Sessione in Sistemi...

Discovery e Sessione - Sistemi Mobili M 1 1

Sistemi Mobili M

Alma Mater Studiorum - Università di Bologna

CdS Laurea Magistrale in Ingegneria Informatica

II Ciclo - A.A. 2014/2015

Corso di Sistemi Mobili M (8 cfu)

06 – Service Discovery e Gestione di

Sessione in Sistemi Convergenti

Docente: Paolo Bellavista

[email protected]

http://lia.disi.unibo.it/Courses/sm1415-info/

http://lia.disi.unibo.it/Staff/PaoloBellavista/

mailto:[email protected]

Discovery e Sessione - Sistemi Mobili M

Agenda per le Prossime Settimane

Chairiti alcuni modelli e pattern di soluzione, vediamo ora come sono applicati in alcuni meccanismi/strumenti di supporto, che possono rientrare nella definizione data di mobile middleware

Alcune funzionalità fondamentali di mobile middleware:

Sincronizzazione dati (SyncML, …)

Resource/service discovery (Jini, SLP, UPnP, …)

Gestione sessione (SIP, IMS, …)

Mobile messaging

Gestione eventi (OMG DDS, …)

E funzionalità avanzate come:

Sharing di info/risorse in smart spaces, reti spontanee, …

Context aggregation&fusion da Cyber Physical Systems di ampia scala, FuturICT, …

2


Resource/Service Discovery

Talora si utilizza il termine in modo ampio per indicare sia discovery

vero e proprio, ma anche operazioni di configurazione necessarie

per accesso risorse/servizi e stesse richieste di risorse/servizi

Funzionalità di supporto chiave per ogni sistema aperto,

dinamico, debolmente accoppiato e peer-to-peer:

Configurazione automatica

Discovery risorse/servizi

Resource/service delivery

Principali standard e soluzioni per discovery:

Jini, Service Location Protocol (SLP), Universal Plug and Play

(UPnP), …

3


Funzionalità Chiave

Auto-configurazione Dispositivi devono configurare se stessi per partecipare a

offerta/richiesta di risorse e servizi Ad es., ma non solo, configurazione di indirizzo IP temporaneo nella

località corrente

Scoperta risorse/servizi disponibili

Chi offre risorse/servizi (chiameremo service provider) deve essere in grado di farne advertising Di quali risorse/servizi

Di come effettuare invocazioni, usando quali interfacce

Cliente deve essere in grado di trovare risorse/servizi (locali)

Accesso a risorse/servizi

Cliente deve essere in grado di comunicare con service provider, invocare servizi, passare parametri e ricevere eventuali risposte

Anche supporto ad autenticazione e autorizzazione

Importanza di avere buona affidabilità e scalabilità

4


Jini (Sun Microsystem, ora Apache River)

Service Broker

Service Provider

Java Service

Object

Service

Attributes

Client

Java Service

Proxy Object

Java Service

Proxy Object

Service

Attributes

Registration

Lookup

5


Soluzione di discovery principe in ambiente Java

Service provider scopre dinamicamente uno o più

servizi di lookup (broker)

Service provider registra oggetto risorsa/servizio

(modellato come oggetto Java) e suoi attributi al servizio

lookup (broker)

Un cliente richiede un servizio, tipicamente

specificando attributi del servizio cercato; una istanza

dell’oggetto risorsa/servizio si muove verso cliente a runtime

Servizio di lookup può notificare clienti registrati

quando vi è cambio di stato per loro risorse/servizi

Cliente interagisce con risorsa/servizio scoperto

tramite oggetto Java ottenuto

Jini (Sun Microsystem)

6


Gestione Affidabilità in Jini

Possibili fallimenti (e non solo, vedi versioning) sono gestiti tramite meccanismo di lease Jini assegna risorse a clienti tramite lease con durata

temporale prefissata (minore o uguale a richiesta cliente)

Terminato il periodo di lease, cliente deve rinnovare lease per continuare accesso a risorsa/servizio

Registrazione a lookup fatta con lease: quindi tutti lease scadono, per tutti gli utenti, in caso di caduta di service provider

Jini supporta ridondanza a livello di infrastruttura e resistenza contro guasti Si può fare deployment di diversi servizi lookup in una rete

Service provider possono registrare loro oggetti proxy di servizio in servizi di lookup plurimi

Anche uso all’interno di transazioni e rollback automatico alla scadenza del lease

7


Scalabilità in Jini

Scalabilità realizzata tramite organizzazione dinamica in

“comunità” o “federazioni”

Gruppi di servizi Jini possono formare una comunità, tipicamente

quella dei servizi locali e registrati almeno in un lookup service

locale

Comunità differenti possono essere collegate insieme in

gruppi ancora più larghi tramite lookup service

Una comunità si registra presso altre comunità registrandovi

il proprio lookup service

Come gestire l’innestamento di lookup service?

8


Service Proxy Object

di Jini è Dinamico

Se paragonato a soluzioni più tradizionali per l’accesso a risorse/servizi, trovati dinamicamente, tramite stub/skeleton intermedi:

Jini supera limitazioni della creazione di stub/skeleton a compile-time tipica delle RPC

Consente a cliente di ottenere stub dal service provider a tempo di esecuzione

Stub RPC analogo a oggetto service proxy che server Jini carica dinamicamente nel servizio di lookup

Oggetto proxy service consente ai clienti di utilizzare il servizio scoperto senza conoscerne i dettagli

9


Service Location Protocol (SLP)

SLP è approccio

standard di Internet

Engineering Task

Force (IETF) per

discovery di

risorse/servizi

Idea base: SLP rende

risorse/servizi visibili

mediante registrazione

URL ad agenti

intermedi

User

Agent (UA)

Service

Agent (SA)

Service

Service

Agent (SA)

Service

Directory

Agent (DA)

Application

10

RFC 2608 - Service Location Protocol, Version 2

RFC 2609 - Service Templates and Service Schemes

RFC 2614 - An API for Service Location Protocol

http://www.openslp.org/doc/rfc/rfc2608.txt




SLP basato su Tre Tipologie di Agenti

Agenti come entità capaci di processare messaggi SLP

Service agent

Fa broadcast (usualmente periodico) di advertisement dei suoi

risorse/servizi (associazioni con URL)

Directory agent (opzionale)

Fa caching di advertisement come repository centralizzato

Processa query di discovery ricevute da user/service agent

restituendo URL che fanno match

User agent

Per la scoperta di risorse/servizi da parte cliente

Anche utilizzo efficiente di multicast verso gruppo di service agent

Fa browsing di risorse disponibili e seleziona sulla base URL

restituiti

Standard piuttosto ricco e flessibile, ma implementazioni non troppo

diffuse a livello industriale (OpenSLP, Sun SLP, Xerox printer, …)

11


Universal Plug-and-Play (UPnP)

Standard avviato da Microsoft (inizialmente soluzione interna

proprietaria)

Obiettivo principale: abilitare advertisement, scoperta e

controllo per dispositivi in rete, servizi, consumer

electronics in ambiente ad hoc, tipicamente

domestico (vedi uso corrente con media center, tv, hi-fi, …)

UPnP sfrutta, come tecnologie sottostanti:

UDP o TCP/IP

HTTP

XML/HTML e SOAP

12


Tramite UPnP un dispositivo può:

Fare join dinamico a una rete, ottenendo un indirizzo IP valido localmente

Rendere note le sue capacità, by need e su richiesta

Scoprire presenza e capacità di altri dispositivi

Lasciare dinamicamente una rete

UPnP supporta:

Configurazione automatica di IP

Scoperta di risorse/servizi

Descrizione risorsa/servizio basata su XML

Service control basato su SOAP

Gestione eventi (tramite Generic Eventing and Notification Architecture - GENA)

Presentazione in HTML/XML

13

Universal Plug-and-Play (UPnP)


Indirizzamento IP in UPnP

Scendendo maggiormente nel dettaglio:

UPnP utilizza Auto IP (protocollo di vera e propria auto-

configurazione) per consentire a dispositivi di collegarsi

alla rete senza necessità di amministrazione esplicita

Quando dispositivo si connette a una rete, cerca di

acquisire un indirizzo IP da un server DHCP, se

disponibile

In mancanza di server DHCP, un indirizzo IP è

reclamato automaticam. da un range fisso e

riservato per utilizzo su rete locale

Un indirizzo IP dal range di indirizzi link-local viene selezionato

in modo random (169.254.0.0/16 per IPv4)

Invio di richiesta Address Resolution Protocol (ARP) per

verificare se altri dispositivi hanno già preso l’indirizzo

14


Service Discovery in UPnP

UPnP utilizza il semplice Simple Service Discovery

Protocol (SSDP) come protocollo di discovery basato su

utilizzo di indirizzo multicast dedicato (239.255.255.250

su porta 1900 via UDP)

Device

Control

Point

URL of

Device

Description

File

ssdp:discover Device

Control

Point

ssdp:alive

(URL)

15


Service Discovery in UPnP

Dispositivo (ad es. proiettore UPnP-compliant) effettua

multicast di messaggio di advertisement (ssdp:alive)

per esibire suoi servizi ai control point attivi (ad es.

tablet o home gateway)

Control point può effettuare multicast di messaggio di

ricerca (ssdp:discover)

Ogni dispositivo che riceve messaggio multicast può

rispondere con messaggio unicast di risposta

URL di XML Device Description File viene restituito a

control point

16


Architettura e Stack Protocollare UPnP

17

Uso di

HTTP su

UDP, sia

multicast

(HTTPMU)

che unicast

(HTTPU)


Descrizione Dispositivo e

suoi Servizi in UPnP

UPnP utilizza XML per descrizione di risorse/servizi

(sforzo di standard. per rappresentazione interoperabile)

Messaggio di advertisement contiene un URL relativo

al file di XML device description

File device description descrive le capability del dispositivo di cui

si fa advertisement

Control point può ottenere dinamicamente tramite HTTP file di

device description e processarlo

Ogni dispositivo può fornire più di un servizio/risorsa

Elemento <service> contiene

Tipo di servizio, service ID

URL del servizio per invocazione via SOAP

URL per event subscription per notifiche di eventi

Altro file (Service Description File) per ogni servizio offerto, con

descrizioni più specifiche

18


File Descrizione Dispositivo

per un Proiettore

<?xml version="1.0" ?>

<root xmlns="urn:schemas-upnp-org:device-1-0">

<device>

<deviceType>urn:schemas-upnp-org:device:projector:1</deviceType>

<UDN>uuid:UPnP-Projector</UDN>

<serviceList>

<service>

<serviceType>urn:schemas-upnp-org:service:control:1</serviceType>

<serviceId>urn:upnp-org:serviceId:control</serviceId>

<controlURL>isapictl.dll?control</controlURL>

<eventSubURL>isapictl.dll?control</eventSubURL>

<SCPDURL>projector-scpd.xml</SCPDURL>

</service>

</serviceList>

</device>

</root>

Service Description File

per servizio di “controllo

proiettore”

projector-desc.xml

19

http://ip-address/lab5_projector/projector-desc.xml

http://www.jini.org/

http://www.ietf.org/html.charters/svrloc-charter.html


Service Control in UPnP

Il file XML di service description per un servizio (ad es.

“controllo proiettore”) contiene:

Action list con operazioni invocabili sul servizio

Tabella di stato del servizio con insieme variabili di stato (e

loro tipi di dato)

Per invocare un dato service control di cui un dispositivo

ha fatto advertisement, control point invia un

messaggio SOAP all’indirizzo URL specificato per il

servizio

Control point può avere accesso e aggiornare variabili di

stato in tabella

Servizio esegue l’azione di controllo richiesta e

restituisce valore di ritorno tramite messaggio SOAP

20


File Descrizione Servizio per

Servizio Controllo Proiettore

<?xml version="1.0" ?>

<scpd xmlns="urn:schemas-upnp-org:service-1-0">

<actionList>

<action>

<name>SetPower</name>

<argumentList>

<argument>

<name>Power</name>

<relatedStateVariable>Power</relatedStateVariable>

<direction>in</direction>

</argument>

</argumentList>

</action>

… Other actions …

</actionList>

projector-scpd.xml

21

http://www.upnp.org/

http://www.upnp.org/resources/documents.asp

http://www.intel.com/technology/UPnP/






…

<serviceStateTable>

<stateVariable sendEvents="yes">

<name>Power</name>

<dataType>Boolean</dataType>

<defaultValue>0</defaultValue>

</stateVariable>

<stateVariable sendEvents="yes">

<name>File</name>

<dataType>string</dataType>

<defaultValue>default.ppt</defaultValue>

</stateVariable>

… Other state variables …

</serviceStateTable>

</scpd>

22

File Descrizione Servizio per

Servizio Controllo Proiettore


Sottoscrizione a Eventi UPnP

Control point può registrarsi per ricezione di eventi di

notifica provenienti da advertised service all’atto del

cambiamento di variabili di stato

Subscription URL contenuto nel file di device description

Messaggi che implementano evento sono espressi in XML e

formattati secondo lo standard General Event Notification

Architecture (GENA); contengono variabili di stato modifcate che

hanno prodotto evento

Ad es. servizio proiettore può notificare eventi verso control point quando si verifica una delle seguenti situazioni: Page up/down (modifca variabile pageNumber)

Power on/off – accensione/spegnimento

Files – lista di file ppt

File – file ppt corrente in presentazione

UPnP NON consente la sottoscrizione di control point a variabili di stato singole; control point deve determinare dinamicamente quale variabile di stato si è modificata e ha prodotto evento di notifica

23


Presentazione UPnP basata su HTTP

Dispositivo può fare advertisement di URL per

presentazione UI con accesso a servizi via Web:

Scaricamento pagina da URL e visualizzazione su browser

Possibilità per utente di controllare dispositivo

Possibilità di visualizzare stato del dispositivo

Dato l’utilizzo di XML per definizione e scambio di dati, UPnP

potenzialmente abilita utilizzo da parte di un’ampia varietà di

dispositivi limitati: anche trasformazioni automatiche di XML

basate su XSLT

Maggior parte di implementazioni UPnP supportano solo

presentazione basata su HTML, lenta transizione verso XML

24


Architettura UPnP e

Possibilità di Bridging

25


Dettagli su Interazione

Service-Control Point

1. Control point invia richiesta SSDP

search

2. Dispositivo risponde con unicast UDP

NOTIFY che contiene URL del file

XML di descrizione dispositivo

3. Control point richiede documento

descrizione XML via HTTP

4. Web server contenuto nel

dispositivo risponde alla richiesta e

restituisce documento XML

5. Per ricevere automaticam. notifiche di

variazioni presso dispositivo, control

point può registrarsi ai servizi di

interesse via HTTP

Control

point

Device

1. M-SEARCH

(multicast)

2. NOTIFY (UDP

unicast)

3. HTTP GET

description.xml

4. HTTP

Response

5. HTTP

SUBSCRIBE

6. HTTP

Response (SID)

7. HTTP M-

POST (SOAP)

8. HTTP (SOAP

response)

9. Notify (GENA

unicast)

26


6. Dispositivo risponde con ACK per

registrazione e restituisce

Subscription Identifier (SID) unico

7. Control point può comandare

esecuzione di operazioni su

dispositivo, con eventuale modifica

di variabili di stato

URL per inviare richieste di

controllo contenuto nel

documento XML di descrizione

dispositivo

Control point invia richiesta

SOAP su HTTP

Control

point

Device

1. M-SEARCH

(multicast)

2. NOTIFY (UDP

unicast)

3. HTTP GET

description.xml

4. HTTP

Response

5. HTTP

SUBSCRIBE

6. HTTP

Response (SID)

7. HTTP M-

POST (SOAP)

8. HTTP (SOAP

response)

9. Notify (GENA

unicast)

27




8. Dispositivo eventualm. modifica variabili di stato e restituisce risposta in termini di messaggio SOAP

9. Dispositivo può notificare clienti dell’avvenuta modifica di stato, sia derivanti da azioni invocate (come 8) sia causate da cambiamenti impliciti al dispositivo

Dispositivo effettua notifica tramite messaggi unicast NOTIFY su HTTP

Control

point

Device

1. M-SEARCH

(multicast)

2. NOTIFY (UDP

unicast)

3. HTTP GET

description.xml

4. HTTP

Response

5. HTTP

SUBSCRIBE

6. HTTP

Response (SID)

7. HTTP M-

POST (SOAP)

8. HTTP (SOAP

response)

9. Notify (GENA

unicast)

28




Ricapitolando…

Funzionalità Middleware UPnP

Service Discovery

Supporto pensato per ambienti peer-to-peer senza strutturazione

gerarchica

Adaptability

Indirizzi IP allocati dinamicamente

Cambiamenti in info stato resi disponibili tramite notifiche

Nessun supporto (ancora) per service routing/selection basati su

locazione cliente

Supporto trasparente alla comunicazione

Utilizzo di standard Internet

No supporto comunicazioni multi-hop ad hoc

Data Transformation

Possibile trasformazione dati da formato XML standard a formati

proprietari control-point-specific (ad es. proprietari Microsoft)

29


Riferimenti Utili

Addizionali su UPnP

S. Helal, “Standards for Service Discovery and Delivery,” IEEE

Pervasive Computing, Vol. 1, No. 3, pp. 95-100, July-Sept. 2002

Jini Forum, at http://www.jini.org/

Service Location Protocol Working Group (svrloc), at


UPnP Forum, at http://www.upnp.org/

UPnP Forum, “Universal Plug and Play Device Architecture,” at


Intel, “UPnP Technology,” at http://www.intel.com/technology/UPnP/

30







http://www.intel.com/technology/UPnP/

Discovery e Sessione - Sistemi Mobili M 31

Esercitazione su UPnP (1)

Realizzare una piccola applicazione che sfrutti UPnP per scoprire

disponibilità di file multimediali offerti nella località

Cercare di rispettare il più possibile scelta architetturale di comunicazione

multimedia out-of-band (diretta fra end point) rispetto a discovery

Situazione molto vicina a scenario reale in cui UPnP viene utilizzato come

soluzione di configurazione, discovery e accesso a servizi in reti domestiche,

in particolare fra media server, dispositivi per rendering, sorgenti dati,

control point, … (vedi approccio Digital Living Network Alliance – DLNA -

http://www.dlna.org/)

Fare riferimento a documentazione e strumenti di sviluppo,

ampiamente disponibili in rete, come:

Microsoft, “Using the UPnP Control Point API”,

http://msdn.microsoft.com/en-us/library/ms898948.aspx

Cling - Java/Android UPnP library and tools (software stack Java

conforme a UPnP), http://teleal.org/projects/cling/

CyberLink (Java/Android),

http://www.cybergarage.org/twiki/bin/view/Main/CyberLinkForJava

http://www.dlna.org/




http://teleal.org/projects/cling/

http://www.cybergarage.org/twiki/bin/view/Main/CyberLinkForJava


Esercitazione su UPnP (2)

Altri strumenti di sviluppo e strumenti di gestione di riferimento,

ampiamente utilizzati nella comunità di sviluppatori:

Tool di riferimento per testing; offre media server, media renderer,

spy, controller... utili per testare le proprie applicazioni; fornisce

anche stack in C# per creare device e servizi UPnP

http://opentools.homeip.net/dev-tools-for-upnp

Coherence (per sviluppo linguaggio Python)

http://coherence.beebits.net/

BRisa, sia per Python (UPnP 1.0) che per qt (UPnP 1.1),

specificamente pensato per piattaforma Maemo

https://garage.maemo.org/projects/brisa

Come al solito, può essere anche il seme iniziale per una

possibile attività progettuale…








http://coherence.beebits.net/

https://garage.maemo.org/projects/brisa


In Alternativa,

Soluzione basata su Jini

Realizzare una piccola applicazione che sfrutti Jini per scoprire

disponibilità di file multimediali offerti nella località

Cercare di rispettare il più possibile la scelta architetturale di

comunicazione multimediale out-of-band (diretta fra end point) rispetto

alla soluzione di discovery

In questo caso, fare riferimento a risorse di documentazione e

strumenti di sviluppo disponibili su:

Jini home page - http://river.apache.org/

Jini Starter Kit - http://river.apache.org/user-guide-basic-river-

services.html

StartNow project - http://java.net/projects/startnow/

http://river.apache.org/

http://river.apache.org/user-guide-basic-river-services.html









http://java.net/projects/startnow/


Gestione della Sessione

Abbiamo già parlato tante volte della rilevanza della

gestione della sessione

Che cosa si intende per sessione?

Che complessità aggiuntive nella gestione sessione

in mobilità?

Conoscete già tante tecniche, ad es. integrate con tecnologie Web, per

mantenimento della sessione

Anche in ambito mobile, pluralità ampia di tecniche e

tecnologie per rendere stato di sessione disponibile nonostante mobilità di utenti, terminali, risorse e servizi a runtime

Qui ci concentreremo su gestione sessione in sistemi

convergenti 4G basati su IP Multimedia Subsystem

(IMS)

34


Servizi mobili multimediali

offerti da terze parti, come

Internet service provider (ad es. weather forecast, news, …)

Scenari di Service Provisioning

in Reti Convergenti 4G

Servizi mobili

multimediali offerti

da operatori di rete (ad es., VoIP, IPTV, …)

Core IP network per fornire servizi di base:

QoS-enabled data transport, mobilità, AAA, …

Piattaforma per service

provisioning: overlay all-IP

per accesso a servizi e

integrazione (ad es. IMS)

IEEE 802.11

(WiFi) Bluetooth

Cellular 3G e WiMAX

Reti di accesso wireless fortemente differenziate ed eterogenee

35


IP-based

network

Hotspot Wi-Fi Hotspot Wi-Fi

3G cellular

Gestione Reti e Servizi 4G:

Ampio Uso di Approcci Basati su Proxy

IMS

IP Multimedia Subsystem

basato su SIP (Session Initiation Protocol)

Nuovi protocolli e

infrastrutture attive

basate su proxy per

gestione sessione

36


Session Initiation Protocol (SIP)

SIP definisce un framework di segnalazione (signaling) e relativi protocolli e messaggi per configurare ogni possibile tipologia di sessione (lavora al livello OSI di sessione)

Molto aperto e general purpose

Include diverse core facility per gestione mobilità, inizializzazione sessione, sua terminazione, suo trasferimento, …

Non include alcuni servizi base comunque essenziali (ad es. AAA, prenotazione/allocazione risorse, …)

SIP non è un protocollo per trasmissione data/media

Altri protocolli specifici per questo fine: Real-time Transport Protocol (RTP),

RTP Control Protocol (RTCP), Real Time Streaming Protocol (RTSP),…

Esempi di utilizzo “classico” di SIP

Stabilire, configurare e chiudere una chiamata voce su VoIP

Instance messaging e servizio di presenza: SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE)

Trasferimento di sessione e ri-direzione di chiamata

37


SIP: un po’ di Storia e

Obiettivi Principali

Proposto a metà anni ’90 (principal investigator: Henning Schulzrinne,

Columbia University), all’interno di ricerche su Multi-party Multimedia

Session Control

Sottomesso a valutazione Internet Engineering Task Force (IETF) nel 1996,

poi sviluppato da SIP Working Group

Pubblicato nel 1999 come IETF RFC 2543; selezionato da 3GPP come

standard di riferimento nel 2000; versione ulteriore (altre modifiche minori

sono successive) in 2002 - RFC 3261

Obiettivi principali: User location: determinazione di end system da usarsi correntemente

User capability: determinazione di quali media utilizzare e con quali

parametri di configurazione

User availability: determinazione della disponibilità di called party a

partecipare a una chiamata

Call setup: "ringing“ e negoziazione dei parametri di chiamata fra

chiamante e chiamato

Call handling: gestione, inclusi trasferimento e terminazione chiamata

38


SIP in una Slide

SIP core signaling

Protocollo HTTP-like basato su scambio di messaggi testuali e su

utilizzo di identificatori SIP email-like (indirizzi)

Protocollo client/server (request/response)

Messaggi di controllo sessione standardizzati

INVITE, REGISTER, OK, ACK, BYE, …

Framework SIP basato sull’uso di proxy. Entità principali:

User agent: end point che possono operare sia come clienti che come

server per loro utente

User Agent Client: crea nuove richieste SIP

User Agent Server: genera risposte per richieste SIP

Dialog: relazione peer-to-peer fra due user agent, stabilita con

metodi appropriati e specifici

Proxy server: router a livello applicativo

Redirect server: ridirige clienti verso server alternativi

Registrar: tiene traccia degli utenti 39


Formato Messaggi SIP

Formato semplice e basato su testo

Linea iniziale (Request Line o Status Line)

Tipo messaggio (tipo di metodo + URI nei messaggi di richiesta, response code nei messaggi di risposta)

Versione protocollo

Header Campi per trasferire attributi del messaggio

Anche su linee multiple, possono apparire diverse volte e duplicati (principio di robustezza); semplicem. valori multipli separati da virgole

Body (contenuto) Per descrivere la sessione che deve essere avviata

Oppure per contenere dati “opaque”, di testo o binari

40


Proxy Server Proxy Server

User Agent Alice User Agent Bob

5. INVITE

To:sip:[email protected]

6. 100 Trying

11. 180 Ringing

14. 200 OK

16. 180 ACK

Media (RTP)

2. 1

00

Try

ing

12

. 1

80

Rin

gin

g

15

. O

K

13

. 20

0 O

K

10

. 10

0 R

ing

ing

9. IN

VIT

E

sip

:bo

b@

test.c

om

DNS

Server

Location

Service

41

Indirizzamento

SIP

Determinazione

SIP Server

Invio richieste

SIP: SIP

Transactions

Metodi SIP

Risposte SIP

Richieste e

risposte

successive

interne a dialog

Semplice Esempio di Utilizzo di SIP


CALLER PROXY A CALLEE PROXY B

(1) INVITE

(4) ACK

(6) 200 OK

Media session (ad es. basata su RTP, NO SIP)

(2) RINGING

(3) 200 OK

(5) BYE

INVITE sip:[email protected] SIP/2.0

Via: SIP/2.0/UDP pc33.atlanta.com;

branch=z9hG4bK776asdhds

Max-Forwards: 70

To: Bob <sip:[email protected]>

From: Alice <sip:[email protected]>;

tag=1928301774

Call-ID:

[email protected]

CSeq: 314159 INVITE

Contact: <sip:[email protected]>

Content-Type: application/sdp

Content-Length: 142

… SDP description …

Start line: • request line (nelle richieste) • status line (nelle risposte)

Header: molti campi presenti

Message body (opzionale): ad es.

descrizione SDP per negoziare codec o

formati audio/video

42



CALLER PROXY A CALLEE PROXY B

(1) INVITE

(4) ACK

(6) 200 OK

Media session (ad es. basata su RTP, NO SIP)

(2) RINGING

(3) 200 OK

(5) BYE

INVITE sip:[email protected] SIP/2.0

Via: SIP/2.0/UDP pc33.atlanta.com;

branch=z9hG4bK776asdhds

Max-Forwards: 70

To: Bob <sip:[email protected]>

From: Alice <sip:[email protected]>;

tag=1928301774

Call-ID:

[email protected]

CSeq: 314159 INVITE

Contact: <sip:[email protected]>

Content-Type: application/sdp

Content-Length: 142

… SDP description …

Start line: • request line (nelle richieste) • status line (nelle risposte)

Header: molti campi presenti

Message body (opzionale): ad es.

descrizione SDP per negoziare codec o

formati audio/video

43



Step Evolutivo Importante in 3G:

IP Multimedia Subsystem (IMS)

IP Multimedia Subsystem come infrastruttura di supporto

all’erogazione di servizi multimediali su reti convergenti

integrate con differenti caratteristiche (fisse e mobili):

Instant Messaging, condivisione multimedia, Push-To-Talk, gaming,

video conferenza, …

Standard di ampia accettazione e sempre più utilizzato nella

pratica industriale

Utilizzo di SIP come protocollo per setup e configurazione di

sessioni multimediali su reti IP-based

SIP come protocollo di segnalazione per:

Localizzare utente dato suo SIP Universal Resource Identifier (URI), ad es. sip:[email protected]

Configurazione sessione e negoziazione dei suoi parametri

Architettura fortissimamente basata sull’utilizzo di proxy

44


DNS1


in una Sola Slide

Visited network 1

P-CSCF

Home Network 1 Home Network 2

Visited network 2

P-CSCF

AS AS

S-CSCF S-CSCF

I-CSCF I-CSCF

HSS HSS

Mobile

Node

(MN)

Corresp.

Node

(CN)

DATA FLOW

DNS2

45


DNS1


in una Sola Slide

Visited network 1

P-CSCF


Visited network 2

P-CSCF

AS AS

S-CSCF S-CSCF

I-CSCF I-CSCF

HSS HSS

Mobile

Node

(MN)

Corresp.

Node

(CN)

DATA FLOW

Funzionalità di signaling

Funzionalità autenticazione

DNS2

46


DNS1


in una Sola Slide

Visited network 1

P-CSCF


Visited network 2

P-CSCF

AS AS

S-CSCF S-CSCF

I-CSCF I-CSCF

HSS HSS

Mobile

Node

(MN)

Corresp.

Node

(CN)

DATA FLOW Application Server (AS)

Funzioni/entità per estensione

e integrazione dell’usuale

IMS Signaling


DNS2

47

Architettura basata su proxy

Lavora a livello OSI di sessione

Protocolli: SIP (+ Diameter)

Set comune di funzioni per semplific.

deployment servizi multimediali

in ambienti wireless

ad alta eterogenità


DNS1


in una Sola Slide

Visited network 1

P-CSCF


Visited network 2

P-CSCF

AS AS

S-CSCF S-CSCF

I-CSCF I-CSCF

HSS HSS

Mobile

Node

(MN)

Corresp.

Node

(CN)

DATA FLOW

Funzionalità di signaling

Application Server (AS)

Funzioni/entità per estensione

e integrazione dell’usuale

IMS Signaling


DNS2

48

Architettura basata su proxy

Lavora a livello OSI di sessione

Protocolli: SIP (+ Diameter)

Set comune di funzioni per semplific.

deployment servizi multimediali

in ambienti wireless

ad alta eterogenità


Entità Funzionali IMS:

DNS e HSS

Domain Name System (DNS): Servizio di nomi standard Internet

Utilizzato da IMS per risolvere indirizzi IP di tutte tipologie CSCF e AS

può essere utilizzato per load balancing (ma solo a basse frequenze di DNS query)

Home Subscriber Server (HSS): Serve memorizzazione permanente di info sottoscrizione utente,

ad es. dati autenticazione e profili di preferenze (utilizzo di DBMS standard)

Una rete IMS può contenere uno o più HSS

Subscriber Location Function (SLF) per associare utenti a specifici HSS

49



Proxy-CSCF

Proxy-Call Session Control Function (P-CSCF):

Primo punto di contatto nella rete IMS, sia in dominio visitato che in dominio home

Svolge il ruolo di proxy SIP outbound/inbound (tutte le richieste da/verso terminali IMS passano attraverso questo proxy)

Principali funzionalità di P-CSCF:

Forwarding di richieste SIP nella direzione opportuna (verso terminali o rete IMS)

Altre funzionalità, come:

Sicurezza

Generazione info di charging (tariffazione e fatturazione)

Compressione e decompressione di messaggi

50



Interrogating-CSCF

Interrogating-Call Session Control Function (I-CSCF): Proxy SIP ai bordi del dominio amministrativo di home

Ce ne possono essere diversi all’interno della stessa rete per motivi di scalabilità e tolleranza a guasti

Registrati in DNS (anche in pluralità)

Server stateless per ridirezione SIP

Principali funzioni I-CSCF: Interazione con HSS per determinare quale S-CSCF è associato con

cliente (utilizzo di protocollo Diameter)

Ridirezione e routing di richieste SIP incoming verso S-CSCF

può anche essere utilizzato per selezionare dinamicamente S-CSCF meno carico

51



Serving-CSCF

Serving-Call Session Control Function (S-CSCF): Sempre posizionato in dominio home

SIP proxy + SIP registrar con possibilità di occuparsi di controllo della sessione

Principali funzioni di S-CSCF: Binding fra indirizzo IP (terminal location) e indirizzo SIP dell’utente

Interazione con application server per creare servizi a cosiddetto valore aggiunto (funzionalità aggiuntive rispetto a segnalazione SIP di base)

Servizi di traslazione (numero telefono/SIP URI)

Routing messaggi (tramite cosiddetti IMS filtering criteria)

può essere utilizzato per dividere staticamente traffico incoming in dipendenza da identità/profilo utente

52



Application Server

Application Server (AS):

Ospita ed esegue servizi

Comunica utilizzando SIP: costoso

Ogni AS interposto genera 2 messaggi (processed+ACK) per ogni messaggio che lo attraversa

Coordinamento complesso per AS stateful e distribuiti

Differenti tipologie di AS per ambienti, integrazioni e funzionalità differenti

SIP AS: adozione di signaling SIP, servizi possono lavorare solo in ambienti SIP

Altre tipologie: Open Service Architecture – Service Capability Server (OSA/SCS), IP Multimedia Service Switching Function (IM-SSF), …

53


IMS:

Esempio di Routing di una Chiamata

User A

HSS

Interrogating CSCF

Serving CSCF

Invite Da: sip:[email protected] A: sip:[email protected] Call-ID

Location Query

User B

Ok

Multimedia data su canale diretto

Serving CSCF

CSCF = Call State Control Function

HSS = Home Subscriber Service

54


Architettura IMS a Livelli e

Tipologie Differenziate di Servizi

IMS Core

P-CSCF I-CSCF

S-CSCF

IMS Service Framework

HSS

(AAA)

IP Core Network

Access Networks

Media

servers

App.

Servers

Media

server/

gateway

PDF

Service Delivery Platform

Components Compositions Adapters

55

Session-Based Non-Session-Based

Chats

Instant Messaging

Web, HTML

Messaging

SMS and MMS

E-Commerce

Real-T

ime Inte

raction

Non-R

eal-T

ime

SIP (IMS) only

Applications

SIP or Non-SIP

Applications

Non-SIP Only

Applications

Voice

Online

Games

Push-to-

Video

Push-to-talk

Peer-to-Peer

Enterprise

VPN

IP/TV Streaming

Video

Video on Demand

Push email


Scalabilità in IMS:

Che Cosa è Facilmente Possibile

Visited network 1

P-CSCF


Visited network 2

P-CSCF

AS AS

S-CSCF S-CSCF

I-CSCF I-CSCF

HSS HSS

Mobile

Node

(MN)

Corresp.

Node

(CN)

DATA FLOW

DNS1 DNS2

1.

4.

5.

6.

7.

8. 2. MN “in call”

3.

I-CSCF required

on registration

load-balancing

56


Scalabilità in IMS:

Che Cosa è Facilmente Possibile

Visited network 1

P-CSCF


Visited network 2

P-CSCF

AS AS

S-CSCF S-CSCF

I-CSCF I-CSCF

HSS HSS

Mobile

Node

(MN)

Corresp.

Node

(CN)

DATA FLOW

DNS1 DNS2

1.

4.

5.

6.

7.

8. 2. MN “in call”

3.

I-CSCF required

on registration

load-balancing

57


Ottimizzazioni single host (locali) con/senza (o con minimo) coordinamento: Selective message dropping

Compressione messaggi SIP e tecniche per parsing parziale

SIP proxy stateful vs stateless

Load balancing intra-domain: Monitoraggio e operazioni di load balancing dinamico

a livello di infrastruttura

Protocolli di coordinamento AS a livello di servizio (anche protocolli ottimizzati ad-hoc e NON-IMS-compliant)

Ottimizzazioni di protocollo inter-domain: Limitare traffico fra domini differenti

Processamento messaggi service-level ai bordi dei domini IMS

Scalabilità in IMS: Alcune Soluzioni (Parziali)

58

Verso utilizzo di supporto ELASTICO cloud per IMS

06 Service Discovery e Gestione di Sessione in Sistemi...

Documents

Transcript of 06 Service Discovery e Gestione di Sessione in Sistemi...