SNMP-PROTOCOLO SENCILLO DE ADMINISTRACIÓN DE REDES

En los primeros días de ARPANET, si el retardo o algún host se volvía inexplicablemente grande, la persona que detectaba el problema simplemente ejecutaba el programa ping para rebotar un paquete en el destino.

Cuando ARPANET se convirtió en el internet mundial, con múltiples columnas vertebrales y operadores, esta solución dejo de ser adecuada, por lo que se requirieron mejores herramientas de administración de red.

Junto con un documento acompañante (el RFC 1155) sobre información de administración, el SNMP proporciono una manera sistemática de supervisar y administrar una red de cómputo. Esta estructura y su protocolo se implementaron ampliamente en los productos comerciales y se volvieron estándares de facto para la administración de redes.

A medida que se adquirió experiencia, se hicieron evidentes las limitaciones del SNMP, por lo que se definió (en los RFC 1441 a 1442) una versión mejorada del SNMP (SNMPv2)             que se volvió un estándar de internet.

ENRUTAMIENTO POR MULTITRANSMISIÓN

En algunas aplicaciones, procesos muy separados trabajan juntos en grupos; por ejemplo, un grupo de procesos que implementan una base de datos distribuida. Si el grupo es pequeño, se puede simplemente transmitir a todos los demás miembros un mensaje punto a punto si el grupo es grande, esta estrategia es cara.

El envió de un mensaje a uno de tales grupos se llama multitransmisión y su algoritmo de enrutamiento es el enrutamiento por multitransmisión.

Por la multitransmisión se requiere administración de grupos. Se necesita lagu8na manera de crear y destruir grupos, y un mecanismo para que los procesos se unan a los grupos y salgan de ellos. La forma de realizar estas tareas no le concierne al algoritmo de enrutamiento. Lo que si le concierne es que, cuando un proceso se una a un grupo, informe a su host del hecho.

Los hosts deben informar a sus enrutadores de los cambios en los miembros del grupo, o los enrutadores deben enviar periódicamente la lista de sus hosts.

ENRUTAMIENTO POR ESTADO DE ENLACE

El enrutador por vector de distancia se usa en ARPANET hasta 1979, cuando fue remplazado por el enrutamiento por estado de enlace. Dos problemas, principales causaron su defunción.

Primero, dado que la métrica de retardo era la longitud de la cola, no tomaba en cuenta el ancho de banda al escoger rutas. Independientemente, todas las líneas eran de 56 kbps, por lo que el ancho de banda no era importante, pero una vez que se modernizaron algunas líneas a 230kbps y otras a 1.544 MBPS, al no tomar en cuenta el ancho de banda se volvió un problema importante.

Segundo, que el algoritmo con frecuencia tardado demasiado en convergir, aun con trucos como el horizonte dividido, por estas razones, el algoritmo fue remplazado por uno nuevo llamado enrutamiento por estado de enlace.

En concepto que se basa el enrutamiento por estado de enlace es sencillo y puede postularse en 5 partes. Cada enrutador debe:

1.- Descubrir a sus vecinos y conocer sus direcciones de red

2.- Medir el retardo o costo para cada uno de sus vecinos

3.- Construir un paquete que indique todo lo que acaba de aprender

4.- Enviar este paquete a todos los demás enrutadores

5.- Calcular la trayectoria más corta a todos lo demás enrutadores.

COMPARACIÓN DE LAS SUBREDES DE CIRCUITOS VIRTUALES Y DE DATAGRAMAS

Tanto los circuitos virtuales como los datagramas tienen sus seguidores y sus detractores.

Dentro de la subred, hay varias diferencias entre los que sacrifican los circuitos virtuales y los datagramas. Una de ellas concierne el espacio de memoria del enrutador y el ancho de banda. Los circuitos virtuales permiten que los paquetes contengan números de circuito en lugar de direcciones de destino completos.

El uso de circuitos requiere una fase de establecimiento, que consume tiempo y recursos, sin embargo, la determinación de lo que hay que hacer con un paquete de datos en una subred de circuitos virtuales es fácil: el enrutador simplemente usa el número   de circuito para buscar en una tabla indicada y encontrar el lugar al que va el paquete.

Los circuitos virtuales tienen algunas ventajas en cuanto a que evitan congestionamiento en la subred, pues los recursos pueden reservarse por adelantado al establecerse la conexión. Con una subred de datagramas, es más difícil evitar los congestionamientos.

Los circuitos virtuales  también tienen un problema de vulnerabilidad. Si se cae en un enrutador, perdiéndose su memoria tendrán que abortarse todos los circuitos virtuales que pasan por él, aun si se recuperan un segundo después. Por el contrario, al caerse un enrutador de datagramas solo sufrirán aquellos usuarios cuyos paquetes estaban encolados en el enrutador en el momento y, dependiendo de si ya habían sido reconocidos o no tal vez ni siquiera todos.

ORGANIZACIÓN INTERNA DE LA CAPA DE RED

En el contexto de la operación interna de la subred generalmente se llama circuito virtual a una conexión por analogía en los circuitos físicos instalados por el sistema telefónico. Los paquetes independientes de la organización de tipo sin conexiones se llaman datagramas, por analogía con los telegramas.

Los circuitos virtuales generalmente se usan en subredes cuyo servicio primario está orientado a conexión, se escoge y se recuerda una ruta de la máquina de  origen   a la de destino como parte del establecimiento de la conexión. Esta ruta se usa para todo el tráfico que fluye por la conexión.

En una subred de datagramas no se determinan  rutas por adelantado, aun si el servicio está orientado a conexión. Dos paquetes sucesivos pueden seguir rutas distintas. Si bien las subredes de datagramas tienen más trabajo que hacer.

Al establecerse una conexión de red, se escoge un número de circuito virtual actual mente desocupado en esa máquina como identificador de la conexión. Dado que cada máquina escoge independientemente los números de circuito virtual, estos números tienen solo significado local.

SERVICIOS PROPORCIONADOS A LA CAPA DE TRANSMISIÓN

La capa de red proporciona servicios a la capa de transporte en la interfaz capa de red/capa de transporte. Esta interfaz muchas veces tiene especial importancia por otra razón: con frecuencia es la interfaz entre la portadora y el cliente es decir, el límite de la sub red. La portada suele controlar los protocolos y las interfaces hasta la capa de red. Por esta razón, esta interfaz debe estar especialmente bien definida.

Los servicios de la capa de red se diseñaron con las siguientes metas en mente:

1.-los servicios deben ser independientes de la tecnología de subred.

2.- La capa de transporte debe estar aislada de la cantidad, tipo y topología de las subredes presentes.

3.-las direcciones de red disponibles para la capa de transporte deben seguir un plan de numeración uniforme, aun a través de varias LAN y WAN.

Un bando aleya que la tarea de la sub red es mover bits de un lado a otro, y nada más. La sub red es inherentemente inestable sin importar SU DISEÑO. Por lo tanto, los hosts deben aceptar el hecho de que es inestable y efectuar ellos mismos el control de errores.

El otro bando (representado por las compañías telefónicas) argumenta que la subred debe proporcionar un servicio confiable orientado a conexión.

La controversia entre el servicio orientado a conexión y el servicio sin conexiones en realidad tiene que ver  con donde está la complejidad. En el servicio orientado a conexión, está en la capa de red (subred); en el servicio sin conexiones, está en la capa de transporte (hosts). 

LA CAPA DE RED

La capa de red se encarga de llevar los paquetes desde el origen hasta el destino. Esta función ciertamente contrasta con lace la capa de enlace de datos, que solo tiene la meta modesta de mover marcos de un extremo del alambre al otro. La capa de red es la capa más baja que maneja la transmisión de punta a punta.