Maestra en Ingeniera de Telecomunicaciones y Networking

Curso: Redes y Protocolos de Comunicacin

Tema: Practica Calificada N1

Catedrtico: Mg. Ing. Jos Luis Muoz Meza Alumno: Ing. Jose Martn Cabellos Gomez

(Pregunta 1) Proporcione algunos ejemplos de duplicidad de funciones entre las distintas capas de la arquitectura de redes IP y haga un anlisis de porque ocurre dicha situacin.

Fuente :Redes de Computadoras Andrew S.Tanenbaun

(Pregunta 2) Describa brevemente el mecanismo de direccionamiento en una red Ethernet. Est preparado para comunicaciones punto-punto y multipunto? Explique. Cada dispositivo equipado con Ethernet opera en forma independiente del resto de los dispositivos de la red, las redes Ethernet no hacen uso de un dispositivo central de control. Todos los dispositivos son conectados a un canal de comunicaciones de seales compartidas. Las seales Ethernet son transmitidas en serie, se transmite un bit a la vez. Las transmisiones se realizan a travs del canal de seales compartidas donde todos los dispositivos conectados pueden escuchar la transmisin. Antes de comenzar una transmisin, un dispositivo escucha el canal de transmisin para ver si se encuentra libre de transmisiones. Si el canal se encuentra libre, el dispositivo puede transmitir sus datos en la forma de una trama Ethernet. Despus de que es transmitida una trama, todos los dispositivos de la red compiten por la siguiente oportunidad de transmitir una trama. La disputa por la oportunidad de transmitir entre los dispositivos es pareja, para asegurar que el acceso al canal de comunicaciones sea justo, ningn dispositivo puede bloquear a otros dispositivos. El acceso al canal de comunicaciones compartido es determinado por la subcapa MAC. Este control de acceso al medio es conocido como CSMA/CS. Direccionamiento Los campos de direcciones en una trama Ethernet llevan direcciones de 48 bits, tanto para la direccin de destino como la de origen. El estndar IEEE administra parte del campo de las direcciones mediante el control de la asignacin un identificador de 24 bits conocido como OUI (Organizationally Unique Identifier, identificador nico de organizacin). A cada organizacin que desee construir interfaces de red (NIC) Ethernet, se le asigna un OUI de 24 bits nico, el cual es utilizado como los primeros 24 bits de la direccin de 48 bits del NIC. La direccin de 48 bits es referida como direccin fsica, direccin de hardware, o direccin MAC. El uso de direcciones nicas preasignadas, simplifica el montaje y crecimiento de una red Ethernet. La topologa lgica de una red determina como las seales son transferidas en la red. La topologa lgica de una red Ethernet provee un nico canal de comunicaciones que transporta seales de todos los dispositivos conectados. Esta topologa lgica puede ser diferente de la topologa fsica o de la disposicin real del medio. Por ejemplo, si los segmentos del medio de una red Ethernet se encuentran conectados fsicamente siguiendo una topologa estrella, la topologa lgica continua siendo la de un nico canal de comunicaciones que transporta seales de todos los dispositivos conectados.

Mltiples segmentos Ethernet pueden ser interconectados utilizando repetidores para formar una red LAN ms grande. Cada segmento de medio es parte del sistema de seales Como se ha comentado en el artculo anterior, el protocolo ethernet enva seales que llega a todos los nodos conectados al medio, y por tanto la direccin de destino dentro de la trama es crtica para identificar el nodo al que se quiere llegar. Por ejemplo, si tenemos tres ordenadores conectados en una misma red ethernet los cuales llamaremos ordenadores 1, 2 y 3 y una impresora a la misma red, cuando el ordenador 2 transmite seales a la impresora, los ordenadores 1 y 3 seguirn recibiendo y examinando la trama. Sin embargo, cuando una de las estaciones recibe una trama primero, verifica la direccin destino para ver si la trama estaba pensada para que el la recibiera. Si no es as, la estacin descarta la trama sin ni siquiera examinar el contenido. Una de las cosas interesantes sobre el direccionamiento ethernet es la implementacin de las direcciones broadcast. Una trama con una direccin de destino igual a la direccin de broadcast, est pensada para cualquier nodo en la red, y todos los nodos recibirn y procesarn este tipo de trama. El problema en una red ethernet, sobre todo con tantas tramas yendo y viniendo, provocan choques y colisiones que pueden entorpecer el fluir de la informacin de una manera correcta. Precisamente por este motivo, existe algo conocido como CSMA/CD (carrier-sense multiple access with collision detection) y describe como el protocolo ethernet regula la comunicacin entre los nodos.

El trmino traducido al espaol significa ms o menos portador sensible de mltiple acceso con deteccin de colisiones. Aunque pueda sonar intimidatorio, si la separamos en conceptos, veremos que es ms sencillo de lo que parece. Para ilustrar la operacin que realiza el protocolo ethernet, usaremos la analoga de una conversacin de un grupo de personas mientras cenan en un restaurante. Representaremos el segmento ethernet como la mesa donde el grupo de amigos estn comiendo, y los amigos que estn metidos en una animada conversacin representarn los nodos. El trmino mltiple acceso cubre lo que ya hemos mencionado: Cuando una estacin ethernet transmite, todas las estaciones en el medio escuchan la transmisin, de igual manera que una persona en la mesa est hablando, todo el mundo es capaz de escucharla sin problemas. Ahora imaginemos que t ests sentado en la mesa y tienes algo que quisieras decir. Sin embargo, por el momento hay una persona que est hablando. Al ser esto una conversacin muy educada, en lugar de empezar a hablar e interrumpir a la persona que est hablando, prefieres esperar a que acabe de hablar para poder comentar lo que quieres. Este es el mismo concepto descrito en el protocolo ethernet mencionado como portador sensible. Antes de que una estacin transmita, escucha al medio para determinar si otra estacin est transmitiendo. Si el medio est callado, la estacin reconoce que es un momento apropiado para empezar a transmitir.

CSMA/CD nos da un buen comienzo a la hora de regular una conversacin, pero hay un escenario que tenemos que tener en cuenta. Si volvemos a la mesa del restaurante e imaginamos que hay un momento de silencio y dos personas quieren decir algo. Ambas personas podran empezar al mismo tiempo a hablar. En trminos ethernet lo que ocurre es una colisin cuando dos ordenadores hablan al mismo tiempo. En una conversacin mientras comemos, podemos manejar esta situacin sin problemas y de una forma amigable. Uno de los dos se callara mientras la otra persona termina de hablar. Los nodos ethernet tambin escuchan en el medio mientras estn transmitiendo para asegurarse de que son los nicos que estn trasmitiendo al mismo tiempo. Si la transmisin escucha su propia transmisin en cualquier forma, al igual que pasara con cualquier otra transmisin, entender que ha ocurrido una colisin. Un nico segmento ethernet es algunas veces llamado dominio de colisin, porque dos estaciones no pueden transmitir al mismo tiempo sin tener una colisin. Cuando las estaciones detectan una colisin, cesan la transmisin, esperan un cierto tiempo, y luego intentan transmitir de nuevo cuando detectan que vuelve a haber silencio en el medio. Esta pausa aleatoria de tiempo y el volver a intentar transmitir, es una parte importante del protocolo ethernet. Si dos estaciones colisiones cuando estn transmitiendo al mismo tiempo, ambas tendrn que transmitir de nuevo. En la siguiente oportunidad de transmitir, ambas estaciones que han tenido la colisin tendrn los datos preparados para transmitir. Si vuelven a transmitir a la primera opcin, podran volver a colisionar de nuevo y as sucesivamente. En lugar de eso, el retraso aleatorio hace poco probable que dos estaciones colisionen cuando estn en un mismo segmento. Las redes Ethernet definen un esquema de direccionamiento de 48 bits. Cada computadora conectada a una red Ethernet es asignada a un nmero nico de 48 bits conocido como direccin Ethernet. Para asignar una direccin, los fabricantes de hardware de Ethernet adquieren bloques de direcciones Ethernet y las asignan en secuencia conforme fabrican el hardware de interfaz Ethernet. De esta manera no existen dos unidades de hardware de interfaz que tengan la misma direccin Ethernet. Por lo general, las direcciones Ethernet se fijan en las mquinas en el hardware de interfaz de anfitrin de forma que se puedan leer. Debido a que el direccionamiento Ethernet se da entre dispositivos de hardware, a estos se les llama a veces direccionamientos o direcciones fsicas. Tmese en cuenta la siguiente propiedad importante de las direcciones fsicas Ethernet: Las direcciones fsicas estn asociadas con el hardware de interfaz Ethernet; cambiar el hardware de interfaz a una mquina nueva o reemplazar el hardware de interfaz que ha fallado provocar cambios en la direccin fsica de la mquina. Conociendo la direccin fsica Ethernet se pueden hacer cambios con facilidad porque los niveles superiores del software de red estn diseados para adaptarse a estos cambios.

El hardware de interfaz anfitrin examina los paquetes y determina qu paquetes deben enviarse al anfitrin. Debe recordarse que cada interfaz recibe una copia de todos los paquetes aun cuando estn direccionados hacia otras mquinas. La interfaz de anfitrin utiliza el campo de direccin de destino de un paquete como filtro. La interfaz ignora los paquetes que est direccionados hacia otras mquinas y selecciona slo los paquetes direccionados hacia el anfitrin. El mecanismo de direccionamiento y filtrado de hardware es necesario para prevenir que una computadora sea abrumada con la entrada de datos. Aun cuando el procesador central de la computadora podra realizar la verificacin, sta se realiza en la interfaz de anfitrin haciendo que el trfico en la red Ethernet sea un proceso menos lento en todas las computadoras.

DIRECCIN DESTINO: (6 bytes) La direccin destino (DD) es de 48 bits (6 bytes) de tamao, el cual se transmite primero el bit menos significativo. La DD es utilizada por la MAC receptora, para determinar si el paquete entrante es direccionado a un nodo en particular. Si el nodo receptor detecta una correspondencia entre su direccin y la direccin dentro de la DD, intentar recibir el paquete. Los otros nodos, los cuales no detectan una correspondencia, ignorarn el resto del paquete. Existen tres tipos de direcciones destino soportadas: 1.-Individual (fsica): El campo DD contiene una direccin nica e individual asignada a un nodo en la red. 2.- Multicast (lgica): Si el primer bit (el menos significativo) del campo DA es asignado, esto denota que una Direccin de Grupo est siendo usada. El "grupo" de nodos que sern direccionados son determinados por las funciones de las capas superiores, pero en general el intento es transmitir un mensaje a un subconjunto similar lgicamente de nodos en la red por instancia, todos los dispositivos de impresin. 3.-Broadcast: esta es una forma especial de multicast, donde el campo DD son puros 1s. La direccin todos 1s es reservada para la funcin broadcast y todos los dispositivos MAC en la red debern ser capaces de recibir el mensaje broadcast. La estructura de la direccin destino es como sigue: I/G U/L bits de la direccin MAC I/G Direccin Individual/Grupo 0 1 Direccin individual Direccin de grupo

U/L Direccin Universal/Local

0 Administrada Universalmente 1 Administrada Localmente

Protocolo Punto a Punto sobre Ethernet (PPPoE)The working standard for the PPPoE protocol was published by the IETF in 1999.El estndar de trabajo para el protocolo PPPoE fue publicado por el IETF en 1999. The IETF specification for PPPoE is RFC 2516. La especificacin IETF para PPPoE es RFC 2516. PPPoE expands the original capability of PPP by allowing a virtual point to point connection over a multipoint Ethernet network architecture. PPPoE expande la capacidad original de PPP, permitiendo un punto virtual para apuntar conexin a travs de una arquitectura de red Ethernet multipunto. PPPoE is a protocol that is widely used by ISPs to provision digital subscriber line (DSL) high speed Internet services, of which the most popular service is ADSL. PPPoE es un protocolo que se utiliza ampliamente por los ISP a disposicin de lnea de abonado digital (DSL) servicios de alta velocidad a Internet, de los cuales el servicio ms popular es el ADSL. The similarity between PPPoE and PPP has led to the widespread adoption of PPPoE as the preferred protocol for implementing high speed Internet access. La similitud entre PPPoE y el PPP ha dado lugar a la adopcin generalizada de PPPoE como el protocolo preferido para implementar el acceso a Internet de alta velocidad. Service providers can use the same authentication server for both PPP and PPPoE sessions, resulting in a cost savings. Los proveedores de servicios pueden utilizar el servidor de autenticacin mismo para ambos PPP y sesiones PPPoE, resultando en un ahorro de costes. PPPoE uses standard methods of encryption, authentication, and compression specified by PPP. PPPoE utiliza los mtodos estndar de encriptacin, autenticacin, y la compresin especificada por el PPP. PPPoE is configured as a point to point connection between two Ethernet ports.PPPoE se configura como una conexin punto a punto entre dos puertos Ethernet. As a tunneling protocol, PPPoE is used as an effective foundation for the transport of IP packets at the network layer. Como protocolo de tnel, PPPoE se utiliza como una base eficaz para el transporte de paquetes IP en la capa de red. IP is overlaid over a PPP connection and uses PPP as a virtual dial up connection between points on the network. IP se superpone sobre una conexin PPP y utiliza PPP como un dial virtual de la conexin entre los puntos de la red. From the user's perspective, a PPPoE session is initiated by using connection software on the client machine or router. Desde la perspectiva del usuario, una sesin de PPPoE se inicia

mediante el uso de software de conexin en el equipo cliente o un router. PPPoE session initiation involves the identification of the Media Access Control (MAC) address of the remote device. La iniciacin PPPoE sesin implica la identificacin de la Media Access Control (MAC) del dispositivo remoto. This process, also known as PPPoE discovery, involves the following steps: Este proceso, conocido tambin como PPPoE descubrimiento, implica los pasos siguientes:1. Iniciacin - El software de cliente enva un PPPoE Active Descubrimiento de

iniciacin (PADI) de paquetes al servidor para intitiate la sesin. 2. Oferta - El servidor responde con una oferta de PPPoE Active Discovery (PADO) paquete.3. Solicitud - Una vez recibido el paquete PADO, el cliente responde con el

envo de una solicitud de PPPoE Active Discovery (PADR) paquete al servidor. 4. Confirmacin - Al recibir el paquete PADR, el servidor responde mediante la generacin de un identificador nico para la sesin PPP y lo enva en una sesin de PPPoE Active Descubrimiento (PAD) de paquetes de confirmacin para el cliente. When a PPPoE session is initiated, the destination IP address is only used when the session is active.Cuando una sesin de PPPoE se inicia, la direccin IP de destino slo se utiliza cuando la sesin est activa. The IP address is released after the session is closed, allowing for efficient re-use of IP addresses. La direccin IP se libera despus de la sesin se cierra, lo que permite la reutilizacin eficiente de direcciones IP.

Metro EthernetLa Red Metro Ethernet, es una arquitectura tecnolgica destinada a suministrar servicios de conectividad MAN/WAN de nivel 2, a travs de UNIs Ethernet. Estas redes denominadas "multiservicio", soportan una amplia gama de servicios, aplicaciones, contando con mecanismos donde se incluye soporte a trfico "RTP" (tiempo real), como puede ser Telefona IP y Video IP, este tipo de trfico resulta especialmente sensible a retardo, al jitter y al grudge.

La utilizacin de las lneas de cobre (MAN BUCLE), garantiza el despliegue de un punto de red ethernet, en cualquier punto del casco urbano. Las redes Metro Ethernet, estn soportadas principalmente por medios de transmisin guiados, como son el cobre (MAN BUCLE) y la fibra ptica, existiendo tambin soluciones de radio licenciada, los caudales proporcionados son de 10Mbps, 20Mbps, 34Mbps, 100Mbps, 1Gbps y 10Gbps. La tecnologa de agregacin de mltiples pares de cobre, (MAN BUCLE), permite la entrega de entre 10 Mbps, 20 Mbps, 34Mbps y 100Mbps, mediante la transmisin simultanea de mltiples lneas de cobre, adems esta tcnica cuenta con muy alta disponibilidad ya que imposible la rotura de todas las lneas de cobre y en caso de rotura parcial el enlace sigue transmitiendo y reduce el ancho de banda de forma proporcional. La fibra ptica y el cobre, se complementan de forma ideal en el mbito metropolitano, ofreciendo cobertura total a cualquier servicio, a desplegar Los beneficios que Metro Ethernet ofrece son: Presencia y capilaridad prcticamente "universal" en el mbito metropolitano, en especial gracias a la disponibilidad de las lneas de cobre, con cobertura universal en el mbito del urbano. Muy alta fiabilidad, ya que los enlaces de cobre certificados Metro Ethernet, estn constituidos por mltiples pares de en lneas de cobre (MAN BUCLE) y los enlaces de Fibra ptica, se configuran mediante Spanning tree (activopasivo) o LACP (caudal Agregado).

Fcil uso: Interconectando con Ethernet se simplifica las operaciones de red, administracin, manejo y actualizacin Economa: los servicios Ethernet reducen el capital de suscripcin y operacin de tres formas:

o

o

o

o

Amplio uso: se emplean interfaces Ethernet que son la ms difundidas para las soluciones de Networking Bajo costo: Los servicios Ethernet ofrecen un bajo costo en la administracin, operacin y funcionamiento de la red. Ancho de banda: Los servicios Ethernet permiten a los usuarios acceder a conexiones de banda ancha a menor costo. Flexibilidad: Las redes de conectividad mediante Ethernet permiten modificar y manipular de una manera ms dinmica, verstil y eficiente, el ancho de banda y la cantidad de usuarios en corto tiempo. El modelo bsico de los servicios Metro Ethernet, est compuesto por una Red switcheada MEN (Metro Ethernet Network), ofrecida por el proveedor de servicios; los usuarios acceden a la red mediante CEs (Customer Equipment), CE puede ser un router; Bridge IEEE 802.1Q (switch) que se conectan a travs de UNIs (User Network Interface) a velocidades de 10Mbps, 20Mbps, 34Mbps, 100Mbps, 1Gbps y 10Gbps. Los organismos de estandarizacin (IEEE, IETF, ITU) y los acuerdos entre fabricantes, estn jugando un papel determinante en su evolucin. Incluso se ha creado el MEF (Metro Ethernet Forum), organismo dedicado nicamente a definir Ethernet como servicio metropolitano.

EVC (Ethernet Virtual Connection)Un EVC es la asociacin entre una o ms interfaces UNIs (User Network Interface). Es un tubo virtual que proporciona al usuario servicios extremo a extremo atravesando mltiples redes MEN (Metro Ethernet Network). Un EVC tiene dos funciones:o

o

Conectar dos o ms sitios (UNIs) habilitando la transferencia de tramas Ethernet entre ellos. Impedir la transferencia de datos entre usuarios que no son parte del mismo EVC, permitiendo privacidad y seguridad.

Un EVC puede ser usado para construir VPN (Virtual Private Network) de nivel 2.

El MEF (Metro Ethernet Frum) ha definido dos tipos de EVC: Punto a Punto (E-Line) Multipunto a Multipunto (E-LAN)

E-LINEEl servicio E-Line proporciona un EVC punto a punto entre dos interfaces UNI (User Network Interface). Se utiliza para proporcionar una conexin Ethernet punto a punto. Dentro del tipo de servicio E-Line se incluye una amplia gama de servicios. El ms sencillo consistente en un ancho de banda simtrico para transmisin de datos en ambas direcciones y no fiable, entre dos interfaces UNI a 10 Mbps. Un servicio ms sofisticado considerado dentro del tipo de servicio E-Line sera, por ejemplo, una lnea E-Line, que ofrezca una CIR concreta junto con una CBS, y una EIR junto con una EBS, y un retardo, variacin del retardo y ver mximos asegurados entre dos interfaces UNI.

E-LANEl tipo de servicio E-LAN proporciona conectividad multipunto a multipunto. Conecta dos o ms interfaces UNI (User Network Interface). Los datos enviados desde un UNI llegarn a 1 ms UNI destino. Cada uno de ellos est conectado a un EVC multipunto. A medida que va creciendo la red y se van aadiendo ms interfaces UNI, stos se conectarn al mismo EVC multipunto, simplificando enormemente la configuracin de la misma. Desde el punto de vista del usuario, la E-LAN se comporta como una LAN. Su estructura esta basa en modelo de capas, las capas que lo conforman son: Core, Distribucin, y acceso.

Atributos de los servicios Metro Ethernet

Los atributos se definen como las capacidades de los diferentes tipos de servicio. Algunos atributos aplican a los puntos de acceso UNI (User Network Interface), mientras que otros a los canales virtuales (EVC). Para los puntos de acceso (UNI) aplican los siguientes atributos:o

o

o

o

Medio fsico: son los especificados en el estndar 802.3 2000. Ejemplos de medios fsicos incluye 10Base-T, 100Base-T, 1000 BaseSX. Velocidad: las velocidades son las especificadas en el estndar Ethernet son las caractersticas de la "negociacin ethernet, aadindose algunos valores intermedios: 10Mbps, 20Mbps, 45Mbps, 100Mbps, 1Gbps y 10Gbps. Modo: un enlace puede soportar Full Duplex, Half Duplex o auto negociacin. Capa MAC: las especificadas en IEEE 802.3 2000.

Caractersticas del ancho de bandaPara Metro Ethernet se tienen en cuenta los siguientes parmetros: CIR (Committed Information Rate): es la cantidad promedio de informacin que se ha transmitido, teniendo en cuenta los retardos, prdidas, etc. CBS (Committed Burst Size): es el tamao de la informacin utilizado para obtener el CIR respectivo. EIR (Excess Information Rate): especifica la cantidad de informacin mayor o igual que el CIR, hasta el cual las tramas son transmitidas sin prdidas. EBS (Excess Burst Size): es el tamao de informacin que se necesita para obtener el EIR determinado

(Pregunta 3) Elaborar una relacin de 10 nuevos protocolos que se vienen desarrollando para atender las nuevas aplicaciones sobre las redes de tipo IP, en cualquiera de las capas de la arquitectura y mencione su mbito de aplicacin o problema que intenta resolver.

SIGTRAN es el nombre del grupo de trabajo de la IETF (Internet Engineering Task Force) que ha desarrollado una serie de protocolos que permiten transportar sealizacin SS7 por redes IP. Por extensin llamamos SIGTRAN a este grupo de protocolos. El protocolo ms significativo es SCTP (Stream Control Transmission Protocol), es el protocolo de nivel de transporte, altenativa a TCP y UDP Para ms informacin sobre SIGTRAN consultar el RFC 2719: Architectural Framework for Signaling Transport. Ejemplos de implementacin son Signalware de Ulticom, SINAP/IP de Stratus, OpenSS7 y LeibICT Sealizacin de Transporte (SIGTRAN) se refiere a una pila de protocolos para el transporte de red de conmutacin de circuitos (SCN) protocolos de sealizacin (SS7/C7) sobre una red IP. SIGTRAN es la evolucin de SS7, que define los adaptadores y una capacidad de transporte bsico donde se mezclan protocolos SS7 y de paquetes para ofrecer a los usuarios lo mejor de ambas tecnologas. Aplicaciones de SIGTRAN incluyen: Internet por Dial-Up, telefona IP interconectada con PSTN y otros servicios. Los componentes clave en la arquitectura SIGTRAN son los siguientes: MGC-Media Gateway Controller, responsable de mediar el control de llamadas (entre la SG y MG) y controlar el acceso del mundo IP hacia y desde la PSTN. SG-Signaling Gateway, responsable de la interconexin a la red SS7 y la transmisin de mensajes de sealizacin a los nodos IP. MG-Media Gateway, responsable de empaquetar de trfico de voz y transmisin del trfico hacia el destino. IP SCP, IP con control de servicios (SCP). Esto existe ntegramente dentro de la red IP, pero es direccionable de la red SS7. Telfono IP, genricamente conocido como terminal. Las interfaces relacionadas con la sealizacin de transporte incluyen la SG a MGC, SG a SG. El transporte de sealizacin potencialmente se puede aplicar a la MGC a MGC o MG MGC a las interfaces, as, dependiendo de los requerimientos para el transporte del protocolo de sealizacin asociadas. Para interconexin con las redes SS7 SCNcontroladas, la SG termina el enlace SS7 y transfiere la informacin de sealizacin a la MGC para utilizar el transporte de sealizacin. El MG termina la troncal interconmutada y controla la base troncal en el control de sealizacin que recibe de la MGC. Para el interfuncionamiento con PSTN (Public Switched Telephone Network), las redes IP necesitarn para el transporte de sealizacin mensajes Q.931 o SS7 ISUP entre los nodos IP, como Signaling Gateway y Media Gateway Controller o Media Gateway. Stream

Control Transmission Protocol (SCTP), protocolo bsico en la pila SIGTRAN que proporciona servicio de transporte entre capas en IP. Algunos ejemplos son: transporte de sealizacin entre un Signaling Gateway y Media Gateway o Media Gateway Controller, el transporte de la sealizacin (" backhaul ") de un Media Gateway a un Media Gateway Controller; transporte de TCAP entre una puerta de enlace de sealizacin y de otros nodos IP. SCTP es utilizado por uno de los siguientes protocolos de usuario de adaptacin de capa: SUA: Signalling Connection Control Part User Adaptation Layer IUA: ISDN Q.921-User Adaptation Layer M3UA: SS7 Message Transfer Part 3 (MTP3) User Adaptation layer M2UA: SS7 Message Transfer Part 2 (MTP2) User Adaptation layer M2PA: MTP2 Peer-to-peer user Adaptation layer V5UA: V5.2-User Adaptation Layer Para cada uno, la pila SS7 se sustituye en una de sus capas bien definidas con un reemplazo de transporte de paquetes. Al mover hasta las capas superiores de la pila ms alta, ms conceptos del legado SS7 pueden ser eliminados y reemplazados con paquetes flexibles y las capacidades de enrutamiento IP. Como SIGTRAN es un estndar de la industria, permite a los clientes interactuar en un entorno multi-fabricante 1.- Transmission of IPv6 Packets over Bluetooth Low Energy draft-ietf-6lowpan-btle06 Energa baja Bluetooth es una tecnologa de bajo consumo de energa del aire interfaz definida por el Bluetooth Special Interest Group (SIG BT). La norma Radio Bluetooth se ha aplicado y est disponible en el mvil telfonos, ordenadores porttiles, auriculares de audio y muchos otros dispositivos. La versin de baja potencia de la tecnologa Bluetooth es una especificacin nueva y permite el uso de esta interfase aire con dispositivos tales como sensores, inteligente metros, electrodomsticos, etc La variante de bajo consumo de Bluetooth es normalmente se especifica en la revisin 4.0 de las especificaciones de Bluetooth y conoce comnmente como Bluetooth 4.0. Este documento describe cmo IPv6 se transporta a travs de Bluetooth de bajo uso de energa 6LoWPAN tcnicas.Active Internet-Draft (6lowpan WG) Document Stream: Last updated: Replaces:

IETF 2012-03-06 draft-patil-6lowpan-v6over-btle

2.-MPTCP Application Interface Considerations draft-ietf-mptcp-api-04 Multipath TCP (MPTCP) aade la posibilidad de usar varias rutas de acceso a la un perodo ordinario de sesiones TCP. A pesar de que est diseado para ser totalmente compatible con versiones anteriores de aplicaciones, el transporte de datos difiere en comparacin con TCP ordinario, y hay varios grados adicionales de la libertad que las

aplicaciones pueden querer explotar. Este documento resume el impacto que puede tener MPTCP en aplicaciones, tales como cambios en el rendimiento. Adems, se analiza la compatibilidad temas de MPTCP en combinacin con la no MPTCP aplicaciones compatibles. Finalmente, el documento describe una interfaz de aplicacin bsica para MPTCP aplicaciones compatibles que proporciona acceso a la direccin de trayectoria mltiple informacin y un nivel de control equivalente a TCP regular.Active Internet-Draft (mptcp WG) Document Stream: Last updated: Replaces:

IETF 2012-02-16 draft-scharf-mptcp-api

3.- DHCP Options for the Port Control Protocol (PCP) En este documento se define la opcin de llevar un nombre en lugar de una IP direccin. Esta eleccin est motivada por consideraciones operativas: En particular, algunos proveedores de servicios estn considerando dos niveles de redireccin: (1) El primer nivel es nacional sabio est a cargo de DHCP: una regionales especficos FQDN ser devuelto; (2) El segundo nivel se lleva a cabo durante la resolucin de la-regional FQDN especfica para redirigir el cliente a un servidor PCP regionales entre un grupo desplegado regionalmente. Distintos equipos operativos son los responsables de cada una de las anteriores los niveles mencionados. Una separacin clara entre lo funcional permetro de cada equipo es una tarea sensible para el mantenimiento de la ofrecen los servicios. Los equipos regionales se requieren para introducir nuevas recursos (por ejemplo, nuevos dispositivos controlados por PCP como Carrier Grade NAT (CGCs, [ID.ietf se comportan los requisitos LSN])) para cumplir con un aumento la base de clientes. Operaciones relacionadas con la introduccin de estos nuevos dispositivos (por ejemplo, la direccin, cambio de direccin, etc) se aplican a nivel local. Contar con esta separacin regional ofrece flexibilidad para gestin de partes de la red operados por equipos especializados. Este informe de dos redireccin de nivel no pueden ser satisfechas por la opcin IP Address. Adems de las consideraciones operativas: o El uso del nombre de NAT64 [RFC6146] podra ser adecuado para equilibrio de carga de los efectos; o Para el caso DS-Lite [RFC6333], si el modo de encapsulacin se utiliza para enviar mensajes de PCP, una direccin IP puede ser utilizado desde el AFTR la seleccin se ha hecho a travs de la opcin de AFTR_NAME DHCPv6 [RFC6334]. Por supuesto, esto supone que el servidor de la PCP es co-

encuentra con la funcin de AFTR. Si estas encuentra, transmitiendo el nombre sera ms conveniente. 4.-LDP Downstream-on-Demand draft-ietf-mpls-ldp-dod-00 in

funciones Seamless

no

son

co-

MPLS

LDP (Label Distribution Protocol): un protocolo para la distribucin de etiquetas MPLS entre los equipos de la red.

Perfecta diseo de MPLS permite a una sola direccin IP / MPLS a escala en central, de metro y el acceso a partes de una infraestructura de red de paquetes grandes utilizando IP estndar / protocolos MPLS. Uno de los objetivos clave de la MPLS es perfecta para satisfacer los requisitos especficos de acceso, incluyendo elevado nmero de dispositivos, su posicin en la topologa de red y su calcular y limitaciones de la memoria que limitan la cantidad de acceso del Estado dispositivos puede contener. Esto se puede lograr con LDP downstream-on-demand (LDP del Departamento de Defensa) etiqueta de anuncio. Este documento describe el uso del Departamento de Defensa del PLD casos y listas que los procedimientos del Departamento de Defensa del PLD en el contexto de Perfecto diseo de MPLS. Adems, un nuevo tipo opcional TLV en el mensaje de solicitud de LDP etiqueta se define para la convergencia de rpido.5.- Protocol to Access WS database (paws)

Protocol to Access White Space database: PS, use cases and rqmts draft-ietf-paws-problem-stmt-usecases-rqmts-03 Las porciones del espectro de radio que estn asignados a un uso particular pero no han sido utilizados o desocupadas en lugares especficos y son los tiempos define como "espacio en blanco". El concepto de permitir adicional transmisiones (que pueden o no tener licencia) en el espacio en blanco es un tcnica para "desbloquear" el espectro existente para un nuevo uso. Una obvia requisito es que estas transmisiones adicionales no interfieran con el uso del espectro asignado. Un mtodo para usar el espectro de espacio en blanco en un momento dado y la ubicacin es verificar con un base de datos para los canales disponibles. Este documento describe el concepto de televisin espacios en blanco. tambin describe los problemas que necesitan ser abordados para permitir blanco el espacio del espectro para otros usos, sin causar interferencia a uso asignado, mediante la consulta de una base de datos que almacena informacin sobre la disponibilidad de canales en cualquier lugar dado y tiempo. Un nmero de posibles casos de uso del espectro de espacio en blanco y tecnologa, as como una serie de requisitos para la consulta de base de datos protocolo tambin se describen.

6.Home Networking Architecture for IPv6 draft-ietf-homenet-arch-01 Este texto describe evolucin de la tecnologa de redes en pequea "vivienda residencial" redes. El objetivo de esta nota es para definir la arquitectura de redes para el hogar basada en IPv6 y el correspondiente principios, consideraciones y exigencias. El texto pone de relieve la impacto de IPv6 en las redes para el hogar, muestra escenarios de la topologa, y muestra cmo los mecanismos estndar IPv6 y abordar puede ser empleado en las redes domsticas. La arquitectura describe la necesidad de especfica extensiones de protocolo para cierta funcionalidad adicional. es supone que la red local IPv6 no es una gestin activa, y se ejecuta como una red slo IPv6 o doble pila. No hay recomendaciones en este texto para la parte de la red IPv4 .Active Internet-Draft (homenet WG) Document Stream: Last updated: Replaces: IETF 2012-01-30 draft-chown-homenet-arch

7.- Native NAT Traversal Mode for the Host Identity Protocol draft-ietf-hip-native-nat-traversal-02 Este documento especifica un traductor de direcciones de red nueva (NAT) el modo de desplazamiento para el anfitrin de Identidad Protocolo (HIP). El nuevo modo es basado en el establecimiento interactivo de conectividad (ICE), la metodologa y UDP encapsulacin de datos y el trfico de sealizacin. El principal diferencia de los modos anteriormente especificadas es el uso de HIP mensajes para todos los procedimientos de NAT transversal.Active Internet-Draft (hip WG) Document Stream: Last updated:

IETF 2011-12-22

8.- Applicability of Access Node Control Mechanism to PON based Broadband Networks draft-ietf-ancp-pon-02

El propsito de este documento es proporcionar aplicabilidad del Nodo de acceso a los mecanismos de control, como se describe en [RFC5851], de acceso de banda ancha basado en PON. La necesidad de un nodo de control de acceso Mecanismo de entre un Network Access Server (NAS) y un nodo de acceso Complejo (una combinacin de terminacin de lnea ptica (OLT) y La terminacin de red ptica (ONT) elementos) se describe en un multi-servicio arquitectura de referencia con el fin de realizar la QoS

afines, relacionados con el servicio y la relacionada con las operaciones de abonado. la Nodo de Acceso mecanismo de control se extiende tambin para la interaccin entre los componentes del complejo nodo de acceso (OLT y ONT). la Nodo de acceso a mecanismo de control se asegurar de que la transmisin de informacin entre el NAS y el Nodo de acceso complejo (Ans) y entre la OLT y la ONT en un ANX no necesita ir a travs de directivos distintos de los elementos sino que utiliza una relacin directa de dispositivo a dispositivo de comunicacin y estancias en la red. Esto permite realizar acceder a las operaciones relacionadas con el enlace dentro de esos elementos de la red a cumplir con los objetivos de rendimiento.Active Internet-Draft (ancp WG) Document Stream: Last updated:

IETF 2012-01-17

9.- Dynamic Link Exchange Protocol (DLEP) draft-ietf-manet-dlep-02

Cuando los dispositivos de encaminamiento se basan en los mdems para efectuar las comunicaciones a travs enlaces inalmbricos, es necesario el conocimiento puntual y preciso de la caractersticas del enlace (velocidad, estado, etc) a fin de que transmisin de las decisiones. En los entornos mviles o de otro tipo cuando stas caractersticas cambian con frecuencia, configuraciones manuales o los inferencia de Estado a travs de protocolos de enrutamiento o de transporte no permitir que el router para tomar las mejores decisiones. Un evento bidireccional, canal de comunicacin impulsada entre el router y el mdem es necesarioActive Internet-Draft (manet WG) Document Stream: Last updated: Replaces:

IETF 2012-02-06 draft-sratliff-manet-dlep

10.-OSPF Hybrid Broadcast draft-ietf-ospf-hybrid-bcast-and-p2mp-01

and

P2MP

Interface

Type

Este documento describe un mecanismo para modelar una red de difusin como un hbrido de difusin y redes punto a multipunto para los propsitos de OSPF operacin. Vecino descubrimiento y mantenimiento, as como LSA la sincronizacin de base de datos se realiz mediante el modelo de radiodifusin, pero la red se representa mediante el modelo de punto a multipunto en el LSA del router de los routers conectados a l. Esto permite una exacta

representacin de los costes de comunicacin entre diferentes routers en la red, manteniendo al mismo tiempo la eficiencia de la red de difusin operacin. Este enfoque es relativamente simple y requiere una mnima cambios en OSPF.Active Internet-Draft (ospf WG) Document Stream: Last updated: Intended RFC status:

IETF 2012-02-29 -

11.-The OAuth draft-ietf-oauth-v2-25

2.0

Authorization

Protocol

El protocolo OAuth 2.0 autorizacin permite a un tercero solicitud para obtener acceso limitado a un servicio HTTP, ya sea sobre nombre de un propietario del recurso por la orquestacin de una interaccin de aprobacin entre el propietario del recurso y el servicio HTTP, o al permitir que el aplicacin de terceros para obtener acceso en su propio nombre. este especificacin sustituye y deja obsoleto al protocolo descrito OAuth 1.0 en el RFC 5849Active Internet-Draft (oauth WG) Document Stream: Last updated: Intended RFC status:

IETF 2012-03-08 Proposed Standard

12.-Camellia Encryption draft-ietf-krb-wg-camellia-cts-01.

for

Kerberos

5

Este documento especifica dos tipos de cifrado y los correspondientes dos tipos de suma de comprobacin para el marco de Kerberos criptosistema definido en el RFC 3961. Los nuevos tipos de utilizar el cifrado de bloques de la camelia en el CBC-mode con texto cifrado el robo y el algoritmo de la CMAC de proteccin de la integridad.

Active Internet-Draft (krb-wg WG) Document Stream: Last updated: Intended RFC status:

IETF 2012-03-08 -

13.-Locator/ID draft-ietf-lisp-22

Separation

Protocol

(LISP)

Este proyecto describe un protocolo de capa de red basado en que permite a los separacin de las direcciones IP en dos nuevos espacios de numeracin: Punto final Identificadores (EER) y localizadores de enrutamiento (RLOCs). No hay cambios requerido para cualquiera de las pilas de protocolos de acogida o el "ncleo" de la Infraestructura de Internet. LISP puede ser desplegado de forma incremental, sin un "Da de la Bandera", y ofrece ingeniera de trfico, mltiples-homing, y beneficios de la movilidad a los primeros usuarios, incluso cuando hay relativamente pocos LISP capaces sitios. Diseo y desarrollo de LISP fue motivada en gran parte por el problema relacin elaborada por el 10 2006 IAB Enrutamiento y direccionamiento Taller.Active Internet-Draft (lisp WG) Document Stream: Last updated: Intended RFC status:

IETF 2012-02-12 Experimental

14.-PCEP extensions draft-ietf-pce-gmpls-pcep-extensions-05

for

GMPLS

El clculo de rutas ptimas para Label Switched Paths (LSP) a travs de varios dominios en el trfico MPLS Ingeniera (MPLS-TE) y GMPLS redes presenta un problema, porque ni un solo punto de la ruta el clculo es consciente de todos los enlaces y recursos en cada dominio. Una solucin puede lograrse mediante el Path Computation Elemento (PCE) de la arquitectura. Cuando la secuencia de los dominios se conoce a priori, diversas tcnicas se pueden emplear para derivar una ruta ptima. Si los dominios son simplemente conexo, o si los puntos preferidos de la interconexin son tambin conocido, la tcnica Ruta por dominio Cmputo puede ser utilizado. Cuando hay mltiples conexiones entre los dominios y no hay ninguna preferencia para la eleccin de los puntos de interconexin, los Procedimiento Sendero Cmputo hacia atrs recursivo (BRPC) se puede utilizar para derivar una trayectoria ptima. Este documento examina las tcnicas para establecer la ruta ptima cuando se la secuencia de los dominios no se conoce de antemano. El documento muestra cmo la arquitectura PCE puede ser ampliado para que el ptimo secuencia de los dominios para ser seleccionadas, y la trayectoria ptima de extremo a

extremo que se derivan a travs del uso de una relacin jerrquica entre dominios.

Active Internet-Draft (pce WG) Document Stream: Last updated: Replaces: Intended RFC status:

IETF 2012-03-09 draft-margaria-pce-gmpls-pcep-extensions -

15.- MVPN: Using Bidirectional P-Tunnels draft-ietf-l3vpn-mvpn-bidir-01

Los documentos que especifican la compatibilidad con multidifusin de IP VPN BGP / MPLS permiten datos de los clientes de multidifusin para ser transportados a travs de un servicio proveedor de la red a travs de un tnel de multidifusin. Estos tneles son anunciada por BGP en un atributo BGP conocido como el proveedor de multidifusin " Interfaz de Servicio (GMPC) Atributo del tnel ". Las especificaciones de base permitir que el atributo Tunnel PMSI para hacer publicidad de multidifusin bidireccional rboles de distribucin como "PMSI Tneles", sin embargo, esos documentos no proporcionar todos los detalles necesarios para el uso de esos tneles. estos detalles se proporcionan en este documento. Este documento tambin especifica los procedimientos para la asignacin de los flujos de multidifusin especfica a los clientes bidireccionales tneles GMPC.Active Internet-Draft (l3vpn WG) Document Stream: Last updated: Replaces: Intended RFC status:

IETF 2012-02-06 draft-rosen-l3vpn-mvpn-bidir -

(Pregunta 4) El protocolo TCP es uno de los pilares de las redes IP, de hecho se suele usar el trmino redes TCP/IP. Elabore una lista de al menos cinco variantes de TCP y las caractersticas bsicas de cada variante.

HistoriaLas primeras implementaciones surgieron en los aos 1980 por parte de los sistemas BSD, que derivaban de los UNIX. En esta poca an se estaba desarrollando la historia de Internet.

Algunas versiones de BSD, y caractersticas TCP ofrecidas. 4.1aBSD, publicada en junio de 1981, ya tena una versin preliminar de TCP/IP, basada en el trabajo de Bolt, Beranek y Newman (BBN) pero algo modificada. La versin

4.1cBSD (1982) tuvo una implementacin mejor, y se incluy en 4.2BSD (1983), que fue la primera que se distribuy a gran escala. DARPA decidi que sera esta versin la que se quedara en 4.3BSD (junio de 1986); adems, en esta versin se mejor su rendimiento. De 4.3BSD deriva 4.3BSD-Tahoe (junio de 1988), y de sta 4.3BSD-Reno (1990), en el camino para la creacin de 4.4BSD (1993). Los nombres Tahoe y Reno son los que identificarn a las implementaciones TCP de estos sistemas. Corresponden a ciudades del estado de Nevada (Estados Unidos) famosas por sus casinos: Tahoe, Reno (Nevada); tambin Las Vegas sirve como nombre a otra versin de 1994. Un listado del nivel de implementacin de TCP en cada una de estas versiones es: 1

1983: 4.2BSD: primera versin ampliamente disponible de TCP/IP 1986: 4.3BSD: mejor rendimiento de TCP 1988: 4.3BSD-Tahoe: inicio lento ("slow-start"), control de congestin ("congestion avoidance"), retransmisin rpida ("fast retransmit") 1990: 4.3BSD-Reno: recuperacin rpida ("fast recovery"), prediccin de cabeceras TCP, cabecera SLIP, compresin 1993: 4.4BSD: multidifusin, modificaciones para canales de alto rendimiento (RFC 1323) 1994: 4.4BSD-Lite

Existe poca documentacin tcnica que recoja los cambios entre versiones. En los libros de Karels y McKusick de 1986 se describen los cambios de 4.2BSD a 4.3BSD, y Jacobson describe en 1990 los cambios de 4.3BSD-Tahoe a 4.3BSD-Reno. (,1 pg. 5)

Implementaciones baseDurante el inicio de TCP hubo tres implementaciones base:

Tahoe, la de 4.3BSD-Tahoe, derivado de 4.3BSD Reno, la de 4.3BSD-Reno, derivada de Tahoe, y usada despus en 4.4BSD-Lite Vegas, que mejora a Reno en velocidad entre un 40 y 70% (segn pgina de Vegas, de 1994)

Es especialmente importante la implementacin de TCP de 4.4BSD-Lite, que sali en junio de 1994, y es la que se toma como referencia por haber sido la base de muchos sistemas actuales. Hoy en da, se sigue usando para ensear cmo funciona un sistema TCP. 1 Muchas implementaciones actuales se han basado en alguna de estas tres en algn momento. Sin embargo, si hoy se creara una nueva, probablemente se basara en una de las modernas (como la de FreeBSD, OpenBSD, NetBSD o BSD/OS) antes que en la original de 4.4BSD-Lite. La reutilizacin del cdigo de BSD fue posible debido a su licencia (licencia BSD), que permite que sea usado en otros sistemas, tanto software libre como propietario. Por

ejemplo, Microsoft Windows usa cdigo derivado de BSD en su implementacin de TCP, e incluye herramientas de red para consola originales de BSD (detalles). Tambin Darwin BSD, el sistema base de Mac OS X, parcialmente deriva de FreeBSD 5. Otros UNIX comerciales, como Solaris, tambin incluyen cdigo BSD.

DerivadasSe han hecho varias versiones que mejoran a Tahoe, Reno y Vegas. Por ejemplo, segn,2 las ms populares son:

Tahoe sin "Fast Retransmit": incluye inicio lento y control de congestin Tahoe: incluye tambin retransmisin rpida Reno: aade recuperacin rpida a Tahoe New-Reno: versin de Reno con un sistema mejorado de recuperacin rpida Reno Plus: en algunos sistemas Solaris SACK: usa confirmaciones (ACK) selectivas

Adems de Vegas, Peach, ATCP, y otras (Westwood, Hybla, etc.). En el mismo artculo se describen sus caractersticas, y, de entre las 6 de esta lista, se concluye que New-Reno es la implementacin ms fiable. Otro estudio s que tiene en cuenta a Vegas, y concluye que Vegas es mejor que el resto de implementaciones probadas (Tahoe, Reno, New-Reno y SACK).3

Implementaciones segn sistema operativoCada sistema operativo muestra un comportamiento distinto en cuanto a TCP, pero algunos se parecen entre ellos porque han compartido cdigo (principalmente, el de BSD). A veces se clasifican los sistemas segn a qu implementacin base se parecen (Tahoe, Reno, NewReno, Vegas, etc.). Los que usan un cdigo escrito desde cero son los que ms se diferencian del resto.

BSDEl 4.4BSD original (implementacin base) permite cuatro familias de protocolos: TCP/IP, Xerox Network Services (XNS), OSI, sockets IPC ("UNIX domain sockets"). En,1 pg. 9, se explica cmo est organizado el cdigo dentro del kernel, y en el resto del libro se explican las funciones de red. Otro estudio, modelizacin, y anlisis de rendimiento del BSD original es,4 que adems cita estudios anteriores hechos sobre este cdigo. Se explica tambin el funcionamiento de implementaciones derivadas, como la de FreeBSD, a la hora de montar un enrutador por software. FreeBSD, NetBSD y OpenBSD son todos derivados de BSD, y por eso han heredado algunos de sus protocolos de red.

LinuxEl cdigo de TCP en Linux se escribi de forma independiente al resto de implementaciones.5 Hay que tener en cuenta que, al estar bajo la licencia GPL, no podra haber usado el cdigo de los sistemas BSD, ya que stos usaban la licencia BSD original (con la clusula de publicidad), incompatible con la GPL (vase [1]). Esta clusula se quit mucho ms tarde, en 1999. Todos los detalles de implementacin de TCP en Linux estn visibles y explicados en su cdigo fuente, disponible en [2]. La parte relacionada con TCP en IPv4 est en el directorio net/ipv4/. Aqu se encuentran archivos importantes, como: tcp_ipv4.c tcp_input.c tcp_output.c

En net/ipv6/ est el cdigo para implementar TCP sobre IPv6. Es una adaptacin del cdigo para IPv4. En un sistema en ejecucin, varios parmetros de TCP se pueden ver y modificar mediante los archivos del directorio /proc, por ejemplo /proc/sys/net/ipv4/ Existen varios libros que explican los detalles de implementacin de TCP/IP en el ncleo Linux y analizan su cdigo. Uno de ellos, que describe hasta la versin 2.4, es:

Wehrle, Klaus; Pahlke, Frank; Ritter, Hartmut; Muller, Daniel; Bechler, Marc (2004). Linux Network Architecture. Prentice Hall. ISBN 0-13-177720-3.

Varios algoritmos de control de congestin seleccionables al compilar Linux (versin 2.6.17.4) Linux implementa muchos algoritmos de control de congestin. Por ejemplo, est SACK, Westwood+ (ver artculo explicativo: [3]), Reno, NewReno, FACK (forward acknowledgement), ECK, H-TCP, y varios ms. Desde la versin 2.6.19 se usa por defecto CUBIC con NewReno como salvaguarda.

Se puede cambiar el algoritmo usado por defecto ajustando las opciones de compilacin, tal como se ve en la imagen adjunta. Aunque al ser modular, tambin puede ser cambiado en caliente modificando /proc/sys/net/ipv4/tcp_congestion_control. Linux 2.4 usando el algoritmo SACK (acuse de recibo selectivo) consigue un rendimiento mayor que otros sistemas que tambin usan SACK (como OpenBSD y FreeBSD), segn 6 Comparando las implementaciones modernas (2004/2005), se ve que han evolucionado por caminos distintos, pero que todas aguantan bien la congestin de red (a diferencia de la implementacin original de BSD). Segn las pruebas, Linux 2.6 el que mejor rendimiento da (de entre FreeBSD 5.3, OpenBSD 3.5, y Windows XP Service Pack 2). 7 Como el desarrollo de Linux es un proceso abierto al pblico, en Internet se encuentran pginas que explican los problemas que daba su implementacin de TCP, y cmo se han solucionado. Por ejemplo: mejora de rendimiento en la versin 2.0.36 (marzo de 1999), problemas de TCP detectados al hacer una comparativa (1999), ajustes para 2.4 y 2.6 (febrero de 2006), problemas en los algoritmos de TCP en Linux 2.6.16.3 (junio de 2006), entre otros. Es habitual que estos fallos se detecten cuando alguien est escribiendo un documento tcnico o comparativa. En caso de comportamiento extrao, un estudio del cdigo fuente sirve para confirmar las sospechas y poder corregir el error en Linux. Como ejemplo, vanse los siguientes artculos sobre redes inalmbricas: 8 o sobre BIC-TCP: 9 .

WindowsSegn uno de los programadores del cdigo de red de Windows NT/2000: 10 Microsoft estaba programando en 1990 el sistema de red para Windows NT. El protocolo usado entonces era uno llamado NetBEUI, pero se vio que TCP/IP se volva cada vez ms importante, y por eso se decidi incluirlo en NT. De esta forma, Microsoft se haca compatible con los UNIX (que usaban TCP/IP desde 1982) a la vez que se posicionaba en contra de Novell Netware, que dominaba el mercado de redes en los aos 90 con su protocolo IPX/SPX (incompatible con TCP/IP hasta 1999). El hecho de incluir TCP/IP en Windows oblig a cambiar la interfaz de acceso a red de NetBEUI (que era NetBIOS) por un sistema de sockets llamado Winsock, basado en el de BSD (los sockets Berkeley). El propio cdigo de TCP/IP (la pila) se compr a una compaa llamada Spider Systems. Su versin estaba basada (total o parcialmente) en el cdigo de BSD y otros UNIX, ya que la licencia BSD lo permite (slo requiere dar crdito al autor original). Sin embargo, usaba la interfaz STREAMS, una alternativa a los sockets Berkeley, que serva como capa de abstraccin para los componentes de red como TCP e IP. Esto haca que la implementacin fuera ms lenta que si usara TCP/IP directamente, as que Microsoft escribi una pila TCP/IP nueva (quizs basndose en el cdigo anterior), que incluy en Windows NT y Windows 95. Por eso ambos sistemas muestran el mismo

comportamiento en las pruebas (ejemplo:5 ), que adems es distinto al de otras implementaciones. Junto con el cdigo comprado a Spider Systems, se incluan utilidades de red para consola, como los programas para Telnet, FTP, rcp o rsh, sacados directamente de BSD. stos no se reescribieron, ya que funcionaban bien y no hay problemas con la licencia. An se muestra el copyright original, que es The Regents of the University of California (universidad de la que forma parte Berkeley, que es la B del BSD). En cuanto a la parte tcnica: en [4] se describen algunos detalles de implementacin de TCP/IP en Windows 2000, incluyendo los RFC que cumple, la arquitectura de red, y los parmetros usados en TCP.

MacintoshLos primeros ordenadores de Apple Computer usaban la familia de protocolos AppleTalk (ya incluidos en el Apple Macintosh original, en 1984). Con el tiempo, estos protocolos se sustituyeron por la familia TCP/IP. A partir de la versin 7.5.1 de su sistema (System 7) se us la implementacin MacTCP, hoy considerada obsoleta y con problemas de compatibilidad con los protocolos actuales. En mayo de 1995, Apple present, junto con su Power Mac 9500, la arquitectura Open Transport, que es la que reemplazara a MacTCP (vase anuncio de 1995). Se incluy en la versin 7.5.2 del sistema, pero tambin se hizo disponible para versiones anteriores. Este entorno estaba basado en una implementacin de STREAMS llamada Mentat Portable Streams y comprada a la empresa Mentat (ms datos: [5]). Open Transport funcionaba ms rpido que MacTCP, por lo que tuvo buena acogida entre usuarios y programadores. Al ser un sistema STREAMS, permita gran flexilidad al aplicar filtros a protocolos. Se inclua cdigo para manejar TCP/IP, AppleTalk y dispositivos serie. Hay una descripcin extensa en: [6]. Sin embargo, ms adelante (al llegar Mac OS X) se abandon el sistema Open Transport basado en STREAMS- para adoptar los sockets Berkeley, mucho ms comunes. Mac OS X (de 2001) se desarroll basndose en Darwin BSD, que est basado en FreeBSD 5 y por tanto tiene una implementacin derivada de la de 4.4BSD. Existen diferencias entre FreeBSD y la versin Mac OS X (vase lista), pero no en cuanto a la implementacin de TCP.

Listado de versiones de TCP usadasAqu se listan varios sistemas operativos junto con el comportamiento TCP que presentan. Los resultados estn agrupados segn la fuente del estudio.

Segn un estudio de 1997 (5 ):

BSDI 1.1, 2.0, 2.1a: Reno DEC OSF/1 1.3a, 2.0, 3.0, 3.2: Reno HP/UX 9.05, 10.00: Reno IRIX 4.0, 5.1, 5.2, 5.3, 6.2a: Reno Linux 1.0: independiente NetBSD 1.0: Reno Solaris 2.3, 2.4: independiente SunOS 4.1: Tahoe Linux 2.0.30, 2.1.36: independiente Trumpet/Winsock 2.0b, 3.0c: independiente Windows 95, NT: independiente

Segn un estudio de 2000 (2 ):

FreeBSD 3.5.1, 4.2: Reno FreeBSD 4.3, 4.4, 4.5: New-Reno Windows 98, 2000: Tahoe sin "Fast Retransmit" RedHat 7.2: New-Reno

En 11 se estudian y describen otras:

Solaris 2.1 SunOS 4.0.3, 4.1.1 HP-UX 9.0 IRIX 5.1.1

(Pregunta 5) Qu finalidad tiene el campo DSCP y ECN en el protocolo IPv4. Cul(es) es (son) el(los) campo(s) que reemplazan sus funcionalidades en IPv6. DSCP ToS (Type of Service) para capacitar el marcado de paquetes con un nivel de servicio requerido. Esta definicin no se utiliz mayormente debido a la ambigedad de su significado, por lo que ms tarde se convirti en el denominado campo DSCP (Differentiated Services Code Point). Este campo s tuvo una aceptacin global y se asumi una interpretacin estndar que permiti a las redes planificar metodologas basndose en sta. Tal fue el xito de esta nueva definicin, que fue incluida para ofrecer las mismas ventajas en el protocolo IPv6 en el denominado campo TC (Traffic Class). Una vez que existe la capacidad de marcar los paquetes utilizando DSCP, es necesario proveer del tratamiento apropiado para cada una de estas clases. La coleccin de paquetes con el mismo valor DSCP circulando hacia una direccin determinada, es llamado Behavior Aggregate (BA). Es as cmo mltiples aplicaciones/fuentes pueden pertenecer al

mismo BA. El PHB se refiere a la programacin, encolamiento, limitacin y modelamiento del comportamiento de un nodo, basado en el BA perteneciente del paquete. ECN Notificacin explcita de congestin (ECN). Este campo se define en el RFC 3168 y permite extremo a extremo notificacin de congestin de la red sin abandonar paquetes. REC es una caracterstica opcional que slo se utiliza cuando ambos extremos se apoyan y estn dispuestos a usarlo. Slo es efectivo cuando el apoyo de la red subyacente. Notificacin explcita de congestin (ECN) es una extensin del protocolo de Internet y en el Protocolo de control de transmisin y se define en el RFC 3168 (2001). REC permite extremo a extremo de la notificacin de congestin de la red sin dejar caer los paquetes. REC es una caracterstica opcional que slo se utiliza cuando ambos extremos se apoyan y estn dispuestos a usarlo. Slo es efectivo cuando el apoyo de la red subyacente. Convencionalmente, el TCP / IP de la congestin de las redes de la seal por la cada de paquetes. Cuando REC se negoci con xito, un router ECN-aware puede establecer una marca en la cabecera IP en lugar de dejar caer un paquete con el fin de sealar la congestin inminente. El receptor del paquete se hace eco de la indicacin de la congestin al remitente, lo que reduce su velocidad de transmisin como si se detect un paquete descartado. OperationECN requiere un apoyo especfico a las capas de Internet y de transporte por las siguientes razones: 1. En los routers TCP / IP funcionan en su mayora en la capa de Internet, mientras que la tasa de transmisin est a cargo de los criterios de valoracin en la capa de transporte 2. Congestin slo debe ser manipulado por el transmisor pero puesto que se sabe que ha sucedido slo despus de un paquete fue enviado, debe haber un eco de la indicacin congestin por el receptor con el transmisor. Sin eco REC indicacin congestin se consigue indirectamente por la deteccin de paquetes perdidos. Con ECN, la congestin se indica mediante el establecimiento de los bits de la CE (ver ms abajo) en un paquete IP y se hizo eco de nuevo por el receptor al transmisor mediante el establecimiento de los bits apropiados en cabecera del protocolo de la capa de transporte. Por ejemplo, cuando a travs de TCP, la indicacin de la congestin se hizo eco de regreso al establecer el bit de la CEPE. El funcionamiento de la REC, con IPECN utiliza las dos menos significativos (extremo derecho) bits del campo DiffServ en la cabecera de IPv4 o IPv6 para codificar cuatro puntos de cdigo diferentes: 00: No ECN-Capacidad de Transporte - no TEC 10: Transporte ECN Capaz - TEC (0) 01: Transporte ECN Capaz - TEC (1) 11: Congestin encontrados CE

Cuando los dos extremos de apoyar a ECN que marcar sus paquetes con la ECT (0) o terapia electroconvulsiva (1). Si el paquete atraviesa una gestin activa de cola (AQM) de la cola (por ejemplo, una cola que utiliza Random Early Detection (RED)) que est experimentando congestin y el router correspondientes soportes de REC, puede cambiar el punto de cdigo a la CE en lugar de dejar caer el paquete. Este acto se conoce como "marcado" y su propsito es informar al extremo receptor de la congestin inminente. En el extremo receptor, la indicacin de congestin es manejada por el protocolo de capa superior (capa de transporte de protocolo) y necesita que se hiciera eco de nuevo al nodo de transmisin con el fin de sealar a reducir su velocidad de transmisin. Debido a que la indicacin CE slo pueden tratarse eficazmente por un protocolo de capa superior que soporta, REC slo se utiliza en conjuncin con los protocolos de capa superior (por ejemplo, TCP) que apoyo y control de la congestin, tener un mtodo para la indicacin CE eco hasta el punto final de transmisin. El funcionamiento de la REC, con TCPTCP soportes ECN con dos banderas en la cabecera TCP. Estos dos bits se utilizan para volver a la indicacin eco congestin (es decir, la seal del emisor para reducir la cantidad de informacin que enva) y reconocer que la congestin indicacin eco se recibi. Estos son los ECN-Echo (CEPE) y la ventana de la congestin fragmentos reducidos (CWR). El uso de ECN en una conexin TCP es opcional, por REC que se usa, debe ser negociado en el establecimiento de la conexin mediante la inclusin de las opciones adecuadas en el segmento SYN y SYN-ACK. Cuando REC se ha negociado en una conexin TCP, el emisor indica que los paquetes IP que llevan los segmentos TCP de esa conexin est llevando el trfico a partir de un transporte de ECN Capaz marcndolos con un punto de cdigo del Tratado CE. Esto permite que los routers intermedios que apoyan la REC para marcar los paquetes IP con el punto de cdigo CE en lugar de dejarlos caer con el fin de sealar la congestin inminente. Tras la recepcin de un paquete IP con la congestin experimentada punto de cdigo, el receptor TCP hace eco de esta indicacin de congestin con la bandera de la CEPE en la cabecera TCP. Cuando un extremo recibe un segmento TCP con el bit de la CEPE se reduce su ventana de congestin como por una cada de paquetes. A continuacin, se reconoce la indicacin de la congestin mediante el envo de un segmento con el bit CWR. Un nodo sigue transmitiendo segmentos TCP con el bit de la CEPE hasta que se recibe un segmento con el bit CWR. Para ver los paquetes afectados con tcpdump, utilice el predicado de filtro (tcp [13] y 0xC0! = 0). ECN y de control TCP packetsSince TCP no lleva a cabo el control de la congestin en los paquetes de control (ACK, SYN, puros segmentos FIN), los paquetes de control no estn normalmente marcados como ECN-capaz.

Una propuesta reciente [3] sugiere marcar los paquetes SYN-ACK como ECN-capaz. Esta mejora, conocido como REC +, se ha demostrado que proporciona importantes mejoras de rendimiento de corta duracin conexiones TCP. [4] El funcionamiento de la REC, con protocolsECN otro medio de transporte que se define para otros protocolos de capa de transporte que realizan el control de congestin, sobre todo DCCP y SCTP. El principio general es similar a TCP, aunque los detalles de la sobre-elalambre de codificacin diferentes. Se debe, en principio, ser posible utilizar ECN con los protocolos de capas por encima de UDP. Sin embargo, UDP requiere que el control de la congestin se realizar por la aplicacin, y las API de red actual no dan acceso a los bits ECN. Efectos sobre la performance Sinc REC slo es eficaz en combinacin con un sistema de gestin de colas activo (AQM) la poltica, los beneficios de la ECN dependen de la AQM precisa que se utilice. Algunas observaciones, sin embargo, parece que se mantienen a travs AQMS diferentes. Como se esperaba, REC reduce el nmero de paquetes perdidos por una conexin TCP, que, al evitar una retransmisin, reduce la latencia y jitter especialmente. Este efecto es ms drstico cuando la conexin TCP tiene un solo segmento excepcional, [5] cuando se es capaz de evitar un tiempo de espera de RTO, lo que a menudo es el caso de las conexiones interactivas (como inicios de sesin remotos) y los protocolos de transacciones (por ejemplo, las peticiones HTTP , la fase de conversacin de SMTP, o peticiones SQL). Efectos de la ECN en el rendimiento a granel son menos claras [6], porque las implementaciones modernas de TCP son bastante buenos para volver a enviar los segmentos se redujo de manera oportuna, cuando la ventana del emisor es muy grande. El uso de REC se ha encontrado que sea perjudicial para el rendimiento en redes altamente congestionadas utilizando algoritmos AQM que nunca abandonan los paquetes. [4] implementaciones modernas AQM evitar esta trampa dejando caer en lugar de marcar los paquetes con carga muy elevada. Implementaciones ImplementationsMany modernos de la suite de protocolos TCP / IP tienen algn tipo de apoyo para la ECN, sin embargo, por lo general vienen con ECN desactivado.

Para escribir la informacin sobre la calidad de servicio de cada datagrama se utiliza un campo de un byte en la cabecera denominado DS. El campo DS se estructura de la siguiente forma:

Subcampo DSCP (Differentiated Servcies CodePoint) ECN (Explicit Congestion Notification)

Longitud (bits) 6 2

El subcampo ECN tiene que ver con la notificacin de situaciones de congestin, cosa que trataremos ms adelante. En cuanto al subcampo DSCP nos permite definir en principio hasta 26 = 64 posibles categoras de trfico, aunque en la prctica se utilizan bastante menos, como veremos a continuacin. Los valores de DSCP se dividen en los tres grupos siguientes:

Codepoint Xxxyy0 xxxx11 xxxx01

Posibles Valores 32 16 16

Uso Estndar Local/Experimental Reservado

As pues, de momento se contemplan 32 posibles categoras de datagramas, correspondientes a los cinco primeros bits del campo DS. En DiffServ (Differentiated Services) se definen tres tipos de servicio, que son los siguientes: o Servicio Expedited Forwarding o Premium: Este servicio es el de mayor calidad. Se supone que debe ofrecer un servicio equivalente a una lnea dedicada virtual, o a un circuito ATM CBR o VBR-rt. Debe garantizar un caudal mnimo, una tasa mxima de prdida de paquetes, un retardo medio mximo y un jitter mximo. El valor del subcampo DSCP relacionado con este servicio es 101110. o Servicio Assured Forwarding: Este servicio asegura un trato preferente, pero no garantiza caudales, retardos, etc. Se definen cuatro clases posibles pudindose asignar a cada clase una cantidad de recursos en los routers (ancho de banda, espacio en buffers, etc.). La clase se indica en los tres primeros bits del DSCP. Para cada clase se definen tres categoras de descarte de paquetes (probabilidad alta, media y baja) que se especifican en los dos bits siguientes (cuarto y quinto). Existen por tanto 12 valores de DSCP diferentes asociados con este tipo de servicio, que son:

Precedencia de descarte Clase4 3 2 1 Baja 10001 01101 01001 00101 Media 10010 01110 01010 00110 Alta 10011 01111 01011 00111

Podemos imaginar la prioridad de descarte como algo equivalente al bit DE de Frame Relay o al bit CLP de ATM, solo que en este caso se pueden marcar tres prioridades de descarte diferentes en vez de dos. En muchas implementaciones se ignora el quinto bit del campo DSCP, con lo que las precedencias media y alta son equivalentes. En estos casos el cuarto bit del DSCP desarrolla un papel equivalente al bit DE de Frame Relay o al CLP de ATM.

En el servicio Assured Forwarding el proveedor puede aplicar traffic policing al usuario, y si el usuario excede lo pactado el proveedor puede descartar datagramas, o bien aumentar la precedencia de descarte. o Servicio Best Effort: este servicio se caracteriza por tener a cero los tres primeros bits del DSCP. En este caso los dos bits restantes pueden utilizarse para marcar una prioridad, dentro del grupo best effort. En este servicio no se ofrece ningn tipo de garantas.

El servicio Expedited Forwarding es aproximadamente equivalente al Servicio Garantizado de IntServ (Integrated Services), mientras que el Assured Forwarding corresponde ms o menos al Servicio de Carga Controlada de IntServ.

Algunos ISPs (proveedores de servicios Internet) ofrecen servicios denominados olmpicos con categoras denominadas oro, plata y normal (o tiempo-real, negocios y normal). Generalmente estos servicios se basan en las diversas clases del servicio Assured Forwarding. El campo DS es una incorporacin reciente en la cabecera IP. Anteriormente exista en su lugar un campo denominado TOS o Tipo de Servicio que tena la siguiente estructura:

Subcampo Precedencia Flags D, T, R, C Reservado

Longitud (bits) 3 4 1

El subcampo Precedencia permita especificar una prioridad entre 0 y 7 para el datagrama (7 mxima prioridad). Este campo es en cierto modo el antecesor del campo DS. A continuacin se encontraba un subcampo compuesto por cuatro bits que actuaban como indicadores o flags mediante los cuales el usuario poda indicar sus preferencias respecto a la ruta que seguira el datagrama. Los flags, denominados D, T, R y C permitan indicar si se prefera una ruta con servicio de bajo retardo (D=Delay), elevado rendimiento (T=Throughput), elevada fiabilidad (R=Reliability) o bajo costo (C=Cost). El campo TOS ha sido muy impopular: el subcampo precedencia se ha implementado muy raramente en los routers. En cuanto a los flags D,T,R,C prcticamente no se han utilizado y su inclusin en la cabecera IP ha sido muy criticada. Estos problemas facilitaron evidentemente la transformacin del campo TOS en el DS, aunque existen todava routers en Internet que interpretan este campo con su antiguo significado de campo TOS. Dado que DiffServ casi siempre utiliza solo los tres primeros bits del DSCP para marcar los paquetes, y que los servicios de mas prioridad, como es el caso del Expedited Forwarding, se asocian con los valores ms altos de esos tres bits, en la prctica hay bastante compatibilidad entre el nuevo campo DSCP del byte DS y el antiguo campo Precedencia del byte TOS, como puede verse en la tabla siguiente:

Valor Campo Precedencia 7 6 5 4 3 2 1 0

Servicio DiffServ correspondiente Reservado Reservado Expedited Forwarding Assured Forwarding clase 4 Assured Forwarding clase 3 Assured Forwarding clase 2 Assured Forwarding clase 1 Best Effort

Evidentemente esta compatibilidad no es accidental. Tradicionalmente el campo Precedencia no haca uso de los dos niveles de prioridad ms altos, que quedaban reservados para mensajes de gestin de la red, como datagramas del protocolo de routing. En DiffServ se han reservado tambin los dos valores ms altos de los tres primeros bits con lo que se mantiene la compatibilidad con el campo precedencia.

Cul(es) es (son) el(los) campo(s) que reemplazan sus funcionalidades en IPv6 En IPv4 los flujos se identifican por las direcciones de origen y destino, el puerto de origen y destino (a nivel de transporte) y el protocolo de transporte utilizado (TCP o UDP). En IPv6 la identificacin puede hacerse de la misma forma que en IPv4, o alternativamente por las direcciones de origen y destino y el valor del campo Etiqueta de Flujo. Aunque el campo Etiqueta de Flujo en IPv6 se defini con este objetivo la funcionalidad an no se ha implementado en la prctica.