TR-069

TR-069 (abbreviazione di Technical Report 069) indica un insieme di specifiche tecniche intitolato Customer Premises Equipment (CPE) WAN Management Protocol (CWMP) redatto a cura del DSL Forum (noto attualmente come Broadband Forum) e definisce il protocollo a livello di applicazione per la gestione remota di dispositivi per l'utente finale.

Storia modifica

A seguito del repentino sviluppo del mercato a banda larga, il numero di dispositivi che permettono l'accesso ad internet è cresciuto notevolmente ed è ad oggi costituito da un gran numero di dispositivi eterogenei, come modem, router, gateway, set-top box e telefoni VoIP. Allo stesso tempo, contemporaneamente allo sviluppo delle molteplici funzionalità di tali dispositivi, la configurazione di questi apparati di rete è diventata sempre più complessa, tanto da non essere più praticabile dall'utente finale. Per questa ragione fu inventato il protocollo TR-069.

Caratteristiche modifica

Il TR-069 è un protocollo bidirezionale basato su SOAP/HTTP che fornisce un metodo di comunicazione fra i cosiddetti customer-premises equipment (CPE) e gli Auto Configuration Servers (ACS). Include sistemi di auto configurazione protetti e strumenti per controllo dei CPE compatibili con funzioni raccolte in un framework integrato.

Utilizzando il TR-069, i terminali vengono messi in contatto con gli ACS che forniscono una configurazione per il loro corretto funzionamento nella rete in modo automatizzato. Opzionalmente possono essere fornite altre funzioni e servizi specifici. Attualmente il TR-069 è lo standard di fatto per la configurazione remota di dispositivi nel campo del mercato DSL a banda larga.

Le informazioni tecniche relative a questo protocollo sono redatte e manutenute dal Broadband Forum. Altre attuali e importanti realtà della rete come Home Gateway Initiative (HGI) e il Digital Video Broadcasting (DVB) hanno assunto il protocollo CWMP per il controllo e la gestione di dispositivi domestici come gateway HGI e terminali di tipo DVB IPTV e set-top box in genere.

Funzioni supportate modifica

Autoconfigurazione e attivazione dinamica di servizi
- configurazione iniziale del CPE
- configurazione remota del CPE
Gestione del firmware
- gestione della versione
- gestione degli aggiornamenti
Controllo dello stato e delle performance
- analisi dei file di log e messaggi dinamici
- servizi di diagnostica
- connettività, controllo del servizio
- monitoraggio periodico del servizio e delle performance

Nel prossimo futuro il protocollo TR-069 potrà controllare opzioni addizionali rispetto allo standard per l'attivazione di:

interrogazioni sulle funzioni dell'apparato
interrogazione di informazioni, diagnostica, stato, e capacità
allarmi automatici controllati da processi.

Comunicazioni modifica

Trasporto modifica

Il CWMP è un protocollo basato su test. I comandi inviati tra il CPE e ACS sono trasportati su HTTP (o più frequentemente su HTTPS). A questo livello (HTTP) il CPE agisce come client e ACS com server HTTP. Questo essenzialmente significa che il controllo sul flusso della sessione di approvvigionamento (provisioning session) è totalmente a carico del CPE.

Parametri di configurazione modifica

Affiché il CPE possa connettersi al server, esso necessita che alcuni parametri siano configurati in precedenza. Questi parametri includono la URL del server a cui l'apparato vuole collegarsi e l'intervallo di tempo tra il quale l'apparato inizierà la sessione di approvviogionamento (PeriodicInformInterval). Inoltre, se l'autenticazione è necessaria per ragioni di sicurezza, informazioni come utente e password devono essere fornite.

Sessione di approvvigionamento (Provisioning session) modifica

Tutte le comunicazioni e le operazioni vengono eseguite nell'ambito della sessione di fornitura. La sessione è sempre avviata dal dispositivo (CPE) e inizia con la trasmissione di un messaggio Inform (informare) .La sua ricezione e disponibilità del server per la sessione è indicata da un messaggio InformResponse (risposta al comando Inform). Questo conclude la fase di inizializzazione della sessione. L'ordine delle due fasi successive dipende dal valore del flag HoldRequests (Sospendere Richieste). Se il valore è falso (false) la fase di inizializzazione è seguita dalla trasmissione delle richieste del dispositivo, altrimenti vengono trasmessi prima gli ordini ACS. La seguente descrizione presuppone che il valore sia falso.

Nella seconda fase, gli ordini vengono trasmessi dal dispositivo all'ACS. Anche se il protocollo definisce più metodi che possono essere invocati dal dispositivo sull'ACS, ne viene comunemente trovato solo uno - TransferComplete (trasferimento completato) - che viene utilizzato per informare l'ACS del completamento di un trasferimento di file avviato da una richiesta di Download o Upload emessa in precedenza. Questa fase è finalizzata alla trasmissione di una richiesta HTTP-request (richiesta HTTP) vuota all'ACS.

Nella terza fase i ruoli cambiano a livello CWMP. La risposta HTTP (HTTP-response) per la richiesta HTTP vuota del dispositivo conterrà una richiesta CWMP (CWMP-request) dall'ACS. Questo sarà successivamente seguito da una richiesta HTTP contenente una risposta CWMP (CWMP-response) per la precedente richiesta CWMP. Più ordini possono essere trasmessi uno per uno. Questa fase (e l'intera sessione di provisioning) viene terminata da una risposta HTTP vuota dall'ACS che indica che non sono più in sospeso ordini.

Attivatori di sessione modifica

Esistono determinati eventi che attiveranno la sessione di provisioning. Questi includono:

Bootstrap: quando il dispositivo contatta il server per la prima volta, l'URL del server è cambiato o le impostazioni del dispositivo sono state ripristinate ai valori predefiniti;
Periodico: il dispositivo è programmato per eseguire una sessione periodica, secondo le impostazioni PeriodicInformInterval;
Richiesta di connessione: il dispositivo risponde alla richiesta di connessione del server;
Modifica valore – il valore per un parametro che viene monitorato è cambiato;
Boot: dopo che il dispositivo è stato ripristinato o ha perso l'alimentazione ed è stato ricollegato;
Pianificato: quando il server ha precedentemente indicato al dispositivo di inizializzare una sessione aggiuntiva con il comando ScheduleInform;
Trasferimento completato – dopo che il dispositivo ha terminato il download o il caricamento dei file richiesti dal server;
Diagnostica completata: una volta che il dispositivo ha terminato una diagnostica.

Sicurezza e autenticazione modifica

Poiché i dati vitali (come nomi utente e password) possono essere trasmessi al CPE tramite CWMP, è essenziale fornire un canale di trasporto sicuro e autenticare sempre il CPE rispetto all'ACS. Il trasporto sicuro e l'autenticazione dell'identità ACS possono essere facilmente forniti mediante l'utilizzo di HTTPS e la verifica del certificato ACS. L'autenticazione del CPE è più problematica. L'identità del dispositivo viene verificata in base a un segreto condiviso (password) a livello HTTP. Le password possono essere negoziate tra le parti (CPE-ACS) ad ogni sessione di provisioning. Quando il dispositivo contatta l'ACS per la prima volta (o dopo un ripristino di fabbrica) vengono utilizzate le password predefinite. Nelle reti di grandi dimensioni è responsabilità dell'approvvigionamento garantire che ogni dispositivo utilizzi credenziali univoche, il loro elenco viene consegnato con i dispositivi stessi e protetto.

Richiesta di connessione modifica

L'inizializzazione e il controllo del flusso della sessione di provisioning è di esclusiva responsabilità del dispositivo, ma è possibile che l'ACS richieda l'avvio di una sessione dal dispositivo. Anche il meccanismo di richiesta di connessione è basato su HTTP. In questo caso il dispositivo (CPE) assume il ruolo di server HTTP. L'ACS richiede una connessione al dispositivo visitando un URL negoziato ed eseguendo l'autenticazione HTTP. Viene inoltre negoziato in anticipo un segreto condiviso con il dispositivo (ad es. sessione di provisioning precedente) per impedire l'utilizzo di CPE per attacchi DDoS sul server di provisioning (ACS). Dopo l'invio della conferma da parte del dispositivo, la sessione di provisioning deve essere avviata il prima possibile e non oltre 30 secondi dopo la trasmissione della conferma.

Richiesta di connessione su NAT modifica

Il protocollo CWMP definisce anche un meccanismo per raggiungere i dispositivi che sono collegati dietro NAT (es. IP-Phones, Set-top box). Questo meccanismo, basato su STUN e UDP NAT traversal, è definito nel documento TR-069 Annex G (ex TR-111).

L'emendamento 5 del protocollo introduce un metodo alternativo di esecuzione della richiesta di connessione tramite NAT basato su XMPP (vedere l'allegato K dell'emendamento 5 TR-069 per i dettagli).

Modello dei dati modifica

La maggior parte della configurazione e della diagnostica viene eseguita attraverso l'impostazione e il recupero del valore dei parametri del dispositivo. Questi sono organizzati in una struttura gerarchica ben definita che è più o meno comune a tutti i modelli di dispositivi e produttori. Broadband Forum pubblica i suoi standard per i modelli di dati in due formati: file XML contenenti una specifica dettagliata di ciascun modello di dati successivo e tutte le modifiche tra le loro versioni e file PDF contenenti dettagli leggibili dall'uomo. SGli standard e le estensioni supportati devono essere chiaramente contrassegnati nel modello dati del dispositivo. Questo dovrebbe essere nel campo Device.DeviceSummary o InternetGatewayDevice.DeviceSummary che è richiesto a partire da Device:1.0 e InternetGatewayDevice:1.1 rispettivamente. Se il campo non viene trovato, InternetGatewayDevice:1.0 è implicito. A partire da Device:1.4 e InternetGatewayDevice:1.6 è stato introdotto un nuovo campo ( '<RO>'.SupportedDatamodel) per le specifiche standard supportate.

Il modello è sempre radicato nella singola chiave denominata Device o InternetGatewayDevice a seconda della scelta del produttore. Ad ogni livello della struttura sono consentiti oggetti e parametri (o istanze di array). Le chiavi sono costruite concatenando i nomi degli oggetti e dei parametri usando '.'(punto) come separatore, ad es. InternetGatewayDevice.Time.NTPServer1 .

Ciascuno dei parametri può essere contrassegnato come scrivibile o non scrivibile. Questo viene segnalato dal dispositivo nel messaggio GetParameterNamesResponse. Il dispositivo non deve consentire la modifica di alcun parametro contrassegnato come di sola lettura. Le specifiche e le estensioni del modello di dati contrassegnano chiaramente lo stato richiesto della maggior parte dei parametri.

Anche i valori applicabili al parametro, il loro tipo e significato sono definiti con precisione dallo standard.

Oggetti multiistanza modifica

Alcune parti del modello dati richiedono l'esistenza di più copie del sottoalbero. I migliori esempi sono quelli che descrivono le tabelle, ad es. Tabella di inoltro delle porte (Port Forwarding Table). Un oggetto che rappresenta un array avrà solo numeri di istanza o nomi di alias come figli.

Un oggetto a più istanze può essere scrivibile o di sola lettura, a seconda di ciò che rappresenta. Gli oggetti scrivibili consentono la creazione dinamica e la rimozione dei loro figli. Ad esempio, se un oggetto rappresenta quattro porte fisiche su uno switch Ethernet, non dovrebbe essere possibile aggiungerle o rimuoverle dal modello di dati. Se un'istanza viene aggiunta a un oggetto, viene assegnato un identificatore. Dopo essere stati assegnati, gli identificatori non possono cambiare durante il ciclo di vita del dispositivo, tranne che per il ripristino delle impostazioni di fabbrica.

Problemi comuni modifica

Anche se l'elenco dei parametri e dei relativi attributi è ben definito, la maggior parte dei dispositivi non segue completamente gli standard. I problemi più comuni includono parametri mancanti, identificatori di istanza omessi (per oggetti a più istanze in cui è presente solo un'istanza), livello di accesso ai parametri errato e utilizzo corretto solo di valori validi definiti. Ad esempio, per il campo che indica lo standard supportato dei protocolli WLAN, il valore 'g' dovrebbe indicare il supporto di 802.11b e 802.11g e il supporto 'g-only' solo di 802.11g. Anche se valori come "bg" o "b/g" non sono legali secondo gli standard del Broadband Forum, si trovano molto comunemente nei modelli di dati del dispositivo.