República Bolivariana de Venezuela

Ministerio del Poder Popular para la Educación Superior

Universidad José Antonio Páez

INFORME SOBRE EL
IETF

Alumno:

Luis Muñoz. C.I. 19.860.020

San Diego, 03 de octubre de 2018.

Vaya al sitio web de la IETF (www.ietf.org) e investigue a que se dedica
esta organización. Elija un proyecto que estén llevando a cabo y escriba
un informe de máximo 3 páginas acerca del problema y solución que
propone.

LA IETF (Internet Engineering Task Force) es una gran comunidad

internacional abierta de diseñadores de redes, operadores, proveedores e
investigadores preocupados por la evolución de la arquitectura de Internet y el
buen funcionamiento de Internet.

Los trabajos o documentos al interior del IETF se plasman en RFC “Requests

for Comments” (en español “petición de comentarios”). Estos documentos o
trabajos, cuando se publican después de un proceso que asegura
precisamente el consenso, se convierten en estándares o protocolos. Los más
importantes están reflejados en este formato. El protocolo IP detallado en el
RFC 791, el File Transfer Protocol para compartir archivos en el RFC 959, o el
HTTP —escrito por Tim Berners Lee— en el RFC 2616. Más adelante en este
mismo documento, se explicara mucho más minuciosamente lo referente a las
RFCs.

Naturalmente, todo RFC comienza como un borrador o “I-Ds” (Internet Draft).

Estos I-Ds están disponibles para proporcionar a los autores la capacidad de
distribuir y solicitar comentarios sobre documentos que eventualmente pueden
enviar para su publicación como RFC. Sin embargo cabe aclarar que los I-Ds
no son una serie de documentos de archivo y que los I-Ds no deben ser citados
en ningún documento formal, excepto como "trabajo en progreso".
Los documentos no revisados colocados en el apartado de I-Ds tienen una vida
útil máxima de 185 días. Después de ese tiempo, si la I-Ds no se actualiza, se
eliminará. El documento RFC 2026 da una información más detallada sobre
estos.

Hay ocho áreas en el IETF: aplicaciones y tiempo real, general, internet,

operaciones y manejo, routing, seguridad, transporte e investigación. En cada
una hay un director de área que se encarga de llevar los borradores (I-Ds) con
los comentarios incorporados al Internet Engineering Steering Group “IESG”
(en español “Grupo Directivo de Ingeniería de Internet”). Ahí se anuncia
una última llamada para comentarios, se revisan, discuten e incorporan más
criterios hasta lograr un consenso u acuerdo sólido que se convierte en RFC.
Cada borrador se puede presentar a título individual o vía un grupo de trabajo
adherido a alguna de las áreas.
De acuerdo a lo requerido en el primer apartado de la asignación #1, nos
enfocaremos en las I-Ds (Internet Draft) como “proyectos que se estén llevando
a cabo” para elegir. No iremos directamente a las RFCs.
Como se mencionaba anteriormente, existen 8 áreas en el IETF. Para el
proyecto a elegir como ejemplo, me centralice en el área de “Aplicaciones y
tiempo real, apartado de “Mantenimiento del núcleo de transporte de audio /
video (avtcore)” en inglés “Applications and Real - Time, Audio/Video Transport
Core Maintenance (avtcore)”
Dentro de este apartado, encontraremos varios documentos I-Ds activos, entre
ellos está “Enviar múltiples tipos de medios en una única sesión RTP”, en
inglés “Sending Multiple Types of Media in a Single RTP Session”
Antes de analizar esta I-Ds, debemos tener algún conocimiento sobre el
protocolo RTP (Protocolo de trasporte en tiempo real), en ingles “Real-time
Transport Protocol”. Este se define como un formato de paquete estándar para
el envío de audio y video sobre Internet.
Este protocolo está definido como estándar contenido en la RFC 1889 (primera
publicación en el año 1996), y actualizado posteriormente en el año 2003 en la
RFC 3550. Fue desarrollado por el grupo de trabajo de transporte de audio y
video y fue publicado en 1996. El protocolo RTP se utiliza ampliamente en los
sistemas de comunicación y entretenimiento que involucran medios de
transmisión, tales como la telefonía, aplicaciones de videoconferencias,
servicios de televisión y web basado en funcionalidades push-to-talk.

Ya una vez orientados en el contexto, el contenido de esta I-Ds se basa

directamente en el Protocolo de transporte en tiempo real RFC 3550, diseñado
para utilizar sesiones RTP separadas para transportar diferentes tipos de
medios. Esto implica que diferentes flujos de capa de transporte se utilizan para
diferentes RTP Streams o corrientes. Tomando como ejemplo, una aplicación
de videoconferencia podría enviar flujos de RTP de tráfico de audio y video en
puertos UDP separados, con el mayor uso de las direcciones de redes/puertos
de traducción, firewalls y otras middleboxes. Sin embargo se les hace difícil
establecer múltiples capas de transporte que fluyen entre puntos finales. Por lo
tanto, hay presión para reducir el número de flujos de transporte concurrentes
utilizados por aplicaciones RTP.
EL protocolo RTP fue diseñado para soportar sesiones multimedia, que
contiene múltiples tipos de medios enviados simultáneamente, mediante el uso
de múltiples flujos de capas de transporte. La existencia de traductores de red,
firewalls y otras middleboxes complica esto. Sin embargo, estos son
necesarios para garantizar que todos los flujos de la capa de transporte
requeridos por él, puedan establecer la aplicación. Esto tiene tres
consecuencias:

1. Mayor demora para establecer una sesión completa, ya que cada uno de los
flujos de la capa de transporte necesitan ser negociados y establecidos.
2. Incremento del consumo de estado y recursos en los middleboxes que
puede conducir a un comportamiento inesperado cuando los límites de
recursos de middlebox se alcanzan.

3. mayor riesgo de que no se pueda establecer un subconjunto de flujos de la

capa de transporte, lo que impide que la aplicación se comunique.

Esta I-Ds indica que el uso de menos flujos de la capa de transporte reduce el
riesgo de falla de la comunicación y puede conducir a una mayor fiabilidad y
rendimiento.

Una de las ventajas de utilizar múltiples flujos de capa de transporte es que

facilita el uso de los mecanismos de calidad de servicio (QoS) de la capa de
red para proporcionar un rendimiento diferenciado para diferentes flujos. Sin
embargo, notamos que muchas aplicaciones que usan RTP no usan las
características de la calidad de servicio de la red (QoS), y no esperan ni
desean ninguna separación en el tratamiento de la red de sus paquetes de
medios, independientemente de si son de audio, video o texto. Cuando una
aplicación no tiene tal deseo, no necesita proporcionar una estructura de flujo
de transporte que simplifique la QoS basada en el flujo.

Dados los problemas anteriores, podría parecer apropiado que las aplicaciones
basadas en RTP envíen todos sus flujos de RTP agrupados en una sesión de
RTP, ejecutándose en un solo flujo de capa de transporte.

Sin embargo, esto está prohibido por la especificación del protocolo RTP,
porque el diseño de RTP hace ciertas suposiciones que pueden ser
incompatibles con el envío múltiples tipos de medios en una sola sesión RTP.
Específicamente, las reglas de tiempo del protocolo de control (RTCP) asumen
que todos los flujos de medios RTP, en una sola sesión RTP, tienen requisitos
de retroalimentación y retroalimentación RTCP similares en general, lo que
puede ser problemático cuando se multiplexan diferentes tipos de medios.
Varias extensiones RTP también hacen suposiciones sobre el uso de SSRC y
los informes RTCP que son incompatibles con el envío de diferentes tipos de
medios en una sola sesión RTP.

Esta I-Ds actualiza los RFC 3550 y RFC 3551, para permitir que las sesiones
RTP contengan más de un tipo de medio en ciertas circunstancias, y da
orientación sobre cuándo es seguro enviar múltiples tipos de medios en una
sola sesión RTP.
¿Qué es un RFC?
RFC (Request For Comments) que en español se traduce como “solicitud de
comentarios” o “A petición de comentarios”, consiste en un documento (escrito
en formato de texto ASCII) que contiene una propuesta para una nueva
tecnología, información acerca del uso de tecnologías y/o recursos existentes,
propuestas para mejoras de tecnologías y proyectos experimentales.
Las RFC conforman básicamente la documentación de protocolos y
tecnologías de Internet, siendo incluso muchas de ellas estándares. Las
mismas son mantenidas por el IETF (Internet Engineering Task Force) y son
accesibles por cualquier persona debido a que son publicadas online y sin
restricciones. Pueden consultarse las mismas en la página de búsqueda de
RFCs del IETF.
La serie RFC tiene una larga historia. La serie se originó en 1969 por Steve
Crocker de UCLA, para organizar las notas de trabajo del nuevo programa de
investigación ARPAnet. El acceso a los datos en línea (por ejemplo, FTP) se
definió en las primeras RFC, y la serie RFC se convirtió en la primera serie de
publicaciones en línea. Durante 28 años, esta serie de RFC fue gestionada y
editada por el pionero de Internet Jon Postel.
La metodología que se utiliza con las RFC es asignarle a cada una un número
único que la identifique y que es el consecutivo de la última RFC publicada.
Una RFC ya publicada jamás puede modificarse, no existen varias versiones
de una RFC. Lo que se hace, en cambio, es escribir una nueva RFC que deje
obsoleta o complemente una RFC anterior.

¿Cuál es su objetivo?
El principal objetivo de las RFCs es hacer que Internet funcione mejor mediante
la producción de documentos técnicos relevantes y de alta calidad que influyen
en la forma en que las personas diseñan, usan y administran Internet.

Una gran parte de los estándares utilizados en Internet están publicados en

RFC. Algunos RFC básicos han sido aprobados oficialmente como estándares.
Sin embargo, la mayoría de RFC no logra alcanzar el estatus de estándar, pero
no obstante se utilizan como tales en todo el mundo. La razón por la que esto
ocurre es que en los grupos o personas colaborativos RFC se invierte el tiempo
principalmente en mejorar los protocolos y no en estandarizarlos.
En las primeras publicaciones de RFC se presentaron supuestos técnicos para
su discusión. Además, el Request for Comments sigue manteniendo su nombre
a pesar de gozar de la aceptación general como un cuasi estándar. La
numeración de un RFC puede cambiar cuando surge un documento nuevo con
modificaciones o suplementos sustanciales o cuando supone una recopilación
de varios precursores.
Los protocolos más importantes de Internet están definidos por RFC, como el
protocolo IP detallado en el RFC 791, el FTP en el RFC 959, o el HTTP —
escrito por Tim Berners-Lee et al.— en el RFC 2616

¿Cómo podría usted beneficiarse del uso y/o consulta de una RFC?

Como estudiantes de ingeniería en telecomunicaciones y específicamente en la

asignatura de transmisión de datos, es imperativo adquirir los conocimientos en
cómo han sido creadas las redes de comunicaciones, como estas han ido
evolucionando a través de los años mediante la creación y actualización de los
diferentes protocolos necesarios para que estas funcionen y tener una visión
hacia donde se dirige el futuro de la redes en general.

Para adquirir estos conocimientos y comprenderlos, que mejor fuente que citar
o consultar las RFCs publicadas por el IETF, las cuales señalan y describen los
protocolos estandarizados de comunicación a nivel mundial. Básicamente
serian como la biblia del internet, y al ser expuestas al público en general, son
una herramienta muy poderosa de las cuales se puede uno beneficiar.

El provecho que puede extraerse al usar o consultar las RFCs, incide

directamente en el conocimiento que estas brindan, ya sea orientados a un
protocolo en específico. Del análisis y comprensión de estos documentos,
pueden surgir ideas de actualizaciones de los protocolos ya estandarizados y
de la creación de nuevas tecnologías de comunicación.

Los RFCs expresan algo esencial: internet es un sistema de tecnología

cambiante. Los documentos de hoy pueden cambiar el mañana.