1. 2013
CORRESPONDENCI
A ENTRE MODELO
OSI Y CON TCP/IP
CECYTES PUEBLITOS V
TAREA 2
ALUMNO (A); JESSICA REYES ARMAS
6 “A”
7 DE FEBRERO DEL 2013
Reyes

2. Correspondencia entre modelo OSI y con TCP/IP
Figura- TCP/IP y OSI muestra un intento de establecer una
correspondencia entre las diferentes capas de las arquitecturas de
TCP/IP y OSI, pero hay que ser consciente de las diferencias básicas
explicadas más abajo.
Figura: TCP/IP y OSI - Correspondencia funcional de las capas.
2.14.1 Diferencias
El modelo de internet sólo puede equipararse funcionalmente al
modelo OSI de ISO, ya que existen diferencias básicas tales como:
En la pila de protocos de internet, una capa representa un
encapsulamiento de una función.
La perspectiva de ISO, por otro lado, trata a las capas como
grupos funcionales bastante reducidos, intentando forzar la
modularidad al requerir capas adicionales para funciones
adicionales.

3. En los protocolos TCP/IP, un protocolo dado puede ser usado por
otros protocolos en la misma capa, mientras que en el modelo
OSI se definiría dos capas en las mismas circunstancias.
Ejemplos de estas "dependencias horizontales" son FTP, que usa
la misma representación común que TELNET sobre la capa de
aplicación, o ICMP, que usa IP para el envío de datagramas en el
nivel de red.
A nivel práctico, lo que estamos discutiendo aquí es la diferencia
entre un estándar "de jure", OSI, y uno "de facto", TCP/IP. El
objetivo en el mundo de TCP/IP consiste en establecer de común
acuerdo un protocolo estándar que pueda funcionar en una
diversidad de redes heterogéneas; siempre se le ha dado mayor
importancia al estándar en sí que a su implementación.
Eficiencia y viabilidad. Las normas de OSI tienden a ser
prescriptivas(por ejemplo, la capa "N" debe atravesar todas las
capas "por debajo" de ella), mientras que los protocolos TCP/IP
tienden a ser descriptivos, y dejan un máximo de libertad a los
implementadores. Una de las ventajas del enfoque de TCP/IP es
que cada implementación concreta puede explotar
características dependientes del sistema, de lo que suele
derivarse una mayor eficiencia(menos ciclos de CPU, mayor
productividad para las mismas funciones), al mismo tiempo que
se asegura la interoperabilidad con otras aplicaciones.
Otra forma de ver esto es que la mayoría de ls protocolos de
internet se han desarrollado primero(codificados y testeados)
antes de ser descritos en un RFC(habitualmente por parte del
implementador) lo que muestra claramente su viabilidad.
2.14.2 El mundo de Internet y OSI
El DoD("Department of Defense"), organismo subvencionador de la
investigación ARPANET original, hizo una consideración acerca de

4. OSI en enero del '88; basada en el GOSIP("Government OSI Profile")
del 22 de abril de 1987.
A continuación mostramos un extracto del documento, que está
publicado en el RFC 1039 - Una consideración de DoD acerca de OSI:
"...Se pretende adoptar los protocolos OSI como un co-estándar de
hecho con los protocolo de DoD cuando GOSIP sea aprobado
oficialmente como un estándar federal de procesamiento de
información("Federal Information Processing Standard"). Dos años
después, los protocolos OSI se convertirían en la pila de protocolos
interoperables predominante; sin embargo, se proporcionaría la
capacidad para interoperar con protocolos DoD a efectos de las
expectativas de vida de los sistemas que soportasen protocolos
DoD..."
El mundo de internet ha realizado numerosos estudios sobre posibles
transiciones y la coexistencia de los protocolos. La siguiente lista es
serie de RFCs emitidos con este propósito:
RFC 983 - Servicios de transporte ISO en la cima de TCP.
RFC 1006 - Servicios de transporte ISO en la cima de TCP -
Versión 3.
RFC 1039 - Una consideración de DoD acerca de OSI.
RFC 1069 - Indicaciones para el uso de direcciones IP de
Internet en el Protocolo de Red No Orientado a Conexión de
ISO.
RFC 1085 - Servicios de presentación de ISO en la cima de
TCP/IP.
RFC 1086 - Puente ISO-TP0 entre TCP and X.25.
RFC 1090 - SMTP en X.25.
RFC 1161 - SNMP enr OSI.
RFC 1195 - Uso de OSI IS-IS para el encaminamiento en
TCP/IP y en entornos duales.

5. RFC 1238 - CLNS MIB para uso con el ISO
8473("Connectionless Network Protocol") e ISO 9542("End
System to Intermediate System").
RFC 1240 - Servicios de transporte no orientados a conexión de
OSI sobre UDP: versión 1.
RFC 1308 - Introducción práctica a servicios de
directorios("Directory Services")usando el protocolo X.500.
RFC 1309 - Descripción técnica de los servicios de directorios
usando el protocolo X.500.
RFC 1327 - Mapeado entre X.400(1998)/ISO 10021 y el RFC
822.
RFC 1328 - X.400 1988 a 1984 "downgrading".
RFC 1330 - ESCC X.500/X.400 "Task Force". Recomendaciones
para la fase 1 de la instalación de los servicios OSI de
directorios (X.500) y de manejo de mensajes(X.400) en la
comunidad ESnet.
RFC 1430 - Un plan estratégico para instalar un servicio de
directorios de Internet X.500.
RFC 1487 - X.500 "Lightweight Directory Access Protocol".
RFC 1488 - La representación con cadenas de las sintaxis de
atributos estándar de X.500("String Representation of
Standard Attribute Syntaxes").
RFC 1491 - Descripción de usos avanzados de X.500.
RFC 1562 - Nombrando indicaciones para el servicio de
directorios AARNet X.500.
RFC 1567 - X.500 monitorizando MIB.
RFC 1608 - Representando información IP en X.500.
RFC 1609 - Esquematizando redes en X.500.
RFC 1617 - Nombrando y estructurando directrices para el
X.500 "Directory Pilots".
RFC 1629 - Directrices para OSI NSAP "Allocation" en
Internet.
RFC 1632 - Un catálogo revisado de implementaciones
disponibles de X.500.

6. RFC 1684 - Introducción a los servicios de páginas amarillas
basados en X.500.
RFC 1706 - DNS NSAP Registros de recursos.
RFC 1729 - Usando el protocolo de rcuperación de información
Z39.50 en Internet.
RFC 1781 - Usando el directorio OSI para el servicio "Achieve
User Friendly Naming".
2.14.3 Consideraciones acerca de la coexistencia de TCP/IP y OSI
Si se tiene como meta la coexistencia de TCP/IP y OSI, con vistas a la
hegemonía eventual de OSI, básicamente hay cinco opciones, divididas
en dos categorías generales: basadas en protocolos y basadas en
servicios.
Los enfoques basados en protocolos incluyen pilas duales y pasarelas
para los niveles de aplicación y de transporte. Los basados en servicios
incluyen puentes en el nivel de transporte y túneles de red.
2.14.3.1 Pilas duales - Un enfoque sencillo
La forma más simple de integrar TCP/IP y OSI e poner ambos
protocolos en cada máquina de la red.
Figura: Pilas duales

7. Aunque este una perspectiva relativamente directa, supone una gran
desventaja: dos redes usarán el mismo conjunto de líneas físicas, pero
los dos conjuntos de protocolos no podrán interoperar. Los usuarios
están forzados a elegir uno de ellos. Esta desventaja de tener dos
redes separadas puede ser una ventaja. Los usuarios que deseen usar
TCP/IP podrán hacerlo; los que prefieran OSI podrán usar OSI. Otra
ventaja es que una red TCP/IP ya existente no será perturbada. No
obstante, las pilas duales consumen mucha memoria, y tienen que
instalarse en cada máquina en la red TCP/IP - OSI.
2.14.3.2 Pasarelas en el nivel de aplicación - El enfoque de DoD
Este enfoque elimina una gran desventaja de las pilas duales(la falta
de interoperabilidad de aplicaciones) Las pasarelas del nivel de
aplicación convierten las PDU("Protocol Data Units") del nivel de
aplicación de una pila al de la otra. Estas pasarelas permiten comunicar
cualquier sistema TCP/IP con cualquier sistema OSI. No es necesario
elegir entre protocolos, ya que el protocolo de aplicación funcionará
en ambas pilas.either stack.
Figura: Nodo pasarela del nivel de aplicación
Otra ventaja de estas pasarelas es que no tienes que añadir o
modificar nada en los sistemas en los extremos. Esto se debe a que la
pasarela(que incluye las dos pilas de protocolos) actúa de

8. intermediaria para el sistema y maneja todas las conversiones de
protocolo. Pero se suele perder funcionalidad en la conversión de un
protocolo de aplicación a otro debido a que la correpondencia o mapeo
entre los dos protocolos no es perfecta, principalmente cuando se va
de aplicaciones de OSI a aplicaciones de TCP/IP. Esto se debe a que
las aplicaciones OSI tiene mayor exuberancia de funcionalidades.
Otra desventaja de las pasarelas es que producen cuellos de botella
que dan lugar a una degradación del rendimiento si la pasarela no es lo
bastante potente.
2.14.3.3 Pasarelas del nivel de transporte - El enfoque equivocado
Figura: Nodo pasarela del nivel de transporte
CLNP significa "ConnectionLess Network Protocol" (ver figura
superior).
Si se dispone de un entorno con el protocolo de transporte TCP en un
extremo y del protocolo de transporte de OSI TP4 en otro, hace
falta un mecanismo de software que traduzca dinámicamente los
paquetes TCP a paquetes TP4. Esta aproximación se considera errónea
porque ninguna aplicación soporta TCP en un extremo y TP4 en otro, y
porque el cambio de direcciones en cualquier lado de la pasarela, que
implica una pérdida en los servicios de directorios.
Los tres enfoques examinados hasta el momento se concentran en la
conversión de protocolos. Sin embargo, es posible ignorar

9. virtualmente el protocolo en sí y concentrarse en emular los servicios.
Aquí es donde entran en juego los puentes del servicio de transporte y
los túneles de red.
2.14.3.4 Puentes del servicio de transporte - El enfoque de ISODE
Figura: Nodo puente del servicio de transporte
ISODE significa "International Standards Organization Development
Environment". Se trata de una colección disponible al público de
librerías de rutinas y programas que implementan los servicios de las
capas superiores de OSI.
En un ejemplo de TCP a TP4, un puente del sevicio de transporte haría
que el servicio de TCP parezca un servicio TP4. Con los puentes del
servicio de transporte, es posible ejectuar aplicaciones OSI sobre
redes TCP/IP. Una ventaja de esto es que sólo se necesita un
protocolo de aplicación - el de OSI. Sólo las capas subyacentes
necesitan cambiar entre los dos entornos. Un puente del servicio de
transporte es esencialmente un "router" que copia PDUs, en vez de
traducirlas. El RFC 1006 define la forma de generar servicios de
transporte de OSI sobre TCP. La principal desventaja de esto este
enfoque es que no hay campo checksum origen - destino. En el ejemplo
de entorno TCP a TP4, se tiene una checksum de TCP en el lado
correspondiente al origen del puente y un checksum en el lado de
destino. Como las pasarelas, los puentes del sevicio de transporte
tienen un sólo punto débil. Es posible usar estos puentes no sólo para

10. implementaciones TCP/IP a OSI sino también para trabajos de
integración de OSI a OSI. Por ejemplo, OSi incluye diferentes
protocolos de transporte, como TP= para WANs y TP4 para LANs. Los
puentes del servicio de transporte son candidatos viables para
conectar esos sistemas OSI con diferentes esquemas de transporte.
2.14.3.5 Túneles de red - El enfoque complejo
Figura: Túneles de red
Esta aproximación elimina el único punto débil y proporciona
checksums origen - destino. Los túneles de red están un nivel por
debajo del punto de vista de los puentes del servicio de transporte.
En vez de emular el servicio de transporte, usan una emulación del
servicio del nivel de paquetes. Los túneles de red operan al nivel de
red y no al de transporte. Encapsulan los paquetes OSI CLNP en
paquetes IP y los hacen circular sobre redes IP. Los túneles de red
son esencialmente "routers" CLNP.
Los túneles de red permiten tener checksums origen - destino, un
mayor grado de transparencia, pero requieren redes basadas en OSI
CLNP y son difíciles de implementar.