<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:dc="http://purl.org/dc/elements/1.1/" version="2.0">
<channel>
<title>I Taller del Grupo de Trabajo de Ingeniería de Internet/Argentina (IETF Day 2015)</title>
<link>http://sedici.unlp.edu.ar:80/handle/10915/54842</link>
<description/>
<pubDate>Tue, 20 Oct 2026 18:48:31 GMT</pubDate>
<dc:date>2026-10-20T18:48:31Z</dc:date>
<item>
<title>Aplicaciones del RFC 5213 – Proxy Mobile IPv6 – Comparación de ambientes móviles en redes académicas</title>
<link>http://sedici.unlp.edu.ar:80/handle/10915/55106</link>
<description>Objeto de conferencia
I Taller del Grupo de Trabajo de Ingeniería de Internet/Argentina (IETF Day 2015) - JAIIO 44 (Rosario, 2015)
The use of academic networks is producing important changes in research and education fields, providing new tools that bring us closer to other scientific and educational worldwide communities. Thus, investigations can be carried out between geographically dispersed work teams. A good complement for these scenarios is the use of mobility techniques. In this paper, a comparison between two different mobile IP alternatives is presented. Evaluated standards are Mobile IPv6 (MIPv6) and Proxy Mobile IPv6 (PMIPv6). Performance, advantages, disadvantages, configuration and installation comparisons are made. Afterwards the behavior of handover is evaluated for traditional and real time applications. Finally, comparisons and a conclusion are made.
</description>
<pubDate>Thu, 01 Jan 2015 00:00:00 GMT</pubDate>
<guid isPermaLink="false">http://sedici.unlp.edu.ar:80/handle/10915/55106</guid>
<dc:date>2015-01-01T00:00:00Z</dc:date>
<dc:description>The use of academic networks is producing important changes in research and education fields, providing new tools that bring us closer to other scientific and educational worldwide communities. Thus, investigations can be carried out between geographically dispersed work teams. A good complement for these scenarios is the use of mobility techniques. In this paper, a comparison between two different mobile IP alternatives is presented. Evaluated standards are Mobile IPv6 (MIPv6) and Proxy Mobile IPv6 (PMIPv6). Performance, advantages, disadvantages, configuration and installation comparisons are made. Afterwards the behavior of handover is evaluated for traditional and real time applications. Finally, comparisons and a conclusion are made.</dc:description>
</item>
<item>
<title>Aplicaciones del RFC 4944 - 6lowPAN - en IoT SIPIA6 - Red de Sensores Inalámbricos con IPv6</title>
<link>http://sedici.unlp.edu.ar:80/handle/10915/55105</link>
<description>Objeto de conferencia
I Taller del Grupo de Trabajo de Ingeniería de Internet/Argentina (IETF Day 2015) - JAIIO 44 (Rosario, 2015)
El proyecto consiste en el diseño y validación del comportamiento de una red de sensores inalámbricos en la adquisición de parámetros ambientales de parcelas agrícolas, con acceso de forma nativa a Internet, denominada SIPIA6. Es la continuación de Red SIPIA, actualmente implementada en una parcela agrícola de prueba. La red SIPIA está basada en la norma IEEE 802.15.4, aplicada al entorno agropecuario en el ámbito de agricultura de precisión. La diferencia principal de la Red SIPIA6 es que sus nodos WSN serán visibles desde Internet y accesibles mediante protocolos y procedimientos estándares. Principalmente se utiliza el protocolo 6lowPAN lo que permite extender la visibilidad de una red de sensores agrícola y por lo tanto convertir a SIPIA6 en una aplicación de Internet de las Cosas.
</description>
<pubDate>Thu, 01 Jan 2015 00:00:00 GMT</pubDate>
<guid isPermaLink="false">http://sedici.unlp.edu.ar:80/handle/10915/55105</guid>
<dc:date>2015-01-01T00:00:00Z</dc:date>
<dc:description>El proyecto consiste en el diseño y validación del comportamiento de una red de sensores inalámbricos en la adquisición de parámetros ambientales de parcelas agrícolas, con acceso de forma nativa a Internet, denominada SIPIA6. Es la continuación de Red SIPIA, actualmente implementada en una parcela agrícola de prueba. La red SIPIA está basada en la norma IEEE 802.15.4, aplicada al entorno agropecuario en el ámbito de agricultura de precisión. La diferencia principal de la Red SIPIA6 es que sus nodos WSN serán visibles desde Internet y accesibles mediante protocolos y procedimientos estándares. Principalmente se utiliza el protocolo 6lowPAN lo que permite extender la visibilidad de una red de sensores agrícola y por lo tanto convertir a SIPIA6 en una aplicación de Internet de las Cosas.</dc:description>
</item>
<item>
<title>Fortalecimiento en la seguridad de web services para aplicaciones críticas</title>
<link>http://sedici.unlp.edu.ar:80/handle/10915/55104</link>
<description>Objeto de conferencia
I Taller del Grupo de Trabajo de Ingeniería de Internet/Argentina (IETF Day 2015) - JAIIO 44 (Rosario, 2015)
Reconociendo a las propiedades de la Seguridad de la Información (confidencialidad, integridad y disponibilidad) como elementos esenciales de cualquier transferencia de datos, haciendo foco en el conjunto de protocolos y estándares utilizados para intercambiar datos entre aplicaciones web, es decir, Web Services, para el presente trabajo definimos el objetivo general de asegurar dichas comunicaciones, teniendo en consideración que la información intercambiada es igual o más crítica y confidencial que la transferida entre sistemas informáticos con la interacción humana.&#13;
Vamos a definir a las Aplicaciones Críticas, aquellas que se encuentran corriendo dentro de las Infraestructuras Críticas, siendo éstas las definidas por la Oficina Nacional de Tecnología de Información (ONTI), dependiente de la Jefatura de Gabinete de Ministros. En este marco es que los aspectos de seguridad cobran una relevancia superior y por tanto los esfuerzos para segurizar los sistemas deben ser extremos. Bajo este objetivo general, se definieron lineamientos particulares para efectuar lo que denominamos “hardening de seguridad de Web Services”, lo que implica la conformación de una guía mediante la cual se establecen medidas de seguridad que ayudan a disminuir los riesgos de violación de las propiedades de seguridad mencionadas.
</description>
<pubDate>Thu, 01 Jan 2015 00:00:00 GMT</pubDate>
<guid isPermaLink="false">http://sedici.unlp.edu.ar:80/handle/10915/55104</guid>
<dc:date>2015-01-01T00:00:00Z</dc:date>
<dc:description>Reconociendo a las propiedades de la Seguridad de la Información (confidencialidad, integridad y disponibilidad) como elementos esenciales de cualquier transferencia de datos, haciendo foco en el conjunto de protocolos y estándares utilizados para intercambiar datos entre aplicaciones web, es decir, Web Services, para el presente trabajo definimos el objetivo general de asegurar dichas comunicaciones, teniendo en consideración que la información intercambiada es igual o más crítica y confidencial que la transferida entre sistemas informáticos con la interacción humana.&#13;
Vamos a definir a las Aplicaciones Críticas, aquellas que se encuentran corriendo dentro de las Infraestructuras Críticas, siendo éstas las definidas por la Oficina Nacional de Tecnología de Información (ONTI), dependiente de la Jefatura de Gabinete de Ministros. En este marco es que los aspectos de seguridad cobran una relevancia superior y por tanto los esfuerzos para segurizar los sistemas deben ser extremos. Bajo este objetivo general, se definieron lineamientos particulares para efectuar lo que denominamos “hardening de seguridad de Web Services”, lo que implica la conformación de una guía mediante la cual se establecen medidas de seguridad que ayudan a disminuir los riesgos de violación de las propiedades de seguridad mencionadas.</dc:description>
</item>
<item>
<title>Demora en cola aplicada al control de congestión TCP</title>
<link>http://sedici.unlp.edu.ar:80/handle/10915/54843</link>
<description>Objeto de conferencia
I Taller del Grupo de Trabajo de Ingeniería de Internet/Argentina (IETF Day 2015) - JAIIO 44 (Rosario, 2015)
Los métodos de control de congestión utilizados por TCP se basan en modificar la tasa de envío en función de la carga de la red. Tradicionalmente la estimación se hacía sólo en base a las pérdidas de paquetes. Dos problemas conocidos de este mecanismo son la necesaria producci´on de pérdidas  de paquetes para estimar la carga y la sincronización de flujos. En 1989 surge la idea de utilizar la demora ida y vuelta experimentada por los paquetes (RTT) para detectar la congestión anticipadamente. El emisor disminuye entonces su tasa de envío antes de que se produzca una pérdida, mejorando la eficiencia del protocolo y el throughput de la red (p. ej. TCP Vegas y FAST).&#13;
Si bien medir el RTT es sencillo, el valor obtenido no basta para una correcta estimación de la carga, ya que se debe tener en cuenta, entre otros factores, la asimetría en los caminos de ida y de vuelta. Por eso se ha intentado estimar la carga en la red de manera más precisa a partir de la demora emisor-receptor (OWD: one way delay). Sin embargo, medir esta demora no es inmediato, ya que los relojes del emisor y del receptor deben estar sincronizados, para lo que se recurre a servidores NTP o uso de GPS. Esto es adecuado para algunas aplicaciones (p.ej.VoIP), pero no para el caso de flujos TCP, ya que por su número y ubicación pueden generar un overhead considerable (NTP) o no tener capacidad de GPS.
</description>
<pubDate>Thu, 01 Jan 2015 00:00:00 GMT</pubDate>
<guid isPermaLink="false">http://sedici.unlp.edu.ar:80/handle/10915/54843</guid>
<dc:date>2015-01-01T00:00:00Z</dc:date>
<dc:description>Los métodos de control de congestión utilizados por TCP se basan en modificar la tasa de envío en función de la carga de la red. Tradicionalmente la estimación se hacía sólo en base a las pérdidas de paquetes. Dos problemas conocidos de este mecanismo son la necesaria producci´on de pérdidas  de paquetes para estimar la carga y la sincronización de flujos. En 1989 surge la idea de utilizar la demora ida y vuelta experimentada por los paquetes (RTT) para detectar la congestión anticipadamente. El emisor disminuye entonces su tasa de envío antes de que se produzca una pérdida, mejorando la eficiencia del protocolo y el throughput de la red (p. ej. TCP Vegas y FAST).&#13;
Si bien medir el RTT es sencillo, el valor obtenido no basta para una correcta estimación de la carga, ya que se debe tener en cuenta, entre otros factores, la asimetría en los caminos de ida y de vuelta. Por eso se ha intentado estimar la carga en la red de manera más precisa a partir de la demora emisor-receptor (OWD: one way delay). Sin embargo, medir esta demora no es inmediato, ya que los relojes del emisor y del receptor deben estar sincronizados, para lo que se recurre a servidores NTP o uso de GPS. Esto es adecuado para algunas aplicaciones (p.ej.VoIP), pero no para el caso de flujos TCP, ya que por su número y ubicación pueden generar un overhead considerable (NTP) o no tener capacidad de GPS.</dc:description>
</item>
</channel>
</rss>
