Protocolos classless y classful

Introducción

Los protocolos classful no anuncian máscaras en sus routing updates, y todas las subredes se interpretan con la misma máscara que está configurada en los equipos. Si la ruta recibida pertenece a la clase del interface por el que se recibe, sea sume la máscara configurada en ese interface. Si pertenece a una clase distinta, se asume la máscara por defecto.

Si en la red todas las máscaras de los interfaces de la misma clase son iguales, se pueden compartir subredes, pero al cambiar de clase se sumariza la red entera (clase). Por ello, no se soporta la discontinuidad de redes .Los protocolos classless anuncian su máscara en los routing updates, lo que permite configurar cada subred a un tamaño concreto, e incluso agregar varias rutas para sumarizar. VLSM (Variable Lengh Subnet Mask) permite que haya diferentes máscaras en cada interface de un router, útil por ejemplo para direccionar enlaces serie, que sólo necesitan 2 direcciones de hosts.

La sumarización consiste en agregar bits a la máscara, de modo que la red resultante sea la suma de todas las subredes. CIDR (Classless Interdomin Routing) es un caso de sumarización, que permite que en BGP4 sólo se publique una red donde puedan ser sumarizadas las redes de un AS.

Cuando un router tiene en su tabla rutas al mismo destino, utiliza la más concreta, es decir, la que tiene máscara con mayor número de bits, independientemente del método de cómo la aprendido.

Protocolos de enrutamiento:

• Protocolos classful.
  Son los protocolos que no transmiten la máscara de subred en sus actualizaciones.
  - La sumarización ocurre en los límites de la red.
  - Las rutas que se intercambian entre redes diferentes se sumarizan al límite de la clase.
  - Dentro de la red, las rutas a las subredes se intercambian sin la máscara de subred.
  - Todas las interfaces de los dispositivos deben utilizar la misma máscara de subred.
  - Es el caso de los protocolos RIP v.1 e IGRP.

• Protocolos classless.
  Son los protocolos que incluyen la máscara de subred en sus actualizaciones.
  - Las interfaces de los dispositivos de una misma red pueden tener diferentes máscaras de subred (VLSM).
  - Soportan el enrutamiento entre dominios sin utilizar clases (CIDR).
  - Algunas rutas pueden ser sumarizadas dentro de los límites de una clase. Esto se hace manualmente.
  - Es el caso de los protocolos RIP v.2, OSPF, EIGRP, IS-IS y BGP.

Tabla de protocolos

Protocolo de Routing	Classfull Classless	Convergencia	Distancia Adminis- trativa	IP v6	Multipro-tocolo	Entradas	Pequeña Mediana Grande	IGP EGP	Unicast Multicast Broadcast
Rip v1	Classfull	90s/Router	120	No	Si	1000	Pequeña	IGP	Broadcast
Rip v2	Classless	90s/Router	120	No	Si	1000	Pequeña	IGP	Multicast
IGRP	Classfull	270s/Router	100	No	Si	3000	Mediana	IGP	Broadcast
EIGRP	Classless	1a vez 2s, después 0	90	Si	Si	44000	Mediana	IGP	Multicast Unicast
OSPF	Classless	6s	110	Si	No	36000	Mediana	IGP	Multicast Unicast
ISIS	Classless	4s	115	Si	Si	70000	Mediana	IGP	Multicast Unicast
E - BEP	Classless	Entre 40s y 2 días	20	Si	Si	Sin límite	Grande	EGP	Unicast
I- BEP	Classless	Entre 40s y 2 días	200	Si	Si	Sin límite	Grande	IGP	Unicast

Referencias bibliográficas

http://librosnetworking.blogspot.com/2006/08/como-funcionan-los-protocolos-de.html

http://es.scribd.com/doc/76603077/17/Protocolos-classless-y-protocolos-classful

https://sites.google.com/site/apuntesccna/protocolos-de-enrutamiento

REQUEST FOR COMMENTS (RFC)

1.    Introducción RFC:

Los RFC son documentos que incluyen información detallada (métodos, comportamientos, innovaciones, investigaciones) acerca de protocolos de internet estandarizados y aquellos que se encuentran aún en estado de desarrollo. También incluyen información relacionada con requisitos de hosts, de enrutadores y asignación de puertos.

Cuanto mayor sea el número que le acompaña al RFC, más actualizada será la versión, la colección completa de RFCs está formada por más de 3000 documentos que especifican estándares, son recomendaciones, informativos o han quedado obsoletos donde los textos son publicados en formato de texto ASCII, los RFC son publicados y adoptados como estándares de internet por el Internet Engineering Task Force (IETF).

Cada RFC tiene un título y un número asignado, que no puede repetirse ni eliminarse aunque el documento se quede obsoleto, cada protocolo de los que hoy existen en internet tiene asociado un RFC adicionales que lo amplían como por ejemplo el protocolo IP que se detalla en el RFC 791, el FTP en el RFC959 y el HTTP el RFC2616.

Antes de que un documento tenga la consideración de RFC, debe seguir un proceso muy estricto para asegurar su calidad y coherencia. Cuando lo consigue, prácticamente ya es un protocolo formal al que probablemente se interpondrán pocas objeciones, por lo que el sentido de su nombre como petición de comentarios ha quedado prácticamente obsoleto, dado que las críticas y sugerencias se producen en las fases anteriores. De todos modos, el nombre de RFC se mantiene por razones históricas.

2.    Estándar de Internet:

El estándar propuesto, el borrador y los protocolos estándar se describen como constituyentes del Internet Standards Track. El track estándar lo controla el Grupo de Dirección de Ingenieros de Internet (IESG) del IETF. Cuando un protocolo alcanza el estado de estándar se le asigna un número estándar (STD). El propósito de los números STD es indicar claramente qué RFCs describen los estándares de Internet.

Los números STD referencian múltiples RFCs cuando la especificación de un estándar se divide en múltiples documentos. No como con los RFCs, donde el número se refiere a un documento específico, los números STD no cambian cuando un estándar se actualiza. Los números STD, sin embargo, no tienen número de versión dado que todas las actualizaciones se realizan vía RFCs y los números de RFC son únicos, de este modo, para especificar sin ambigüedad qué versión de un estándar único se está refiriendo, se pondría de manifiesto el número estándar y todos los RFCs que incluye como por ejemplo, el Sistema de Nombres de Dominio (DNS) es STD 13 y se describe en los RFCs 1034 y 1035, cuatro estándares de Internet tienen una importancia particular:

-   STD 1 - Estándares de Protocolos Oficiales de Internet: Este estándar da el estado y status de cada protocolo o estándar de Internet y define los significados atribuidos para cada estado o status diferente.

-   STD 2 - Números Asignados en Internet: Este estándar lista actualmente números asignados y otros parámetros de protocolos en la familia de protocolos de Internet.

-   STD 3 - Requerimientos del Host: Este estándar define los requerimientos para el software de host de Internet (a menudo con referencia a los RFCs relevantes). El estándar viene en dos partes:

RFC 1122 - Requerimientos para hosts de Internet - capas de comunicaciones y rfc.

RFC 1123 - Requerimientos para hosts de Internet- aplicación y ayuda.

-   STD 4 - Requerimientos de Pasarela: Este estándar define los  requerimientos para el sofware de pasarela de Internet (router). Es el RFC 1009.

3.    Comunicaciones mediante RFC:

PP-PI y el sistema de control se comunican entre sí mediante la Llamada de función remota (RFC). RFC es un método de comunicaciones desarrollado por SAP que proporciona una transferencia de datos adecuada entre sistemas diferentes. Los interlocutores intercambian datos mediante Common Program Interface Communication (CPI-C). Gracias a la tecnología RFC a nivel R/3, la aplicación no necesita gestión de comunicaciones. A nivel de máquina, SAP soporta la generación automática de un programa de ejemplo RFC con un generador de códigos. El módulo de funciones de SAP R/3 mediante el que se deben intercambiar los datos se utiliza como base para la generación del programa de ejemplo. Los programas generados soportan RFCs sincrónicos pero no soportan RFCs transaccionales. Cuando se necesite el RFC transaccional (véase a continuación), el programa se deberá ajustar de la manera adecuada. Después, se deben compilar y enlazar en la máquina de control y se pueden utilizar para la aplicación real como un Interfase de programa de aplicación (API).

Módulos de funciones RFC de la interfase PI-PCS:

	Llamada
Función	De	A	Denominación de la función
Download de receta de control	PP-PI	CS	CONTROL_RECIPE_DOWNLOAD
	PP-PI	CS	CONTROL_RECIPE_AVAILABLE
	CS	PP-PI	CONTROL_RECIPE_PULL
	CS	PP-PI	CONTROL_RECIPE_PULL_SINGLE
Upload de mensaje	CS	PP-PI	PROCESS_MESS_UPLOAD
	PP-PI	CS	PROCESS_MESS_GET_RETURN_CODE
Download de mensaje	PP-PI	CS	PROCESS_MESS_DOWNLOAD
Download de datos de detalle sobre características	CS	PP-PI	PROC_CHAR_GET_LIST_WITH_DETAIL
Download de valores permitidos para característica	CS	PP-PI	PROC_CHAR_HELPVALUES_GET

4.    Introducción OSPF

Open Shortest Path First (OSPF) es un protocol de enrutamiento de estado de enlace desarrollado como remplazo del protocol de enrutamiento por vector de distancia RIP RIP, constituyó un protocolo de enrutamiento aceptable en los comienzos del networking y de Internet; sin embargo, su dependencia en el conteo de saltos como la única medida para elegir el mejor camino rápidamente se volvió inaceptable en redes mayores que necesitan una solución de enrutamiento más sólida. OSPF es un protocolo de enrutamiento sin clase que utiliza el concepto de áreas para realizar la escalabilidad. RFC 2328 define la métrica OSPF como un valor arbitrario llamado costo. El IOS de Cisco utiliza el ancho de banda como la métrica de costo de OSPF.

Las principales ventajas de OSPF frente a RIP son su rápida convergencia y escalabilidad a implementaciones de redes mucho mayores. En este capítulo final del curso de Conceptos y protocolos y de enrutamiento, aprenderá sobre implementaciones y configuraciones de OSPF básicas de área única. Las configuraciones y conceptos de OSPF más complejos se reservan para los cursos de nivel CCNP.

5.    Tipos de Paquetes OSPF

Existen cinco tipos de paquetes de enlace (LSP) de OSPF que cada una cumple funciones especificas en el proceso de enrutamiento de OSPF que son:

-  Saludo: Los paquetes de saludo se utilizan para establecer y mantener la adyacencia con otros routers OSPF.

-   DBD: El paquete de Descripción de bases de datos (DBD) incluye una lista abreviada de la base de datos de estado de enlace del router emisor y lo utilizan los routers receptores para comparar con la base de datos de estado de enlace.

-   LSR: Los routers receptores pueden luego solicitar más información acerca de una entrada en la DBD enviando una Solicitud de estado de enlace.

-   LSU: Los paquetes de Actualización de estado de enlace (LSU) se utilizan para responder las LSR y para anunciar nueva información.

-   LSAck: Cuando se recibe una LSU, el router envía un Acuse de recibo de estado de enlace(LSAck) para confirmar la recepción de LSU

6.    Relación RFC y OSPF

Open Short Path First versión 2, es un protocolo de routing interno basado en el estado del enlace o algoritmo Short Path First, estándar de Internet, que ha sido desarrollado por un grupo de trabajo del Internet Engineering task Force, cuya especificación viene recogida en el RFC 2328.

OSPF, ha sido pensado para el entorno de Internet y su pila de protocolos TCP/IP, como un protocolo de routing interno, es decir, que distribuye información entre routers que pertenecen al mismo Sistema Autónomo.

7.    Referencia Bibliográfica

http://tic-tac.teleco.uvigo.es/profiles/blogs/introduccion-a-request-for

http://www.rfc-es.org/

http://es.wikipedia.org/wiki/Request_for_Comments

http://darkjrof.wordpress.com/2010/05/06/request-for-comments/

http://help.sap.com/saphelp_40b/helpdata/es/12/3bbf79504811d182c20000e829fbfe/content.htm

http://www.xuletas.es/ficha/protocolos-de-encaminamiento-rip-y-ospf/