Resource location and distribution base protocol

RELOAD viene de REsource LOcation and Discovery Base Protocol. Está pendiente de aprobación como RFC. Es un protocolo de señalización Peer-to-Peer. Sirve para proveer un almacenamiento abstracto y un servicio de mensajería entre un conjunto de peers cooperantes que forman la red Overlay.
Permite a los nodos enrutar mensajes a otros nodos y almacenar y recuperar datos en la red Overlay.
Define un modelo de seguridad basado en un servicio de registro que provee identidades únicas. NAT Traversal es un servicio fundamental del protocolo.

Conceptos básicos

Destaca por ofrecer características que son críticas para un protocolo P2P exitoso:

Marco de seguridad: Una red P2P normalmente suele establecerse entre peers que no confían unos con otros. RELOAD proporciona un servidor de inscripción central para cada peer pueda usar para autenticar cada operación. Esto reduce la posibilidad de realizar un ataque.
Modelo de uso: está diseñado para soportar gran variedad de aplicaciones. Permite la definición de nuevos usos de la aplicación, cada uno de ellos puede definir sus propios tipos de datos, con sus reglas de uso.
NAT Traversal: está diseñado para funcionar con la mayoría de los nodos dentro de un NAT o un firewall. Incluye ICE (Interactive Connectivity Establishment) para establecer nuevos RELOAD o conexiones del protocolo de aplicación.
Enrutamiento optimizado: Los peers que participan en la petición de la ruta de la red P2P pidan en nombre de otros peers. Esto implica carga en estos peers. Por ello, la cabecera de reenvío se ha hecho ligera para minimizarla.
Plugable overlay algorithms
Support for Clients: diferencia entre clientes RELOAD y peers RELOAD. Los clientes no almacenan información en favor de otros nodos, pero solo usan el ‘overlay’ para localizar usuarios y recursos así como almacenar información.

Una instancia Overlay consiste en un conjunto de nodos parcialmente conectados. A cada uno de estos nodos se le asigna un ID numérico que determina su posición dentro de la instancia y el conjunto de nodos a los que está conectado.
Al estar parcialmente conectado, no puede hablar con todos los nodos de forma directa. En estos casos, se comunicará primero a un nodos directo para obtener instrucciones de cómo llegar al nodo deseado. Estas conexiones dependerán del algoritmo utilizado.
Además de lo anterior, también es una red de almacenamiento. Los registros se almacenan en direcciones numéricas, los ID de los recursos, que ocupan el mismo espacio que los identificadores de los nodos. Los peers son los encargados de almacenar los datos asociados al conjunto de direcciones determinadas por su ID de nodo.
A parte de los peers también soporta clientes. Los clientes tienen ID de nodo pero no participan en el enrutamiento o el almacenamiento.

Arquitectura

RELOAD es fundamentalmente una red ‘overlay’. Tiene una arquitectura en capas equiparable al modelo de internet en Overlay:

Por tanto, sus capas o componentes son los siguientes:

Capa de uso

Cada aplicación define un conjunto de tipos de datos y comportamientos que describen cómo usar los servicios proporcionados por RELOAD. La comunicación RELOAD entre estos es realizada a través del servicio Message Transport común a todos ellos.
Tiene usos de aplicación tales como el ‘SIP Registration Usage’ [I-D. ietf-p2psip-sip]. El objetivo de esta capa es implementar los usos de la aplicación específica de los servicios Overlay genéricos provistos por RELOAD. Es decir, define como una aplicación específica mapea sus datos en algo que puede ser almacenado en el Overlay, dónde almacenar los datos, cómo ofrecer seguridad a estos y como las aplicaciones pueden recuperar y usar los datos.

Message Transport

Provee un servicio de enrutamiento de mensajes genérico para el Overlay. Es responsable de las transacciones end-to-end. Cada peer es identificado por su localización en el Overlay, con su ID de nodo.
Un componente que sea cliente del ‘Message Transport’ puede realizar dos funciones básicas:

Enviar un mensaje a un peer especificado por el ID del nodo o el peer responsable del ID del recurso.
Recibir mensajes que otros peers enviaron al ID del nodo o al ID del recurso del que el receptor es responsable.

Esta capa no provee control de congestión puesto que está basado en pregunta-respuesta lo que no permite su control. En la realidad, se suele usar un temporizador para la retransmisión end-to-end.

Storage

Permite a los nodos almacenar datos en el Overlay y recuperar datos almacenados por otros nodos o por ellos mismos.
Procesa mensajes relacionados con el almacenamiento y la recuperación de datos.
Se comunica con el ‘Topology plugin’ para manejar la duplicidad y migración de los datos, y con el componente ‘Message Transport’ para enviar y recibir mensajes.
El ID del nodo determina el conjunto de recursos del que es responsable de almacenar. Esto dependerá en parte del algoritmo utilizado.
Cuando el ID de un recurso cambia, esto es notificado al ‘Topology plugin’ y el componente ‘Storage’ se ha de encargar entonces de migrar el recurso a otros peers.

Topology plugin

Sirve para implementar el algoritmo Overlay usado. Tiene dos funciones: la construcción de las instrucciones de envío locales, y la selección de la topología de funcionamiento, como, por ejemplo, la creación de enlaces para enviar mensajes de gestión Overlay.
La razón de ser implementados mediante un plugin es permitir trabajar con distintas topologías.
Se encarga de la tabla de enrutamiento, de crear nuevas conexiones y de proporcionar datos redundantes para evitar la pérdida de información en el caso de que un nodo falle.

Forwarding and Link Management

Proporciona servicios de reenvío de paquetes entre nodos. También maneja el establecimiento de nuevos enlaces entre nodos.
Establece y mantiene conexiones de red según el Topology plugin.
Algo importante a mencionar es que permite configurar conexiones entre peers a través de firewalls y NATs mediante ICE (Interactive Connectivity Establishment).

Overlay Link Layer

Se encarga de transportar directamente el tráfico entre nodos. Para la comunicación salto a salto utiliza TLS [RFC5246] y DTLS [RFC637]. También es posible definir nuevos protocolos para ello.

Además, los nodos pueden comunicarse con una infraestructura central de almacenamiento para conseguir información de configuración, credenciales de autenticación, y el conjunto de nodos inicial con los que comunicarse para unirse al Overlay.

Seguridad

La seguridad está implementada mediante la posesión por parte de cada nodo de una o más claves públicas certificadas.
Estos certificados son proporcionados por un servidor central que también asigna el ID de los nodos. Si la red fuese pequeña, se podrían utilizar certificados auto-firmados.
Las credenciales son utilizadas para proporcionar seguridad a la comunicación en tres niveles:

Nivel de conexión: las conexiones entre los nodos se protegen mediante TLS, DTLS u otros protocolos.
Nivel de mensaje: cada mensaje RELOAD es firmado.
Nivel de objeto: los objetos almacenados son firmados por el nodo que lo ha creado.

De esta forma, es posible verificar el origen y la recepción correcta de los datos.
Cada nodo es identificado por su ID. Este ID se utiliza para:

Dirigirse a sí mismo
Determinar la posición en la topología
Determinar el conjunto de recursos del que es responsable.

Cada nodo tiene un certificado que contiene su ID, este ha de ser único en la instancia Overlay. Este certificado va a servir para:

Permitir al usuario almacenar datos en ubicaciones específicas dentro de la instancia. Cada tipo de dato define una regla específica para determinar qué certificado puede acceder a cada para ID de tipo – ID de recurso.
Permitir al usuario operar en el nodo cuyo ID se encuentra en el certificado.
Permitir al usuario usar el nombre de usuario incluido en el certificado.

Opcionalmente, provee una función de admisión basada en la compartición de secretos. En este modelo, todos los peers comparten un clave única que es usada para la autenticación entre peers mediante conexiones a través de TLS-PSK [RFC4279] o TLS-SRP [RFC5054].

Peers y clientes

Llamamos peer a un nodo que enruta mensajes de otros nodos a los que está directamente conectado. A parte de esto, también tiene funciones de almacenamiento.
Los clientes al contrario, son nodos que no hacen esa función de enrutamiento ni tienen responsabilidades de almacenamiento.

Enrutamiento

El enrutamiento de RELOAD proporciona las siguientes capacidades:

Enrutamiento basado en el recurso.Estos mensajes son entregados al nodo responsable del recurso. Soporta tanto Overlays estructuradas como desestructuradas.
Enrutamiento de mensajes a un nodo específico en el Overlay.
Clientes. Soporta solicitudes hacia y desde clientes que no participan en el enrutamiento Overlay.
NAT Traversal. permite la conexión entre nodos separados por uno o más NATs.
Low state. los algoritmos de enrutamiento no requieren estados significativos para almacenar peers intermedios.
Enrutamiento en topologías inestables. Se permite volver a enrutar cuando se producen fallos para conseguir llegar al destino.

Utiliza tres mecanismos básicos:

Lista de destinos: proporciona una capacidad de enrutamiento como Listas de Destinos que proveen una lista de nodos por los que debe circular el mensaje. En esta lista debe aparecer al menos un nodo.
Listas Via: permite responder por el mismo camino por el que se ha recibido un mensaje. Esto es porque se van añadiendo en esta lista los nodos por los que ha pasado el mensaje.
Cola de enrutamiento: Sirve para indicar una cola por la que enviar en el siguiente salto.

Su mecanismo de enrutamiento principal consiste en el Enrutamiento simétrico recursivo. Esto es, cada nodo reenvía a otro nodo más cercano al destino hasta llegar a él. La respuesta seguirá el mismo camino. Es el algoritmo usado por defecto en los nodos para enrutar mensajes a través del Overlay.

Gestión de conectividad

Para proveer un enrutamiento eficiente, los peers necesitan mantener un conjunto de conexiones directas a otros nodos. En el caso de que haya NATs entre estos, usamos ICE para establecer la conexión.
En general, un peer necesita mantener conexiones con todos los peers cercanos en la instancia Overlay. El algoritmo ‘Topology plugin’ indica un número determinado de conexiones. Si no se tiene este número, puede seguir funcionando, pero en cuanto sea posible establecer esas conexiones con peers cercanos deberán establecerse.

Estructura del mensaje

RELOAD es un protocolo orientado a mensajes de tipo pregunta-respuesta. Los mensajes son codificados usando campos binarios. El principal planteamiento de los campos es utilizar el modelo TLV, es decir, tipo, longitud y valor. De esta forma, permiten que sea extensible. Por otro lado, los campos que sean siempre obligatorios, se les define una posición fija sin usar tipo y longitud.
Los mensajes están estructurados en tres partes:

Cabecera de reenvío

Es una cabecera general para permitir el reenvío entre peers hasta llegar al destino. Es la única parte del mensaje que se examina en los nodos intermedios.

La estructura de esta cabecera es como sigue:

Campos:

relo token (32bits): identifica el mensaje como mensaje RELOAD. El valor del campo será siempre 0x2454c4f.
overlay (32bits): hash del Overlay en uso. Se forma cogiendo los 32 bits más bajos del hash SHA-1 del nombre del Overlay. Pensado para que los nodos puedan participar a la vez en varios Overlays.
Configuration sequence (16bits): número de secuencia del fichero de configuración.
version (8bits): versión del protocolo en uso. En nuestro caso 1.0, valor 0x0a.
ttl (8 bits): número máximo de saltos antes de que el mensaje sea descartado. Se decrementa en 1 por cada salto a lo largo de la ruta del mensaje. Al llegar a 0 y el nodo que lo ha recibido no es el destino, el mensaje no se reenvía más.
Fragment (32bits): para permitir fragmentación indicando si es último fragmento o no. También incluye el offset del fragmento.
Length (32bits): número de bytes del mensaje incluyendo la cabecera y una vez hecha la fragmentación.
Transaction ID (64bits): número único que identifica la transacción. Se ha de generar de forma aleatoria. La respuesta llevará el mismo ID.
Max response length (32bits): número máximo de bytes permitidos en la respuesta. En la respuesta su valor es 0.
Via list length (16bits): longitud en bytes de la via list.
Destination list length (16bits): longitud en bytes de la destination list.
Options length (16bits): longitud en bytes de las opciones de cabecera.
Via list (variable): secuencia de destinos a través de los cuales el mensaje ha pasado.
Destination list (variable): secuencia de destinos por los que el mensaje debería pasar. Se crea en el nodo origen. El primer elemento de esta secuencia es el destino de reenvío siguiente.

Contenido del mensaje

Es el mensaje, la información que desea transmitirse entre peers. No es analizada por los nodos intermedios, pero sí por capas superiores.

Campos:

Message code(16bits):indica mensaje enviado. El valor 0 está reservado. Entre el 1 y el 0x7fff indican número de petición o repuesta. Las peticiones siempre serán números impares y su respectiva respuesta el número de la petición más 1. Si el código fuese 0xffff indicaría que se ha producido un error.
Message body (16bits): cadena de longitud variable. Dependen del valor del campo anterior.
Extensions: actualmente no existe ninguna extensión. Aunque estas podrían ser definidas. Las extensiones están formadas por
Type: tipo de la extensión.
Critical: si es necesario que sea entendida la extensión para procesar el mensaje. En el caso de que valga TRUE, se enviará un mensaje de error si el receptor no puede entenderla.
Extension contents: contenido de la extensión, dependiente del tipo.

Bloque de seguridad

Contiene certificados y la firma digital de la parte del contenido del mensaje. Han de estar obligatoriamente firmados por el peer origen del mensaje.

Algunos métodos importantes

Unión de un nodo

Cuando un peer desea unirse a la instancia Overlay, necesitará un ID y un conjunto de credenciales unidos a ese ID. Existe la posibilidad de que ese peer no disponga todavía de credenciales. En ese caso, si existe un servidor para ello, este le proporciona un certificado en el que está incluido el ID del nodo. Una vez se tienen credenciales, se utiliza el mensaje JoinReq para unirse al Overlay. Depende del ‘Topology plugin’ a qué nodo será enviada esta petición. Si todo es correcto, se responde con el mensaje JoinAns. Ahora se ha de ejecutar una secuencia de operaciones de almacenamiento y actualizaciones para transferir la sección asignada al espacio Overlay del nodo.

Salida de un nodo

Se utiliza el mensaje LeaveReq para indicar que va a salir del Overlay. Este mensaje ha de enviarse a todos los nodos a los que está directamente conectado. Los nodos que reciban este mensaje tendrán que actualizar su tabla de enrutamiento y enviar las secuencias de almacenamiento y actualización necesarias para reestablecer el Overlay.

Actualización

Para ello se utiliza el mensaje Update. Se envía a los nodos a los que está conectado directamente. Sirve para informar del estado actual de su tabla de enrutamiento. Estos mensajes se envían cuando se detecta un cambio.

RouteQuery

Es una solicitud que permite al emisor preguntar a un peer por donde enrutaría hacia un determinado destino. Uno de sus usos es permitir el enrutamiento iterativo.

Probe

Permite a un nodo determinar de qué recursos son responsables otros nodos.

Attach

Es un mensaje enviado por un nodo para solicitar una conexión directa con un determinado nodo para el envío de mensajes RELOAD. Puede ser enrutado como un ID de nodo o como un ID de un recurso.

Almacenamiento

Para almacenar datos en el Overlay se utiliza el mensaje StoreReq.

Búsqueda

Para buscar uno o más elementos almacenados en un determinado ID de recurso, se utiliza la petición Fetch.

Enlaces externos

ietf-p2psip-26.