Transporte de tráfico IP sobre redes basadas en contenido Marielena Márquez Barreiro
←
→
Transcripción del contenido de la página
Si su navegador no muestra la página correctamente, lea el contenido de la página a continuación
Transporte de tráfico IP sobre redes basadas en
contenido
Marielena Márquez Barreiro
Trabajo de fin de grado
Escuela de Ingeniería de Telecomunicación
Grado en Ingeniería de Tecnologías de Telecomunicación
Tutores
Miguel Rodríguez Pérez
Sergio Herrería Alonso
Curso 2020/2021
Escuela de Grado en Ingeniería de Mención:
Ingeniería de Tecnologías de Telemática
Telecomunicación
Telecomunicación
Índice
Introducción .................................................................................................................................. 1
Objetivos ....................................................................................................................................... 2
Named Data Networking (NDN)................................................................................................... 3
Bases de su funcionamiento ...................................................................................................... 4
Estado del arte: aplicaciones y avances ..................................................................................... 5
Metodología y desarrollo .............................................................................................................. 6
Escenario desarrollado .............................................................................................................. 7
Instalación y configuración del escenario ................................................................................. 8
Captura y procesado de paquetes IP ........................................................................................ 10
Inyección en la red de paquetes IP .......................................................................................... 11
Pasarela con protocolo básico ................................................................................................. 12
Pasarela con protocolo mejorado ............................................................................................ 14
Pruebas realizadas ................................................................................................................... 16
Resultados ................................................................................................................................... 18
Conclusiones ............................................................................................................................... 19
Bibliografía ................................................................................................................................. 19
Anexo 1: Conceptos relevantes sobre el protocolo NDN ............................................................ 21
Anexo 2: Configuración y pruebas con tecnologías de enlace para conectividad entre nodos NDN
..................................................................................................................................................... 25
Anexo 3: Funcionamiento detallado de la pasarela con el protocolo básico ............................... 27
Anexo 4: Modelado del código de la pasarela con el protocolo mejorado.................................. 33
Anexo 5: Resultados de las pruebas con iperf............................................................................. 36
0
Escuela de Grado en Ingeniería de Mención:
Ingeniería de Tecnologías de Telemática
Telecomunicación
Telecomunicación
TRANSPORTE DE TRÁFICO IP
SOBRE REDES BASADAS EN
CONTENIDO
Autor: Marielena Márquez Barreiro
Tutores: Miguel Rodríguez Pérez,
Sergio Herrería Alonso
Curso: 2020/2021
1. Introducción
No es necesario resaltar el tremendo impacto que ha tenido la invención de Internet en las vidas
del ser humano a día de hoy y, sin lugar a dudas, que tendrá a futuro. Indiscutiblemente vivimos
en un mundo impulsado por las comunicaciones digitales, siendo intrínsecas y esenciales en
prácticamente cualquier sector de nuestra sociedad. Las suposiciones y bases iniciales sobre las
que nació el Internet que conocemos han ido mutando con su evolución, surgiendo con el paso de
los años nuevos usos y aplicaciones. Sin embargo, los fundamentos de estas ya no concuerdan
con aquellos del modelo de comunicación original que subyace de la pila de protocolos TCP/IP.
La realidad es que, para la inmensa mayoría de las comunicaciones del presente, el requisito IP
de comunicarse descubriendo y especificando un origen y un destino supone una limitación y una
dificultad. Esto se debe a que lo único realmente importante en muchas de las aplicaciones
actuales son los datos en sí mismos.
Para adaptarse a esta nueva visión de las aplicaciones a nivel conceptual, es inevitable e
imprescindible transformar la arquitectura del modelo de red predominante actualmente. Los
cimientos para ajustarse a las necesidades del presente ya no pueden ser los que sostienen al
modelo original (los terminales en comunicaciones punto a punto y sus direcciones). Ahora el
foco debe ponerse en lo relevante hoy en día para los usuarios y aplicaciones vigentes: el
contenido de las comunicaciones.
En este contexto nació el proyecto Named Data Networking (NDN) [1], fundado en 2010 por la
National Science Foundation (NSF) de los Estados Unidos. Este aspira a ser una alternativa a la
arquitectura TCP/IP, desarrollándose con principios ajustados a los incipientes patrones de
comunicación, focalizándose en la transmisión de los datos en sí mismos y, por lo tanto,
poseyendo gran potencial de cara a los entornos IoT (Internet of Things). Dicho proyecto es
relativamente reciente y aún se encuentra en vías de investigación y desarrollo para solventar las
dificultades técnicas que han ido surgiendo. A pesar de esto, los avances y pruebas significativas
ya realizadas convierten a esta arquitectura en candidata indiscutible para el Internet del futuro.
Pero ninguna transición es sencilla. Aún cuando la arquitectura NDN llegue a estar
completamente validada y consolidada, la actualización y/o reemplazo de los millones de
dispositivos actuales que no la implementan será un proceso arduo. Con la motivación de idear
un mecanismo factible que facilite dicho proceso surge la idea de desarrollar el sistema que se
presenta a continuación: una pasarela que soporte el transporte de tráfico IP a través de una red
NDN.
1
Escuela de Grado en Ingeniería de Mención:
Ingeniería de Tecnologías de Telemática
Telecomunicación
Telecomunicación
2. Objetivos
Entre las aplicaciones que predominan en Internet en nuestro día a día destaca el consumo de
contenido multimedia, redes sociales, aplicaciones móviles o e-commerce. El nexo común entre
ellas es la concepción de Internet como un mecanismo de distribución de contenido. Para esta
interpretación, como ya se apuntaba, el protocolo IP resulta poco práctico e innecesariamente
complejo, al estar basado en la comunicación punto a punto.
Por esta razón, en este proyecto se han explorado las posibilidades que ofrece una arquitectura de
red alternativa y novedosa como NDN a la hora de adaptar la capa de red a las necesidades del
mundo actual, caracterizado por el uso de Internet como una red de distribución más que como
la red de comunicación que era en su creación.
Para ello, será imprescindible conocer y comprender con cierto grado de profundidad los
principios de diseño, desarrollo e investigación en torno a la arquitectura de red NDN. Estos
conocimientos serán necesarios para llegar a completar el objeto sustancial de este Trabajo Fin
de Grado: el desarrollo de una herramienta que facilite y agilice la transformación de la forma en
la que se diseñan, desarrollan y despliegan redes y aplicaciones a día de hoy.
Dicha herramienta, a grandes rasgos, implementará la funcionalidad de pasarela para transportar
paquetes IP usando NDN como protocolo de red. Para llegar a conseguir su funcionamiento
exitoso, se definen una serie de actividades globales que marcan el desarrollo de este proyecto:
• El diseño de un protocolo que permita el transporte de paquetes IP sobre una red NDN.
• La creación de una aplicación que capture, procese y encamine el tráfico IP a través de la
red NDN.
• El desarrollo de un escenario de prueba que permita validar el funcionamiento del sistema
implementado. Sobre dicho escenario se realizarán pruebas de rendimiento y se ejecutará
una aplicación de streaming de vídeo para demostrar la transmisión exitosa de datos
multimedia a través de la pasarela desarrollada.
• El estudio y desarrollo de las modificaciones necesarias en el protocolo para optimizar su
rendimiento (tasa).
Este sistema se plantea para emplearse sobre un escenario como el representado en la Figura 1,
en el que el núcleo de la red está integrado por equipos comunicándose usando el protocolo NDN.
Los gateways serán aquellos routers que se encuentran en la frontera de dicho núcleo,
interconectándolo a redes de equipos que solo implementen IP. La aplicación desarrollada se
estará ejecutando en estos gateways, cada uno conectado a una subred IP diferente. Será gracias
a ella que se consiga comunicación entre las distintas subredes IP. Así, los equipos que solo
implementen la pila TCP/IP enviarán paquetes que atravesarán el núcleo NDN de forma
transparente para ellos.
Figura 1: Escenario de la pasarela IP-NDN
2
Escuela de Grado en Ingeniería de Mención:
Ingeniería de Tecnologías de Telemática
Telecomunicación
Telecomunicación
En resumen, el foco deberá estar puesto en la consecución de un funcionamiento exitoso de dicha
pasarela, realizando y evaluando pruebas claras que validen su correcta operación. Esto no se
conseguirá sin antes comprender y familiarizarse con los principios, mecanismos y herramientas
disponibles para trabajar y desarrollar con NDN como protocolo de red. De todo ello cabe destacar
la relevancia de aprender a experimentar y desarrollar con ciertas tecnologías novedosas, como
son: el software del router que implementa el protocolo NDN (NFD, Named Data Networking
Forwarding Daemon) [2]; la librería oficial de programación en C++ que implementa las
primitivas del protocolo NDN (ndn-cxx) [3]; o la librería libpcap [4] para la captura, filtrado y
procesado de paquetes necesarios.
Finalmente, es importante señalar también las limitaciones a las que se encuentra ligado este
proyecto. Se trata de un marco sin conocimiento previo alguno, ni teórico ni práctico, y que
precisa del uso de tecnologías desconocidas para desarrollar, desde cero, una herramienta
innovadora. Todo ello, además, en un tiempo de investigación y desarrollo limitado. Por esta
razón, ciertas líneas y funcionalidades muy significativas proporcionadas por el modelo de NDN
quedarán fuera del ámbito de este trabajo, como pueden ser el área de la seguridad o la
autoconfiguración de rutas.
3. Named Data Networking (NDN)
El concepto de Named Data Networking (NDN) nace y evoluciona a partir de su proyecto
predecesor Content-Centric Networking (CCN), con la intención de crear una arquitectura de red
alternativa a IP que tenga los datos como motivo central. Concretamente, se trata de un diseño
arquitectónico específico dentro de la línea global de investigación Information-Centric
Networking (ICN). NDN pretende convertirse en la nueva capa de red universal, pudiendo
ejecutarse sobre cualquier otro protocolo y pudiendo cualquier protocolo ejecutarse sobre él
(inclusive IP en ambos casos). Es decir, al igual que IP, su diseño pretende compatibilizar el
desarrollo e innovación independiente de protocolos en capas inferiores y superiores. Pero, al
contrario de IP, aspira a cambiar el objetivo del servicio de red propiamente dicho, esto es, que
deje de ser la entrega de paquetes a una cierta dirección destino, para convertirse en la
recuperación de datos identificados por un nombre concreto [1].
NDN mantiene la arquitectura en forma de reloj de arena del Internet actual, pero transformando
su núcleo: la capa de red (la parte estrecha del reloj que se aprecia en la Figura 2) se altera
buscando adaptarla al concepto de red de distribución. Esta parte central se diseñó inicialmente
con el propósito de proporcionar las funcionalidades mínimas necesarias para conseguir
interconectividad a nivel global, imponiendo la restricción de que las únicas entidades nombrables
en los paquetes IP serían los extremos de las comunicaciones.1 Y es justamente esta imposición
la raíz de muchos de los problemas de este modelo, asociados al control y distribución de
contenidos. Esta clase de inconvenientes del paradigma de la comunicación punto a punto se ve
reflejada en, por ejemplo, los Content Distribution Networks (CDN)2 o en el hecho de que el
protocolo Transport Layer Security (TLS) procure la protección de las comunicaciones, en lugar
de la protección de los datos.
Por ese motivo, NDN elimina dicha restricción en su modelo, estableciendo que el nombre en sus
paquetes puede identificar objetos más allá de los extremos de la comunicación: desde un
fragmento de un contenido multimedia hasta un comando para realizar una acción concreta. De
esta forma, se deja atrás la unidad de comunicación fundamental de la arquitectura TCP/IP: un
can
1
Requisito explícito presente en el RFC791 (Internet Protocol).
2
La caída de Fastly, un gran proveedor de Internet, a principios del mes de junio de 2021 evidencia las
terribles consecuencias de la tendencia a re-centralizar Internet que demuestran los CDN.
3
Escuela de Grado en Ingeniería de Mención:
Ingeniería de Tecnologías de Telemática
Telecomunicación
Telecomunicación
Figura 2: Arquitecturas IP y NDN. Reproducido de [1].
punto a punto con los extremos de la comunicación identificados por una dirección IP.3 Ahora,
en cambio, los bloques principales de la arquitectura NDN pasan a ser los fragmentos de
contenido.
Este protocolo aplica ciertos principios arquitectónicos disruptivos. Incluye, por ejemplo, un
bloque de seguridad específico para asegurar el contenido de los paquetes (no el contenedor),
firmando todos los datos nombrados que se transmiten. Consigue así desacoplar la confianza en
los datos de la confianza en los hosts y permite mecanismos como el caché automático para
optimizar el ancho de banda. Pretende, también, la autorregulación del tráfico en la red por medio
del balance de flujo entre paquetes Interest y Data. Y, además, soporta funcionalidades como el
reenvío multipath y el almacenamiento en red, con el objetivo de fomentar la competencia entre
distintas implementaciones y el poder de decisión del usuario final para elegir entre ellas.
3.1. Bases de su funcionamiento
Los principios de diseño de la arquitectura NDN dan lugar a un protocolo de comunicación en el
que se diferencian claramente dos roles: el productor (servidores del contenido) y el consumidor
(receptores del contenido). Además, el proceso de comunicación en sí mismo es impulsado por
los receptores. Estas entidades intercambian paquetes que pueden ser de dos tipos: Interest o Data,
ambos nombrados para identificar a un fragmento de datos concreto. El proceso de comunicación
se puede describir de la siguiente manera:
1. Un consumidor crea un paquete Interest, con el nombre que identifica los datos que desea
recibir, y lo envía a la red.
2. Los routers de la red NDN reenvían este paquete Interest hacia algún nodo que contenga
una copia del dato nombrado, esto es, hacia algún productor (o productores) de los datos.
Para ello se basarán en el nombre especificado en el paquete.
3. Cuando el productor, o los productores, reciban el Interest, responderán con un paquete
Data: este tendrá el nombre y contenido correspondientes, y estará firmado con la clave
de la fuente original del dato. Este paquete llegará de vuelta al consumidor siguiendo el
camino inverso del Interest que lo generó.
Para comprender mejor el protocolo NDN, su funcionamiento y ventajas, se incluye en el Anexo
1 una explicación más extensa de los conceptos relevantes sobre la entrega de los datos, el
encaminamiento de los paquetes y los elementos concretos que conforman su arquitectura.
3
Aunque el canal punto a multipunto también existe en IP, el modelo punto a punto es claramente
predominante.
4
Escuela de Grado en Ingeniería de Mención:
Ingeniería de Tecnologías de Telemática
Telecomunicación
Telecomunicación
3.2. Estado del arte: aplicaciones y avances
Los avances conseguidos desde la aparición de NDN son prometedores. En primer lugar, se ha
logrado tener una especificación del protocolo disponible para todos los usuarios. En ella se
encuentran estandarizados los formatos de los paquetes Interest y Data [5], así como la
descripción de las funcionalidades soportadas por este protocolo de red [6]. Además, se dispone
de librerías para desarrollar aplicaciones usando aspectos claves del protocolo como el
nombramiento de los paquetes, su reenvío y enrutado, o la gestión de confianza.
Con todo ello, ya se han implementado y probado diversas aplicaciones funcionales. Gracias a
ellas, se ha conseguido verificar y validar ciertas ventajas de la arquitectura NDN, ilustrando así
tanto sus beneficios como los retos que aún quedan por cumplir. Entre las múltiples aplicaciones
desarrolladas en estos años, por las mejoras que evidencian, se destacan las siguientes:
• NDNVideo [7]: ha demostrado la capacidad de reproducir un streaming de vídeo HD en
directo a través de NDN. Con esto se ilustraron los beneficios de NDN de cara a la
distribución de contenidos multimedia. Por ejemplo, reflejó que:
o El almacenamiento en red elimina la necesidad de una comunicación directa entre
productor y consumidor, lo que supone una mejora considerable en cuanto a la
escalabilidad de este tipo de aplicaciones.
o El diseño del espacio de nombres, marcado por la aplicación, ofrece soporte para
la selección de fragmentos del vídeo y su reagrupación.
• ChronoChat [8]: consiste en una aplicación de chat multiusuario en tiempo real. Su
funcionamiento ha permitido constatar avances en cuanto a técnicas de sincronización de
datos y modelos de confianza no jerárquicos.
• Ndnrtc [9]: se trata de una aplicación de videoconferencia, por lo que se sitúa en el mismo
marco que la aplicación anterior. En este caso, su desarrollo permitió investigar varios
aspectos de las comunicaciones en tiempo real, como el control de la congestión, la
adaptación de tasa y la sincronización.
• Aplicaciones relacionadas con la automatización y gestión de edificios [10]: mediante
este tipo de aplicaciones se han explorado requisitos específicos en cuanto al diseño de
los espacios de nombres y del almacenamiento en redes extensas y heterogéneas de
sensores y otros dispositivos. En particular, trataron de dar soporte a la necesidad
prioritaria de estas aplicaciones de centrarse en la recopilación y agregación de datos.
• Interconexión de vehículos [11]: el desarrollo de esta clase de aplicaciones ha mostrado
las ventajas de NDN en cuanto a la recuperación de contenido en base a la localización.
Además, han permitido diseñar también nuevos modelos de confianza con la finalidad de
ajustarlos a comunicaciones ad-hoc y oportunistas.
• Cabe mencionar que hay muchas más aplicaciones que han supuesto progresos en la
evolución de NDN, más allá de las ya mencionadas: sistemas de archivos distribuidos,
juegos multiusuario, herramientas de gestión de red, aplicaciones para la salud…
Esta variedad de aplicaciones resalta las principales características que hacen de NDN una
arquitectura ideal para el futuro de las comunicaciones: la distribución de contenido,
nombramiento amigable ajustado a las necesidades de cada aplicación, seguridad robusta y
soporte para movilidad y broadcast.
Así mismo, se ha apostado por incentivar el desarrollo por parte de los usuarios de más
aplicaciones que sigan demostrando la capacidad de este protocolo para resolver problemas reales.
Con esta motivación, tal y como ya se esbozaba, hay disponibles una serie de herramientas para
que todo usuario pueda colaborar en dicha tarea. Todas ellas conforman la plataforma NDN,
integrada por un conjunto de paquetes software que implementan los componentes críticos de la
5
Escuela de Grado en Ingeniería de Mención:
Ingeniería de Tecnologías de Telemática
Telecomunicación
Telecomunicación
arquitectura. El conjunto de estas herramientas permite construir y probar redes NDN y
aplicaciones, destacando las siguientes:
• NDN Forwarding Daemon (NFD) [2]: se trata de uno de los componentes del núcleo de
la plataforma NDN, que permite experimentar con diferentes elementos del protocolo de
forma modular y extensible. Ofrece soporte para el reenvío de paquetes NDN gracias a
sus principales módulos:
o Núcleo: incluye rutinas de computación hash, ficheros de configuración,
monitorización de interfaces, etc.
o Interfaces: se implementa una abstracción de interfaces NDN sobre mecanismos
de transporte de más bajo nivel.
o Tablas: estructuras de datos necesarias para permitir el reenvío de los paquetes
NDN, como son la Content Store (CS), la Pending Interest Table (PIT) y la
Forwarding Information Base (FIB). La funcionalidad y descripción de cada una
se encuentra detallada en el Anexo 1.
o Reenvío: implementa los procedimientos para el procesado de paquetes NDN a
partir de la interacción entre interfaces, tablas y distintas estrategias de reenvío.
o Protocolo de control NFD [12]: permite a usuarios, herramientas y programas del
plano de control recuperar, monitorizar y alterar el estado del NFD forwarder.
Para conseguirlo, utiliza el intercambio de paquetes Interest-Data entre las
aplicaciones y el NFD.
o Control de la RIB (Routing Information Base), cuya descripción se encuentra
también en el Anexo 1.
• Librería ndn-cxx [3]: software desarrollado para implementar las primitivas NDN en
C++. Es la herramienta principal para que los usuarios puedan escribir y desarrollar
nuevas aplicaciones.
• ndnSIM [13]: simulador que permite evaluar el rendimiento de sistemas NDN en redes
de gran tamaño. También proporciona medios para analizar el comportamiento de los
componentes de su arquitectura y el flujo del tráfico.
Existe, ligado a todas estas herramientas, un banco de pruebas NDN en funcionamiento, el cual
interconecta routers programables de todas las instituciones participantes en el proyecto. Su
finalidad es la de evaluar tanto las aplicaciones como los componentes del núcleo de la
arquitectura. Consiste, por lo tanto, en un recurso compartido con propósitos de investigación que
acepta solicitudes de sitios externos para conectarse a él.
Como ya se apuntaba con anterioridad, todas estas aplicaciones y herramientas manifiestan el
auge de este novedoso protocolo de red. Sin embargo, la búsqueda de herramientas que faciliten
la posible futura etapa de transición entre TCP/IP y NDN ha resultado ser muy poco fructífera.
Sorprendentemente, los planteamientos de sistemas o herramientas que permitan transportar
datagramas IP sobre redes NDN son prácticamente inexistentes. A nivel formal, solo se ha
encontrado una propuesta enfocada a resolver el problema descrito [14]: evitar la problemática de
migrar el código original de aplicaciones basadas en TCP/IP a NDN. Es por este motivo que el
objeto de este Trabajo Fin de Grado cobra aún más relevancia.
4. Metodología y desarrollo
El desarrollo de este proyecto ha tenido dos vertientes claramente diferenciadas, tal y como ya se
apuntaba anteriormente: una vertiente teórica y otra práctica.
La primera etapa consistió únicamente en un ejercicio de investigación, tratándose, por lo tanto,
de un trabajo completamente teórico. En ella se hizo un aprendizaje exhaustivo sobre los
principales conceptos relacionados con la arquitectura NDN. De esta forma se consiguió adquirir
6Escuela de Grado en Ingeniería de Mención:
Ingeniería de Tecnologías de Telemática
Telecomunicación
Telecomunicación
conocimientos acerca del protocolo, sus principios de diseño y elementos principales, su
funcionamiento y las herramientas y aplicaciones disponibles para trabajar con él. Esta base
teórica permitió pasar a una segunda etapa de desarrollo más práctica.
Este segundo período del proyecto estuvo centrado en familiarizarse con las herramientas que
componen la plataforma NDN, ya mencionadas en el apartado 3.2 de este documento. En
particular, se llevó a cabo, haciendo uso de la documentación oficial de NDN, la instalación del
software necesario, la configuración del entorno de desarrollo y la implementación de sencillas
aplicaciones de prueba para experimentar con las librerías del protocolo.
Una vez alcanzado cierto grado de soltura con estas herramientas, se pasó a la última, y más
importante, etapa de desarrollo. El trabajo consistió en el diseño de un protocolo que permitiese
transportar los paquetes IP sobre la red NDN configurada, comenzando así a implementar la
pasarela IP-NDN. Fue también en esta etapa final, cuando el código desarrollado ya era funcional,
que se desarrolló el escenario de pruebas para validar el funcionamiento del sistema. En dicho
escenario se realizaron múltiples ensayos hasta conseguir que la pasarela funcionara exitosamente
y, tras evaluar los resultados obtenidos, se propuso una optimización del protocolo inicial con el
propósito de mejorar su rendimiento. Tras implementar dicha mejora en el sistema se repitieron
las pruebas realizadas en el escenario desarrollado. De esta forma, se pudo concluir el proyecto
con un análisis comparativo de ambas versiones, el cual demuestra la operación satisfactoria de
la pasarela con unas prestaciones que cumplen (o incluso superan) los objetivos marcados
inicialmente.
4.1. Escenario desarrollado
En la Figura 3 se ilustra el escenario sobre el que la pasarela IP-NDN presentada en este proyecto
ha sido implementada y probada. La topología se compone de dos subredes IP independientes
(subred A a la izquierda y subred B a la derecha), las cuales están interconectadas por un núcleo
de routers que implementan NDN como protocolo de red (equipos centrales). En concreto, los
dos equipos situados en la frontera de dicho núcleo son los que ejecutan el código de la
herramienta implementada y, por este motivo, son los que ejercen el rol de gateways. Estos dos
routers son la clave para conseguir que los equipos situados en las subredes IP, que no soportan
NDN, se comuniquen. Esto es, los paquetes enviados por estos terminales atraviesan el núcleo
NDN de forma transparente para ellos gracias a nuestra pasarela implementada en los dos
gateways. El gateway situado en la frontera con la subred IP A se identifica como nodoA, mientras
que el que interconecta el núcleo NDN con la subred IP B se identifica como nodoB. El nodoA
ejerce el rol de productor para el prefijo /mired/nodoA, esto es, es el encargado de producir los
datos NDN correspondientes con los datagramas IP generados por la subred A. Por su parte, el
nodoB hace lo mismo para el prefijo /mired/nodoB.
Figura 3: Escenario de desarrollo de la pasarela IP-NDN
7Escuela de Grado en Ingeniería de Mención:
Ingeniería de Tecnologías de Telemática
Telecomunicación
Telecomunicación
El software que se ejecuta en cada gateway dispone de una tabla de encaminamiento conformada
por duplas de gateways NDN y direcciones de subredes IP. Esta información permite conocer qué
subred IP es alcanzable por cada gateway del núcleo, ejerciendo el rol de productor de un prefijo
NDN concreto. Esto es, las entradas de esta tabla establecen hacia qué gateway debe reenviarse
un paquete IP capturado según la dirección IP destino de este, listando el identificador de dicho
gateway destino. Estos pares subred IP-nodo NDN serán conocidos por todos los gateways del
núcleo. Inicialmente, por simplicidad, esta tabla de encaminamiento es cargada directamente por
cada gateway a partir de un fichero local de configuración durante su inicialización.
4.2. Instalación y configuración del escenario
Para completar la creación del escenario mostrado, ha sido necesario instalar y configurar un
entorno virtual de desarrollo. Todos los equipos presentes en él son emulados con máquinas
virtuales que tienen Ubuntu 20.04 como sistema operativo. A continuación, se lista el software
particular y más relevante que ha sido instalado y configurado en los tres equipos que integran el
núcleo de la red NDN:
• La librería ndn-cxx y sus prerrequisitos, tal y como se describe en la documentación
oficial de NDN, en el apartado Getting started with ndn-cxx [3].
• El Named Data Networking Forwarding Daemon (NFD), siguiendo también las
indicaciones especificadas en la documentación oficial de NDN, en el apartado Getting
started with NFD [15].
• La colección de herramientas esenciales proporcionadas por NDN, las ndn-tools [16]. En
ella se incluyen herramientas de utilidad para el desarrollo de la pasarela IP-NDN, como
son el ndnping, que permite probar el alcance entre dos nodos NDN, o el dissect-
wireshark, una extensión del programa Wireshark para inspeccionar paquetes NDN.
Una vez instalado todo el software anterior en las máquinas virtuales, ya es posible lanzar el NFD
y conectarse a nodos NDN pertenecientes al banco de pruebas NDN. Con esto queda asegurada
la correcta instalación y configuración de nuestro router NDN [17]. Este proceso se realiza en
una única máquina virtual para, posteriormente, clonarla y replicar así la instalación y
configuración en los otros dos routers que implementan NDN, presentes en el escenario. En
cambio, las dos máquinas que representan equipos legacy 4 en el escenario, situadas en las
respectivas subredes IP, no constan del software desglosado: son simples máquinas virtuales con
Ubuntu 20.04 que implementan la típica arquitectura TCP/IP. La simulación y puesta en marcha
del escenario completo, integrado por estos cinco equipos configurados y conectados, ha sido
llevada a cabo en el emulador software de red GNS3 (Graphical Network Simulator-3).
Para proporcionar la conectividad entre los equipos de la red NDN se consideraron varias
tecnologías de enlace diferentes, con las que se pudo experimentar utilizando comandos de la guía
del NFD (disponibles en el apartado Manpages de la documentación oficial [15]):
• El empleo directo de Ethernet como faz 5 de NDN, tanto empleando multicast como
añadiendo una faz unicast con las direcciones MAC correspondientes.
• El empleo del soporte IPv6.
• La configuración de IPv4 para usar interfaces udp4 multicast o para crear interfaces punto
a punto.
4
Término empleado, en este contexto, para referirse a equipos que solamente implementan la arquitectura
TCP/IP y no soportan NDN.
5
Generalización del concepto interfaz de red usado en la arquitectura de red actual. El término faz hace
referencia a una abstracción de cualquier canal de comunicación que el NFD pueda usar para el reenvío de
paquetes NDN, ya que el intercambio de paquetes no solo se lleva a cabo sobre interfaces físicas de red
sino que puede darse también entre aplicaciones en la misma máquina directamente.
8Escuela de Grado en Ingeniería de Mención:
Ingeniería de Tecnologías de Telemática
Telecomunicación
Telecomunicación
Con cada una de estas alternativas de configuración de la red se consiguió conectividad entre los
nodos NDN, demostrada utilizando la herramienta ndnping. El proceso de configuración y
pruebas específicas realizadas en este punto del proyecto se presenta detallado en el Anexo 2. De
entre las alternativas descritas en este anexo, en el escenario de desarrollo del sistema final
implementado se optó por emplear IPv4 con rutas configuradas sobre faces UDP multicast. El
principal motivo de esta decisión fue la sencilla configuración que implicaba, si bien el resultado
final no depende en absoluto de la tecnología de enlace empleada.
Finalmente, con todo este procedimiento completado, era necesario familiarizarse con la API de
la librería ndn-cxx [18] antes de comenzar a desarrollar el código de la pasarela IP-NDN con ella.
Con este propósito, se creó una aplicación de comunicación básica sobre NDN. Esta aplicación
consiste en un módulo productor y otro consumidor simples, en el que el paquete Data transmitido
contiene la hora actual. A pesar de su sencillez, sirvió para demostrar el correcto funcionamiento
de la configuración definitiva de la red.
En resumen, para el desarrollo de la pasarela IP-NDN, se añade en el nodoA una ruta con el prefijo
/mired/nodoB hacia la faz udp4 multicast asociada al enlace que lo conecta al núcleo. 6
Análogamente, se añade una ruta en el nodoB con el prefijo /mired/nodoA. Es sólo en el nodo
intermedio del núcleo NDN donde es necesario tener añadidas dos rutas, una hacia cada prefijo
respectivamente. A modo de ejemplo, la Figura 4 muestra estas dos rutas añadidas en el nodo
intermedio del escenario desarrollado, mientras que en la Figura 5 se ven listadas las faces
disponibles en dicho equipo (marcadas en rojo las empleadas para crear esas dos rutas).
Figura 4: Rutas añadidas en el nodo intermedio de la red NDN
Figura 5: Faces disponibles en el nodo intermedio de la red NDN
6
El comando empleado para ejecutar esta acción es: nfdc route add prefix nexthop
9Escuela de Grado en Ingeniería de Mención:
Ingeniería de Tecnologías de Telemática
Telecomunicación
Telecomunicación
4.3. Captura y procesado de paquetes IP
Tal y como se ha señalado a lo largo de este documento, el objeto central de este Trabajo Fin de
Grado ha sido el desarrollo de una herramienta que permita transportar paquetes IP sobre una red
NDN. Para alcanzar dicho objetivo, además de la configuración del escenario descrita en el
apartado anterior y de la implementación del propio algoritmo que ofrece esta funcionalidad
(expuesta en los siguientes apartados), ha sido fundamental el desarrollo de un módulo de captura
del tráfico. Este módulo es imprescindible para el funcionamiento de la pasarela: los gateways
necesitan capturar y procesar los paquetes provenientes de la subred IP a la que estén conectados,
antes de aplicar el protocolo que permita a cada uno de ellos atravesar la red NDN.
A la hora de decidir qué herramienta emplear para llevar a cabo este proceso de captura y
procesado, se ha tenido en cuenta que la librería ndn-cxx está implementada en C++ y, por lo
tanto, sería este el lenguaje de implementación de la pasarela IP-NDN. Por este motivo, la
herramienta empleada finalmente ha sido libpcap, la implementación para entornos UNIX de la
librería PCAP [19]. La documentación y ejemplos proporcionados por esta librería vienen
enfocados al desarrollo en lenguaje C y, gracias a esto, su uso en este sistema es compatible con
la programación usando ndn-cxx. Además, escribir este proceso en código C ofrece las ventajas
características de este lenguaje, como es su eficiencia para el trabajo en tiempo real.
En cada gateway, durante su inicialización, se realiza la configuración de la interfaz de la que se
desea capturar el tráfico, la cual lo conecta a la subred IP correspondiente. Esta configuración
sigue el proceso descrito a continuación e ilustrado en el diagrama izquierdo de la Figura 6:
1. Se buscan las interfaces del equipo disponibles para abrir una captura, empleando el
método pcap_findalldevs.
2. Las interfaces encontradas se listan de forma numerada, mostrando el nombre y subred a
la que pertenece cada una.
3. El usuario introduce el número de la interfaz escogida y, automáticamente, se asigna un
método gestor de la captura en modo promiscuo con la llamada a pcap_open_live.
4. A este se le aplica un filtro que restringe la captura a paquetes IP provenientes de la
dirección y máscara de la subred seleccionada.
Tras la configuración de la interfaz, durante su inicialización, el gateway crea un proceso
(pcap_reader) que se queda, en bucle, esperando la llegada de paquetes a través de esta interfaz
y se ocupa de capturarlos. Su funcionamiento está representado en el diagrama derecho de la
Figura 6. La captura se inicia de forma no bloqueante, gracias a la llamada al método
pcap_setnonblock, y se detecta la llegada de cada paquete con el método pcap_next. Para cada
paquete capturado se lleva a cabo un procesado del mismo, distinguiéndose los siguientes pasos:
1. Se asegura que el paquete capturado se trate de un paquete IP, para lo cual se analiza el
campo tipo presente en la cabecera Ethernet del mismo.
2. Se analiza el contenido de la cabecera IP del paquete para obtener, entre otros datos, su
dirección IP destino y el protocolo encapsulado en el paquete (ICMP, UDP o TCP).
3. Se obtiene también el tamaño del paquete IP capturado, analizando el campo longitud de
su cabecera que indica el tamaño total en bytes del datagrama.
Una vez finalizado este primer procesado, y ya prescindiendo de la cabecera Ethernet, se pasa a
comprobar si la dirección IP destino del paquete es alcanzable por alguno de los gateways del
núcleo. Es decir, se busca una entrada coincidente con esta dirección en la tabla de
encaminamiento del gateway, descrita en el apartado 4.1, para enviar hacia el prefijo
correspondiente este paquete. Esta tarea ya es realizada por el proceso pcap_callback en el que,
en caso de encontrar una coincidencia, el gateway inicia el protocolo de actuación diseñado para
transportar paquetes IP sobre la red NDN. Con la invocación de este método, el proceso
pcap_reader vuelve al inicio de su bucle para esperar de nuevo la llegada de otro paquete IP.
10Escuela de Grado en Ingeniería de Mención:
Ingeniería de Tecnologías de Telemática
Telecomunicación
Telecomunicación
Figura 6: Diagramas de flujo del proceso de configuración, captura y procesado de paquetes IP
4.4. Inyección en la red de paquetes IP
Después de aplicarse el protocolo que lleva un paquete IP desde su gateway origen hasta el
gateway conectado a su subred IP destino, este último router realiza el procedimiento oportuno
para extraer el paquete IP original del paquete Data recibido. Este procedimiento será explicado
en detalle en los apartados posteriores.
Una vez recuperado el datagrama original, este debe enviarse por la subred IP conectada al
gateway para que llegue a su destinatario final. La herramienta empleada para llevar a cabo esta
tarea es un socket RAW, el cual permite transmitir paquetes IP directamente, sin protocolo de
transporte y sin necesidad de especificar las cabeceras de nivel de enlace. Además, ofrece la
posibilidad de escribir manualmente la cabecera del datagrama enviado. Cabe mencionar que una
de las restricciones que implica su uso es la necesidad de contar con privilegios de superusuario.
En concreto, el socket RAW empleado en este sistema pertenece a la familia AF_INET,
caracterizado por delegar la construcción de las cabeceras de nivel de enlace en el propio sistema
operativo. Además, el campo protocolo especificado en la creación del socket es IPPROTO_RAW,
el cual implica que el buffer de la llamada al método sendto sobre el socket ya contiene la cabecera
IP. De esta manera, la dirección destino contenida en esta cabecera se usa para encaminar el
paquete.
11Escuela de Grado en Ingeniería de Mención:
Ingeniería de Tecnologías de Telemática
Telecomunicación
Telecomunicación
4.5. Pasarela con protocolo básico
La parte fundamental de este proyecto es el diseño e implementación del protocolo de transporte
de paquetes IP sobre el núcleo de la red NDN. Este procedimiento se activa cuando, tras la captura
y procesado de un paquete IP (descrita en el apartado 4.3), se encuentra, en la tabla de
encaminamiento del gateway, una entrada coincidente con la dirección IP destino del paquete
capturado. Antes de presentar el protocolo diseñado, es importante resaltar que, recordando los
principios de NDN, un dato no puede ser transmitido directamente, sino que dicha transmisión
debe ser desencadenada por la recepción previa de un paquete Interest solicitándolo. Por este
motivo, un gateway nunca podrá enviar datos (un paquete IP en este caso) hacia otro gateway sin
antes recibir una solicitud de los mismos de alguna forma. Esto es, sin existir en la red un Interest
pendiente de satisfacer.7
Teniendo esto en mente, la primera versión del algoritmo consta de tres etapas diferenciadas,
llevadas a cabo individualmente para cada paquete capturado. Para poder explicarlas con mayor
claridad, se plantea una situación específica en el escenario: el equipo perteneciente a la subred
IP B (con dirección 1.2.3.6 y al que nos referiremos de ahora en adelante como hostB) envía un
paquete IP destinado al nodo situado en la subred IP A (con dirección 5.6.7.10 y al que nos
referiremos como hostA). Este caso puede generalizarse a cualquier equipo en una subred IP
enviando tráfico dirigido a otro equipo en una subred IP diferente. En el escenario propuesto, el
proceso llevado a cabo es el siguiente (ilustrado de forma concisa mediante el diagrama de
tiempos de la Figura 7):
Figura 7: Protocolo básico de la pasarela IP-NDN
7
Existen algunas propuestas en la literatura que plantean la posibilidad de enviar datos en un paquete
Interest. A pesar de que ciertas redes ICN lo permiten, NDN no lo acepta: iría en contra de los principios
del propio protocolo.
12Escuela de Grado en Ingeniería de Mención:
Ingeniería de Tecnologías de Telemática
Telecomunicación
Telecomunicación
1. Tal y como ya se indicaba al final del apartado 4.3, el gateway nodoB, después de capturar
y procesar el paquete procedente del hostB, ejecuta el proceso pcap_callback. En este
punto, busca en su tabla de encaminamiento una coincidencia para la dirección 5.6.7.10.
En ella encuentra una entrada asociando dicha dirección al gateway nodoA. Tras esto,
procede a almacenar el paquete IP en su cola de paquetes pendientes por enviar,
asignándole un número de secuencia que lo identifique unívocamente. Supongamos, por
ejemplo, que este número es 3. Finalmente, para terminar la actividad del pcap_callback,
el nodoB envía a la red NDN un Interest con el nombre /mired/nodoA/ip/request/nodoB/3.
Generalizando, el nombre de los paquetes Interest enviados en este punto está formado
por la concatenación de las cadenas del identificador del gateway destino del paquete
(obtenido de la tabla de encaminamiento), /ip/request/ (ip actúa como identificador del
proceso que actúa de pasarela y request especifica el comando para dicho proceso), el
identificador del gateway origen del paquete8 y el número de secuencia con el que se
almacenó el paquete (el parámetro necesario para el método request). A partir de ahora,
nos referiremos a los paquetes enviados en este punto como Interests request.
2. Todos los gateways, durante su inicialización, registran la faz que los conecta al núcleo
NDN al prefijo /mired//ip/request. De esta forma, cuando
reciben un paquete Interest con un nombre perteneciente a este prefijo, ejecutan una
función callback registrada para gestionarla: onInterest_request. Gracias a esto, cuando
el Interest enviado por el nodoB llega al nodoA (pues no hay ningún Data almacenado en
los nodos intermedios que lo pueda satisfacer), este gateway ejecuta dicha función. Con
su ejecución, se procesa el nombre del paquete recibido para extraer el identificador del
gateway del que proviene y su correspondiente número de secuencia. Seguidamente, el
nodoA genera un nuevo Interest con el nombre /mired/nodoB/ip/datagram/3 y lo envía a
la red. A partir de ahora, para referirnos a estos paquetes Interests de respuesta,
utilizaremos el término Interests datagram. Generalizando este caso particular, los
Interest datagram se nombran concatenando el identificador del gateway que envió el
Interest request y al que debe llegar este Interest datagram, /ip/datagram/ (ip vuelve a
actuar como identificador del proceso que actúa de pasarela y datagram especifica el
comando para dicho proceso) y el número de secuencia también extraído del Interest
request recibido (el parámetro necesario para el método datagram). Este paquete actúa
como un “permiso” concedido por el nodoA al nodoB para enviarle un datagrama IP.
Además, a la hora de enviarlo, se le asocia otra función callback (onData), cuya ejecución
será activada al recibirse el paquete Data asociado al Interest datagram enviado.
3. Todos los gateways, también al inicializarse, registran la faz conectada al núcleo a otro
prefijo NDN: /mired//ip/datagram. A este registro se le
asocia otra función callback distinta para ejecutarse al recibirse un Interest de este prefijo:
onInterest_datagram. En consecuencia, la recepción del Interest datagram enviado por
el nodoA provoca la ejecución de esta función en el nodoB. En ella se comienza
procesando el nombre en el paquete recibido con el propósito de extraer el número de
secuencia incluido en él. Así, el gateway puede identificar el paquete IP para el que este
Interest autoriza el envío y procede a recuperarlo de la cola de paquetes pendientes. Este
paquete IP constituye el contenido del paquete Data que el nodoB envía en respuesta al
Interest datagram recibido. Finalmente, una vez enviado el Data, el nodoB elimina el
datagrama IP de su cola. Por su parte, cuando el nodoA recibe el Data, ejecuta el callback
onData previamente mencionado: se extrae el contenido del Data, es decir, el paquete IP
que transporta, y su tamaño. Una vez recuperado el datagrama, se procesa la cabecera IP
que contiene con el propósito de conocer la dirección IP destino. En posesión de toda esta
información, el nodoA envía, empleando el método sendto sobre el socket RAW, el
paquete IP hacia su destino final, el hostA.
8
El nombre identificativo del gateway se pasa como parámetro al lanzar la ejecución del sistema.
13Escuela de Grado en Ingeniería de Mención:
Ingeniería de Tecnologías de Telemática
Telecomunicación
Telecomunicación
El funcionamiento completo del sistema ejecutado en cada gateway se describe con detalle en el
Anexo 3. En él se incluyen una serie de diagramas de actividad para ilustrar y explicar los procesos
concurrentes que actúan en estos equipos y que, en conjunto, hacen funcionar la pasarela de
manera exitosa. También en este Anexo se presenta la estructura del código implementado
mediante diagramas de clase.
4.6. Pasarela con protocolo mejorado
La pasarela IP-NDN, utilizando el protocolo descrito en el apartado anterior, se probó en el
escenario desarrollado. Las pruebas realizadas, explicadas con detalle en el próximo apartado,
demuestran que el sistema funciona correctamente empleando este protocolo básico. Sin
embargo, las prestaciones obtenidas con él no son satisfactorias: la tasa alcanzada es
excesivamente baja. Por este motivo, fue necesario implementar una nueva versión de la
herramienta, buscando mejorar su rendimiento. Se diseñó, con este propósito, una segunda
versión del protocolo de transporte de paquetes IP sobre el núcleo de la red NDN, el cual pretende
optimizar el envío de paquetes a través del núcleo.
En el protocolo básico, cada paquete Data enviado a la red NDN, una vez completado todo el
procedimiento definido en el apartado anterior, transporta únicamente un paquete IP. Esto es, el
protocolo de intercambio de paquetes NDN entre gateways se activa una vez por cada paquete IP
capturado. Esta es la razón por la cual la tasa obtenida con la primera versión del protocolo es tan
reducida: el transporte de cada paquete IP genera el envío de 3 paquetes sobre el núcleo. La
motivación del diseño de la nueva versión del protocolo fue, por un lado, evitar esta limitación y,
por otro lado, aprovecharse de la realidad de la gran mayoría de aplicaciones actuales: un
consumidor, por regla general, no solicita solamente un dato al servidor, sino que solicita
múltiples datos y de manera consecutiva. Este es claramente el caso de, por ejemplo, cualquier
aplicación que implica la reproducción de contenidos multimedia.
El principal cambio del protocolo mejorado con respecto al básico es que, con esta nueva versión,
cada paquete Data que atraviesa el núcleo NDN puede contener uno o varios paquetes IP. La
característica común de todos los datagramas transportados en el mismo Data es que su gateway
destino es el mismo. Precisamente por este motivo, existe un cambio radical en cuanto al
modelado del sistema. Mientras que en la primera versión de la pasarela IP-NDN cada gateway
mantenía una sola cola con todos los paquetes IP pendientes, en esta nueva versión, el gateway
mantiene una cola independiente por cada otro gateway del núcleo.9 Además, cada cola tiene su
propio número de secuencia para identificar unívocamente a los elementos que la integran. Estos
elementos ya no son paquetes IP individuales, sino que se trata de macro-paquetes. Este término
lo utilizaremos de ahora en adelante para referirnos a la concatenación de varios paquetes IP con
un mismo gateway destino. Así, con esta nueva versión, el contenido de cada paquete Data
enviado será un macro-paquete. Cada uno estará integrado por un número de paquetes IP variable,
condicionado por el tamaño de estos. Esta restricción viene dada por el propio NFD, ya que limita
la longitud máxima de los datos transportados en un paquete Data.
Para implementar este cambio conceptual en el protocolo, se realizaron numerosos cambios en la
implementación de la pasarela IP-NDN. Sin embargo, no fue necesario cambiar nada del
procedimiento ejecutado en cada gateway para la captura y procesado de paquetes IP entrantes.
Es decir, el proceso descrito en el apartado 4.3 se mantiene exactamente igual. Tampoco hay
variaciones en el intercambio de mensajes entre los gateways (Interest request, Interest datagram
y Data), a excepción de que el nombre de los paquetes Interest datagram incluye a mayores el
identificador del gateway que lo envía. Este parámetro, con la nueva versión, es necesario para
9
El resto de gateways presentes en el núcleo se conocen gracias a la tabla de encaminamiento cargada en
cada gateway durante su inicialización.
14Escuela de Grado en Ingeniería de Mención:
Ingeniería de Tecnologías de Telemática
Telecomunicación
Telecomunicación
que el gateway que desea enviar el macro-paquete sepa de qué cola extraerlo. Esto se traduce en
que, ahora, el número de secuencia ya no basta para identificar un paquete pendiente en el
gateway, sino que se necesita conocer a mayores a qué cola pertenece.
Las modificaciones más significativas en cuanto a la operativa de la herramienta se reflejan en
los diagramas de actividad de la Figura 8. En concreto, el funcionamiento cambia a partir del
momento en el que el gateway, durante la ejecución del callback pcap_callback, comprueba su
tabla de encaminamiento y procede a almacenar el paquete. Ahora, la búsqueda de una entrada
coincidente en su tabla de encaminamiento, además de indicar si el destino es alcanzable a través
del núcleo y hacia qué gateway enviar (o no) el Interest request, permite conocer en qué cola se
debe almacenar este nuevo paquete IP. La lógica detrás del propio proceso de añadir el datagrama
a la cola correspondiente es mucho más complejo que en la versión básica de la pasarela. Antes
bastaba con generar un nuevo objeto de la clase Paquete_cola y añadirlo al map que modelaba la
cola del nodo, asociándole el número de secuencia correspondiente como identificador. Sin
embargo, ahora, las acciones del gateway a la hora de almacenar el datagrama capturado dependen
de su estado. Tal y como se muestra en el diagrama central de la Figura 8:
1. Primero se comprueba si la cola para el gateway destino en cuestión está vacía, es decir,
si no contiene ningún macro-paquete aún. Si lo está, se crea un nuevo macro-paquete con
el datagrama, asignándole el número de secuencia que corresponda en ese momento.
2. Si en la cola ya hay algún macro-paquete, se procede a comprobar si es viable concatenar
el nuevo datagrama al último macro-paquete de la cola. Para que esto sea factible, deben
darse dos condiciones. Por un lado, la suma de la longitud de dicho macro-paquete (la
longitud del conjunto de paquetes IP que lo conforman) y la longitud del nuevo paquete
IP, no puede superar el máximo impuesto para un paquete Data. A mayores, dicho macro-
paquete no puede estar ya en proceso de ser enviado en un paquete Data. En caso de
cumplirse ambas condiciones, el nuevo paquete IP se concatena al final de este último
macro-paquete, sin necesidad de añadir uno nuevo a la cola.
3. Por el contrario, si la suma anterior supera el tamaño máximo o si el último macro-
paquete está siendo procesado para enviarse, se crea un nuevo macro-paquete con este
datagrama. Se le asocia el número de secuencia siguiente al último empleado en su cola,
actualizando así dicho contador para este gateway destino.
El resultado de la lógica anterior determina la respuesta a la cuestión fundamental de este nuevo
protocolo: ¿es necesario enviar un nuevo Interest request a la red? La respuesta es directa:
solamente es necesario si se generó un nuevo macro-paquete. Por el contrario, si el paquete IP
entrante se concatenó a un macro-paquete ya existente en la cola, el gateway sabe que
eventualmente recibirá el Interest datagram que le permitirá incluir este paquete IP en un Data.
Por lo tanto, no tiene necesidad de volver a solicitarlo con un nuevo Interest request, ahorrando
así el intercambio de 3 nuevos paquetes NDN en el núcleo.
Estas modificaciones a la hora de almacenar y gestionar los paquetes IP pendientes no se traducen
en cambios significativos en la forma de recuperarlos de la cola. El proceso es muy semejante a
la versión básica de la pasarela. Lo único que cambia es que, como ya se insinuaba previamente,
el gateway que recibe el Interest datagram no solo emplea el número de secuencia indicado, sino
que también debe saber a qué cola acudir según el gateway del que proviene el Interest. Pero el
sistema de búsqueda y recuperación es el mismo: el número de secuencia permite extraer
directamente el macro-paquete concreto de la cola, ya que sigue siendo modelada por un map.
Estos datos son directamente el contenido del Data que envía al gateway en respuesta.
15También puede leer
