Ebook en PDF Redes de Ordenadores Protocolos

LOS PROTOCOLOS
EN LAS REDES DE
ORDENADORES
Antonio Salavert Casamor

Ingeniero Industrial
Consultor de redes y comunicaciones
Registro General de la propiedad Intelectual

Número de Asiento Registral 02/2003/4864
INDICE
CAPÍTULO 1. INTRODUCCIÓN.........................................................................................................................1
CAPÍTULO 2. LOS PROTOCOLOS EN LAS REDES......................................................................................3

2.1 FUNCIONALIDADES..............................................................................................................................................3
2.2 ESTRUCTURA......................................................................................................................................................4
CAPÍTULO 3. DEFINICIONES BÁSICAS.........................................................................................................5
CAPÍTULO 4. MODELO OSI...............................................................................................................................7

4.1 NIVEL FÍSICO (1)................................................................................................................................................8
4.2 NIVEL DE ENLACE (2)..........................................................................................................................................8
4.3 NIVEL DE RED (3)...............................................................................................................................................9
4.4 NIVEL DE TRANSPORTE (4)...................................................................................................................................9
4.5 NIVEL DE SESIÓN (5)...........................................................................................................................................9
4.6 NIVEL DE PRESENTACIÓN (6)..............................................................................................................................10
4.7 NIVEL DE APLICACIÓN (7)..................................................................................................................................10
CAPÍTULO 5. CONCEPTOS DE LAN Y WAN...............................................................................................11
CAPÍTULO 6. COMUNICACIONES ENTRE ORDENADORES DE UNA RED........................................13
CAPÍTULO 7. RELACIÓN MODELO OSI Y COMUNICACIÓN ENTRE ORDENADORES.................15

7.1 CASO DE 2 ORDENADORES CONECTADOS EN RED SIN LÍNEA DE COMUNICACIONES.........................................................18
7.2 CASO DE 1 ORDENADOR CONECTADO A INTERNET...................................................................................................18
7.3 CASO DE 2 REDES CONECTADAS POR UNA LÍNEA DE COMUNICACIONES A TRAVÉS DE 2 ENRUTADORES.............................19
CAPÍTULO 8. PROYECTO IEEE 802...............................................................................................................21
CAPÍTULO 9. ORGANISMOS DE NORMALIZACIÓN................................................................................23
CAPÍTULO 10. DIRECCIONAMIENTO..........................................................................................................25

10.1 CLASES.........................................................................................................................................................25
10.2 DIRECCIONES SEGÚN PROTOCOLO.......................................................................................................................25
CAPÍTULO 11. PROTOCOLOS DE NIVEL FÍSICO (1)................................................................................27
CAPÍTULO 12. PROTOCOLOS DE NIVEL ENLACE (2).............................................................................29

12.1 IEEE 802.2.................................................................................................................................................29
12.2 IEEE 802.3 / ETHERNET................................................................................................................................30
12.2.1 Nivel físico..........................................................................................................................................31
12.2.2. CSMA/CD (Carrier Sense Multiple Access con Detección de Colisión)..........................................33
12.2.3 Dominio de colisión ..........................................................................................................................35
12.2.4 Ventana de colisiones.........................................................................................................................35
12.3 FAST ETHERNET.............................................................................................................................................36
12.4 GIGABIT ETHERNET.........................................................................................................................................37
12.5 IEEE 802.5 / TOKEN RING............................................................................................................................38
12.6 FDDI - FIBER DISTRIBUTED DATA INTERFACE...................................................................................................42
12.7 PROTOCOLOS DE REDES INALÁMBRICAS...............................................................................................................43
12.8 PROTOCOLOS ORIENTADOS AL BIT......................................................................................................................44
12.8.1 HDLC - High Level Data Link Control..............................................................................................44
12.8.2 SDLC - Synchronous Data Link Control............................................................................................45
12.8.3 LAPB - Link Access Procedure Balanced..........................................................................................46
CAPÍTULO 13. MODELO TCP/IP....................................................................................................................47
13.1 IP - INTERNET PROTOCOL................................................................................................................................47
13.1.1 Cabecera IP........................................................................................................................................48
13.1.2 Fragmentación y ensamblado............................................................................................................49
13.1.3 Direccionamiento y clases IP.............................................................................................................49
13.1.4 Máscaras............................................................................................................................................50
13.1.5 Enrutamiento......................................................................................................................................50
13.1.6 Referencias.........................................................................................................................................52
13.2 TCP - TRANSMISSION CONTROL PROTOCOL.......................................................................................................52
13.3 UDP - USER DATAGRAM PROTOCOL................................................................................................................57
13.4 ICMP - INTERNET CONTROL MESSAGE PROTOCOL.............................................................................................57
13.5 ARP - ADDRESS RESOLUTION PROTOCOL..........................................................................................................59
13.6 RARP - REVERSE ADDRESS RESOLUTION PROTOCOL.........................................................................................60
CAPÍTULO 14. OTROS PROTOCOLOS DE LAN..........................................................................................61
14.1 NETBIOS / NETBEUI..................................................................................................................................61
14.1.1 SMB - Server Message Block.............................................................................................................62
14.2 PROTOCOLOS DE UNA RED NOVELL NETWARE.....................................................................................................63
14.2.1 IPX - Internet Packet Exchange.........................................................................................................64
14.2.2 SPX - Sequenced Packet Exchange....................................................................................................65
14.2.3 NCP - Netware Core Protocol...........................................................................................................66
14.2.4 SAP - Service Advertising Protocol...................................................................................................67
14.3 PROTOCOLOS DE UNA RED APPLE......................................................................................................................68
14.3.1 DDP – Datagram Delivery Protocol.................................................................................................69
14.3.2 NBP – Name Binding Protocol..........................................................................................................69
14.3.3 ZIP – Zona Information Protocol.......................................................................................................69
14.3.4 ATP - AppleTalk Transaction Protocol..............................................................................................69
14.3.5 ADSP – AppleTalk Data Stream Protocol.........................................................................................70
14.3.6 ASP – AppleTalk Session Protocol.....................................................................................................70
14.3.7 PAP – Printer Access Protocol..........................................................................................................70
14.3.8 AFP – AppleTalk Filing Protocol .....................................................................................................70
14.3.9 AEP – Appletalk Echo Protocol.........................................................................................................71
14.4 OTROS PROTOCOLOS DE LAN..........................................................................................................................71
14.4.1 Redes DECnet....................................................................................................................................71
14.4.2 Redes Xerox........................................................................................................................................72
14.4.3 Redes Banyan VINES.........................................................................................................................72
14.5 NETBIOS SOBRE TCP/IP..............................................................................................................................73
14.6 NETBIOS SOBRE IPX....................................................................................................................................73
14.7 DLSW - DATA LINK SWITCHING......................................................................................................................74
CAPÍTULO 15. PROTOCOLOS DE APLICACIONES..................................................................................75
15.1 FTP - FILE TRANSFER PROTOCOL.....................................................................................................................75
15.2 TFTP - TRIVIAL TRANSFER PROTOCOL.............................................................................................................76
15.3 TELNET ....................................................................................................................................................76
15.4 DNS - DOMAIN NAME SYSTEM.......................................................................................................................77
15.4.1 Organización de los nombres.............................................................................................................78
15.4.2 Servidores de nombres.......................................................................................................................79
15.4.3 Resolución de nombres.......................................................................................................................79
15.4.4 Estructura del mensaje.......................................................................................................................79
15.4.5 DNS dinámico....................................................................................................................................80
15.4.6 Consideraciones con Microsoft Windows..........................................................................................80
15.4.7 Referencias.........................................................................................................................................80
15.5 LPDP - LINE PRINTER DEAMON PROTOCOL......................................................................................................81
15.6 NFS - NETWORK FILE SYSTEM........................................................................................................................81
15.7 X- WINDOWS.................................................................................................................................................82
15.8 DHCP - DYNAMIC HOST CONFIGURATION PROTOCOL........................................................................................83
15.9 BOOTP - BOOTSTRAP PROTOCOL....................................................................................................................85
15.10 SNMP - SIMPLE NETWORK MANAGEMENT PROTOCOL......................................................................................86
15.11 LDAP - LIGHTWEIGHT DIRECTORY ACCESS PROTOCOL....................................................................................89
CAPÍTULO 16. PROTOCOLOS DE WAN.......................................................................................................92
16.1 SISTEMAS DE COMUNICACIONES.........................................................................................................................93
16.2 PROTOCOLOS DE NIVEL FÍSICO...........................................................................................................................94
16.3 PROTOCOLOS DE ENRUTAMIENTO........................................................................................................................94
16.3.1 Conceptos...........................................................................................................................................97
16.3.2 Algoritmos de enrutamiento...............................................................................................................98
16.3.3 GGP – Gateway-to-Gateway Protocol............................................................................................100
16.3.4 RIP - Routing Information Protocol.................................................................................................101
16.3.5 RIP de Novell...................................................................................................................................103
16.3.6 IGRP - Interior Gateway Routing Protocol.....................................................................................103
16.3.7 OSPF - Open Shortest Path First.....................................................................................................105
16.3.8 EGP - Exterior Gateway Protocol...................................................................................................107
16.3.9 BGP - Border Gateway Protocol.....................................................................................................108
16.4 RVSP - RESOURCE RESERVATION SETUP PROTOCOL........................................................................................110
16.5 SLIP - SERIAL LINK INTERNET PROTOCOL......................................................................................................111
16.6 PPP - POINT TO POINT PROTOCOL..................................................................................................................112
16.7 PAP - PASSWORD AUTHENTICATION PROTOCOL...............................................................................................113
16.8 CHAP - CHALLENGE HANDSHAKE AUTHENTICATION PROTOCOL........................................................................114
16.9 EAP - EXTENDED AUTHENTICATION PROTOCOL...............................................................................................114
16.10 RDSI - RED DIGITAL DE SERVICIOS INTEGRADOS...........................................................................................115
16.11 ADSL - ASYNCHRONOUS DIGITAL SUBSCRIBER LINE ....................................................................................118
16.12 FRAME RELAY............................................................................................................................................120
16.13 X.25........................................................................................................................................................123
16.14 ATM - ASYNCHRONOUS TRANSFER MODE....................................................................................................125
16.15 SMDS - SWITCHED MULTIMEGABIT DATA SERVICE.......................................................................................130
CAPÍTULO 17. PROTOCOLOS DE INTERNET..........................................................................................133
17.1 PROTOCOLOS DE CORREO ELECTRÓNICO............................................................................................................133
17.1.1 SMTP - Simple Mail Transfer Protocol...........................................................................................133
17.1.2 MIME - Multipurpose Internet Mail Extensions..............................................................................135
17.1.3 POP3 - Post Office Protocol version 3............................................................................................137
17.1.4 IMAP4 - Internet Message Access Protocol version 4.....................................................................138
17.2 HTTP - HYPERTEXT TRANSFER PROTOCOL.....................................................................................................140
17.3 PROTOCOLOS DE SEGURIDAD...........................................................................................................................143
17.3.1 Comunicación remota......................................................................................................................143
17.3.2 PPTP - Point-to-Point Tunneling Protocol......................................................................................143
17.3.3. L2F - Layer 2 Forwarding..............................................................................................................145
17.3.4 L2TP - Layer 2 Tunneling Protocol.................................................................................................145
17.3.5 RADIUS - Remote Authentication Dial-In User Service..................................................................147
17.3.6 Kerberos...........................................................................................................................................149
17.3.7 IPSec - Internet Protocol Security...................................................................................................151
17.3.8 SSL – Secure Sockets Layer.............................................................................................................153
17.4 IGMP - INTERNET GROUP MANAGEMENT PROTOCOL.......................................................................................154
17.5 IPV6 - INTERNET PROTOCOL VERSION 6...........................................................................................................156
17.6 WAP - WIRELESS APLICATION PROTOCOL......................................................................................................157
APÉNDICE A. BIBLIOGRAFÍA......................................................................................................................159
APÉNDICE B. REFERENCIAS RFCS............................................................................................................161

Introducción 1
Capítulo 1. Introducción
El objetivo de este libro es dar a conocer los protocolos de las redes de datos y de los de comunicaciones
directamente relacionados con los mismos. De cada uno de ellos:
 se define sus funciones
 se explica sus características
 se detalla su relación con otros protocolos y
 se especifica los ámbitos en que se utiliza
y que en un lenguaje menos técnico sería:
 qué son
 para qué sirven
 cómo utilizarlos
 cómo se interaccionan entre ellos
 donde utilizarlos
Con el fin de facilitar este conocimiento al mayor número de personas, independientemente de su grado de
formación técnica sobre estos temas, la exposición de los mismos no es ni muy exhaustiva ni muy técnica,
excepto en algunos protocolos concretos como pueden ser los de Internet. Las especificaciones de estos
protocolos es pública y por tanto se conoce al detalle su funcionamiento.
En cuanto al desarrollo del libro, los capítulos del 1 al 10 son de carácter general, con conceptos que son
necesarios para entender el funcionamiento de los protocolos.
A continuación, se ha agrupado los protocolos según el nivel al que corresponden según el modelo de referencia
OSI. Así:
 En el capítulo 11, se mencionan los protocolos de nivel físico de forma sucinta y breve, ya que no
se ha considerado que sean un objeto de este libro.
 En el capítulo 12, se desarrollan los protocolos de nivel de enlace.
 En el capítulo 13, se desarrollan todos los protocolos correspondientes al modelo TCP/IP versión 4,
es decir, los protocolos IP, TCP, UDP, ICMP, ARP y RARP.
 En el capítulo 14, se desarrollan los protocolos de niveles de red y transporte en redes distintas a las
de protocolos TCP/IP.
 En el capítulo 15, se desarrollan los protocolos de nivel de aplicación. En este caso, dado que la
inmensa mayoría de ellos son propietarios, solo se mencionan principalmente los protocolos
relacionados con las redes TCP/IP.
 En el capítulo 16, se desarrollan de forma breve aquellos protocolos de comunicaciones
directamente relacionados con las redes de ordenadores. En este capítulo se han incluido los
protocolos de enrutamiento.
 En el capítulo 17, se desarrollan aquellos protocolos de las redes TCP/IP que no han tenido cabida
en otros capítulos como son los de correo electrónico, HTTP, de seguridad, etc.
Introducción 2
Los protocolos en las redes 3
Capítulo 2. Los protocolos en las redes
Los protocolos son la base de las comunicaciones entre los dispositivos que forman las redes de datos, es decir,
son la base del intercambio de información entre dispositivos. Sin embargo los dispositivos tienen que hablar
lenguajes con los que entenderse. Estos lenguajes son los protocolos, y la estructura de los mismos es su sintaxis
Según el modelo de referencia OSI, se define como protocolo a aquel conjunto de reglas y formatos que
gobiernan las comunicaciones entre entidades que ejecutan funciones a un mismo nivel en diferentes sistemas
abiertos.
Protocolo es por tanto un conjunto de normas que se usan para componer los mensajes que contienen la
información a transmitir.
Dado que estamos trabajando con redes digitales, la información y estructura de los protocolos siempre es
binaria, es decir, está formada por unos y ceros. Así se dice que los datos se transmiten de forma empaquetada, y
que viajan como mensajes.
2.1 Funcionalidades
Hay 4 conceptos sobre el funcionamiento de los protocolos que deben resaltarse y que son los siguientes:
 Propietario o estándar.
 Control de flujo.
 Control de errores.
 Protocolos orientados o no a la conexión.
Protocolo propietario o estándar

El concepto de protocolo propietario consiste en que las especificaciones del mismo no son públicas y además
como es natural, están registradas, lo que obliga al pago por su uso.
Por lo tanto estas especificaciones han sido diseñadas por una o varias empresas para su utilización. De esta
forma ninguna otra empresa sin autorización de las empresas propietarias, puede desarrollar aplicaciones con
este protocolo por desconocimiento de su funcionamiento y su estructura.
Para las empresas que lo han desarrollado, les puede dar importantes ganancias económicas si consiguen una
amplia implantación del mismo, o graves perjuicios económicos, si su implantación es mínima. En este último
caso, tendería a desaparecer en el tiempo.
Por el contrario, a los demás protocolos se les denomina estándar y por tanto son los que forman parte de los
llamados entornos abiertos. El ejemplo lo tenemos en la actualidad con el protocolo TCP/IP y todos los
protocolos publicados en Internet.
La mayoría de protocolos a nivel de aplicación son protocolos propietarios. Muchas aplicaciones para su
funcionamiento necesitan de un protocolo, que lógicamente está diseñado por la propia empresa, y es habitual
que sea propietario.
Control de flujo
Cuando se envían mensajes entre dos dispositivos, debe haber una sincronización entre ellos, por ejemplo,
porque trabajan a distintas velocidades, o porque el tamaño de la memoria de almacenamiento es distinta en
cuanto a tamaño. También podría ser porque el camino que siguen los mensajes, atraviesan zonas de baja
velocidad. Esto es lo que se entiende por control de flujo.
Hay protocolos como el TCP que incorporan esta facilidad y otros muchos no como el IP.
Así el control de flujo minimiza los problemas relacionados con:
 Sobrecargas de tráfico.
 Congestiones.
 Bloqueos de tráfico.
 Inadaptación de velocidades.
 Repartición no equitativa de recursos.
Los protocolos en las redes 4
El uso del control de flujo es más importante cuanto menos fiable sea el medio de transmisión. En el ámbito de
las líneas de comunicaciones es necesario.
Control de errores
El objetivo principal de un protocolo de red es suministrar un flujo de información entre dispositivos de la propia
red. Sin embargo, no es suficiente con el envío de esta información, sino también de asegurarnos de que esta
información ha llegado a su destino y de forma satisfactoria.
Este control es fundamental y por lo general, la mayoría de tipos de mensajes llevan unos bits de control, de
forma que se puede detectar si algún bit del mensaje durante la transmisión ha sido alterado. Incluso en algún
caso se podrían reconstruir los bits afectados sin necesidad de una nueva retransmisión.
Por otro lado, es habitual que una información esté contenida en varios mensajes. Entonces el destinatario los
envía en orden y secuencialmente una detrás del otro. Los caminos que seguirán estos mensajes puede que sean
distintos, y que la velocidad de transmisión de cada uno de ellos también. Esto hace que lleguen a su destino
desordenados, también duplicados alguno de ellos y alguno se haya perdido. En este el destinatario debe
controlar este desorden y ser capaz de ordenarlo y volver a solicitar la información que falta.
Orientados o no a la conexión.
Cuando un dispositivo quiere enviar mensajes, lo puede hacer de dos formas:
Enviando directamente a la red, los mensajes con la dirección del dispositivo destino, sin consulta previa de si
existe o está en condiciones de recibir dicha información. Este tipo de envíos se les llama no orientados a
conexión. Es el caso del protocolo IP. Esto no quiere decir que a continuación, pueda solicitar un acuse de recibo
del dispositivo destino.
Antes de enviar los mensajes con la información, el dispositivo origen envía un mensaje en el cual solicita la
respuesta del dispositivo destino, y además se aprovecha este intercambio inicial para el intercambio de algunos
parámetros necesarios para la transmisión. Una vez se reconocen ambos dispositivos, el origen y el destino, es
cuando se envían los mensajes con la información propiamente dicha. Este tipo de transmisión llamada
orientada a conexión, envía una proporción mayor de octetos que no son de información que la anterior. Por
otro lado una vez terminada la transmisión debe haber una tercera fase de liberación de la conexión.
Concretamente, las tres fases de una transmisión orientada a conexión son:
1 Establecimiento de la conexión
2 Transmisión de la información
3 Liberación de la conexión
2.2 Estructura
Todos los mensajes de los protocolos constan de 3 partes:

 Cabecera. Esta parte del mensaje contiene información relativa al mismo en cuanto
a control y funcionalidades del mismo.
 Datos.
 Control de error.
También muchos de ellos contienen los campos de:
 Inicio de mensaje.
 Fin de mensaje y
 Longitud del mensaje.
En cada apartado de cada protocolo se detalla la estructura correspondiente, explicándose sus funcionalidades.
Definiciones básicas 5
Capítulo 3. Definiciones básicas
A continuación se definen una lista de palabras con el significado que se le asigna a cada una de ellas en este
libro. La razón de este capítulo es que dado que idioma principal que se emplea en esta tecnología es el inglés, su
equivalencia al castellano varía según quien la emplea.
Dispositivo: es cualquier elemento que físicamente sea una caja, por ejemplo, un ordenador, un módem externo,
etc.
Interface: es cada una de las conexiones de un dispositivo a una red o sistema de comunicaciones. Una tarjeta de
red es una interface. Un puerto serie es otra interface a efectos de redes.
Mensaje: es el conjunto de octetos que en forma de mensaje envía un dispositivo a otro dispositivo.
Independientemente del ámbito del protocolo, en este libro siempre se escribirá mensaje, aunque a veces se
emplean otras nomenclaturas como llamar trama si es de nivel enlace o mensaje si son mensajes de protocolos de
nivel de red.
Enrutador. En inglés, router. Son aquellos dispositivos que encaminan los mensajes entre distintos segmentos
de una red. Funcionan con protocolos a nivel de red según el modelo de referencia OSI.
Puente. En inglés, bridge. Son aquellos dispositivos que encaminan los mensajes entre distintos segmentos de
una red. Funcionan con protocolos a nivel de enlace según el modelo de referencia OSI.
Concentrador. En inglés, hub. Es un dispositivo a donde se conectan las interfaces de otros dispositivos,
dándoles conectividad física. En general se emplean en las redes Ethernet.
Puerta de enlace. Son dispositivos que se emplean para el encaminamiento de mensajes dentro de un mismo
segmento de red.
Definiciones básicas 6
Modelo OSI 7
Capítulo 4. Modelo OSI
Este modelo ha sido y sigue siendo la referencia de todos los protocolos de redes incluso muchas veces en el
ámbito de las comunicaciones. Por esta razón, el autor de este libro lo aconseja como base para poder organizar
y entender los distintos tipos de protocolos y su ámbito de actuación.
Es un modelo dividido en niveles, cada una de las cuales indica una función concreta. Las razones para esta
división de las funciones de red son las siguientes:
 Los niveles dividen los aspectos de las operaciones de red en elementos menos
complejos.
 Los niveles definen las interfaces estándar para la compatibilidad plug-and-play.
 Los niveles permiten que los ingenieros especialicen sus esfuerzos de diseño y de
desarrollo en funciones modulares.
 Los niveles promueven la simetría en las distintas funciones modulares de red para
que trabajen de forma conjunta.
 Los niveles evitan que los cambios en un área afecten otras áreas, de manera que
cada área pueda evolucionar más rápidamente.
 Los niveles dividen la complejidad de la operativa de las redes en operaciones
separadas de fácil aprendizaje.
Sin embargo, la evolución de los sistemas informáticas y las comunicaciones asociadas a ello, hace que en
algunos casos, no sea aplicable como se irá explicando a lo largo de este documento. De todas maneras, como
modelo de referencia sigue siendo plenamente válido.
Así en 1978, la Organización Internacional de Estándares (ISO) publicó un conjunto de especificaciones que
describía una sistema de arquitectura de red para conectar distintos dispositivos. En 1984, esta misma
organización publicó una revisión de este modelo y lo llamó modelo de referencia de Interconexión de Sistemas
Abiertos (OSI - Open System Interconnection).
Este modelo consta de 7 niveles y son los siguientes :
7 Aplicación
6 Presentación
5 Sesión
4 Transporte
3 Red
2 Enlace
1 Físico
Y en la siguiente figura se enumeran los protocolos y ámbitos más habituales en cada uno de sus niveles.
7 Sistemas Operativos Apple

DOS, Windows, OS/2, Novell, MVS, Banyan MAC
6
5 NetBIOS LU 6.2
4 DECNET TCP/IP IPX/SPX SNA EtherTalk
3 XNS
2 Drivers software
1 802.3 802.5 FDDI
A continuación se describen las principales funcionalidades que deben tener los protocolos que funcionan según
el nivel al que pertenecen. Como ya se ha comentado anteriormente, no se trata de analizar las especificaciones
Modelo OSI 8
con detalle de cada nivel de este modelo, pero si que este modelo permite situar cada protocolo en su ámbito y
poder relacionarlo con los demás protocolos.
La conclusión es que el modelo OSI es un modelo teórico y no hay ningún protocolo que se ajuste de una forma
específica a un solo nivel. Los protocolos existentes en la actualidad se ajustan al modelo OSI de forma
aproximada.
4.1 Nivel físico (1)

A este nivel corresponde la determinación de las especificaciones correspondientes a las características
mecánicas, eléctricas y de procedimiento requeridas para establecer, mantener y desactivar los enlaces físicos.
Por ejemplo, a este nivel se determina las características físicas de los conectores y de los cables que se emplean
en las redes.
El nivel físico relaciona las interfaces eléctrica, óptica, mecánica y funcional con el cable.
Sus funciones son :
- Activación y desactivación de la conexión física.
- Transmisión de unidades de datos del servicio físico.
- Control de nivel físico.
- Sincronización a nivel de bit.
Las especificaciones de este nivel sirve para que los fabricantes de hardware, hagan que sus dispositivos sean
compatibles entre si, ya sean conectores, cables, etc.
4.2 Nivel de enlace (2)

Los protocolos de este nivel son los responsables de transmitir sin errores y de establecer conexiones lógicas
entre dispositivos. Esto se consigue empaquetando los bits procedentes de la capa física en bloques de datos, y
enviando éstas con la necesaria sincronización y orden. Los protocolos de este nivel efectúan la detección y
corrección de errores que puedan producirse en el nivel físico.
Sus funciones son :

- Inicialización. Establecimiento de una conexión activa sobre un camino físico ya existente.
- Identificación. Proceso necesario para distinguir un receptor o transmisor entre todos los que
pueden estar presentes.
- Sincronización a nivel carácter.
- Segmentación de los mensajes.
- Transparencia en cuanto a la estructura o formato de la información del usuario.
- Control de flujo.
- Control de error.
- Recuperación de condiciones anómalas.
- Terminación.
- Control del enlace.
El protocolo más extendido de este nivel es el 802.3 o Ethernet.

Otros protocolos son : 802.5 o Token Ring, 802.2, SDLC, SNAP
En el mundo de las comunicaciones, los protocolos de este nivel son: HDLC, SMDS, ATM, xDSL, Frame
Relay, RDSI entre otros.
También corresponden a este nivel los protocolos PPP, PAP, CHAP, PPTP, L2TP, L2F, CSLIP, SLIP
En el caso de las redes de datos, todas y cada una de las tarjetas de red de cada dispositivo, llevan asociadas un
número establecido de forma única por el propio fabricante. A este identificación se le conoce como dirección
MAC (Media Access Control) y tiene una longitud de 6 octetos (48 bits). Esta dirección MAC consta de 2
partes:
Modelo OSI 9
- Los primeros 3 octetos (24 bits), corresponden a un número identificativo del fabricante. Por
ejemplo IBM es 10005A. La asignación de esta numeración está regida por el IEEE.
- Los restantes 3 octetos, es un número dado por el propio fabricante y que no lo puede repetir en
dos tarjetas o interfaces.
Hay dos formatos para las direcciones MAC: 0000.0c12.3456 y 00-00-0c-12-34-56.
4.3 Nivel de red (3)

Los protocolos de este nivel son los responsables de las funciones de direccionamiento y control (p.e.
enrutamiento) necesarios para mover los datos a través de la red. También estos protocolos tienen que establecer,
mantener y finalizar las conexiones, incluyendo la conmutación de mensajes, el enrutamiento, la congestión de
mensajes, el ensamblaje de mensajes y la traducción de direcciones lógicas a direcciones físicas.
El protocolo más extendido de este nivel es el IP en el mundo de Internet, así como el IPX en las redes de Novell
Netware. El protocolo NetBIOS/NetBEUI realiza funciones de este nivel y el siguiente, es decir, el de transporte.
También corresponden a este nivel los protocolos de enrutamiento como son: RIP, BGP, IGRP y OSPF entre
otros.
Otros protocolos de este nivel son : ICMP, DHCP, RSVP, IGMP y PIM
4.4 Nivel de transporte (4)

La frontera entre el nivel de transporte(4) y el nivel de sesión(5) es en realidad la frontera entre los protocolos
del nivel de aplicación y los protocolos de los niveles más bajos. Mientras los niveles de sesión, presentación y
aplicación tienen que ver con los asuntos relativos de la aplicación, los cuatro niveles más bajos se refieren a los
elementos del transporte de la propia red de datos.
Este nivel de transporte asegura que los mensajes se entregan sin errores, secuencialmente y sin pérdidas ni
duplicaciones. Este nivel divide los mensajes largos en varios mensajes en el caso de envío a nivel de red. En la
recepción se ensamblan los mensajes, volviéndose a obtener los mensajes con el mismo formato en que estaban
en el dispositivo origen en este nivel.
Este nivel proporciona control de flujo y control de errores y participa en la solución de problemas relacionados
con la transmisión y recepción de mensajes.
El protocolo más extendido de este nivel es el TCP, así como el UDP y el SPX. También el protocolo
NetBIOS/NetBEUI realiza funciones de este nivel.
Otros protocolos son de este nivel son: ARP, RARP, vio
4.5 Nivel de sesión (5)

Este nivel permite que dos aplicaciones de dos dispositivos distintos establezcan, usen y finalicen una conexión
llamada sesión. Este nivel realiza el reconocimiento de nombres y las funciones, como la seguridad, necesarias
para permitir a dos aplicaciones comunicarse a través de la red.
El nivel de sesión proporciona la sincronización entre tareas de usuarios colocando puntos de control en el flujo
de datos. De esta forma, si la red falla, sólo es preciso retransmitir los datos posteriores al último punto de
control. Este nivel lleva también a cabo el control del diálogo entre los procesos de comunicación, regulando que
lado transmite, cuando, por cuanto tiempo, etc.
Es difícil encontrar protocolos que únicamente desarrollen funcionalidades de este nivel. Lo más habitual es que
los llamados protocolos de aplicaciones incorporen estas funcionalidades.
Unos protocolos con funcionalidades de únicamente este nivel serían: DNS, LDAP, RPC, SQL
Modelo OSI 10
4.6 Nivel de presentación (6)

Este nivel determina el formato utilizado para intercambiar datos entre equipos en red. Se puede llamar el
traductor de la red. En emisión, este nivel convierte los datos desde un formato enviado por el nivel de
aplicación a otro formato intermedio reconocido. En recepción, este nivel convierte el formato intermedio a un
formato útil para el nivel de aplicación de ese equipo. En nivel de presentación es responsable de convertir los
protocolos, traducir los datos, codificar los datos, cambiar o convertir el juego de caracteres y expandir los
comandos gráficos. El nivel de presentación administra también la compresión de datos para reducir el número
de bits que se necesita transmitir.
Lo mismo que se ha dicho de los protocolos de nivel de sesión, en este caso, también es difícil encontrar
protocolos que únicamente desarrollen funcionalidades de este nivel. Lo más habitual es que los llamados
protocolos de aplicaciones incorporen estas funcionalidades.
Unos protocolos con funcionalidades de únicamente este nivel serían: LU6.2, XNS Courrier, Postcript.
4.7 Nivel de aplicación (7)

Este nivel sirve de ventana para que los procesos de aplicación tengan acceso a los servicios de red. Este nivel
representa los servicios a disposición de las aplicaciones del usuario, como por ejemplo el software para la
transferencia de ficheros (protocolo FTP), para el acceso a base de datos y para el correo electrónico (protocolo
SMTP, MIME, POP3 y IMAP).
El nivel de aplicación controla el acceso general a la red, el control de flujo y la recuperación de errores.
A continuación se enumeran solamente algunos de los más conocidos, porque en la actualidad es muy habitual
que la mayoría de aplicaciones importantes tengan algunos protocolos propios y en general propietarios, por lo
que las empresas no dan a conocer su funcionamiento.
Algunos protocolos de este nivel son: FTP, HTTP, X-Windows, SNMP, SMB, NetBIOS sobre TCP/IP, Telnet.
Conceptos de LAN y WAN 11
Capítulo 5. Conceptos de LAN y WAN
Los conceptos de LAN y WAN son esenciales y básicos para entender como se interaccionan y relacionan los
protocolos en las redes de datos, y para distinguirlos si son de red o comunicaciones.
Una LAN (Local Area Network) consiste en una red de ordenadores sin que exista entre ellos ninguna línea de
comunicaciones propiamente dicha.
Una WAN (Wide Area Network) consiste en 2 o más LANs conectadas entre si mediante líneas de
comunicaciones.
¿Por qué se han de tener muy claros la distinción entre LAN y WAN ? Porque los protocolos que se emplean son
distintos, es decir, si es una WAN, además de los protocolos de LAN, se utilizan aquellos protocolos de WAN de
acuerdo con el tipo de comunicaciones que se emplee.
Protocolos de LAN siempre están presentes ya sea LAN o WAN, sin embargo, los protocolos de WAN solo se
incorporan a la red si hay líneas de comunicaciones.
La comunicación entre LANs sin líneas de comunicaciones emplea los protocolos de LANs.
LAN LAN
WAN
LAN
Sin embargo, si 2 LANs se comunican mediante una o varias líneas de comunicaciones, los protocolos de estas
líneas es distinto del de las LANs.
Así por ejemplo analicemos un enrutador con interfaces de LAN y WAN. Cuando la información entra o sale de
una interface LAN, se utilizan protocolos de LAN. Pero si son interfaces de WAN, se emplean protocolos de
WAN para comunicarse con el otro extremo. Por tanto internamente, estos dispositivos han de poder convertir
información en base a protocolos de LAN a WAN y viceversa.
Por otro lado, hemos de tener en cuenta los rangos de velocidades que se utilizan en cada uno de estos ámbitos
LAN y WAN.
En la actualidad, en LAN las velocidades son de
Ethernet 10 Mbps, 100Mps, 1 Gbps, 10 Gbps

Token Ring 4 Mbps, 16 Mbps
Siendo las unidades bits por segundo.

Conceptos de LAN y WAN 12
En WAN, las velocidades oscilan entre las 33k bits por segundo en líneas analógicas hasta 2 Mbps. En el mundo
de las comunicaciones digitales se están alcanzando velocidades superiores pero lejos de las velocidades de
LAN.
Comunicaciones entre ordenadores de una red 13
Capítulo 6. Comunicaciones entre ordenadores de una red
Los ordenadores constan de 3 partes :

- El hardware.
- El sistema operativo y
- Las aplicaciones.
Cada una de ellas, está relacionada con la siguiente, es decir, en general el software de las aplicaciones no está
directamente relacionado con el hardware, sino a través de los drivers del propio sistema operativo que hay
instalado.
En las redes, en que se comunican más de un ordenador, el diálogo en principio se establece hardware contra
hardware y esto genera un nivel de protocolos, por ejemplo, el IEEE 802.3 o Ethernet.
La comunicación entre los sistemas operativos de 2 ordenadores también es a través de drivers de protocolos que
se relacionan directamente con el hardware.
A nivel de aplicaciones, también hay sus protocolos.
Así se refleja en el modelo OSI, donde los protocolos de nivel 1 y 2 son los relacionados con el hardware y los
de nivel 5, 6 y 7 con las aplicaciones.
Comunicaciones entre ordenadores de una red 14
Relación modelo OSI y comunicación entre ordenadores 15
Capítulo 7. Relación modelo OSI y comunicación entre ordenadores
El modelo de referencia OSI describe como fluye la información de los programas de aplicación de un ordenador
a través de la red a otro programa de aplicación en otro ordenador.
Como ejemplo de esta transmisión según el modelo de referencia OSI, supongamos que el sistema A sea un
ordenador, que tiene que enviar información al sistema B, que es otro ordenador. El programa de aplicación del
sistema A comunica con el protocolo de nivel 7 del sistema A y le transmite la información que debe llegar al
sistema B. A continuación envía esta información al protocolo del nivel 6 del mismo sistema A y así
sucesivamente hasta alcanzar el protocolo de nivel 1 del sistema A. El nivel 1 es el que pone la información en el
medio físico de la red.
A continuación, esta información llega al sistema B porque están conectados físicamente. El protocolo del nivel
2 absorbe esta información, verifica que es para este sistema y a continuación transmite la información al
protocolo de nivel 2 del sistema B. Así asciende a través de los protocolos de los distintos niveles del sistema B
en sentido inverso hasta llegar al programa de aplicación del propio sistema B.
Sistema A Sistema B
Nivel 7 Nivel 7
Nivel 6 Nivel 6
Nivel 1 Nivel 1
RED
Así se dice que el protocolo de cada nivel del sistema A comunica con el protocolo de los niveles adyacentes del
propio sistema A, y a su vez que el protocolo de cada nivel del sistema A se debe corresponder con el protocolo
del mismo nivel del sistema B. Así el objetivo principal del protocolo de nivel 1 del sistema A es comunicarse
con el protocolo de nivel 1 del sistema B; el protocolo de nivel 2 del sistema A comunica con el protocolo de
nivel 2 del sistema B y así sucesivamente.
El sistema de niveles del modelo OSI excluye la comunicación directa entre niveles iguales en distintos sistemas.
Cada nivel del sistema A debe sin embargo relacionarse con los servicios de los niveles adyacentes del sistema
A, con el fin de alcanzar la comunicación del mismo nivel del sistema B.
Asumamos que el nivel 4 del sistema A debe comunicar con el nivel 4 del sistema B. Para hacer esto, el
protocolo de nivel 4 del sistema A debe usar los servicios del protocolo de nivel 3 del sistema A. El nivel 4 se
dice es el usuario del servicio, mientras que el nivel 3 es el proveedor del servicio. Los servicios del nivel 3
suministran al nivel 4 un punto de acceso (SAP), que es simplemente un punto donde se intercambian la
información.
Formatos de los mensajes
¿Cómo sabe el protocolo de nivel 4 del sistema B lo que quiere del protocolo de nivel 4 del sistema A?
Los requerimientos específicos del nivel 4 se guardan en la información de control, que se pasa entre los
protocolos del mismo nivel en un bloque llamado cabecera. Por ejemplo, supongamos que el sistema A quiere
enviar un texto al sistema B. Este texto se pasa del programa de aplicación del sistema A, al protocolo del nivel
de aplicación del sistema A. Este protocolo debe pasar esta información al protocolo del mismo nivel del sistema
B. El principio se pasa al protocolo de nivel 6 del sistema A con su propia información de control.
Este mensaje crece en tamaño a medida que baja de nivel hasta llegar a la red, donde el texto original con todas
las informaciones de control asociadas se envía al sistema B, que lo absorbe a través del nivel 1. Éste analiza su
cabecera, la lee y así sabe lo que tiene que hacer. De la misma forma lo pasa al nivel 2 que hace lo mismo, es
decir, leer la cabecera y realizar la acción correspondiente. Al final se llega al nivel de aplicación y de aquí al
programa de aplicación del sistema B, con el texto recibido.
Los datos de un nivel pueden contener información de control de otros niveles además de la información a
enviar.
Encapsulación
¿Cómo es el mensaje que circula por la red a nivel físico? Su contenido es un conjunto de bits con unos y ceros.
Este contenido ha de tener una estructura bien determinada para que cada protocolo lo entienda y actúe en
función de ello.
Así como ya se ha mencionado, todo mensaje de un protocolo consta de cabecera, datos y control de error.
Cabecera Datos Control de error
Volvamos al caso de una aplicación del sistema A que ha de transmitir información a la aplicación del sistema
B. En principio la aplicación del sistema A prepara un mensaje de acuerdo con el formato del protocolo que se
emplea a nivel 7. Por ejemplo, el envío de un fichero con el protocolo FTP.
Esta información se transmite al protocolo de nivel 4. Un protocolo de nivel 4 sería por ejemplo el TCP. Ahora
el formato del mensaje sería
Cabecera Cabecera Datos Control

Nivel 4 Nivel 7 de error
El protocolo de nivel 4 envía este mensaje al protocolo de nivel 3, por ejemplo, IP. Ahora el formato del mensaje
es
Cabecera Cabecera Cabecera Datos Control

Nivel 3 Nivel 4 Nivel 7 de error
Esto se repite con el nivel 2, con lo que el mensaje queda preparado para transmitirlo al nivel físico y que por
tanto su estructura es
Cabecera Cabecera Cabecera CabeceraNiv Datos Control

Nivel 2 Nivel 3 Nivel 4 el 7 de error
Este mensaje llegará con este formato o estructura al dispositivo destino y allí se deberá proceder al proceso
inverso.
El protocolo de nivel 2 del sistema B lee su cabecera y de ella extrae el protocolo de nivel 3 al que debe
transmitir el mensaje.
El protocolo de nivel 3 del sistema B repite el proceso de leer su cabecera y transmitir su mensaje al protocolo de
nivel 4 indicado en su cabecera.
Así llega finalmente la información a la aplicación correspondiente del sistema B.

A continuación se detalla la estructura de un mensaje, obtenida de un analizador de redes, correspondiente a una

red Ethernet, con protocolo de nivel 3 IP y de nivel 4 TCP.
SUMARY Abs Time Destination Source Summary
1 15:35:58.5299 Backbone B Score DLC Ethertype=0800, size=60 by
IP D=[36.54.0.11] S=[36.53.0.41]
TCP D=515 S=1023 SYN SEQ=10139
DLC: -------------- DLC Header -------------
DLC:
DLC: Frame 1 arrived at 15:35:58.5299 ; frame size is 60 (003C hex) bytes.
DLC: Destination: Station IntrlnOO2C6O, Backbone B
DLC: Source : Station 3Com 063885, Score
DLC: Ethertype = 0800 (IP)
DLC:
IP: ---------------- IP Header ------------------
IP:
IP: Version = 4, header length = 20 bytes
IP: Type of service = 00
IP: 000. .... = routine
IP: ...0 .... = normal delay
IP: .... 0... = normal throughput
IP: ---- -0.. = normal reliability
IP: Total length = 44 bytes
IP: Identification = 29539
IP: Flags = ox
IP: .0.. .... = may fragment
IP: ..0. .... = last fragment
IP: Fragment offset = 0 bytes
IP: Time to live = 14
IP: Protocol = 6 (TCP)
IP: Header checksum = F0CA (correct)
IP: Source address = [36.53.0.41]
IP: Destination address = [36.54.0.11), Lindy
IP: No options
IP:
TCP: --------------- TCP header -------------------------
TCP:
TCP: Source port = 1023
TCP: Destination port = 515 (Remote print)
TCP: Initial sequence number = 101396545
TCP: Data offset = 24
TCP: Flags = 02
TCP: ..0. .... = (No urgent pointer)
TCP: ...0 .... = (No acknowledgment)
TCP: .... 0... = (No push)
TCP: .... .0.. = (No reset)
TCP: .... ..1. = SYN
TCP: .... ...0 = (No FIN)
TCP: Window = 2048
TCP: Checksum = 0CEE (correct)
TCP:
TCP: Options follow
TCP: Haximum segment size = 1024
Se trata de un mensaje sin datos. El inicio de la línea DLC corresponde al la cabecera de nivel 2 que en este
mensaje corresponde al protocolo Ethernet. El indicativo de principio de línea IP corresponde a la cabecera del
protocolo IP de nivel 3 y el resto es la cabecera del protocolo TCP de nivel 3.
La cabecera de un nivel contiene una identificación del protocolo del nivel superior. En este caso en la cabecera
de nivel 2 (DLC), el código 0800 corresponde al protocolo IP de nivel 3. Lo mismo sucede con la cabecera IP,
donde se especifica el protocolo nº 6, que corresponde al protocolo TCP de nivel 4.
7.1 Caso de 2 ordenadores conectados en red sin línea de comunicaciones

Se trata de una red compuesta por ordenadores y sin ninguna línea de comunicaciones, es decir, una red aislada
de Internet por ejemplo.
Supondremos que a nivel físico se ha empleado cable trenzado sin apantallar (UTP) y conector RJ-45, que es lo
más habitual en la actualidad.
Si queremos que a nivel 2 se comuniquen, es necesario que tengan instalado el mismo protocolo. El estándar de
facto actual es el protocolo Ethernet.
Ahora bien, si además de estar los dos ordenadores conectados a un misma red, uno tiene instalada una tarjeta
Ethernet y el otro una tarjeta Token Ring no se pueden comunicar. Los 2 protocolos son incompatibles, debido
no solo a su funcionamiento sino también a la distinta estructura del mensaje.
Ordenador A Ordenador B
Nivel Aplicación Nivel Aplicación
Nivel 4 Nivel 4
Nivel 3 Nivel 3
Nivel 2 Nivel 2
En cuanto a los protocolos de nivel 3 y 4, pueden instalarse más de uno en un mismo dispositivo, pero como
mínimo 2 deben ser iguales.
En la actualidad el estándar de facto es el protocolo TCP/IP. Otros protocolos de estos niveles son en el caso de
las redes Novell Netware, los protocolos IPX a nivel 3 y SPX a nivel 4, en redes Microsoft e IBM el protocolo
NetBEUI con funcionalidades de nivel 3 y 4.
7.2 Caso de 1 ordenador conectado a Internet

Se trata de analizar a nivel de protocolos como se conecta un ordenador a través de su puerto serie con un
módem a Internet. Ahora a nivel físico se empleará un cable con conectores DB-9 o DB-25 conectado al módem.
A nivel 2, no se necesita ni el protocolo Ethernet ni el Token Ring, porque en este caso, no hay tarjeta de red. El
protocolo a utilizar en las interfaces serie con módem es el protocolo PPP.
Ordenador A
Nivel Aplicación
Nivel 4
Nivel 3
Nivel 2
Modem
A nivel 3 y 4, se debe instalar el protocolo TCP/IP que es el que se emplea en Internet.
A nivel aplicación, si solo se navega, con el protocolo HTTP sería suficiente, protocolo que ya lo llevan
incorporado los propios navegadores.
7.3 Caso de 2 redes conectadas por una línea de comunicaciones a través de 2

enrutadores
Hoy es habitual la conexión de una red empresarial a Internet a través de algún tipo de línea de comunicaciones.
También muchas redes tienen una comunicación vía algún tipo de línea de comunicación porque muchas
empresas disponen de locales geográficamente alejados.
En este caso, cada red dispone de un enrutador con un mínimo de 2 interfaces:

- una de LAN, con tarjeta de red Ethernet o Token Ring y
- otra de WAN, que corresponde a una interface serie y que es a través de la que se conecta a la
línea de comunicaciones, sea del tipo que sea, es decir, ya sea un módem, un adaptador RDSI, un
adaptador ADSL, línea Frame Relay, X.25, etc.
En cuanto a la LAN, los protocolos de nivel 2 son Ethernet o Token Ring. Los de nivel 3 y 4 como mínimo han
de tener instalado el protocolo TCP/IP que es el empleado en Internet.
Ordenador A
Nivel 7
Nivel 4
Nivel 3
Nivel 2 Nivel 2
Modem
Ahora se trata de analizar que sucede si el ordenador A envía un mensaje a través del módem. La aplicación
envía los datos al protocolo de nivel 4, TCP, que le añade la cabecera correspondiente y lo envía al protocolo de
nivel 3, IP, que le añade otra cabecera.
Cabecera Cabecera Cabecera Datos Control de

IP TCP Nivel 7 errores
A continuación el protocolo IP ve que lo tiene que enviar a la interface WAN donde está el módem. Por esta
razón, no lo enviará al protocolo de nivel 2, Ethernet o Token Ring, pero si al protocolo PPP que es el encargado
de enviarlo a través del puerto serie al módem.
Con este ejemplo, lo que se quiere demostrar el hecho de que los protocolos se pueden clasificar por su ámbito
de LAN y WAN, es decir, los protocolos de enlace Ethernet y Token Ring son de LAN, y PPP, RDSI, ADSL,
Frame Relay, X.25, etc. son de WAN.
Organismos de normalización 21
Capítulo 8. Proyecto IEEE 802
En la aplicación práctica del modelo OSI, sucede de que los fabricantes han discrepado en cuanto a la definición
de las especificaciones del protocolo a nivel de enlace de dicho modelo. Por esta razón, en el seno de la IEEE se
desarrolló el proyecto 802, en el cual se redefinen las especificaciones de este protocolo así como sus relaciones
con los protocolos de nivel físico.
Así en Febrero de 1980, la Computer Society del Institute of Electrical and Electronic Engineers (IEEE)
establecía el Proyecto 802 para hacer borradores de estándares para redes de área local (LAN). En línea con el
enfoque del modelo OSI, el IEEE Project 802 creó un modelo de referencia con 2 niveles, que corresponden con
los niveles físico y de enlace de datos del citado modelo de referencia OSI. Sin embargo, en el modelo del IEEE,
el nivel de enlace de datos está subdividido en 2 subniveles:
- El subnivel de control de enlaces lógicos (LLC) y
- El subnivel de control de acceso al medio (MAC).
El subnivel de control de enlaces lógicos (LLC) se describe en el protocolo IEEE 802.2 y es independiente del
protocolo de control de acceso al medio (MAC) que se use. En realidad el protocolo LLC es el protocolo de
enlace entre los protocolos de nivel físico y los distintos protocolos de nivel MAC, como son el Ethernet, el
Token Ring, el FDDI, entre otros.
El subnivel de control de acceso al medio (MAC) proporciona:

- El reconocimiento de direcciones.
- El reconocimiento de control de tramas.
- La delimitación de las tramas y
- La generación de estado de tramas entre otras funciones.
Por otra parte este proyecto 802 también ha especificado otros protocolos y que se agrupan en:
IEEE 802.1 - Estándar de interface de nivel superior, relativos a los protocolos de nivel físico.
IEEE 802.2 - Estándar de control de enlaces lógicos (LLC)
IEEE 802.3 - Estándar CSMA/CD
IEEE 802.4 - Estándar Token Passing Bus
IEEE 802.5 - Estándar Token Passing Ring
IEEE 802.6 - Metropolitan Area Networks (MAN)
IEEE 802.7 - Broadband Technical Advisory Group
IEEE 802.8 - Fiber Technical Advisory Group
IEEE 802.9 - Integrated Voice/Data on LAN
IEEE 802.10 - Interoperable LAN Security
IEEE 802.11 - Redes inalámbricas
Organismos de normalización 22
Direccionamiento 23
Capítulo 9. Organismos de normalización
A continuación se citan los principales organismos que han desarrollado distintas especificaciones tanto a nivel
de redes de ordenadores como de sistemas de comunicaciones.
ANSI (American National Standards Institute)

Esta organización es miembro de ISO y es muy conocida por sus estándares en FDDI.
CCITT (Consultative Commitee for International Telegraph and Telephone)

Es muy conocida por sus estándares en X.25
ECMA (European Computer Manufacturers Association)
EIA (Electronic Industries Association)

Es muy conocida por sus estándares de nivel 1.
IAB (Internet Activities Board)

Es un grupo de investigadores de redes que se reúnen regularmente para discutir temas sobre Internet. Algunos
documentos RFC (Request for Comments) han sido establecidos como estándares en Internet, como por ejemplo,
el correspondiente a los protocolos TCP/IP y SNMP.
IEEE (Institute of Electrical and Electronic Engineers)

Esta organización profesional ha definido los estándares de redes, siendo el más conocido el proyecto 802.
ISO (International Standard Organization)

Es una organización muy conocida por la definición de su modelo de referencia OSI.
ITU (International Telecommunication Union)

Esta organización es la responsable de toda la estandarización referente a los aspectos de las comunicaciones en
general, incluyendo por tanto las comunicaciones de datos.
TIA (Telecommunicaction Industry Association)

Es muy conocida por sus estándares de nivel 1.
Direccionamiento 24
Direccionamiento 25
Capítulo 10. Direccionamiento
En las redes de ordenadores, su objetivo es transmitir información entre 2 dispositivos. Esto hace imprescindible
identificar de alguna manera estos dispositivos.
En el lenguaje de las redes, a esta identificación se le llama dirección. A continuación vamos a analizarlas en
cada tipo de dispositivo de una red:
- Un ordenador. Se trata de dispositivos cuya funcionalidad tanto puede ser de servidor o estación
cliente o de trabajo. En este caso a cada tarjeta de red le ha de corresponder una dirección. Si es
un ordenador multihomed, es decir, que tiene más de una tarjeta de red, cada una de ellas debe
tener una dirección, independientemente pertenezcan al mismo segmento o no.
- Un repetidor. Este tipo de dispositivos no tienen nunca dirección de red, porque funcionan a nivel
físico.
- Un concentrador. Tampoco necesita ser identificado por una dirección, ya que es un dispositivo
sin posibilidad de configuración. Sin embargo cada dispositivo conectado a sus conectores, si que
tiene una dirección establecida.
- Un switch. Este dispositivo como tal no necesita ser identificado por una dirección, sin embargo
si se quiere dar facilidades de configuración externa, debe ser dotado de una dirección que lo
identifique.
- Un puente. Debe tener tantas direcciones como interfaces.
- Un enrutador. Debe tener tantas direcciones como interfaces.
10.1 Clases
Estas direcciones de red dependen no solo del nivel de operación del protocolo, sino también de cada protocolo
en si mismo.
Así a nivel de enlace, cualquier protocolo del proyecto 802, funciona con las llamadas direcciones MAC
En el nivel de red, es imprescindible la dirección, sin embargo los principales tipos son:
- IP
- IPX
- Apple
- NetBEUI
10.2 Direcciones según protocolo

Dirección MAC
Consta de 48 bits, siendo los 24 primeros identificativos del fabricante, y los 24 restantes, el propio fabricante
los debe asignar de forma unívoca a sus dispositivos, es decir, que no puede repetirlos. Es la que emplean los
protocolos de nivel 2 como Ethernet, Token Ring y FDDI.
Dirección IP
Esta dirección es la que emplea el protocolo IP y consta de 32 bits. Su representación consiste en 4 números
decimales del 0 al 255, separados por un punto (X.X.X.X).
Dirección IPX
Esta dirección es la que emplea el protocolo IPX y tiene una longitud de 12 octetos, y que se compone de:
- La dirección de la red. 4 octetos.
- La dirección del nodo. 6 octetos. Es la dirección de la interface del dispositivo. En general
coincide con la dirección MAC.
- Un número del socket. 2 octetos. Es el número por el que el servidor recibirá las solicitudes.
Direccionamiento 26
Dirección Apple
Esta dirección es la que emplea el protocolo DDP de Apple Talk y tiene una longitud de 24 bits, y que se
compone de:
- La dirección de la red. 16 bits.
- La dirección del nodo. 8 bits. Es la dirección de la interface del dispositivo.
Dirección DECnet
Esta dirección es la que emplea el protocolo DECnet y se compone de:
- La dirección de la red, 6 bits, un valor comprendido entre 1 y 63 y
- La dirección del nodo, 10 bits, un valor comprendido entre 1 y 1023.
En total, una longitud de 16 bits.
Dirección NetBIOS
Corresponde al nombre del dispositivo.
Protocolos de nivel físico (1) 27
Capítulo 11. Protocolos de nivel físico (1)
En este nivel no hay ningún protocolo propiamente dicho, ya que a este nivel corresponde la determinación de
las especificaciones correspondientes a las características mecánicas, eléctricas y de procedimiento requeridas
para establecer, mantener y desactivar los enlaces físicos. Por tanto cabe determinar aquí los tipos de cables y
conectores tanto en el ámbito LAN como el WAN.
A continuación se citan los conectores y cables más empleados, pero no es objeto de este libro entrar en detalle
en estas especificaciones.
Ámbito LAN
En cuanto a conectores, en la actualidad el más utilizado en los cables de cobre es el RJ45 de 8 hilos. El conector
de datos de IBM está en desuso, así como el cable coaxial con su conector BNC. En cuanto a cables de fibra
óptica, el conector más utilizado es el ST, pero también se emplea el mini BNC, el bicónico, el SMA, el FC/PC y
el SC.
En cuanto a cables, hoy el más utilizado es el par trenzado de categoría 5, que permite velocidades de hasta 100
Mbps. Dentro de esta categoría, hay distintas coberturas en función del ámbito donde está instalado. Hay que
destacar que lo habitual es usar cable no apantallado (UTP), excepto en ambientes con importantes
interferencias, en cuyo caso se usará el cable apantallado (STP). En general este tipo de cable tiene mayor
atenuación. En la actualidad también hay cable par trenzado de categoría 6 y 7, que son más adecuados para
velocidades de 100 Mbps. y superiores.
Aparte tenemos los cables de fibra óptica. Hay de 2 tipos: monomodo y multimodo. El cable monomodo, con un
diámetro inferior a 10 micras, permite distancias mayores entre equipos.
Ámbito WAN
Los conectores son RJ-11 de 2 y 4 hilos, V35, X21 y BNC para cable coaxial.
El cable que se utiliza muchas veces es el coaxial de cobre y también cable de fibra óptica. Para distancias
cortas, se utiliza cable telefónico.
También hay cable V.35 y cable RS-232
Protocolos de nivel físico (1) 28
Protocolos de nivel enlace (2) 29
Capítulo 12. Protocolos de nivel enlace (2)
En este apartado se explican aquellos protocolos que se usan en el ámbito de las LAN y que corresponden al
nivel de enlace (2) del modelo OSI. Estos protocolos se comunican por una parte con los protocolos de nivel
físico (1) y por otra con los de nivel de red (3).
En la actualidad el más difundido y utilizado es el protocolo 802.3 o Ethernet. Este protocolo se apoya en el
protocolo LLC del IEEE 802.2 según el esquema del modelo OSI y del proyecto 802.
También hemos de mencionar en este nivel el protocolo 802.5 o Token Ring.
Otro protocolo de estas nivel de enlace es el FDDI. En la actualidad sólo se usa en la comunicación de redes con
cableado de fibra óptica y con una necesidad de un ancho de banda muy importante como puede ser por ejemplo
un campus universitario.
La utilización de fibra óptica se emplea como medio de comunicación mediante la utilización de conversores de
cobre a fibra óptica o viceversa. En estos casos estos conversores trabajan a nivel físico, por lo que los
protocolos que se utilizan en estos casos son los propios de los cableados con cobre.
En las redes AppleTalk, los protocolos de este nivel son LocalTalk, EtherTalk, TokenTalk y FDDITalk.
12.1 IEEE 802.2

El protocolo 802.2 se corresponde con el subnivel LLC del proyecto 802 dentro del nivel de enlace (2) del
modelo OSI. Por un lado interopera con los protocolos 802.3, 802.5,etc. del subnivel MAC del nivel de enlace
(2) y por otro con los protocolos de nivel de red (3).
Nivel 3 IP IPX NetBIOS

LLC 802.2
Nivel 2
MAC 802.3 802.5 Otros
Este protocolo no se refleja en los mensajes que circulan por las redes, porque son internos, es decir, van dentro
del propio dispositivo como un driver. Sus direcciones origen y destino (SAPs), se corresponden a los protocolos
de nivel 3 de los dispositivos origen y destino.
LLC inicia el intercambio de señales de control, organiza el flujo de datos, interpreta los comandos, genera
respuestas y gestiona las funciones de control de errores y su recuperación.
Este protocolo 802.2 ofrece 3 tipos de servicio:

- Tipo 1 : sin reconocimiento y no orientado a conexión. También se llama modo de operación
datagrama del usuario. Es el más usado por ejemplo en redes TCP/IP. No hay reconocimiento por
parte del receptor, ni el emisor lo espera, porque se consideran las redes suficientemente fiables.
Por esta razón, los servicios del nivel transporte tienen que proporcionar la recuperación y la
segmentación de tramas.
- Tipo 2 : orientado a conexión. En este caso, se establecen circuitos virtuales entre el dispositivo
que envía y el dispositivo que recibe. Es el caso del protocolo HDLC en modo ABME
(Asyncrhonous Balanced Mode Extended). En este caso, hay primero el establecimiento del
enlace y luego durante la transmisión, hay una detección de errores, su recuperación y un control
de flujo.
- Tipo 3 : con reconocimiento y no orientado a conexión. En este caso no hay circuitos virtuales.
Este tipo resulta especialmente interesante para las LAN de alta velocidad como FDDI y
concretamente para los protocolos de gestión de la LAN.
La estructura del mensaje es

SAP destino SAP origen Control Datos
donde
- SAP destino es un campo de 8 bits, de los cuales 6 representan la dirección propiamente dicha. El
bit 8 es el indicativo de I/G (individual o grupo). La dirección significa la puerta del protocolo
LLC correspondiente con el protocolo de nivel de red del dispositivo destino.
- SAP origen es un campo de 8 bits. El bit 8 es 0 o 1, si el mensaje es un comando o una respuesta.
La dirección que utiliza 6 bits, significa la puerta del protocolo LLC correspondiente con el
protocolo de nivel de red del dispositivo origen.
- Control, campo de 1 o 2 octetos donde se especifica la función del comando de solicitud o
respuesta, así como el tipo de LLC empleado. Su contenido se parece mucho al del protocolo
SDLC, así hay 3 tipos de formatos: sin secuencia, supervisor y de información.
- Datos.
En cuanto al campo de control su contenido puede ser
Formato Configuración binaria Nombre

Sin secuencia 000 F 1111 DM
010 F 0011 DISC
011 F 0011 UA
011 F 1111 SABME
100 F 0111 FRMR
101 P/F 1111 XID
111 P/F 0011 TEST
Supervisor 00000001 RRRRRRR P/F RR
00000101 RRRRRRR P/F RNR
00001001 RRRRRRR P/F REJ
Información SSSSSSS0 RRRRRRR P/F I
Donde P/F es un bit con el significado de sondeo/final.
En cuanto a la dirección SAP, un dispositivo puede tener más de un SAP asociado a ella para un nivel específico,
igual que un dispositivo puede tener más de una sesión activa mediante un SAP.
Los procesos de los niveles superiores usan los servicios del protocolo 802.2 a través de puntos de acceso al
servicio (SAP - Service Access Points). Estos SAP identifican los protocolos del nivel de red que deben
recibirlo, en el caso de pasar mensajes de nivel 2 al 3. Sin embargo si es al contrario, es decir, un mensaje que
pasa del nivel 3 al 2, el SAP destino es el protocolo de nivel de red del dispositivo de destino.
Algunos valores de SAP son los siguientes:
APPN 04 Vines BC
TCP/IP 06 IPX E0
SNA 08 NetBIOS F0
X.25 7E RPL F8
SNAP AA Ungerman-Bass FA
12.2 IEEE 802.3 / Ethernet

Ethernet o IEEE 802.3 es el protocolo más utilizado actualmente en el mundo de las redes informáticas por
razones de economía. Desde su introducción en el mercado en los años 70, se ha implantando en un gran abanico
de ámbitos de todo tipo.
Inventado por Xerox en los años 70 y llevado al mercado con el nombre de Ethernet V.1, el protocolo fue
desarrollado por un foro donde estaban DEC, Intel y Xerox. Este foro sacó en los años 80 una nueva versión de
Ethernet llamada Ethernet (DIX) V2.
También hicieron pública su arquitectura y así de la mano del Institute of Electrical and Electronics Engineers
(IEEE), ha llegado a ser un estándar internacional de facto. El IEEE ratificó el estándar Ethernet DIX V2 con
ligeras modificaciones y lo denominó IEEE 802.3. El estándar IEEE 802.3 ha sido también aprobado por otras
organizaciones tales como el American National Standards Institute (ANSI) y el International Organization for
Standardization (ISO 8802-3).
Así hay 4 versiones de este protocolo que son las siguientes:
Ethernet Esta versión corresponde a la versión original DIX y su posterior

versión II
802.3 Corresponde al protocolo 802.3 sin empleo del protocolo 802.2. Este
protocolo lo empleó Novell Netware cuando aún no estaban
aprobadas las especificaciones del protocolo.
802.3 – 802.2 LLC Es el protocolo 802.3 pero que necesita del protocolo 802.2 para su
funcionamiento.
802.3 – 802.2 LLC - SNAP Ethernet SNAP extiende el encabezado IEEE 802.2 agregando un
encabezado de Protocolo de acceso de subred (SNAP) que
proporciona un código de "tipo de encapsulamiento" similar al
definido en la especificación de Ethernet Versión II y utilizado con
TCP/IP y AppleTalk.
Las principales ventajas de Ethernet / 802.3 son :

 Amplia elección de equipos.
 Bajo precio de los mismos.
 Alta velocidad de transmisión.
En cuanto a su topología:
– Físicamente es una estrella (hub o concentrador).
– Lógicamente es una estrella.
El acceso al medio es utilizando el método CSMA/CD (Carrier Sense Multiple Access with Collision Detection).
Este método se basa en escuchar el medio para ver si está ocupado por alguna trama de alguna estación antes de
transmitir tramas. A pesar de que se escuche el medio las tramas pueden “colisionar” en el medio con lo que es
necesario retransmitirlas.
Otro método similar es el CSMA/CA, que consiste en informar de forma previa a la red de que se va a transmitir.
Con ello se evitan colisiones, pero disminuye la eficiencia de la red, ya que hay una información adicional que se
transmite y que no son datos propiamente dichos.
12.2.1 Nivel físico
Ethernet forma una familia de LANs que abarca Ethernet (10 Mbps), Fast Ethernet (100 Mbps) y Gigabit
Ethernet (1000 Mbps) sobre cables de cobre STP y UTP, y de fibra óptica multimodo y monomodo.
El método de codificación es Manchester, es decir, el tiempo de bit se divide en dos mitades, siendo su transición
en función del contenido del bit, así
- el 1 corresponde a una transición baja-alta y
- el 0 a una transición alta-baja
En cuanto a la velocidad de 10 Mbps, Ethernet define 4 configuraciones básicas: 10Base2, 10Base5, 10BaseT y
10BaseF.
El significado del número a la izquierda es su velocidad. En cuanto el código a su derecha, corresponde a la

máxima distancia en cientos de metros o a la clase de medio de transmisión empleado.
10 Base2
En este caso se trata de redes Ethernet que emplean cable coaxial de tipo thin, de aquí que también se las
conozca como Thinnet o Cheapnet.
El empleo de este tipo de cableado hace que los dispositivos se conecten en bus (segmento) y el empleo de taps
(impedancias de 50 ) en sus extremos.
El tipo de conector es BNC-T. Este conector conecta la tarjeta de red (NIC) de la estación al cable coaxial.
La distancia máxima recomendada es de 200 m.
10Base5
En este caso se trata de redes Ethernet que emplean cable coaxial de tipo thick, de aquí que también se las
conozca como Thicknet.
En el caso de tener un 10Base5 se usa un transceiver para conectar la tarjeta de red al cable. El hardware está
repartido entre la tarjeta de red y el transceiver. En este caso los conectores que se emplean son los AUI
(Attachment Unit Interface).
La distancia máxima recomendada es de 500 m.
10BaseT
Las configuraciones básica 10BaseT emplea cable de cobre con par trenzado UTP-3 y UTP-5.
Los concentradores implementan internamente un bus. Las estaciones se conectan generalemente con cable UTP
y conector RJ45 entre las tarjetas de red de la estación y el puerto del concentrador.
10BaseF
Las configuraciones básica 10BaseF emplea fibra óptica. Los conectores son del tipo SC o ST.
10BaseF define 3 variantes:
– 10BaseFP (passive star): repetidor óptico pasivo con un máximo de 33 nodos y 1Km/segmento.
– 10BaseFL (link): interconecta nodos o repetidores con un límite de 2 Km.
– 10BaseFB (backbone): interconecta repetidores hasta 2 Km entre ellos con transmisión síncrona
(hasta 15 repetidores en cascada), excediendo el límite de la regla 5-4-3. Se usa para interconectar
múltiples concentradores en cascada y así incrementar la longitud de la red excediendo la regla de
que sólo haya 5 segmentos de red conectados entres sí.
Formato de los mensajes Ethernet y IEEE 802.3

Los formatos de los mensajes para Ethernet y IEEE 802.3 son distintos, sin embargo, ambos protocolos usan el
mismo medio y método de acceso. Esto significa que los equipos de la red pueden compartir ambos formatos en
el bus común, pero no se pueden comunicar entre sí.
La estructura del mensaje 802.3 / Ethernet es la siguiente :
Preámbulo Sincroni- Dirección Dirección Tipo Datos PAD Control de

zación destino origen error
donde
- Preámbulo – 7 octetos. Permite que la electrónica de señalización del nivel físico pueda
sincronizar con la electrónica de recepción de mensajes. En contenido de cada octeto es
10101010
- Sincronización (SFD-Start Frame Delimiter) – 1 octeto. Indica que porción de datos del mensaje
vienen a continuación en la transmisión del mismo. Su contenido es 10101011
- Dirección destino (DA) - 48 bits. Se corresponde a la dirección MAC (Media Access Control).
Tres tipos de direcciones destino son posibles : individual, de multicast y de broadcast. La
individual contiene una única dirección de un nodo concreto de la red. La de multicast significa
que se usa un grupo de direcciones. La de broadcast es una forma especial de multicast, pero para
todos los nodos de la red.
- Dirección origen (SA) - 48 bits. Su significado es el mismo que la dirección destino.

- Tipo - 16 bits. Este campo identifica el tipo de protocolo del nivel superior. Los fabricantes
deben registrar sus protocolos de acuerdo con el estándar Ethernet. Cada protocolo registrado
tiene un identificador de 2 octetos. En el protocolo 802.3, este campo corresponde a la longitud
del mensaje. La identificación del protocolo de nivel superior en el caso del protocolo 802.3 se
realiza en las direcciones SAP del protocolo 802.2, por ejemplo 0x0800 si es protocolo IP o
0x0806 si es protocolo ARP.
- Datos - Este campo contiene los datos a transmitir y su longitud oscila entre 46 y 1500 octetos.
Ethernet asume que los niveles superiores asegurarán que el tamaño mínimo de mensaje sea de 46
octetos. Si se emplea el protocolo 802.2, dentro de este campo se incluye la cabecera de este
protocolo.
- PAD - campo de relleno. IEEE 802.3 (y Ethernet) especifican un tamaño mínimo de mensaje de
64 octetos. Sin embargo, el 802.3 permite que el campo de datos sea inferior a los 46 octetos
requeridos para que la longitud total sea como mínimo de 64 octetos. Por ello el 802.3 añade los
caracteres de rellenos necesarios para cumplir este requisito.
- Control de error - 32 bits. Se emplea el método de control de error CRC-32.
En el caso del protocolo 802.3 con 802.2, el campo de datos se desglosa en:
- SAP destino.
- SAP origen.
- Control, campo de 1 ó 2 octetos.
El protocolo 802.3 con SNAP desglosa su campo de datos en:

- SAP destino.
- SAP origen.
- Control, campo de 1 ó 2 octetos.
- Id. Organización, 3 octetos.
- Tipo, 2 octetos. Corresponde al tipo de protocolo de nivel superior, así para IP, es 2048 y para
ARP, 2054.
12.2.2. CSMA/CD (Carrier Sense Multiple Access con Detección de Colisión)
CSMA/CD (Carrier Sense Multiple Access con Detección de Colisión) es el nombre de la tecnología utilizada en
el bus del protocolo Ethernet /IEEE 802.3 que controla la operación de la red.
Su esquema de funcionamiento está detallado en el esquema adjunto.
Transmisión
Cuando la estación transmisora quiere enviar una trama,
1) primero debe montar la trama con la información recibida del protocolo del nivel superior.
2) A continuación verificar si el medio está libre. Si otro dispositivo está transmitiendo, debe esperar
a que termine su transmisión.
3) En el caso de que esté libre, verificar que el tiempo IPG que ha de transcurrir entre la
transmisión de dos tramas consecutivas ha transcurrido. La razón de este tiempo IPG es con el fin
de que una estación esté mucho tiempo transmitiendo y no deje transmitir a otra.
4) Transmitir el primer bit de la trama y a continuación comprobar si hay colisión. Ésta puede existir
dado que hay una distancia entre dispositivos y en consecuencia un retardo, que hace que aunque
se verifique que el medio esté libre otra estación puede también verificarlo y en el tiempo del
retardo ponerse también a transmitir.
5) Esta transmisión de bits y su verificación de colisión se realiza durante toda la transmisión de la
trama.
Colisión
Si hay colisión, la estación que la detecta, envía una señal de jamming consistente en varios bits que fuerzan a
que la colisión se prolongue durante un tiempo suficiente para que se enteren todas las estaciones del segmento.
A continuación la estación que quiere transmitir, deja transcurrir un tiempo aleatorio o tiempo de backoff, y
vuelve a intentar la transmisión pendiente. El componente aleatorio de este tiempo es para minimizar la
probabilidad de nuevas colisiones.
Estos intentos también son controlados por un contador, que una vez superado un umbral establecido intentos, da
la trama por no transmitida.
La probabilidad de una colisión es proporcional a

- El número de dispositivos conectados al bus.
- La frecuencia de transmisión.
- El tamaño de los mensajes y
- La longitud de los cables de la red.
Recepción
Mientras un dispositivo no emite, está en estado de escucha. Cuando detecta la presencia de una señal en la red,
inhibe la posibilidad de transmisión del mismo.
Con los bits de preámbulo obtiene la sincronización necesaria para leer la trama. Lo primero que obtiene es la
dirección MAC de destino de la misma y la compara con la suya. En caso afirmativo, la dirección MAC origen,
la dirección MAC destino y los datos son enviados al buffer para su procesamiento.
A continuación verifica el código de error de la trama, dándola por correcta o errónea.
También verifica la longitud de la trama, y si es más pequeña de 64 octetos la descarta.
Si lo que lee es consecuencia de colisión, envía una secuencia de jamming y deja de transmitir.
Valores
Es habitual en Ethernet el empleo de los siguientes valores:
 Límite de intentos de transmisión = 16
 Tamaño de la señal de jamming = 32 bits
 IPG = 9,60 s (96 bits)
12.2.3 Dominio de colisión
Dominio de colisión es aquel conjunto de dispositivos conectados físicamente entre si, pero que en cada instante
solo uno de ellos puede transmitir. Al área en el que cuando se produce una colisión esta es propagada se le
llama Dominio de Colisiones.
En el caso de un concentrador, todos los dispositivos conectados a él forman un dominio de colisión.

Si tenemos varios concentradores conectados entre si, en este caso solo hay un dominio de colisión.
Sin embargo, si la unión de 2 concentradores se hacen mediante el uso de un puente o un enrutador, cada
concentrador es un dominio de colisión.
Regla 5-4-3 : Para evitar que el dominio de colisiones sea muy grande hay una regla llamada 5-4-3 que dice que
dos estaciones no pueden estar separadas por más de 5 segmentos, 4 repetidores y sólo 3 de los 5 segmentos
pueden estar poblados con estaciones.
12.2.4 Ventana de colisiones
En Ethernet, como protocolo de detección de colisiones (CSMA/CD), hay un tamaño mínimo de trama. La razón
es que si una estación transmite, y se produce una colisión porque otra estación también está transmitiendo,
¿cuando tiempo tarda en conocerlo? La situación peor, es decir, la de tiempo máximo es lo que se llama la
ventana de colisiones.
Este tiempo máximo es el que transcurre:

- desde que se propaga el primer bit de la trama de una estación
- más el tiempo que tarda en propagarse el primer bit de la señal de jamming de la otra estación que
ha detectado primero la colisión.
Hay que dar tiempo a que si se produce una colisión entre las dos estaciones más lejanas el primer bit de la trama
llegue a la estación más lejana (un Tp ), ésta detecte la colisión y transmita su jamming (otro Tp ).
En esta situación límite, si cuando llega el primer bit de la señal de jamming a la primera estación, ésta ya ha
transmitido toda la trama, no detectará la colisión y dará por entregada correctamente dicha trama, cuando en
realidad no ha sido así porque ha habido colisión.
La ventana de colisión, también llamada tiempo de vulnerabilidad Tv , nos permite conocer durante cuanto
tiempo el sistema es vulnerable de que haya colisiones dado que una estación ha transmitido una trama.
Los dos tiempos de propagación, en el caso peor, corresponde a las dos estaciones más alejadas.
ventana de colisión = 2 · Tp max
Por otro lado se define como diámetro de la red (DR) a la distancia entre los dos dispositivos más alejados.
Por todo lo expuesto el tamaño mínimo de trama L min vale
L min = ventana de colisión / T b
siendo T b el tiempo de bit y la ventana de colisión
Ventana de colisión = 2 · T p max = 2 · ( DR / v p)
siendo v p la velocidad de propagación.
El protocolo 802.3/Ethernet ha establecido el tamaño de trama mínima en 64 octetos, es decir, 512 bits.
En consecuencia para la velocidad de 10 Mbps, el diámetro máximo de red es
Ventana de colisión = L min · T b = 512 . (1 / 10000000) = 0,0000512 seg.

DR = (0,0000512 · v p ) / 2 = 0,0000256 · v p
La velocidad de propagación depende del medio de transmisión empleado, que puede ser cable de cobre o fibra
óptica.
Para 100 Mbps, el diámetro máximo de red vale

DR = (0,00000512 · v p ) / 2 = 0,00000256 · v p
Es decir, 10 veces menos.
Sin embargo el empleo de concentradores activos, introduce unos retardos por cada uno de ellos que se
encuentren entre los dos dispositivos más alejados.
Por esta razón en estos casos la ventana de colisión vale
Ventana de colisión = 2 · T p max + suma de retardos de los enlaces + suma de los retardos de los repetidores +
retardo NIC 1 + retardo NIC 2
siendo retardo NIC el tiempo de procesamiento en la tarjeta de red del dispositivo.
Las configuraciones básicas definen el tamaño máximo de un segmento Ethernet, en 10Base2 es de 185 mt, en
10Base5 es de 500 mt, en 10BaseT es de 100 mt y en 10BaseF depende si se emplea fibra multimodo o
monomodo. Si queremos aumentar el tamaño de la red (Diámetro de la Red) hasta su tamño máximo (Diámetro
Máximo de la Red) hay que utilizar repetidores.
Las configuraciones básicas definen cual es el diámetro máximo de la red: en un 10Base2 es de 1 Km y en un

10Base5 es de 2.5 Km.
Primitivas
Las funciones necesarias para el funcionamiento del protocolo se llaman primitivas y en el caso del protocolo
802.3/Ethernet son:
- request. Esta función consiste en una solicitud del protocolo 802.3/Ethernet al protocolo de nivel
superior, que en la actualidad es el 802.2
- Indication. Esta función consiste en recibir una notificación de sucesos procedente del protocolo
de nivel superior. En la actualidad es el 802.2
- Confirm. Esta función consiste en una respuesta a una solicitud del protocolo de nivel superior, es
decir, el 802.2
12.3 Fast Ethernet

El IEEE Higher Speed Ethernet Study Group se formó para estudiar la viabilidad del protocolo Ethernet a una
velocidad de 100 Mbps. El grupo se escindió en dos, porque unos defendían el método CSMA/CD y los demás
creían que se debía emplear otro método. El primero pasó a llamarse Fast Ethernet Alliance y el otro 100VG-
AnyLAN Forum. Así aparecieron dos especificaciones, la 100BaseT y la 100VG-AnyLAN, respectivamente.
100BaseT es la especificación del IEEE en cuanto a las implementaciones de Ethernet a 100 Mbps con cableado
de cobre de cables cruzados sin apantallar (UTP) y apantallados (STP). El nivel MAC (Media Access Control) es
totalmente compatible con el nivel MAC del IEEE 802.3.
En cuanto al 100VG-AnyLAN es una especificación IEEE para redes de 100 Mbps, tanto para implementaciones
Token Ring como Ethernet con cableado de cobre de cables cruzados de 4 pares sin apantallar. El nivel MAC no
es compatible con el nivel MAC de las especificaciones IEEE 802.3. El 100VG-AnyLAN ha sido desarrollado
por Hewlett-Packard (HP).
Así el Fast Ethernet o es un protocolo exactamente igual que el protocolo 802.3/Ethernet. La única diferencia
está en que su velocidad es de 100 Mbps en vez de los 10 Mbps del Ethernet estándar. Por esta razón pueden
convivir dispositivos con tarjetas de 10 Mbps y de 100 Mbps. Su estandarización también ha corrido a cargo del
IEEE siendo su especificación la 802.3u.
En cuanto al cableado con cobre, la diferencia principal entre el 100BaseT y el 10BaseT es el diámetro de la
red, es decir, con 100BaseT se recomienda un máximo de 205 m., 10 veces menos que con Ethernet a 10 Mbps.
Los tipos son:
100BaseTX 100BaseFX 100BaseT4

Cable Categoría 5 Fibra óptica Categoría 5
Nº de pares 2 2 4
Conector RJ45 SC / ST RJ45
Longitud máxima del segmento (m) 100 400 100
El tipo 100BaseTX y el 100BaseT4 son con cable de cobre y el 100BaseFX para fibra óptica. La diferencia
entre los dos primeros es su tipo de señalización, así el tipo 100BaseTX emplea señalización 100BaseX y el
segundo señalización 4T+
Ambas señalizaciones son interoperables en el dispositivo y en los concentradores. La señalización 100BaseX

permite la mezcla de canales con transmisión full-duplex, con cableado de fibra óptica, en cuanto a que pueden
emplear la misma señalización.
La señalización 4T+ emplea un par de hilos para detectar la colisión y los otros 3 pares para la transmisión de
datos. Soporta operación full-duplex y se podrían utilizar cables de cobre de Categoría 3. La especificación IEEE
802.3u para redes 100BaseT4 permite un máximo de dos repetidores y un diámetro máximo de red de 200 m..
12.4 Gigabit Ethernet

Estas redes se basan en el protocolo 802.3/Ethernet, pero a diferencia de aquel, su velocidad de transmisión es de
1 ó 10 Gbps.
1 Gigabit Ethernet
En cuanto a las redes de 1 Gbps, su protocolo es una combinación del Fibre Channel y del IEEE 802.3, Su
recomendación se encuentra detallada en la especificación 802.3z.
Sin embargo se ha completado con el estándar 802.3ad, que define como 2 o más conexiones Gigabit Ethernet se
pueden combinar para compartir o equilibrar las cargas.
En cuanto a su cableado, está restringido exclusivamente a medios de fibra óptica.
El formato del mensaje es el mismo que el Ethernet /802.3.
Las aplicaciones del Gigabit Ethernet son fundamentalmente para interconectar troncales más que estaciones o
servidores a una red.
10 Gigabit Ethernet
Su recomendación se basa en el IEEE802.3ae. Solo se ha desarrollado para su uso con fibra óptica y full duplex,
por lo que los protocolos de detección de colisiones son innecesarios.
El formato del mensaje es el mismo que el de la recomendación IEEE 802.3
En cuanto a distancias con el 10 Gigabit Ethernet y fibra óptica monomodo se alcanzan 40 Km. Mientras que
con el Gigabit Ethernet solamente 5 Km.
12.5 IEEE 802.5 / Token Ring

El estándar IEEE 802.5 describe el llamado protocolo Token Ring. Este protocolo está en la actualidad en desuso
por razones de mercado, aunque existen muchas instalaciones con este protocolo. Tecnológicamente es mejor
que el Ethernet, porque permite un mayor aprovechamiento del ancho de banda (hasta un 90%, contra un 30%
del Ethernet). Sin embargo el precio de los dispositivos y el no haber superado los 16 Mbps, hace que no hayan
nuevas redes con este protocolo.
En una red Token Ring los equipos están físicamente conectados a un concentrador cableado con una topología
en anillo y cableado en estrella.
A C
El código Diferencial Manchester es el que se usa para convertir los datos binarios en elementos de señalización,
que son transmitidos a velocidades de 4 o 16 Mbps (velocidades estándar del IEEE). El estándar no especifica el
tipo de cableado a utilizar porque este corresponde al nivel de enlace. En la implementación de redes Token
Ring de IBM, se recomienda cable STP aunque también se puede usar UTP. El cable de fibra óptica es otra
opción de cableado.
El acceso al anillo es controlado por un token que circula continuamente por el mismo. El equipo que quiera
transmitir datos, esperará que le pase el token y a su vez que esté libre. Cuando le llega el token, el equipo lo
cambia por un mensaje, al que le añade los datos y lo transmite. Si el equipo de destino está activo, copiará el
mensaje, lo marcará como copiado, y lo reenviará al equipo transmisor. Este equipo descargará los datos y
liberará el token al anillo.
Las principales funciones de gestión del adaptador de red de cada dispositivo son:
 Diagnóstico de conexión o no al anillo.
 Prueba de conexión del latiguillo y fallos del mismo.
 Detección de fallo de señal y beaconing.
 Funciones de monitorización activas y de reserva.
 Detección e información de errores de transmisión.
 Aislamiento de los componentes fallados con recuperación automática o manual.
Resumiendo, el protocolo Token Ring se basa en :

Una monitorización activa por parte de uno de los dispositivos del anillo y que consiste en
Asegurar el retardo del anillo.
Avisos a los equipos vecinos.
Monitorización de la transmisión del token y del mensaje.
Detección de tokens y mensajes perdidos.
Eliminar tokens o mensajes del anillo.
Eliminación automática del anillo si hay varios equipos en monitorización.
Una monitorización de reserva, es decir, los dispositivos que no tiene la monitorización activa, están
pendientes de que si falla el que lo tiene, alguno tiene que hacerse cargo de la misma.
Proceso de token claiming y consiste en que si el dispositivo con monitorización activa falla, se abra un
proceso para que otro dispositivo del anillo se haga cargo del mismo.
El formato del token es
Inicio Control de acceso Fin
donde
- Inicio, 1 octeto, sirve para alertar a los dispositivos de la llegada del token.
- Control de acceso, 1 octeto, contiene la prioridad, un bit indicativo de que es un mensaje token y
no de comando o datos y un bit de monitorización.
- Fin, 1 octeto, indicativo de fin de mensaje.
El formato del mensaje tipo comando o de datos es
Inicio Control de Control del Dirección Dirección Datos Control de Fin

acceso mensaje destino origen error
Donde
- Inicio, 1 octeto, sirve para alertar a los dispositivos de la llegada del token.
- Control de acceso, 1 octeto, contiene la prioridad, un bit indicativo de que es un mensaje token y
no de comando o datos y un bit de monitorización.
- Control de mensaje, 1 octeto, cuya estructura se explica a continuación.
- Dirección destino, 6 octetos, es igual que en Ethernet, es la dirección MAC.
- Dirección origen, 6 octetos, es igual que en Ethernet, es la dirección MAC.
- Control de error, 4 octetos.
- Fin, 1 octeto, indicativo de fin de mensaje.
En cuanto al tamaño máximo del mensaje son 4k, es decir, 4096 octetos.
En cuanto a las direcciones, hay un grupo de funcionales que son un subgrupo de las direcciones de grupo
administradas localmente y que son las siguientes:
Nombre de la función Dirección funcional Producto

Monitor activo C00000000001 Cualquier estación del anillo
Servidor de parámetros del C00000000002 Ninguno
anillo
Control de errores del anillo C00000000008 Diagnóstico del anillo
Puente
Gestor de la red Token Ring
Servidor de informes de C00000000010 Cualquier aplicación NetBIOS
configuración
NetBIOS C00000000080 Puente
Puente C00000000100
Definido por el usuario C000000800000 hasta
C00040000000
En cuanto al campo control del mensaje, el protocolo Token Ring o 802.5 da lugar a 28 tipos distintos de
mensajes, cada uno de ellos identificado por un MVID (major vector identifier). Los principales son:
Active Monitor Present (05). Monitorización del token por parte del dispositivo correspondiente.
Ring Purge (04). Consiste en que el dispositivo que controla el token, envía un mensaje de este tipo, antes de
generar un nuevo token. Los dispositivos cuando reciben un mensaje de este tipo, se ponen en modo de
repetición normal, cancelando y reiniciando todos los temporizadores correspondientes.
Standby Monitor Present (06). Monitorización de reserva del token.
Claim Token (03). Es el proceso por el que se elige un nuevo dispositivo para el control del token.
Inserción de un nuevo dispositivo en el anillo.
Duplicate Address Test (07).
Request Initialization.
Beacon (02).
Soft Error Report.
Monitor del token

En cada anillo se designa una estación del anillo como monitor activo del token. El monitor del token es
responsable del control del token y la ejecución de otras funciones de gestión del anillo. Todas las demás
estaciones del anillo actúan como monitores de reserva y pueden convertirse en monitores activos si se produce
una anomalía en la estación que funciona como monitor activo.
El monitor activo protege al anillo contra situaciones de error, tales como tokens perdidos, mensajes y tokens de
prioridad que circulan por el anillo más de una vez, presencia de más de un monitor activo o anillos con demora
corta.
El establecimiento del monitor del token se realiza en el momento de la inicialización.
Inserción en el anillo
Cuando se inserta una estación en un anillo, se desarrolla un proceso que consta de 5 fases:
1) La primera fase se desarrolla cuando la estación está preparada para insertarse en el anillo y
consiste en que la estación se verifica su estado y comprueba su conexión al anillo.
2) La segunda fase empieza mediante el arranque de un temporizador y espera que pase un mensaje
del tipo Active Monitor Present MAC, Standby Monitor Present MAC o Ring Purge MAC antes
de que se agote el tiempo del temporizador.
3) En la tercera fase, la estación comprueba si hay una dirección duplicada en el anillo.
4) En la cuarta fase, la estación participa en la notificación de entorno, es decir, obtiene las
direcciones de las 2 estaciones vecinas.
5) La quinta fase es opcional y consiste en que la estación puede enviar un mensaje Request
Parameter MAC al servidor de parámetros del anillo. En este caso el servidor devolverá a la
estación el mensaje con los valores de la ubicación física, el valor del temporizador de informes
de errores de software y el número del anillo.
Prioridades
Los protocolos básicos de la red Token Ring permiten el uso de diferentes prioridades de acceso.
Esto se controla mediante el empleo de 3 bits de los propios mensajes Token Ring y sus valores posibles son de
la tabla siguiente:
Bits de prioridad Prioridad
000 Prioridad de usuario normal
Mensajes MAC que no necesitan token
Mensajes MAC de tipo de respuesta
Mensajes MAC que necesitan token
100 Puentes
101 Reservado para IBM
110 Reservado para IBM
111 Gestión de estaciones especializadas
Beacon
El beacon es una situación en la que el anillo está completamente inactivo, tras varios intentos del monitor para
corregirlo. En general es consecuencia de un error de hardware como por ejemplo la inserción de una estación
con una tarjeta de 4 Mbps en un anillo de 16 Mbps.
Una estación empieza a hacer beacon cuando ve la pérdida de una señal, una corriente de datos o cuando se
agota el tiempo de sus temporizadores.
Early Token Release

Una opción permite que el equipo transmisor genere un token libre al anillo, después de transmitir los datos,
aunque no haya recibido la respuesta. A esto se le llama Early Token Release y reduce los tiempos muertos de
los anillos de 16 Mbps. El protocolo Token Ring tiene un conjunto de funciones de aislamiento de fallos y
recuperación de errores.
Eficiencia
El protocolo 802.5/Token Ring en cuanto a su control de flujo, no tiene una eficiencia del 100%, es decir, cuanto
una estación quiere transmitir una trama, debe esperar que le llegue el token vacío para poder transmitir.
Esta técnica de control de flujo hace que se presenten dos situaciones límite:
1) Caso de que todas las estaciones quieran transmitir. En este caso, la utilización del anillo será
muy alta, porque cuando un token queda libre, solamente tiene que recorrer el camino hasta llegar
a la estación siguiente, para que se genere una trama con datos. Sin embargo, a efectos de cada
estación, su eficiencia es muy baja, ya que una estación que quiera transmitir, debera esperar en
promedio un tiempo muy alto hasta que le llega un token libre. Como ejemplo, lo podríamos
comparar con una autopista con una densidad de tráfico muy elevada. A efectos de la empresa
propietaria, economicamente es muy rentable, pero para cada uno de los usuarios, la eficiencia es
muy baja.
2) Caso de que solo quiera transmitir una sola estación. En este caso cuando una estación transmite
una trama, el tiempo que debe transcurrir hasta poder enviar la siguiente es el tiempo de dar la
vuelta al anillo esta trama y a continuación el tiempo en dar la vuelta el token libre. La eficiencia
del anillo es muy baja, sin embargo para la estación su eficiencia es máxima ya que su
transmisión no es retardada por la necesidad de transmitir de otra estación. Volviendo al ejemplo
de la autopista, sería el caso de transitar un único vehículo. En cuanto a la empresa propietaria, su
rendimiento económico sería casi nulo, pero para el usuario sería de una eficiencia máxima.
Ahora podemos traducir en fórmulas estos 2 casos.
Caso 1
La eficiencia se calcula a partir del cálculo del tiempo a transcurrir entre la transmisión de 2 tramas consecutivas
respecto al tiempo de transmisión de una trama.
En este caso a este tiempo se llama tiempo de ocupación y vale
T ocup =  + t t + T k +  / N
siendo
 el tiempo de latencia, es decir, el tiempo que tarda un bit en dar la vuelta al anillo.
T t el tiempo de transmisión de la trama
T K el tiempo de transmisión del token
N el número de estaciones activas del anillo
En cuanto a la latencia  su valor es el tiempo de propagación como consecuencia de la longitud del anillo y de
los retardos provocados por el procesamiento del número de bits (B) del buffer de cada dispositivo.
La longitud del anillo es lo que se denomina diámetro (D). Por tanto la latencia vale
=(D/vp)+N·(B/vt)
La utilización U del anillo valdrá

U = t t / T ocup
Y la velocidad de transmisión efectiva por estación, que corresponde al valor mínimo de la misma, valdrá
V ef min = ( U / N ) · V t
Caso 2
Como el caso anterior la eficiencia se calcula a partir del cálculo del tiempo a transcurrir entre la transmisión de
2 tramas consecutivas respecto al tiempo de transmisión de una trama.
En este caso dado que solo hay una estación transmitiendo, su tiempo de ciclo, que es el tiempo que transcurre
entre el envío de dos tramas consecutivas vale
Tc=2+tt+Tk
Y en consecuencia la eficiencia E del anillo valdrá

E=tt/Tc
En cuanto a la velocidad de transmisión efectiva coincide la del anillo con la de la estación, dado que solo hay
una estación transmitiendo y que por tanto será máxima y valdrá
V ef max = E · v t
12.6 FDDI - Fiber Distributed Data Interface

Este tipo de redes FDDI (Fiber Distributed Data Interface) se crearon en el seno de ANSI en los años 80.
Posteriormente pasó a ISO, que avaló la versión ANSI.
Consiste en una red LAN de 100 Mbps, de doble anillo y método de acceso al medio en paso de testigo (token-
passing) con cable de fibra óptica. Define un nivel físico y otro de enlace subnivel MAC, análogo a los 802.3 y
802.5 del modelo OSI.
FDDI
DAS Concentrador
SAS SAS SAS

Como su propio nombre indica una de las características fundamentales de protocolo FDDI es el hecho del
empleo de fibra óptica en cuanto a su cableado, lo que permite respecto al cobre un mayor ancho de banda, una
mayor fiabilidad y una mayor seguridad. También es inmune a las interferencias electromagnéticas y no puede
ser pinchada. En la actualidad, el abaratamiento de la fibra óptica, ha vuelto a activar la instalación de este tipo
de redes.
Una red FDDI puede conectar un máximo de 500 estaciones con una distancia máxima de 2 Km. con fibra
multimodo o de 20 Km. si es monomodo. La longitud máxima del anillo es de 200 Km.
Especificaciones
Se definen 4 distintas especificaciones:
- Nivel físico con su protocolo de este nivel.
- Nivel MAC que corresponde al subnivel de acceso al medio del nivel de enlace (2).
- PMD (Physical Layer Medium Dependent) que define las características del medio de
transmisión, tales como enlaces, potencia, tasa de errores, componentes y conectores.
- Gestión de la estación (SMT).
FDDI especifica el uso de dos anillos. El tráfico de cada uno de ellos viaja en sentido contrario. Un anillo es el
primario y el otro se le llama secundario.
Ambos anillos conectan dos estaciones adyacentes hasta cerrar los anillos.
Esta topología es tolerante a fallos, ya que ante un fallo en un tramo de un anillo, los equipos cierran el anillo
aprovechando la redundancia existente.
En cuanto a equipos, pueden ser de 2 tipos:
- Clase A o DAS (dual attached stations). Son las estaciones con entrada y salida del anillo. De
éstas hay de 2 tipos: la estación propiamente dicha o un concentrador al que se le pueden conectar
varias estaciones clase B.
- Clase B o SAS (single attached station). Son las estaciones conectadas al concentrador.
En cuanto al tipo de tráfico, puede ser: síncrono y asíncrono. Parte del tráfico que circula puede ser de un tipo y
el resto del otro. El tráfico síncrono es el habitual, mientras que el asíncrono es el de gestión. Dentro del tráfico
asíncrono, pueden establecerse hasta 8 niveles de prioridad.
Estructura del mensaje
Preámbulo Inicio Control Dirección Dirección Datos Control de Fin Estado

destino origen error
Los campos son:

- Preámbulo. Cuando detecta esta combinación de bits, prepara la estación para la recepción del
resto del mensaje.
- Inicio. Es el indicativo de principio de mensaje.
- Control. Indica el tamaño de los campos de direcciones, si el tráfico es síncrono o asíncrono, etc.
- Dirección destino, 6 octetos, como en Ethernet y Token Ring.
- Dirección origen, 6 octetos, como en Ethernet y Token Ring.
- Datos.
- Control de error.
- Fin. Es el indicativo de final de mensaje.
- Estado. Este campo permite a la estación origen determinar si hubo algún error y si el mensaje fue
reconocido y leído por la estación destino.
El formato del mensaje del token es:
Preámbulo Inicio Control Fin
El campo de control del mensajes consta de 8 bits:

- 1 bit llamado de clase, si es 0 indica tráfico asíncrono y 1 tráfico síncrono.
- 1 bit indicativo de la longitud de los campos de dirección ( 0 = 48 bits, 1 = 16 bits).
- 2 bits indicativos del formato (00 = mensaje MAC, 01 = mensaje LLC, 10 = dependiente de la
implantación, 11 = reservada).
- 4 bits de control dependientes del tipo de trama.
12.7 Protocolos de redes inalámbricas

Se trata de aquellos protocolos que permiten enlazar dispositivos de una red de datos a un concentrador sin la
necesidad de cables. En estos casos los concentradores disponen de unas pequeñas antenas que permiten su
comunicación con otras antenas de las que están dotadas las tarjetas de red. Para ello es necesario el empleo de
ondas electromagnéticas en unas bandas de frecuencia previamente autorizadas por los organismos
correspondientes.
En la actualidad no hay un protocolo estándar, y así nos encontramos con distintos protocolos como : el 802.11,
el Bluetooth, el HiperLAN2 y el HomeRF entre otros. Algunos de ellos con más instalaciones que otros, pero sin
una opción clara de hacia donde convergerá el mercado.
IEEE 802.11b
Este protocolo corresponde al ámbito de redes inalámbricas dentro de las recomendaciones del proyecto 802 del
IEEE.
El protocolo IEEE 802.11 está limitado a especificaciones en cuanto al nivel físico y al subnivel Medium Access
Control (MAC) del nivel de enlace (2) del modelo OSI.
A nivel físico se utiliza la tecnología DSSS complementario por clave de código y a nivel enlace, el método
CSMA/CA. Este método a diferencia del CSMA/CD que utiliza Ethernet, consiste en la prevención de
colisiones. El CSMA/CD verifica si ha habido colisión después de enviar una trama. Sin embargo el CSMA/CA
cada dispositivo indica su intención de transmitir antes de enviar la trama de datos. De esta forma se hace una
prevención de colisiones, que obviamente redunda en unas menores prestaciones en cuanto a la velocidad real
de la red.
En la actualidad este protocolo trabaja en la banda de los 2,4 Ghz, alcanzándose una velocidad de transmisión de
hasta 11 Mbps.
Se está desarrollando también el protocolo IEEE.802.11a, que opera en la banda de los 5 Ghz y alcanza
velocidades de transmisión entre 6 y 54 Mbps.
Bluetooth
Este protocolo utiliza a nivel físico la tecnología FHSS (Espectro Extendido de Salto de Frecuencia) y a nivel
enlace, un método de control central de recursos.
En la actualidad su velocidad es de 1 Mbps y su radio de acción es de 10 m.
HiperLAN2
Los estándares de este protocolo se están desarrollando en el ámbito del ETSI (Instituto Europeo de Estándares
de Telecomunicaciones) dentro de la iniciativa Red de Acceso por Radio de Banda Ancha (BRAN).
A nivel físico utiliza la tecnología OFDM (Multiplexación por División de Frecuencia Ortogonal) y a nivel
enlace, un método de control central de recursos, con orientación a conexión.
Soporta calidad de servicio y está previsto alcanzar velocidades de hasta 25 Mbps.
HomeRF
Este protocolo utiliza a nivel físico la tecnología FHSS y a nivel enlace, el método CSMA/CA, es decir, de
prevención de colisiones.
En la actualidad se alcanza una velocidad de 10 Mbps.
12.8 Protocolos orientados al bit

Estos protocolos se caracterizan porque no tienen dependencia del código usado, es decir, la transmisión es bit a
bit sin tener en cuenta que estos bits forman parte de algún tipo de agrupación.
El protocolo básico es el HDLC y de él se derivan los protocolos SDLC, LAPB y LAPD.
12.8.1 HDLC - High Level Data Link Control
ISO define el protocolo HDLC (High Level Data Link Control) como un protocolo del nivel de enlace de su
modelo de referencia OSI. Es un protocolo con sus propias especificaciones, y que a su vez ha servido como
base para los protocolos SDLC, LAPB y LAPD.
HDLC es un protocolo orientado al bit y como tal no tiene dependencia del código usado. Tiene una alta
eficiencia en la transmisión y está desligado de las aplicaciones. Este protocolo proporciona dos tipos de
configuraciones:
- punto a punto y
- multipunto.
Dentro de este protocolo se definen 3 modos de operación :

- Modo normal de respuesta (NRM). En este modo, el dispositivo secundario no se comunica con
el primario hasta que éste no le da permiso. Se emplea en configuraciones centralizadas punto a
punto o multipunto.
- Modo de respuesta asíncrona (ARM). En este modo, el dispositivo secundario puede iniciar una
comunicación por si mismo, sin tener que esperar el permiso del primario. También se emplea en
configuraciones centralizadas punto a punto o multipunto.
- Modo equilibrado asíncrono (ABM). Es un modo combinado ya que el dispositivo tanto puede
actuar como primario o secundario. Solamente se emplea en configuraciones punto a punto.
También existen 3 tipos de estaciones en cuanto a sus funcionalidades:

- estación primaria. Es la que inicia las transacciones de datos. Una por enlace, y puede
trabajar en modo NRM y ARM.
- estación secundaria. Es la que recibe comandos y transmite respuestas a las estaciones
primarias. Una o varias por enlace, y puede trabajar en modo NRM y ARM.
- estación combinada. Ésta tiene capacidad completa de control de enlace. Dos por enlace, y
su modo de trabajo es únicamente ABM.
La estructura del mensaje es
F Dirección Control Datos Control de F

error
donde
- F : es el indicador de principio y fin de trama - 8 bits.
- Dirección - 8 bits. En modo NRM, esta dirección es la identificación de la estación secundaria.
En modo ARM, esta dirección identifica la estación emisora. En modo ABM identifica a la
estación generadora de la respuesta.
- Control - 8 bits. Identifica la función y el propósito de la trama.
- Datos. Longitud variable.
- Control de error - 16 bits.
12.8.2 SDLC - Synchronous Data Link Control
SDLC (Synchronous Data Link Control) es un protocolo desarrollado por IBM en los años 70 con el fin de
sustituir el protocolo BSC (Binary Synchronous). El protocolo SDLC funciona en el nivel de enlace (2) según el
modelo de referencia OSI y se basa en las especificaciones del protocolo HDLC.
Cumple las normas HDLC excepto en las configuraciones en anillo, en la que se definen comandos y respuestas
no utilizadas en el HDLC. En los demás casos sus características son las de un procedimiento normal no
equilibrado (UN) de HDLC y modo NRM.
Estaciones
En cuanto a estaciones, solo se permite una estación primaria en un extremo del enlace y una o varias
secundarias en el otro. Una estación primaria puede enviar información a varias estaciones secundarias.
En cuanto a direcciones, hay una para cada estación y además 2 direcciones especiales : la de broadcast que son
todo unos y sin dirección que son todo ceros.
Tipo de circuitos
Puede funcionar como
- Punto a punto.
- Red conmutada y
- En anillo. En este caso opera como una línea half-duplex, pero la información viaja
siempre en el mismo sentido.
Modos de operación
Una estación secundaria puede estar en uno de los 3 estados siguientes:
- Modo de inicialización. Siempre será por un requerimiento de la estación primaria.
- Modo normal de respuesta (NRM)
- Modo normal de desconexión.

Es exactamente igual al del protocolo HDLC, sin embargo el campo de control, cuya longitud puede de 1 ó 2
octetos, tiene 3 posibles formatos:
- De información. Estos mensajes llevan información de los niveles superiores además de información de
control, principalmente si la transmisión es full-duplex. En este caso, contiene un número de secuencia de
recepción y envío de 7 bits, 1 bit de indicación de final.
- De supervisión. Son mensajes de control y su contenido consta de 7 bits de un número de secuencia de
recepción, el bit de final y un campo de código de 6 bits.
- Sin numerar. Se llaman así porque no contienen ningún número de secuencia, pero en su lugar contienen un
campo de código de 6 bits. Pueden ser de 1 ó 2 octetos.
12.8.3 LAPB - Link Access Procedure Balanced
Es un protocolo que funciona a nivel de enlace (2) según el modelo de referencia OSI, y se utiliza en la
Recomendación X.25.
Las funciones que realiza son de :

- sincronización
- establecimiento y desconexión del enlace
- control de flujo y
- detección y recuperación de errores
Es un protocolo basado en el HDLC y por tanto orientado al bit. Trabaja en modo de operación asíncrono
balanceado y las estaciones son de tipo combinado, es decir, 2 por enlace. Por esta razón, las 2 estaciones pueden
enviar comandos e iniciar respuestas sin necesidad de permiso de la otra.
Utiliza líneas full duplex para datos y solo polling cuando la trama de datos no suministra la aceptación del nivel
de enlace necesario.
Modelo TCP/IP 47
Capítulo 13. Modelo TCP/IP
En la actualidad la expansión de Internet ha hecho que el protocolo TCP/IP sea un estándar de facto en las redes
de ordenadores.
El modelo TCP/IP consta fundamentalmente de los protocolos siguientes:
IP Internet Protocol Protocolo de nivel 3

ICMP Internet Control Message Protocol Protocolo de nivel 3, responsable de
la generación de mensajes
TCP Transmission Control Protocol Protocolo de nivel 4
UDP User Datagram Protocol Protocolo de nivel 4
ARP Address Resolution Protocol Protocolo de nivel 3, dada una
dirección IP busca su dirección MAC
RARP Reverse Address Resolution Protocol Protocolo de nivel 3, que realiza la
operación inversa del protocolo ARP
Como se ve en la tabla anterior, los protocolos IP, ICMP, ARP y RARP funcionan a nivel de red según el
modelo de referencia OSI, mientras que los protocolos TCP y UDP funcionan a nivel de transporte. A
continuación se explica el funcionamiento de cada no de ellos.
13.1 IP - Internet Protocol

La especificación del protocolo IP se encuentra en
- La RFC 791 Internet Protocol y
- La RFC 950 Internet Standard Subnetting Procedure.
IP es un protocolo que funciona a nivel red (3) según el modelo de referencia OSI, es decir, se interrelaciona con
los protocolos que funcionan a nivel enlace (2) y a nivel transporte (4). Los protocolos de nivel enlace son
cualesquiera que soporten el estándar IEEE 802 e incluso cualquier otro protocolo de los que habitualmente se
emplean en los sistemas de comunicaciones.
En cuanto a los protocolos de nivel de transporte, el protocolo IP solo se entiende con el TCP y el UDP, que a su
vez enlazan con los protocolos de aplicaciones.
Sus dos características básicas son:

- IP es un protocolo no fiable, es decir, no realiza un control de mensajes perdidos ni duplicados y
- IP no está orientado a conexión. Esto significa que los mensajes IP pueden llegar desordenados e
incluso pueden llegar duplicados si la red es mallada, porque el camino que siguen para ir del
dispositivo origen al de destino puede variar en función del estado de la red. Una de las razones
por las que este protocolo IP es no orientado a conexión, es porque así se minimiza la
dependencia de otras redes que utilizan redes jerárquicas orientadas a conexión.
Cuando un dispositivo o host envía un mensaje IP, inserta en el mismo la dirección origen y la dirección destino
en su cabecera. A continuación examina la dirección destino y la compara con la tabla de enrutamiento local. En
función de esto, hay 3 posibles soluciones :
- pasar el mensaje a una capa más arriba del propio dispositivo
- enviarla a la red a través de su interface o
- tirarlo, es decir, no enviarlo.
Modelo TCP/IP 48
13.1.1 Cabecera IP
Los mensajes IP constan de una cabecera, un campo de datos de longitud variable y un tercer campo de control
de error. Los campos de la cabecera son los siguientes:
Versión Longitud Servicio Tamaño

Identificación Flags Fragmentación
Supervivencia Protocolo Control de error
Dirección origen
Dirección destino
Tipo Longitud Opción
Opciones
Opciones Relleno
Datos
donde
 Versión del IP (actualmente la 4), 4 bits
 Longitud, 4 bits. Corresponde al tamaño de la cabecera del mensaje en mensajes de 32 bits.
 Servicio, 1 octeto. Es una indicación de la calidad de servicio requerida, es decir, si tiene prioridad o no,
se puede retrasar o no, etc.
 Tamaño del mensaje, 4 octetos. Es la longitud total del mensajes, es decir, la longitud de la cabecera
más los datos y se expresa en octetos.
 Identificación, 2 octetos. Un número único asignado por el emisor. Esta identificación permite el
ensamblado de mensajes fragmentados si los hubiera, ya que todos los fragmentos tienen la misma
identificación.
 Flags, 3 bits. Dos bits DF y NF. El primero indica si el mensaje se puede o fragmentar o no y el
segundo indica si es el último mensaje de la fragmentación o es uno intermedio.
 Fragmentación, 13 bits. Se utiliza con los mensajes fragmentados. Su valor indica la posición relativa
de cada mensaje fragmentado.
 Supervivencia, 1 octeto. Utilizado para indicar el tiempo máximo que se le permite a un mensaje
circular por la red. Es lo que también se llama tiempo de vida. Cuando un mensaje es procesado por un
enrutador, éste resta uno al valor original.
 Control de error, 4 octetos. Suma de pruebas complementada a uno de la cabecera IP para detectar
posibles errores.
 Protocolo, 1 octeto. Indica el protocolo de nivel de red (3) del que procede o se dirige. Algunos valores
en decimal son:
1 ICNP
4 IP (IP encapsulado en IP)
6 TCP
8 EGP
17 UDP
29 ISO-TP4
36 XTP
 Dirección origen/destino, 4 octetos. La dirección origen y destino se mantiene siempre según va
progresando por la red. La dirección destino permite encaminar el mensaje a través de los diferentes
enrutadores que interconectan las redes.
 Opciones. Es un campo de longitud variable e implementa elementos de seguridad, control etc..
Algunas de estas opciones son:
o Source routing. Si esta opción está activa, en el campo opciones se indica el camino que debe
seguir el mensaje hasta llegar a su destino. Para ello se anotan las diferentes direcciones IP en
estos campos de opciones.
o Record route. En este caso el campo opciones se va rellenando con las direcciones de los
dispositivos que va atravesando el mensaje hasta llegar a su destino.
Modelo TCP/IP 49
o Time stamp. Esta opción fuerza a los enrutadores a grabar la hora (contador de 32 bits en
unidades de milisegundos) en la que pasa el mensaje por este dispositivo y esto se hace en el
campo opciones. También se rellena con la dirección IP del dispositivo en cuestión.
13.1.2 Fragmentación y ensamblado
Las distintas redes interconectadas entre si no tienen por que utilizar el mismo tamaño de mensaje (MTU), así
por ejemplo en Ethernet lo habitual son tamaños del orden de 1500 octetos y en las redes Token Ring, 4096
octetos. Así cuando la longitud del mensaje del protocolo IP es mayor que el del protocolo de nivel de enlace, es
preciso realizar una fragmentación del mensaje IP. Este proceso se realiza en el propio dispositivo origen y
cada fragmento se encamina a su destino de forma independiente, siendo responsabilidad del dispositivo de
destino su ensamblado.
El proceso de fragmentación en el dispositivo origen consiste en:

 Comprobar el bit DF del campo IP para ver si está permitida su fragmentación. Si no lo está se
descarga el mensaje, es decir, no se retransmite.
 En función del tamaño máximo permitido por la red física, se divide el campo de datos en varios
segmentos.
 Con estos mensajes del campo de datos del mensaje original, se forman nuevos mensajes, cuyo
cabecera IP es idéntica a la original excepto en:
* El bit de más datos (MF) se pone a uno, excepto el del último
mensaje.
* En el campo de fragmentación, se indica la posición de cada
fragmento.
* Se recalcula el campo de longitud.
* Se recalcula el control de error.
En el dispositivo destino se ensamblan todos los mensajes con la información fragmentada. Para ello se utiliza
el campo de identificación y el de fragmentación. El primero para saber todos los mensajes que corresponden a
la misma fragmentación y el segundo para saber el orden en que se deben ensamblar.
El sistema final utiliza un buffer de recepción que liberará en caso de transcurrir un tiempo determinado y no
haber llegado todos los mensajes correspondientes.
Debido al propio funcionamiento del protocolo IP, se pueden producir situaciones de pérdida de mensajes,
duplicado de los mismos, la llegada al destino fuera de secuencia, o con errores. En todos estos casos es el
protocolo de nivel superior (TCP) quien se encarga del tratamiento de la pérdida o duplicación de la
información.
13.1.3 Direccionamiento y clases IP
El protocolo IP utiliza un modelo de direccionamiento, de forma que a cada interface de cada dispositivo se le
asigna una dirección independientemente de su dirección MAC, que es la que utilizan los protocolos de nivel de
enlace. La dirección IP destino es un dato que debe ser suministrado por las aplicaciones que corren en el propio
dispositivo al protocolo IP. La dirección IP origen la calcula el protocolo IP a partir de las tablas de enrutamiento
que se explican más adelante.
Estas direcciones IP constan de 32 bits y para su representación se emplea la notación decimal de puntos
(X.X.X.X). Ésta consiste en 4 números decimales separados por un punto, por ejemplo
194.110.100.200
El ámbito de cada valor es de 0 a 255, dado que corresponden a 1 octeto, o sea, 8 bits. Su representación
hexadecimal sería
C2.6E.64.C8
Modelo TCP/IP 50
y la representación binaria
11000010.01101110.01100100.11001000
El valor más a la derecha sólo puede oscilar entre 1 y 254 porque el 255 está reservado a la dirección de
broadcast y el 0 es indicativo de toda la red.
En Internet, para acomodar la estructura de direccionamiento a las diferentes necesidades de utilización, el

ámbito de direcciones IP se ha agrupado en clases de acuerdo con el criterio siguiente:
Clase Prefijo Sufijo

Clase A: 0 + 7 bits para red y 24 para los dispositivos
Clase B: 10 + 14 bits para red y 16 para los dispositivos
Clase C: 110 + 21 bits para red y 8 para los dispositivos
Clase D: 1110 + 28 bits para multicasting
Clase E: 1111 + 28 bits experimental
De esta forma la simple inspección de una dirección IP permite conocer a que clase pertenece, así los rangos de
direcciones IP correspondientes a cada clase son:
Clase A: de la 0.0.0.0 a la 127.255.255.255

Clase B: de la 128.0.0.0 a la 191.255.255.255
Clase C: de la 192.0.0.0 a la 223.255.255.255
Clase D: de la 224.0.0.0 a la 238.255.255.255
Clase E: de la 240.0.0.0 a la 247.255.255.255
13.1.4 Máscaras
Con posterioridad a la definición inicial del protocolo IP aparecen las máscaras, y es como consecuencia de la
necesidad de subdividir las redes en varias subunidades y cada una de ellas con un grupo de direcciones IP
distinto (RFC 950).
Estas máscaras constan de 4 octetos (32 bits), igual que una dirección IP y por como se utilizan deben contener
unos a la izquierda y ceros a la derecha, es decir, no pueden haber mezclas de unos y ceros.
En Internet es habitual el empleo de las siguientes máscaras para cada clase:
Clase Máscara
A 255.0.0.0
B 255.255.0.0
C 255.255.255.0
Si a una dirección IP aplicamos la máscara con el operador AND, en realidad dividimos la dirección IP en 2
partes.
Estas direcciones IP constan de 32 bits y se dividen en dos partes:

- La parte izquierda que corresponde a la identificación de la red física, y
- La parte derecha que identifica al dispositivo dentro de cada red.
Con las máscaras introducimos el concepto de número de red dentro del campo de dirección IP.
Es característico del protocolo IP el hecho de que las máscaras no viajan en los mensajes IP, es decir, se emplean
de forma local en cada dispositivo.
13.1.5 Enrutamiento
Modelo TCP/IP 51
El protocolo IP es un protocolo enrutado en tanto en cuanto sus mensajes son encaminados según el contenido de
unas tablas que contienen cada uno de los dispositivos de la red. A estas tablas, se les denomina tablas de
enrutamiento.
El empleo de estas tablas de enrutamiento se realiza cuando un mensaje de protocolo IP tiene que salir de un
dispositivo.
¿Cómo llega el mensaje al protocolo IP? Hay 2 posibles caminos:

- puede proceder de protocolos de nivel superior del propio dispositivo o
- puede haber entrado por una interface de un enrutador, es decir, procedente de un protocolo de
nivel inferior, el cual lo debe encaminar para que siga su camino.
Así una vez el protocolo IP ha confeccionado su mensaje IP, debe decidir por cual de sus interfaces debe
dirigirlo. Según sea la interface, este mensaje IP será procesado por el protocolo de nivel de enlace
correspondiente.
La decisión de cual es la interface de salida se calcula mediante el empleo de la tabla de enrutamiento del
dispositivo. Para ello vamos a emplear el ejemplo siguiente. Se trata de un ordenador con una tarjeta de red con
dirección IP 192.168.0.5, máscara 255.255.255.0 y puerta de enlace 192.168.0.254
Su tabla de enrutamiento es la siguiente:
Dirección de red Máscara Puerta de enlace Interface

0.0.0.0 0.0.0.0 192.168.0.254 192.168.0.5
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1
192.168.0.0 255.255.255.0 192.168.0.5 192.168.0.5
192.168.0.5 255.255.255.255 127.0.0.1 127.0.0.1
192.168.0.255 255.255.255.255 192.168.0.5 192.168.0.5
255.255.255.255 255.255.255.255 192.168.0.5 192.168.0.5
Cada línea de la tabla es una solución posible, así para cada dirección de red con su máscara, le corresponde una
puerta de enlace y una interface por la que debe salir el mensaje IP.
Vamos a analizar cada una de sus líneas que corresponde a una posible solución:
- La dirección de red 0.0.0.0 con máscara 0.0.0.0 es la solución por defecto, es decir, si no cumple
ninguna de las otras soluciones, el mensaje IP será enviado a la puerta de enlace 192.168.0.254
por la interface 192.168.0.5
- La dirección de red 127.0.0.0 con máscara 255.0.0.0 siempre se reserva como dirección IP interna
o de localhost. Por esta razón siempre se encamina a la propia dirección IP interna 127.0.0.1. En
este caso el mensaje IP no sale por ninguna interface y por tanto no es necesario que esté
conectado a una red.
- La dirección de red 192.168.0.0 y máscara 255.255.255.0 corresponde a la red donde está
conectado el dispositivo. Por esta razón, si la dirección IP destino corresponde a esta red, debe
salir por su interface 192.168.0.5 y no debe ser dirigida a la puerta de enlace. El objetivo de la
puerta de enlace es enviar el mensaje a otras redes distintas de la suya 192.168.0.0
- La dirección de red 192.168.0.5 y máscara 255.255.255.255 corresponde a la propia interface, por
lo que el mensaje IP se envía a la dirección IP interna 127.0.0.1
- La dirección de red 192.168.0.255 y máscara 255.255.255.255 corresponde a la dirección de
broadcast de esta red, por lo que los mensajes IP con dirección IP destino 192.168.0.255 deben
salir por la interface 192.168.0.5
- La dirección de red 255.255.255.255 y máscara 255.255.255.255 es una dirección de broadcast
general y como tal los mensajes IP con esta dirección IP destino deben salir por la interface
192.168.0.5
Una vez explicado el significado de la tabla de enrutamiento, vamos a explicar como el protocolo IP encuentra la
solución de por qué interface debe enviar cada mensaje IP. Esto lo realiza tomando la dirección IP de destino de
Modelo TCP/IP 52
cada mensaje y la compara con cada una de las direcciones de red de la tabla aplicándole la máscara
correspondiente con el operador lógico AND.
Supongamos una dirección IP de destino 192.168.0.100. En la tabla siguiente, la columna resultado consiste en
aplicar la máscara de cada línea a la dirección IP destino 192.168.0.100, es decir,
resultado = 192.168.0.100 AND máscara
Dirección de red Máscara Resultado Interface

0.0.0.0 0.0.0.0 0.0.0.0 192.168.0.5
127.0.0.0 255.0.0.0 192.0.0.0 127.0.0.1
192.168.0.0 255.255.255.0 192.168.0.0 192.168.0.5
192.168.0.5 255.255.255.255 192.168.0.100 127.0.0.1
192.168.0.255 255.255.255.255 192.168.0.100 192.168.0.5
255.255.255.255 255.255.255.255 192.168.0.100 192.168.0.5
Si comparamos la columna dirección de red y resultado, hay 2 posibles soluciones, la primera y la tercera. Como
la solución solamente puede ser una, se elige la que tiene la máscara con más unos a la izquierda en
representación binaria, por tanto la solución es la tercera y el mensaje IP es enviado a la interface 192.168.0.5
En el caso de un enrutador, se hace exactamente lo mismo, lo que sucede es que en estos casos hay más de una
interface. También en el caso de los enrutadores, el mensaje IP no se procesa si su tiempo de vida es cero.
13.1.6 Referencias
- RFC 791 Internet Protocol,

- RFC 950 Internet Standard Subnetting Procedure
- RFC 919 Broadcasting Internet Datagrams
- RFC 922 Broadcasting Internet datagrams in the presence of subnets
- RFC 1122 Requirements for Internet hosts - communications layers
- RFC 1349 Type of Service in the Internet Protocol Suite
- RFC 2474 Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6
Headers
- RFC 894 Standard for the transmission of IP datagrams over Ethernet networks
- RFC 815 IP datagram reassembly algorithms
- RFC 2475 An Architecture for differentiated Service
13.2 TCP - Transmission Control Protocol

El protocolo TCP es un protocolo que funciona a nivel de transporte según el modelo de referencia OSI y como
tal por una parte enlaza con los protocolos de niveles superiores y por otro con el protocolo de nivel de red IP. Es
un protocolo que no se entiende con otros protocolos de nivel de red tales como IPX, NetBIOS, etc.
El protocolo TCP se describe básicamente en la RFC 793. También se desarrolla, amplia y complementa en las
RFC siguientes:
- RFC 1122, amplía y actualiza algunos conceptos.
- RFC 813, describe la gestión de ventanas,
- RFC 816, describe como aislar los fallos y como recuperarlos
- RFC 879, desarrolla los tamaños máximos de los mensajes
- RFC 896, comenta el tema de la congestión
Este protocolo TCP tiene como características principales:

- Es un protocolo orientado a conexión
- La realización de recuperación de errores
- El control de flujo y
Modelo TCP/IP 53
- Conexión full duplex. El protocolo TCP funciona mediante una comunicación full duplex, es
decir, suministra flujo de datos concurrentes en ambas direcciones
El objetivo principal del protocolo TCP es suministrar un circuito lógico fiable y un servicio de conexión entre
pares de procesos de distintos dispositivos. No asume la fiabilidad de los protocolos de nivel inferior como el IP,
es decir, el TCP debe garantizar por si mismo la fiabilidad de sus mensajes TCP.
Desde el punto de vista de las aplicaciones, el protocolo TCP transfiere un flujo continuo de octetos a través de
la red. La aplicación no tiene que preocuparse con la fragmentación de los datos en bloques. El TCP ya hace esto
agrupando los octetos en segmentos TCP, que son pasados al protocolo IP para su transmisión a destino.
A veces una aplicación necesita estar segura de que todos los datos han pasado al protocolo TCP con el fin de ser
transmitidos a su destino. Por esta razón, existe una función push, que cuando se activa, se envían todos los
segmentos TCP almacenados al equipo destino. La función de cierre normal de la conexión incluye la función
push.
Puertos
El protocolo TCP es un protocolo de nivel de transporte y como tal debe intercambiarse datos con los distintos
protocolos a nivel de aplicación. Este intercambio será a doble dirección, es decir, del protocolo de aplicación al
protocolo TCP y viceversa.
Por esta razón el protocolo TCP debe poder distinguir los distintos protocolos de aplicación existentes. Esto se
realiza mediante la definición de puerto. Un puerto TCP equivale a un buffer para cada protocolo de aplicación
del dispositivo en cuestión. Para un mismo protocolo pueden definirse más de un puerto.
Así el protocolo POP, deja sus datos en el puerto 110, datos que procesa el protocolo TCP. A la inversa, cuando
llega un mensaje POP al protocolo TCP de este dispositivo, el protocolo TCP los deja en el puerto 110.
En una transmisión de información entre dos dispositivos, el mensaje TCP contiene un campo que identifica el
número del puerto del dispositivo origen y otro con el número del puerto del dispositivo destino, y que no tienen
porque coincidir.
Puerto 1 Puerto 2 Puerto 3
Protocolo TCP
Protocolo IP
El empleo de puertos equivale pues a un efecto de multiplexación cuando se transmiten mensajes al exterior y de
desmultiplexación cuando se pasan a nivel superiores al de transporte. Esto permite que varios protocolos de
aplicaciones puedan transmitir y recibir simultáneamente desde el protocolo TCP.
En Internet, los números de los puertos TCP se dividen en 3 rangos y pueden encontrarse en la dirección de
Internet http://www.iana.org/assignments/port-numbers y son:
- Los Bien Conocidos (de 0 a 1023), asignados por el IANA
- Los Registrados (de 1024 a 49151) y
- Los Dinámicos y Privados ( de 49152 a 65535).
Cabecera TCP
Los mensajes TCP constan de una cabecera, un campo de datos de longitud variable y un tercer campo de
control de error. Los campos de la cabecera son los siguientes:
Puerto origen Puerto destino
Número de secuencia
Número de reconocimiento
Tamaño Flags Ventana
Modelo TCP/IP 54
Control de error Indicador de urgencia

Opciones
Datos
 Puertos de origen / destino, 16 bits. Estos campos contiene el número de los puertos de los dispositivos
origen y destino de la conexión TCP. Estos dos valores junto con las direcciones IP de origen y destino
contenidas en la cabecera del protocolo IP, constituyen la conexión entre procesos ULP, que será única
en la red.
 Números de secuencia, 32 bits. Contiene un valor que representa el número de secuencia del primer
octeto de datos del mensaje. Si el indicador SYN está activo, el campo número de secuencia será el
inicial (ISN), por lo que el primer mensaje de datos tendrá el número ISN+1.
 Número de reconocimiento, 32 bits. Si el indicador ACK está activo, este campo contendrá el valor del
siguiente número de secuencia que el transmisor del mensaje está esperando recibir.
 Tamaño, 4 bits. Indica el número de palabras de 32 bits de la cabecera TCP.
 Indicador de control. Son condiciones que se emplean en el establecimiento, mantenimiento y
finalización de las conexiones y están representadas cada una de ellas por un bit.
URG: Indicador de urgencia.
ACK: Este mensaje incluye un reconocimiento (ACK).
PSH: Activación de la función push.
RST: Reinicio de le conexión.
SYN: Sincronización de los números de secuencia.
FIN: Indicativo de que no hay más datos del transmisor.
 Ventana, 16 bits. Se emplea en los mensajes ACK, y especifica el número de octetos de datos,
comenzando en el número contenido en el campo del número de validación, que el transmisor del
segmento es capaz de aceptar.
 Control de error, 16 bits. Es el complemento a uno de la suma de los complementos a uno de la
cabecera y el campo de datos.
 Indicador de urgencia, 16 bits. Solamente es significativo cuando el bit URG está activo. Contiene el
valor del offset positivo desde el número de secuencia del octeto que va a continuación de los datos
urgentes.
 Opciones. Existen solamente tres opciones definidas:
o Fin de opciones, con el valor de opción 0
o No operación, con el valor de opción 1.
o Tamaño máximo de segmento con el valor de opción 2. Esta opción se utiliza en la solicitud de
conexión inicial.
Fases del TCP

El protocolo TCP está orientado a conexión, por lo que antes de enviar los datos propiamente dichos, debe
establecer la conexión entre los dispositivos origen y destino y cuando ha terminado la transmisión de datos,
debe cerrar esta conexión.
Así en la operación del protocolo TCP podemos distinguir tres fases: el establecimiento de la conexión, la fase
de transmisión de datos y la finalización de la conexión. Vamos a detallar cada una de estas fases.
a) Fase de establecimiento de la conexión o sincronización

Las aplicaciones indican su disponibilidad a aceptar conexiones solicitando al protocolo TCP el establecimiento
de un estado "pasive open”. En esta solicitud se debe indicar el número de puerta local. Establecido el estado de
“pasive open”, la puerta identificada se mantendrá en estado de escucha "listen" hasta la recepción de una
apertura activa.
Cuando una aplicación quiere establecer una conexión con otra aplicación que se encuentra en estado "listen",
solicitará un "active open" a su aplicación local,
indicando dirección y número de puerta remotas junto con su número de puerta local único. Para ello el
protocolo TCP enviará un mensaje de sincronización "SYN" en el que incluirá las direcciones de las puertas de
los dispositivos origen y destino, el número de secuencia del siguiente octeto de datos que espera recibir y otros
datos opcionales.
Modelo TCP/IP 55
El protocolo TCP del dispositivo destino comparará los valores recibidos con sus puertas en escucha salientes, y
si algún valor coincide, enviará otro mensaje de sincronización SYN con un ACK, direcciones y el número de
secuencia del primer octeto de datos que espera recibir.
Este mensaje se confirma a su vez mediante otro mensaje SYN-ACK, con lo que queda la conexión establecida.
El dispositivo destino con el protocolo TCP que está en estado de escucha, pasará al estado de conexión
establecida al recibir este tercer mensaje.
Si el mensaje SYN inicial no recibe el mensaje ACK debido a problemas en la red o que el dispositivo destino
no se encuentra en estado de escucha para la puerta solicitada, al vencimiento del temporizador se hará un
reintento, repitiéndose un cierto número de veces. Si al final no puede establecerse la conexión, el protocolo TCP
del dispositivo origen notificará el fallo de la conexión mediante "open failure" a la aplicación que había
realizado la solicitud.
b) Fase de datos
Una vez establecida la conexión, el protocolo TCP soporta un flujo de datos full duplex entre las aplicaciones
que se comunican. El flujo de datos que genera el dispositivo origen respeta la secuencia de origen.
Cuando no sea posible la entrega de los datos dentro de los límites impuestos por los temporizadores del usuario,
el protocolo TCP notificará a su aplicación local el fallo del servicio y finalizará la conexión.
El flujo de datos se controla numerando cada octeto que se transmite a través de la conexión establecida. Este
mecanismo también sirve para la ordenación de los datos, la detección de duplicaciones, la aceptación y
mecanismo de ventana en el dispositivo destino. La información de control es también numerada y se controla
su secuencia.
Todos los datos que se transmiten deben ser validados por el dispositivo destino. Para controlar esto, se emplean
temporizadores, al vencimiento de los cuales sin aceptación del dispositivo destino se procede a la retransmisión
de los datos. Los valores particulares de temporizadores, contadores de retransmisión y frecuencia de
aceptaciones dependen de cada implementación particular.
El mecanismo de detección de error, basado en el control de error de 16 bits incluido en la cabecera TCP,
permite recuperar errores por un mecanismo sencillo
que consiste en descartar los mensajes erróneos, siendo retransmitidos por el dispositivo de destino al no recibir
la correspondiente aceptación.
c) Fase de finalización de la conexión

La finalización de las conexiones TCP, en el caso normal, es ordenada. Esto requiere la sincronización de ambos
extremos para garantizar que toda la información correspondiente al canal full duplex es transmitida y validada
antes del cierre final de la conexión.
La solicitud de finalización se realiza mediante un mensaje "close request", que indica que la aplicación local ha
completado su transferencia de datos. Una vez solicitado el cierre de la conexión, el dispositivo origen no
enviará más información por la conexión en proceso de cierre, y comprobará que todos los datos enviados sean
aceptados por el dispositivo destino.
El protocolo TCP del dispositivo origen enviará un mensaje FIN para notificar el cierre al dispositivo destino,
que a su recepción notificará a su aplicación local mediante un mensaje "closing indication". A continuación, el
dispositivo destino enviará un mensaje FIN-ACK con lo que el dispositivo origen transmite un mensaje "close
request" a su aplicación, momento en que ésta enviará un mensaje FIN.
Temporizadores
En todos los protocolos es importante conocer que temporizadores que se emplean y en base a que parámetros se
rigen cada uno de ellos. En el caso del protocolo TCP, en que se emplean distintos sistemas de comunicaciones,
es importante conocer estos temporizadores, porque muchas veces su conocimiento y análisis explican porque
algunos mensajes no llegan nunca a su destino, o se requiere una nueva retransmisión de los mismos, con lo que
los tiempos de respuesta aumentan.
El protocolo TCP utiliza 7 temporizadores en cada conexión, y son los siguientes:
1 ) Un temporizador arranca cuando se envía una señal de sincronización (SYN) con el fin de establecer una
nueva conexión. Si al cabo de 75 segundos no se ha recibido respuesta, se aborta dicho intento de conexión.
2 ) Otro temporizador arranca cuando el protocolo TCP del dispositivo origen empieza a enviar datos, es decir,
una vez ya establecida la conexión. Si no hay reconocimiento por parte del dispositivo destino, el protocolo TCP
del dispositivo origen retransmite los datos. El valor de este temporizador se calcula dinámicamente y varía en
función de las retransmisiones. Su valor oscila entre 1 y 64 segundos.
Modelo TCP/IP 56
3 ) Las señales de reconocimiento (ACK) tardan 200 ms. en enviarse a partir del instante que el dispositivo sabe
que las tiene que enviar, es decir, se añade un retardo. Si hay más datos a enviar, se envían con el mensaje de
datos.
4 ) Cuando la ventana llega a cero, arranca otro temporizador mientras no se envían nuevos datos. Si el protocolo
TCP del dispositivo origen continua sin poder enviar datos porque el dispositivo destino no contesta a ventana
cero, y el temporizador también llega a cero, el dispositivo origen envía 1 octeto de datos con el fin de verificar
que la ventana sigue abierta.
5 ) Hay un temporizador llamado keepalive, que obliga al otro extremo a responder. De esta forma un dispositivo
conoce si el dispositivo en el otro extremo de la conexión está en línea, es decir, activo.
6) Temporizador FIN_WAlT_2. Cuando una conexión pasa del estado FIN_WAlT_1 al FIN_WAlT_2 la
conexión no puede enviar más datos, estableciéndose este temporizador en 10 minutos. Pasado este tiempo, si no
ha habido el cambio de estado correspondiente, la conexión se pierde. El objetivo de este temporizador es que no
quede en permanente estado FIN_WAlT_2
7) También entra en juego otro temporizador cuando se entra en estado TIME_WAlT. Transcurrido este tiempo
sin un cambio de estado, la conexión se cierra.
Para entender como funcionan estos 3 últimos temporizadores, debemos conocer como funciona el cierre de una
conexión que en principio siempre es solicitado por el dispositivo origen. Para ello el dispositivo origen envía un
mensaje FIN al dispositivo destino. En este instante el dispositivo origen entra en estado FIN_WAIT_1, en
espera de recibir el mensaje de reconocimiento ACK del dispositivo destino, quedando este en estado CLOSE-
WAIT. Cuando el dispositivo origen lo recibe pasa a estado FIN_WAIT_2.
Cuando se quiere cerrar la sesión, el dispositivo destino también envía al dispositivo origen un mensaje de FIN,
quedando en estado LAST-ACK. Cuando el dispositivo origen lo recibe, pasa a estado TIME-WAIT, a la vez
que envía un mensaje de reconocimiento ACK al dispositivo destino.
Reconocimientos y retransmisiones
El protocolo TCP asigna un número de secuencia a cada mensaje que transmite, consistente en la posición del
primer octeto que envía respecto a todos los datos a enviar. Por ejemplo, supongamos que tienen que transmitirse
96234 octetos. Si el número de secuencia es 11200, significa que el primer octeto de datos de este mensaje
corresponde al 11200 de todos los datos a transmitir.
Por otro lado, el dispositivo destino envía reconocimientos periódicos de los mensajes que va recibiendo. Si el
mensaje de reconocimiento ACK no es recibido en un tiempo preestablecido, el dispositivo origen los
retransmite pero solo a partir del número de secuencia del mensaje que no ha recibido reconocimiento.
También el protocolo TCP del dispositivo destino usa los números de secuencia para ensamblar los segmentos
cuando llegan sin orden y a su vez eliminar los duplicados si los hubiere.
Control de flujo. Ventanas

Se entiende por control de flujo a la sincronización que se establece entre dos dispositivos que se transmiten
datos.
En el caso del protocolo TCP, cuando el dispositivo destino envía un mensaje de reconocimiento ACK al
dispositivo origen, también le notifica del número de octetos que puede recibir después del último mensaje TCP
recibido, sin provocar saturación ni overflow en sus buffers internos. Esto es lo que se llama ventana o
windowing. De esta forma el dispositivo origen aumenta o disminuye el flujo de transmisión de datos, con el fin
de optimizar el tiempo de respuesta.
A mayor tamaño del mensaje, menor segmentación y por tanto el tiempo de transmisión es menor. Sin embargo,
un mayor tamaño de mensaje comporta una mayor probabilidad de errores durante la transmisión. De aquí que se
negocie este tamaño entre el dispositivo origen y destino durante la transmisión.
Referencias
- RFC 793 Transmission Control Protocol
- RFC 813 Window and acknowledgement strategy in TCP
- RFC 816 Fault isolation and recovery
- RFC 879 TCP maximum segment size and related topics
- RFC 896 Congestion control in IP/TCP internetworks
- RFC 889 Internet delay experiments
Modelo TCP/IP 57
13.3 UDP - User Datagram Protocol

UDP (User Datagram Protocol) es un protocolo descrito en la RFC 768. Es un protocolo que funciona en el nivel
transporte (4) del modelo de referencia OSI. Sus relaciones con los protocolos a nivel de aplicación es escasa, es
decir, hay pocos protocolos de nivel 7 que lo emplean como protocolo de transporte. En cuanto a los protocolos
de nivel inferior, es decir de red, sólo se entiende con el protocolo IP.
UDP es un protocolo alternativo al protocolo TCP. Sin embargo a diferencia de éste no es ni fiable, ni hace
control de flujo ni control de errores, por lo que solo se recomienda en redes con sistemas de transmisiones
fiables como son las LANs.
UDP es un protocolo no orientado a conexión, es decir, no hay un establecimiento previo de la conexión

Este protocolo UDP aporta un procedimiento para que los programas de aplicación puedan enviar mensajes a
otros programas con un mínimo de mecanismo de protocolo. El protocolo se orienta a transacciones, y tanto la
entrega como la protección ante duplicados no se garantizan.
El protocolo UDP puede ser considerado como poco pesado, por lo que no genera sobrecargas, sin embargo
requiere que la aplicación se haga cargo de la recuperación de errores.
Las aplicaciones que envían mensajes UDP a otro dispositivo necesitan identificar la aplicación de este
dispositivo destino, ya que los mensajes se dirigen normalmente a ciertos procesos y no al sistema en general.
Los mensajes UDP constan de una cabecera, un campo de datos de longitud variable y un tercer campo de
control de error. Los campos de la cabecera son los siguientes:
Puerto origen Puerto destino

Longitud Control de error
Datos
donde
 Puerto Origen, 16 bits. Indica el puerto del dispositivo origen. Es opcional y si no se utiliza, se inserta
un valor cero.
 Puerto Destino, 16 bits. Especifica el puerto del dispositivo destino.
 Longitud, 16 bits. Es el tamaño, en octetos, del mensaje incluida la cabecera.
 Control de error, 16 bits. Es un conjunto de bits de comprobación.
Con el fin de calcular de una manera más fiable el campo control de error, se hace a partir de la confección de
una pseudo-cabecera UDP que no se transmite. Esta pseudo-cabecera contiene la dirección IP del dispositivo
origen, la dirección IP del dispositivo destino, el código del protocolo UDP en IP (17) y la longitud del mensaje
UDP. La razón de la inclusión de las direcciones IP hará que sea más fiable en cuanto se garantiza mejor el
reconocimiento por parte del dispositivo destino. Esta información proporciona protección frente a mensajes mal
encaminados.
En cuanto a los puertos, su funcionamiento es exactamente igual que el protocolo TCP, sin embargo no son los
mismos puertos. En Internet, el número de estos puertos también esta reglamentado y es habitual que tengan el
mismo número que el puerto TCP.
Los principales protocolos a nivel de aplicación que utilizan este protocolo UDP a nivel de transporte son:
- el DNS (Domain Name Server)
- el TFTP (Trivial File Transfer Protocol)
- el SNMP (Simple Network Management Protocol) y
- el programa Ping
13.4 ICMP - Internet Control Message Protocol

Modelo TCP/IP 58
ICMP es un protocolo que se describe en la RFC 792 y está actualizada en la RFC 950. Es un protocolo que
funciona en el nivel de red (3) según el modelo de referencia OSI y se basa en el protocolo de red IP.
Cuando un enrutador o un dispositivo destino debe informar al dispositivo origen de errores en el procesado de
los mensajes del protocolo IP, usa el Internet Control Message Protocol (ICMP) para informar del tipo de error
al dispositivo origen. Esto no siempre es bueno, porque a veces el dispositivo origen no puede hacer nada según
del error de que se trate.
El ICMP se caracteriza por :

 El uso del IP como protocolo de más bajo nivel (los mensajes ICMP se encapsulan en mensajes IP). Sin
embargo el ICMP es una parte integral del IP y debe ser implementado en cada mensaje del protocolo
IP.
 Informar de algunos errores, es decir, no hace el protocolo IP más seguro. Los mensajes pueden
perderse, sin tener información vía ICMP. La seguridad del protocolo IP debe llevarse en protocolos de
más alto nivel.
 Informar de errores de cualquier mensaje del protocolo IP, excepto de los propios mensajes ICMP.
 En el caso de fragmentación, los mensajes del protocolo ICMP solo informan de errores del fragmento
cero.
 Los mensajes del protocolo ICMP nunca se envían como respuesta de un mensaje que tenga dirección
IP origen que no sea de un dispositivo en concreto, es decir, que no sea ni loopback, ni broadcast ni
multicast.
 Los mensajes del protocolo ICMP nunca se envían como respuesta a mensajes de error de ICMP.

Los mensajes ICMP su estructura es la misma que la de un mensaje IP excepto en que el tipo de servicio es cero
y el campo de protocolo es un 1 indicativo del protocolo ICMP. Esta es la razón por la que el protocolo ICMP se
considera de que es un protocolo de nivel de red.
El campo de datos contiene los campos siguientes:
- Tipo, 8 bits. Contiene la identificación del tipo de mensaje.
- Código, 8 bits. Contiene más detalle del tipo de mensaje
- Datos
- Control de error, 16 bits
Tipos de mensajes
Los tipos de mensajes son:
0 Respuesta de eco (Echo Reply) Se emplea en un ping
3 Destino inalcanzable (Destination El campo de código especifica si es la red, el
Unreachable) dispositivo, el protocolo, etc.
4 Suprimir origen (Source Quench) Significa que los mensajes llegan demasiado
rápido para ser procesados. Síntoma de congestión.
5 Redirigir (Redirect) Aconseja al dispositivo origen otra ruta.
8 Eco (Echo) Se emplea en un ping.
11 Tiempo superado (Time exceeded)
12 Problema de parámetros (Parameter
Problem)
13 Marca horaria (Timestamp) Se usa para sincronización de relojes entre
dispositivos.
14 Respuesta de marca horaria
(Timestamp Reply)
15 Petición de información (Information
Request)
16 Respuesta de información (Information
Reply)
17 Solicitud de máscara (Address mask
request)
18 Respuesta de máscara (Address mask
Modelo TCP/IP 59
reply)
Referencias
- RFC 792 Internet Control Message Protocol
- RFC 896 Congestion control in IP/TCP internetworks
- RFC 1016 Something a host could do with source quench: SQuID
- RFC 950 Internet Standard Subnetting Procedure
- RFC 1256 ICMP Router Discovery Messages
13.5 ARP - Address Resolution Protocol

El sistema de direccionamiento del protocolo IP plantea un problema desde el punto de vista de
direccionamiento del nivel físico (1). Por ejemplo en una red local Ethernet, dos dispositivos solo pueden
comunicarse si se conocen sus respectivas direcciones físicas (MAC).
El protocolo ARP permite encontrar las direcciones físicas basándose en las direcciones IP de los dispositivos.
Para ello se realiza primeramente una emisión broadcast de un mensaje de control conteniendo entre otros datos
la dirección IP que se desea localizar. Todas los dispositivos de la red reciben este mensaje, pero solamente
aquel cuya dirección IP coincida, responde con otro mensaje de control. Este mensaje contiene la dirección física
(MAC) de dicho dispositivo. Al recibirse la respuesta, el primer dispositivo "aprende" la dirección física (MAC)
del segundo. Esta información se mantiene en memoria caché para posteriores envíos.
Las entradas en la memoria caché se asocian a un temporizador para permitir la modificación dinámica de la
dirección física de los dispositivos porque
- la dirección IP puede ser cambiada por necesidades de operación y
- la dirección física MAC también cambia si se cambia su tarjeta de red.
En base a su funcionamiento, el protocolo ARP es de nivel de red (3) según el modelo de referencia OSI y sus
especificaciones están desarrolladas en la RFC 826.
El algoritmo para el envío del protocolo ARP es el siguiente:

- Dada una dirección IP, primero consultar en la tabla ARP del propio dispositivo.
- Si se encuentra dicha dirección IP, utilizar la correspondiente dirección física.
- Sí no está, enviar una solicitud ARP de broadcasting.
- Temporizar y reenviar si no se recibe respuesta.
El proceso de recepción de mensajes de búsqueda del protocolo ARP funciona de la siguiente manera:
- Al recibir una solicitud del protocolo ARP, si la dirección IP corresponde al equipo:
* Se almacenan las direcciones IP y físicas recibidas en la tabla ARP del propio
dispositivo.
* Se rellena el campo correspondiente de la dirección física del dispositivo.
* Se envía un mensaje de respuesta con su dirección física.
- Sí la dirección IP no es la del dispositivo, se almacena la dirección IP y la física correspondiente
en su tabla ARP para posibles usos futuros.
Un posible problema que puede aparecer en redes TCP/IP es el denominado "tormenta de broadcast". Cuando
un dispositivo envía un comando ARP buscando una determinada dirección, puede provocar una cadena de
mensajes ARP por parte del resto de los dispositivos. Normalmente esto se produce cuando algunas de los
dispositivos conectados a la red no cumplen exactamente las mismas reglas en situaciones muy particulares (por
ejemplo unos soportan subdireccionamiento y otras no, etc..). En este caso todos los dispositivos que utilizan el
subdireccionamiento pueden repetir el comando ARP intentando buscar el dispositivo en su subred.

El mensaje ARP corresponde al campo de datos del protocolo de nivel de enlace de la red en cuestión. Así si es
una red 802.3/Ethernet con protocolo 802.2 SNAP, los campos SAP origen y destino contienen el número 170, y
Modelo TCP/IP 60
el campo de tipo de Ethernet 2054, indicativo de que se trata de un mensaje ARP. Por esta razón se considera de
que es un protocolo de nivel de red según el modelo de referencia OSI.
Los campos de la dirección física del destino van a 0 en el mensaje de búsqueda. El dispositivo destino insertará
aquí su dirección física en el mensaje ARP de respuesta.
Referencias
- RFC 826 Ethernet Address Resolution Protocol
- RCC 814 Name, addresses, ports, and routes.
- RFC 1029 More fault tolerant approach to address resolution for a Multi-LAN system of
Ethernets.
- RFC 1166 Internet numbers.
13.6 RARP - Reverse Address Resolution Protocol

Las especificaciones de este protocolo RARP están descritas en la RFC 903.
El protocolo RARP permite asignar direcciones IP a dispositivos sin unidades de disco y así resolver este
problema. Para ello se utilizan mensajes del mismo tipo que los del protocolo ARP.
Todos los dispositivos con interface de red tiene una dirección física MAC pero en nuestro caso, estos
dispositivos no disponen de dirección IP, por lo que no pueden comunicarse con protocolos de niveles superiores
al de enlace. Por esta razón este protocolo RARP funciona a nivel de red (3) según el modelo de referencia OSI.
El proceso comienza cuando un dispositivo envía una solicitud de dirección IP. En la respuesta se indica además
de la dirección IP, la dirección física del dispositivo y a continuación se pone en estado de espera de una
respuesta por parte de uno o varios servidores RARP que le indiquen su dirección IP.
También debemos tener en cuenta, de que si los servidores RARP están fuera de servicio, los dispositivos
pendientes de ellos, no podrán conectarse a la red.
El mensaje RARP corresponde al campo de datos del protocolo de nivel de enlace de la red en cuestión. Así si es
una red 802.3/Ethernet con protocolo 802.2 SNAP, los campos SAP origen y destino contienen el número 170, y
el campo de tipo de Ethernet 32821, indicativo de que se trata de un mensaje RARP. Por esta razón se considera
de que es un protocolo de nivel de red según el modelo de referencia OSI.
Referencias
- RFC 903 Reverse Address Resolution Protocol
- RFC 906 Bootstrap loading using TFTP
- RFC 1293 Inverse Address Resolution Protocol
Otros protocolos de LAN 61
Capítulo 14. Otros protocolos de LAN
Dentro de este apartado se contemplan aquellos protocolos de nivel de red (3) y transporte (4) correspondiente al
modelo de referencia OSI que se utilizan en el ámbito de las LAN y que no corresponden al modelo TCP/IP.
Estos protocolos se deben entender por una parte con los de nivel de enlace (2) y por otro con los de nivel de
sesión (5) y superiores, que se comentan en el apartado de protocolo de aplicaciones.
En la actualidad aunque el protocolo más difundido y utilizado es el TCP/IP, también existen otros protocolos
tales como el IPX de las redes Novell Netware, así como los de las redes Apple, DECnet, Xerox y Banyan
Vines.
En cuanto al protocolo NetBIOS, en sus orígenes no era un protocolo sino una API de Microsoft. En la
actualidad se basa en el protocolo SMB también propietario de Microsoft. No es utilizable en redes WAN en
tanto que :
- Utiliza nombres para identificar los dispositivos. Debido a esta característica, la utilización de
enrutadores IP, hace que este protocolo no pueda atravesarlos, por lo que no es un protocolo
enrutable.
- Los nombres de los ordenadores no están correlacionados con el nombre del dominio.
Este protocolo NetBIOS también se utiliza a nivel de aplicación en redes TCP/IP, así en este caso es conocido
como NetBIOS sobre TCP/IP y se explica en el apartado correspondiente.
En las redes Novell Netware, los protocolos básicos son IPX, SPX, NCP y SAP.
En la redes AppleTalk, los protocolos son NBP, ZIP y RTMP entre otros.
14.1 NetBIOS / NetBEUI

El origen del NetBIOS (Network Basic Input Output System) se remonta al año 1984 y fue un proyecto
desarrollado por IBM. En realidad no era un protocolo, sino un conjunto de APIs (funciones) que permitían
conectar dispositivos y compartir ficheros.
En 1985 esta API se convirtió en el protocolo NetBEUI (NetBIOS Enhanced User Interface) y permitía usar el
protocolo NetBIOS en redes con protocolos de nivel de enlace Ethernet y Token Ring. Microsoft incorporó en su
sistema el protocolo NetBEUI, más conocido como SMB (Server Message Block) y actualmente como CIFS
(Common Internet File System).
Este protocolo es propietario, razón por la cual sus especificaciones no han sido publicadas, sin embargo, en
LINUX hay el programa SAMBA que permite interactuar una máquina con sistema operativo LINUX con otras
con sistema operativo Windows y protocolo NetBIOS. A partir de su manual, se pueden conocer a grandes
rasgos sus funcionalidades.
NetBIOS proporciona soporte de nombres, en el que se identifican y conocen los dispositivos. Los mensajes se
envían sin ningún requisito de reconocimiento y tiene su propio SAP X'04' del protocolo 802.2 correspondiente
al subnivel LLC del nivel 2 del modelo de referencia OSI.
El bloque de control de interfaces entre la aplicación y la interface del protocolo NetBIOS es el NCB (Network
Control Block) y tiene una longitud de 64 octetos.
En resumen, el NetBIOS :
- tiene servicios de control
- da soporte de nombres
- tiene servicios de soporte de sesión y
- tiene soporte de mensajes
Las funcionalidades del protocolo NetBIOS abarca las de los niveles de enlace (2), red (3), transporte (4) y
sesión (5) del modelo de referencia OSI, y son la siguientes:
- Nivel de enlace (2). Emplea servicios orientado a conexión.
- Nivel de red (3). Es un nivel nulo a efectos de este protocolo, de aquí su imposibilidad de
enrutamiento.
- Nivel de transporte (4). En este nivel, se crean las conexiones punto a punto que soportan la
transmisión de datos y sus reconocimientos, realizando así funciones de control de flujo.
- Nivel de sesión (5). En este nivel, NetBIOS establece la conexión entre nombres.
Servicios de sesión
Una sesión es un intercambio de mensajes fiable entre dos aplicaciones basadas en NetBIOS. Las sesiones son
full-duplex, secuenciadas y fiables. Los datos se encapsulan en los mensajes. El tamaño de cada mensaje puede
oscilar entre 0 y 131071 octetos. Pueden existir múltiples sesiones entre dos dispositivos.
La detección de un fallo de la sesión es uno de los servicios que lleva incorporado el protocolo NetBIOS.
Sus primitivas son:
- Call. Iniciar una sesión con un proceso que está escuchando y tiene un nombre concreto.
- Listen. Acepta una sesión de un solicitante.
- Hang Up. Terminar una sesión.
- Send. Transmitir un mensaje.
- Receive. Recibir un mensaje.
- Estado de la sesión. Obtener información de la sesión en cuestión.
Servicio de datagrama
El servicio de datagrama es un servicio no fiable, no secuenciado y no orientado a conexión. En este caso se
pueden enviar a un nombre concreto o en broadcast.
14.1.1 SMB - Server Message Block
Este protocolo SMB (Server Message Block) es un modelo cliente/servidor e incluye los comandos para todas
las operaciones de ficheros e impresión, tales como :
- abrir y cerrar un fichero
- crear y borrar ficheros y subdirectorios
- leer y escribir un fichero
- búsqueda de ficheros
- poner y eliminar ficheros de las colas de impresión.
Este protocolo es del tipo petición / respuesta, es decir, un cliente solicita algo a un servidor y éste le responde
con un mensaje SMB.
El formato del mensaje consta de dos partes:

- una cabecera de longitud fija y
- un comando de longitud variable.
La estructura de la cabecera es :
ID COM RCLS REH ERR REB RES TID PID UID MID
donde
- ID. 1 octeto. Identificador del protocolo.
- COM. 1 octeto. Código del comando.
- RCLS. 1 octeto. Clase de error.
- REH. 1 octeto. Reservado.
- ERR. 2 octetos. Código de error.
- REB. 1 octeto. Reservado.
- RES. 14 octetos. Reservado.
- TID. 2 octetos. Identificador del árbol.
- PID.2 octetos. Identificador del proceso que lo solicita.

- UID. 2 octetos. Identificador del usuario.
- MID. 2 octetos. Identificador multiplex.
El relleno de más o menos campos de esta cabecera depende del tipo de comando del que forme parte, es decir,
no siempre se rellenan todos.
El establecimiento de la conexión consta de 4 pasos:

- Establecimiento de una conexión virtual. Esta consiste en que el protocolo NetBIOS es el
encargado de hacer la conexión a nivel de sesión (5) según el modelo de referencia OSI. El
resultado es un canal bidireccional virtual entre el cliente y el servidor. Esto se realiza con
solamente 2 mensajes entre ambos.
- Negociación del protocolo variant por el que hablar. Una vez establecida la conexión, el cliente
envía un mensaje al servidor con el fin de negociar el protocolo SMB. En este mensaje su
identificador TID es cero, porque es el servidor el que se lo tiene que dar. También en este caso,
es el cliente el que le pasa todos sus variants posibles, para que el servidor escoja uno, lo que se lo
indica con un índice.
- Establecimiento de los parámetros de la sesión. Estos parámetros son el nombre de la cuenta y su
contraseña, el nombre del grupo de trabajo, el máximo tamaño del mensaje y el número de
solicitudes pendientes que puede soportar su cola.
- Hacer la conexión. Es en esta fase cuando el servidor le comunica su identificador TID y es la
forma de dar por buena la conexión de acuerdo con los parámetros antes recibidos.
El protocolo CIFS (Common Internet File System) es una ampliación del SMB introducida por Microsoft con
sus nuevos productos de Windows 2000.
14.2 Protocolos de una red Novell Netware

Se trata de los protocolos que utilizan las redes con servidores Novell Netware. Novell, Inc., desarrolló e
introdujo NetWare a principios de la década del 80. NetWare utiliza una arquitectura cliente/servidor. Los
clientes (a veces llamados estaciones de trabajo) solicitan servicios, tales como acceso a archivos e impresoras, a
los servidores.
Esta redes de datos utilizan cualquiera de los protocolos de nivel físico (1) y enlace (2) que existen, ya sean
802.3/Ethernet, Token Ring, FDDI, etc.. Hasta el lanzamiento de la versión NetWare 5.0 de Novell en 1998,
todas las redes NetWare utilizaban IPX como único protocolo de nivel de red, sin embargo en la actualidad
también soportan el protocolo TCP/IP.
Netware de Novell es un conjunto propietario de protocolos que incluyen los siguientes:

 IPX, un protocolo de nivel 3 no orientado a conexión que no requiere acuse de recibo para cada mensaje y
define la red y las direcciones de nodo.
 El protocolo de publicación de servicio (SAP) que permite publicar servicios de red.
 El protocolo central de NetWare (NCP) que permite proporcionar conexiones y aplicaciones cliente a
servidor.
 Servicio de Intercambio de mensaje secuenciado (SPX) para los servicios orientados a conexión de nivel 4.
 El protocolo de información de enrutamiento de Novell (RIP), que es diferente del RIP de IP, facilita el
intercambio de información de enrutamiento.
Así la estructura de protocolos de Novell Netware se puede representar de la forma siguiente:
Aplicación
Presentación
SAP
Sesión NCP
Transporte SPX
Red IPX
A continuación se detalla el funcionamiento de cada uno de estos protocolos, excepto el protocolo de

información de enrutamiento de Novell (RIP), que es diferente del RIP de las redes TCP/IP, y que facilita el
intercambio de información de enrutamiento entre los servidores Novell Netware.
El protocolo IPX utiliza el enrutamiento por vector de distancia (como RIP) o de estado de enlace (como el
protocolo de servicios de enlace NetWare (NLSP)). RIP de IPX envía actualizaciones de enrutamiento cada 60
segundos. RIP utiliza tictacs (retardo de red) y número de salto como su métrica de enrutamiento y se limita a un
máximo de 16 saltos.
14.2.1 IPX - Internet Packet Exchange
IPX (Internet Packet Exchange) es un protocolo de nivel red (3) según el modelo de referencia OSI y es
propietario de Novell Netware. Sus características principales son:
- Es un protocolo no orientado a conexión
- Emplea transmisión full-duplex.
- Envía los mensajes, pero no garantiza que alcancen su destino.
- Utiliza sockets para distinguir los distintos protocolos de nivel superior.
En las redes Netware, cada red física debe identificarse con un número, ya que el protocolo IPX lo usa para
diferenciar redes separadas y para su enrutamiento.
También cada servidor Netware tiene que tener su identificador con el fin de que los enrutamientos sean según
un recorrido lo más corto posible. Todo ello es así porque los servidores Netware también realizan funciones de
enrutador.
En cuanto al direccionamiento del protocolo IPX se utiliza una dirección que consta de dos partes:
 el número de red física de 32 bits y
 el número de nodo de 48 bits. El número de nodo es generalmente la dirección de Control de Acceso al
Medio (MAC) para una interfaz de red en el nodo final.
IPX de Novell soporta múltiples redes lógicas en una interfaz individual; cada red requiere un solo tipo de
encapsulamiento.

La estructura del mensaje es :
Control de error
Longitud
Control del transporte Tipo de mensaje
Red de destino
Nodo de destino
Socket de destino
Red de origen
Nodo de origen
Socket de origen
Datos
donde
- Control de error, 16 bits.
- Longitud, 16 bits. Contiene la longitud del mensaje en octetos. No hay fragmentación de
mensajes.
- Control de transporte, 8 bits. Número de enrutadores por los que ha pasado el mensaje. Cuando
llega a 15, se tira el mensaje.
- Tipo, 8 bits. Especifica que protocolo de la capa superior tiene que recibir la información del
mensaje. Si es 5 corresponde al protocolo SPX (Sequenced Packet Exchange) y 17 al protocolo
NCP (Netware Core Protocol)
- Dirección destino. Consta de 3 partes: red (32 bits), nodo (48 bits) y socket (16 bits). El número
del socket es el número por el que el servidor recibirá las solicitudes. Algunos valores
hexadecimales de los sockets son:
01 RIP
451 NCP
452 SAP
455 NetBIOS
- Dirección origen. Consta de la misma estructura que la dirección origen.

- Datos
Encapsulaciones con Ethernet

El protocolo IPX es un protocolo de nivel de red y por tanto se encapsula en protocolos de nivel de enlace.
Respecto al protocolo Ethernet o 802.3 conviene tener en cuenta la evolución histórica del mismo. Así hay 3
posibles implementaciones:
- Ethernet versión II. Era la época en que aún no habían las especificaciones IEEE 802.3
- IEEE 802.3 o también llamada Ethernet cruda ya que el IEEE no había terminado aún de
"cocinarla". Es la opción por defecto de las versiones 2 a 3.11 de NetWare.
- IEEE 802.2 o SAP, que el formato de trama IEEE estándar, incluyendo un encabezado LLC
802.2. Con el lanzamiento de NetWare 3.12 y 4.x, este encapsulamiento se convirtió en el nuevo
formato de trama estándar de Novell.
- IEEE 802.2 SNAP. Corresponde al encabezado IEEE 802.2 agregando un encabezado de
Protocolo de acceso de subred (SNAP) que proporciona un código de "tipo de encapsulamiento".
Es la versión completa del 802.2
14.2.2 SPX - Sequenced Packet Exchange
El protocolo SPX (Sequenced Packet Exchange) es un protocolo de nivel de transporte (4) según el modelo de
referencia OSI y que se comunica con el protocolo IPX de nivel inferior.
Sus características principales son:

- Es un protocolo orientado a la conexión.
- Garantiza la llegada del mensaje.
Así el protocolo SPX realiza:

- Tareas de recuperación de datos duplicados y recuperación de errores. Por ello cada mensaje tiene
un número de secuencia.
- Control de flujo. El dispositivo destino no tiene que reconocer cada mensaje de forma inmediata,
sino que se establece una ventana, cuyo número representa cada cuantos mensajes recibidos tiene
que enviar un mensaje de reconocimiento.
SPX II es una nueva versión mejorada del protocolo SPX y que apareció con la versión 4 de Netware. Sus
principales diferencias con la versión anterior son:
- Lleva incorporado un verdadero algoritmo de ajuste de ventana.
- Recibe reconocimientos afirmativos y negativos indicativos de haber llegado o no a su destino.
En caso negativo, deben ser retransmitidos.
- El tamaño máximo de mensaje de 576 octetos del SPX ha aumentado, y se negocia entre los 2
dispositivos origen y destino.
- Hay posibilidad de cerrar la sesión sin pérdida de datos.

La estructura del mensaje del protocolo SPX es la siguiente:
Control Tipo datos ID conexión origen

ID conexión destino Número de secuencia
Número reconocimiento Tamaño buffer
Datos
Donde:
- Control, 8 bits. Sus significados posibles son:
0x10 Final de mensaje

0x20 Atención
0x40 Reconocimiento requerido
0x80 Mensaje del sistema
- Tipo de datos. 8 bits. Su significado está relacionado con el fin de la conexión. Si su valor es
0xFE significa que es el último mensaje y si es 0xFF incluye reconocimiento.
- ID conexión origen. 16 bits.
- ID conexión destino. 16 bits.
- Número de secuencia. 16 bits. Controlado por el dispositivo origen.
- Número de reconocimiento. 16 bits. Número de secuencia esperado.
- Tamaño buffer.
Parámetros
En cuanto a sus parámetros los más importantes son:
- El SPX Watchdog Abort Timeout. Es el tiempo que espera el protocolo SPX sin recibir un
mensaje de un dispositivo con una sesión de SPX existente. Por defecto es del orden de 30
segundos.
- El SPX Watchdog Verify Timeout. Como el anterior pero en este caso el mensaje debe provenir
de la aplicación del dispositivo. Por defecto es del orden de 6 segundos.
- El SPX Ack Wait Timeout. Es el tiempo de espera de un mensaje de reconocimiento procedente
de la aplicación. Por defecto es del orden de 3 segundos. Si no se recibe el mensaje, la aplicación
decide que no ha sido recibido y lo vuelve a enviar.
- El SPX Default Retry Count. Esta opción controla cuantas veces se ha reenviado un mismo
mensaje sin haber recibido su reconocimiento. Por defecto es 10.
- El Maximum Concurrent SPX Sessions. Esta opción controla el número de sesiones SPX
concurrentes. Como máximo es 2000, consumiendo cada una de ellas 4 octetos de memoria.
14.2.3 NCP - Netware Core Protocol
El protocolo NCP (Netware Core Protocol) es un protocolo de Novell Netware y es una interface de usuario que
sirve para solicitar servicios de la red a sus proveedores de servicios. Sus funciones corresponden a los niveles
de transporte (4), sesión (5) y presentación (6) según el modelo de referencia OSI.
Este protocolo NCP es el equivalente al SMB del protocolo NetBIOS.
Cada uno de estos servicios tienen una identificación dada por el servidor, el cual se lo envía al cliente dentro de
un mensaje del protocolo NCP. También se incluye un número de conexión por cada sesión establecida con el
servidor. De esta manera se puede hacer un seguimiento de las sesiones establecidas.
Estos mensajes del protocolo NCP siempre van encapsulados en mensajes de protocolo IPX.
Hay 2 tipos de mensajes:

- Solicitud. Son los que el receptor solicita.
- Respuesta. Son los que el transmisor envía.

El formato del mensaje del protocolo NCP es el siguiente:
Tipo de mensaje
Número de secuencia Número de conexión (parte inferior)
Número de tarea Número de conexión (parte superior)
Código Estado
Datos
Donde:
- Tipo, 16 bits. Sus valores posibles son:
0x1111 Creación de conexión
0x2222 Mensaje de solicitud
0x3333 Mensaje de respuesta
0x5555 Cierre de la conexión
0x7777 Burst Mode packet
0x9999 Server Busy packet
- Número de secuencia, 8 bits.

- Número identificativo de la conexión. Este número ocupa 2 octetos, que en el mensaje se separan
con el número de tarea en medio de ellos.
- Número de tarea. 8 bits. Cuando es cero, el servidor da por finalizadas todas las tareas.
- Código. 8 bits. Este campo solo está en el mensaje de respuesta e indica el estado del mensaje de
respuesta.
- Estado. 8 bits. Este campo solo está en el mensaje de respuesta y corresponde al estado de la
conexión.
14.2.4 SAP - Service Advertising Protocol
El protocolo SAP (Service Advertising Protocol) lo usa Novell Netware para advertir a sus dispositivos
proveedores de servicio acerca de los servicios de la red y sus direcciones. En general estos dispositivos son los
servidores.
Sus funciones corresponden a los niveles de transporte (4), sesión (5), presentación (6) y aplicación (7) según el
modelo de referencia OSI.
El nodo proveedor de servicios envía un mensaje SAP de broadcast cada 60 segundos, conteniendo la
información del servicio. Todos los nodos SAP emplean este intervalo de tiempo. De esta forma, todos los nodos
SAP pueden actualizar sus tablas y tener todos la misma información.
Sin embargo esto puede generar congestión en grandes redes, por lo que se recomienda en estos casos, el empleo
de enrutadores con protocolo IPX.
Un agente SAP debe existir en cada nodo proveedor de servicios. Estos agentes recogen la información de este
servicio y su dirección, y lo guardan en una tabla llamada Server Information. Si todos los agentes SAP se
intercambian correctamente su información, estas tablas contendrán la información de todos los servidores. Estas
tablas se guardan en los servidores y en los enrutadores, y no en las estaciones de trabajo.
A cambio, los clientes pueden contactar con los agentes SAP para obtener la información de los servidores. Con
la dirección del servidor, el cliente podrá iniciar una sesión con este servidor.
Hay 2 tipos de mensajes:

- de solicitud, de 32 bits. Este tipo de mensaje consta de dos campos, uno con el tipo de mensaje y
otro con el tipo de servidor y
- de respuesta.

La estructura del mensaje de respuesta consta de los siguientes campos:
- Tipo de mensaje, 16 bits. Los tipos posibles son:
0x1 Consulta general

0x2 Respuesta general
0x3 Petición del protocolo GNS
0x4 Respuesta del protocolo GNS
- Tipo de servicio, 16 bits. Los tipos más significativos son:
4 Servidor de archivos Netware

7 Servidor de impresión
24 Enrutador
- Nombre del servidor, 48 bits.

- Dirección de la red, 32 bits.
- Dirección del nodo, 48 bits.
- Dirección del socket,16 bits.
- Número de saltos, 16 bits.
14.3 Protocolos de una red Apple

AppleTalk es el nombre comercial utilizado para identificar las redes locales que conectan ordenadores Apple
Macintosh. Los protocolos que utilizan son propietarios de Apple Computer. Sin embargo a nivel físico emplean
el mismo protocolo especificado por la IEEE y el modelo de referencia OSI.
La estructura de protocolos es la siguiente:
Presentación AFP
Sesión ADSP ZIP ASP PAP
Transporte RTMP AEP ATP NBP
Red DDP
Enlace TokenTalk EtherTalk LocalTalk
Protocolos a nivel de enlace

El protocolo EtherTalk cumple las especificaciones del protocolo IEEE 802.3, el protocolo TokenTalk las del
protocolo IEEE 802.5, y FDDI Talk las del FDDI.
Sin embargo el LocalTalk es específico de Apple y funciona en una topología de bus y con el método de acceso
CSMA/CA.
Protocolos a nivel de red

El protocolo fundamental es el DDP. Sin embargo los protocolos NBP, ZIP y RTMP también se pueden
considerar de nivel de red en cuanto usan los servicios del DDP.
Este protocolo RTMP también sirve para intercambiarse la información de las tablas de enrutamiento entre
enrutadores periódicamente.
Protocolos a nivel de transporte

Básicamente son dos: el ATP y el ADSP, el primero orientado a conexión y el segundo de tipo stream, es decir,
transmisión sin mensajes de reconocimiento.
Los demás protocolos como los ASP, AFP, PAP y AEP se pueden considerar de aplicaciones.
14.3.1 DDP – Datagram Delivery Protocol
El protocolo DDP en cuanto a sus funciones corresponde a un protocolo de nivel de red (3) según el modelo de
referencia OSI.
El protocolo DDP es el responsable del enrutamiento, de la transmisión y entrega de los datos de las aplicaciones
y el empaquetamiento de los datos.
Todos los protocolos cuando envían datos a la red física, deben enviar sus datos a este protocolo DDP.
Sus características son:
- no está orientado a conexión
- no hace corrección de errores, es decir, no requiere ningún reconocimiento de la recepción del
mensaje.
- Su tamaño máximo es de 586 octetos
- Como máximo puede atravesar 15 enrutadores.
Direccionamiento
El las redes AppleTalk, cada dispositivo se identifica por una dirección de 24 bits compuesta por:
- una dirección de la red, 16 bits y
- una dirección del nodo, 8 bits.
El proceso de asignación de la dirección del nodo consiste en que cuando un dispositivo se conecta a la red, se
asigna un número y a continuación verifica si ya existe. Este proceso se repite hasta que se asigna una dirección
que no existe.
14.3.2 NBP – Name Binding Protocol
El protocolo NBP en cuanto a sus funciones corresponde a un protocolo de nivel de transporte (3) según el
El protocolo NBP se usa para convertir las direcciones numéricas que la red utiliza para sus comunicaciones, en
nombres alfanuméricos, que use AppleTalk. Los dispositivos se identifican por nombres y éstos deben tener su
equivalencia en la dirección del nodo.
Este protocolo es pues el encargado de mantener estas tablas de equivalencia que no están centralizadas, es decir,
cada nodo tiene la suya.
14.3.3 ZIP – Zona Information Protocol
El protocolo ZIP en cuanto a sus funciones corresponde a un protocolo de nivel de sesión (3) según el modelo de
referencia OSI.
AppleTalk emplea el concepto de zona para identificar un agrupamiento lógico de una red. Precisamente es este
protocolo ZIP el encargado de mantener unas tablas con la identificación de cada zona con un número.
Este tipo de información facilita el enrutamiento, razón por la cual las tablas ZIT (Zone Information Table) se
guardan en los enrutadores.
14.3.4 ATP - AppleTalk Transaction Protocol
El protocolo ATP en cuanto a sus funciones corresponde a un protocolo de nivel de transporte (4) según el
El protocolo ATP está orientado a conexión. Su principal función es la de garantizar la entrega de los mensajes
al dispositivo de destino. Para ello, ATP requiere de un reconocimiento una vez el mensaje ha llegado a su
destino.
También si falla la conexión, es el protocolo ATP el encargado de intentar recuperarla.
Por otro lado, ATP es el responsable no solo de la transmisión de los datos, sino también de su reconocimiento,
retransmisión, secuenciado, fragmentación y ensamblaje. En cuanto a la segmentación de un mensaje, está
limitado a 8.
14.3.5 ADSP – AppleTalk Data Stream Protocol
El protocolo ADSP en cuanto a sus funciones corresponde a un protocolo de nivel de sesión (4) según el modelo
de referencia OSI.
El protocolo ADSP es un protocolo no orientado a conexión y para sus servicios establece una transmisión full-
duplex, lo que permite una conversación entre dispositivos simultáneamente en los 2 sentidos.
El protocolo ADSP también tiene un mecanismo de control de flujo, con el fin de que un transmisor muy rápido
no colapse al receptor. Esto se consigue de forma que el receptor informa al transmisor del tamaño de buffer
disponible. Así también se garantiza una entrega correcta de datos.
14.3.6 ASP – AppleTalk Session Protocol
El protocolo ASP en cuanto a sus funciones corresponde a un protocolo de nivel de sesión (5) según el modelo
de referencia OSI.
El protocolo ASP se encarga de que los comandos recibidos estén en el mismo orden que fueron enviados.
Una sesión es una relación lógica entre 2 dispositivos. Las sesiones se identifican con un identificador único
cada una de ellas. El protocolo ASP es el responsable de abrir y cerrar sesiones, y manejar los comandos, tanto
los de servidores como otros dispositivos.
14.3.7 PAP – Printer Access Protocol
El protocolo PAP en cuanto a sus funciones corresponde a un protocolo de nivel de sesión (5) según el modelo
de referencia OSI.
El protocolo PAP está orientado a conexión. Su responsabilidad es la de mantener las comunicaciones entre un
cliente y un servicio de impresión. Sus funciones incluyen el mantenimiento de la conexión, la transferencia de
datos y la desconexión cuando ha terminado el trabajo.
14.3.8 AFP – AppleTalk Filing Protocol
El protocolo AFP en cuanto a sus funciones corresponde a un protocolo de nivel de presentación (6) según el
El protocolo AFP es el que permite a un usuario acceder en remoto a los ficheros de otro dispositivo, sin
embargo previamente verifica que esta petición sea local.
Sus servicios son los siguientes:

- Poder obtener información de un servidor y otras partes de su estructura de ficheros.
- Poder modificar aquella información.
- Crear y borrar ficheros y directorios.
- Leer y escribir información en ficheros individuales.
14.3.9 AEP – Appletalk Echo Protocol
El protocolo AEP en cuanto a sus funciones corresponde a un protocolo de nivel de transporte (7) según el
El protocolo AEP es un protocolo de verificación y que lo pueden usar los protocolos de nivel de transporte
(ATP, ASP, etc.) para determinar si un dispositivo es accesible. También puede servir para conocer los tiempos
de respuesta de un dispositivo.
Este protocolo se usa para enviar un mensaje de un dispositivo a otro y recibir respuesta al mismo, es decir, un
eco. Para ello es necesario que en el dispositivo destino esté instalado el programa correspondiente.
14.4 Otros protocolos de LAN

A continuación se comentan brevemente otras redes LAN con una implantación muy minoritaria, tales como
- DECNET
- Xerox
- Banyan Vines
14.4.1 Redes DECnet
En las últimas versiones, sus protocolos se rigen por una arquitectura similar a la del modelo de referencia OSI,
excepto en que el nivel de transporte le llaman servicios de red y los niveles de sesión y presentación, son uno
llamado “DNA session control”.
Una red DECnet está dividida lógicamente en áreas. Como máximo una red puede tener 63 áreas y cada una de
ellas un máximo de 1023 nodos.
Así la dirección de cada nodo está formado por el número del área a la que pertenece (6 bits) y otro número (10
bits), es decir, está representada en total por 2 octetos.
Aplicación DAP, CTERM,Mail-11

Transporte NSP
Red CLNS, CONS
Enlace DDCMP
Sus principales protocolos son:

- DDCMP (Digital Data Communications Message Protocol). Este protocolo, que es de nivel de
enlace, se usa en la WAN para la conexión punto a punto entre 2 dispositivos.
- CLNS (Connectionless Network Service Protocol). Es un protocolo de nivel de red, no orientado
a conexión y por tanto no fiable.
- CONS (Connection-Oriented Network Service Protocol). Es un protocolo de nivel de red,
orientado a conexión.
- NSP (DNA Network Services Protocol). Es un protocolo de nivel de transporte. Establece
conexiones a nivel NSP y se encarga de enviar mensajes de datos, hacer su control y su
reconocimiento.
- DAP (Data Access Protocol). Es un protocolo de transferencia de ficheros.
- CTERM (Command Terminal Protocol). Es un protocolo de emulación de terminal.
- Mail-11. Es un protocolo de correo.
- NTP (Network Time Protocol). Este protocolo permite la sincronización de los relojes de los
distintos dispositivos tanto a nivel LAN como WAN.
- LAT (Local Area Transport Protocol). Este protocolo es para soportar los dispositivos orientados
al carácter.
- MOP (Maintenance Operations Protocol). Este protocolo permite el uso de dispositivos sin disco
duro.
14.4.2 Redes Xerox
Esta redes han sido la base de otras como Banyan y Novell.
Su estructura de protocolos coincide fundamentalmente con el modelo de referencia OSI. Su diferencia principal
es que las funciones del nivel de sesión se incluyen en las de nivel de aplicación.
Aplicación Printing, Mail

Transporte SPP, PEX, Error, Echo
Red IDP
Sus protocolos son:

- IDP (Internet Datagram Protocol). Es un protocolo de nivel de red, encapsulando los protocolos
de nivel superior. Este protocolo no está orientado a conexión por lo que su servicio no es fiable.
Cada mensaje contiene toda la información en cuanto a direccionamiento.
- Error Protocol. Es un protocolo de nivel de transporte, que conlleva unas funciones que permiten
a cualquier agente de la red informar de algún error. Si lo hubiere el mensaje no se retransmite.
- Echo Protocol. Es un protocolo de nivel de transporte, que funciona cuando un dispositivo o
enrutador detecta algún fallo que no permite entregar el mensaje a su destinatario.
- SPP (Sequenced Packet Protocol). Es un protocolo de nivel de transporte y orientado a conexión,
lo que permite una transmisión fiable de los mensajes.
- PEX (Packet Exchange Protocol). Es un protocolo de nivel de transporte y se usa para transmitir
un mensaje y recibir una respuesta de forma segura. Así este protocolo incorpora posibilidad de
retransmisión, pero no detecta mensajes duplicados.
En cuanto a su direccionamiento, cada dispositivo tiene una dirección de 12 octetos y que consta: de una
identificación de red (32 bits), una identificación de dispositivo (48 bits) y un número de puerto (16 bits).
14.4.3 Redes Banyan VINES
Su estructura de protocolos coincide fundamentalmente con el modelo de referencia OSI.
Las direcciones de Internet de Vines constan de 48 bits, de los cuales los 32 más significativos corresponden a la
identificación de la red.
Transporte IPC, SPP

Red IP, RTP, ARP, ICP
Enlace Echo
Los protocolos a nivel de transporte son el IPC y el SPP. El protocolo SPP suministra control de flujo y
reconocimientos, el protocolo IPC fiable solo incorpora reconocimiento pero no hace control de flujo y el IPC
datagram no hace ninguna de las 2 funciones.
En cuanto a nivel de red, el protocolo básico es el IP, pero de funcionamiento distinto del IP de Internet, y
estructura de mensaje también diferente.
Sus principales protocolos son:

- Vines Echo Protocol. Este protocolo que funciona a nivel enlace, consiste en que un cliente envía
un mensaje a un servidor, y éste lo devuelve como respuesta.
- Vines IP (Vines Internet Protocol). Es un protocolo que funciona a nivel de red y como tal no está
orientado a conexión. Consecuentemente es un protocolo no fiable porque no garantiza que los
mensajes lleguen a su destino ni en el orden en que fueron enviados.
- Vines RTP (Vines Routing Update Protocol). También es un protocolo a nivel de red que maneja
las tablas de enrutamiento, que hacen que los mensajes Vines IP sigan las rutas más óptimas.
Asimismo se encarga de la actualización de estas tablas.
- Vines ARP (Vines Adressing Resolution Protocol). Es un protocolo que funciona a nivel de red.
Los servidores y enrutadores Vines tienen direcciones de Internet preasignadas pero no los demás
dispositivos. Es mediante este protocolo ARP que se hace la asignación de direcciones.
- Vines ICP (Vines Internet Control Protocol). También es un protocolo a nivel de red que permite
la notificación de una determinadas condiciones y también hace de eco en otras. Por ejemplo, si
un mensaje Vines IP durante su transmisión no puede continuar siendo enrutado ni llega a su
destino, mediante el protocolo Vines ICP se informa del hecho al dispositivo origen.
14.5 NetBIOS sobre TCP/IP

Este encapsulamiento se define en las RFC 1001 y 1002 y está implementado en el protocolo TCP/IP de
Microsoft. En este caso el protocolo NetBIOS funciona como protocolo a nivel de aplicación según el modelo de
referencia OSI.
Cuando los clientes de Windows 2000, NT 4.0, Windows 95, o Windows 98 configuran el protocolo TCP/IP
activando la opción de compartir ficheros e impresoras, se incorpora automáticamente el protocolo NetBIOS
sobre TCP/IP.
Como ya se escrito más arriba el protocolo NetBIOS no puede enrutar porque identifica los dispositivos por
nombres. Con esta encapsulación sobre TCP/IP se rompe esta funcionalidad, porque el protocolo TCP/IP si es
enrutable.
Las RFC 1001/1002 no definen una técnica de encapsulación; ellas definen el mapeo de los servicios de
NetBIOS en UDP/IP y TCP/IP. Por ejemplo, cuando se establece una sesión NetBIOS, definen que comandos de
puertos se emplearán en una conexión TCP para enviar datos de una sesión de NetBIOS.
Los dispositivos que tienen instalado esta funcionalidad, se pueden definir de 3 formas:
- Nodo broadcast (B). Emplean el protocolo UDP como broadcast para establecer conexiones e
intercambiar mensajes. Como no pueden atravesar los enrutadores, solo sirve para redes de un
solo segmento.
- Nodo punto a punto (P). En este caso la distribución de mensajes depende del servidor NetBIOS.
- Nodo mixto (M). Es la mezcla de los 2 anteriores.
Hay también el tipo de nodo híbrido, no definido en las RFCs, que también es una combinación de los nodos B y
P.
14.6 NetBIOS sobre IPX

Se trata de la implementación de un emulador NetBIOS por encima del protocolo IPX, protocolo de nivel de red
de Novell Netware.
Este protocolo NetBIOS funciona por tanto a nivel de transporte, es decir, equivalente al protocolo SPX.
Novell dice que es un emulador en cuanto sus mensajes no son compatibles con el NetBIOS oficial.
14.7 DLSw - Data Link Switching

El protocolo Data Link Switching (DLSw) lo creó IBM en Marzo de 1993 y está documentado en la RFC 1795.
Este protocolo permite transportar tráfico del protocolo IBM SNA y IBM NetBIOS a través de redes TCP/IP.
Como ya se comentó con anterioridad, el protocolo NetBIOS no tiene funciones de nivel de red, por lo que no
puede enrutar, es decir, no hay ni es posible la existencia de enrutadores NetBIOS.
A cambio hay enrutadores IP. Así IBM decidió crear este protocolo DLSw que implementado en los enrutadores,
permitía ser enrutado. Por otro lado, este protocolo encapsula los protocolos NetBIOS y SNA, por lo que
aparentemente permite su enrutamiento.
Si se emplean los protocolos NetBIOS y SNA en redes con líneas de comunicaciones de baja velocidad, puede
suceder que un mensaje se dé por perdido cuando en realidad no ha tenido tiempo de llegar a su destino. Esto
sucede si se emplean puentes comunicados mediante líneas de comunicaciones.
Si se sustituyen estos puentes por enrutadores con protocolo DLSw, son estos dispositivos los que controlan los
temporizadores, cosa que no hacen los puentes. Así se detecta si un mensaje está en camino y no que se ha
perdido. La razón es que estos enrutadores con DLSw se comunican con los dispositivos origen y destino de la
conexión.
DLS DLS
Red IP
Inf
Info o
RR RR
El DLSw es capaz de hacer una combinación de tráfico 802.2, SDLC y TCP/IP en una red que opera a nivel
lógico como una sola red 802.2, ya que funciona a nivel de MAC, sin conocer lo que es una PU ni una LU,
términos del protocolo SNA.
El DLSw opera a nivel transporte (4), los mensajes SDLC o LLC son validados localmente por el enrutador con
protocolo DLSw y reenviados a una interface del protocolo TCP/IP.
El DSLw utiliza el protocolo SSP (Switch to Switch Protocol). Este protocolo se utiliza para encapsular tráfico
SNA y NetBIOS entre los enrutadores con protocolo DLSw, así como para el intercambio de mensajes de
control entre ellos. Los mensajes de control se utilizan para el establecimiento de las sesiones, control de las
mismas y para la búsqueda de dispositivos en la red.
No es necesario configurar todos los enrutadores de la red TCP/IP con protocolo DLSw, solamente aquellos que
soporten las conexiones SNA o tengan que enrutar protocolo NetBIOS.
Protocolos de Aplicaciones 75
Capítulo 15. Protocolos de Aplicaciones
Dentro de este apartado se contemplan aquellos protocolos de nivel de sesión (5), presentación (6) y aplicación
(7) según el modelo de referencia OSI y que se utilizan en el ámbito de las LAN.
Estos protocolos se deben entender por una parte con los de nivel de transporte (4) y por otro las aplicaciones
que se utilizan.
A continuación se desarrollan solamente algunos de los más conocidos, porque en la actualidad es muy habitual
que la mayoría de aplicaciones importantes tengan algunos protocolos propios y en general propietarios, por lo
que las empresas no dan a conocer su funcionamiento.
15.1 FTP - File Transfer Protocol

El protocolo FTP se describe en la RFC 959 y está actualizado en la RFC 2228 FTP Security Extensions. Es un
protocolo que funciona a nivel de aplicación según el modelo de referencia OSI.
La funcionalidad principal de este protocolo es la de copiar ficheros de un dispositivo a otro, lo cual es una de las
operaciones más frecuentes en las redes de ordenadores. La transferencia de datos puede ser de cliente a servidor
o viceversa.
Desde el punto de vista del usuario, este enlace está orientado a la conexión, es decir, los dos dispositivos cliente
y servidor, han de estar funcionando y tener implementado el protocolo TCP/IP. El protocolo FTP usa el TCP
como protocolo de transporte dando seguridad a la conexión extremo a extremo.
Para establecer una conexión FTP, se necesita un servidor FTP que escuche, en general por los puertos 20 y 21
del protocolo TCP, las solicitudes de los clientes. Para ello se usan dos conexiones:
- la primera para login y a continuación el protocolo TELNET y
- la segunda para control de la transferencia de datos.
Dado que es necesario registrar el dispositivo remoto, el usuario debe tener un nombre y un contraseña para
poder acceder a los ficheros y subdirectorios, que debe estar registrado en el servidor FTP al que accede. El
usuario que inicia la conexión asume el papel de cliente, mientras que la función de servidor es asumida por el
dispositivo remoto.
En ambos lados del enlace, la aplicación FTP se basa en un PI (Protocol Interpreter), una DPT (Data Transfer
Process), y una interface de usuario. Ésta se comunica con el PI, que es el encargado de la conexión de control.
El PI tiene que comunicar la información necesaria a su propio sistema de ficheros.
Usuario Interface
de usuario Conexión de
control
PI PI
Sistema de Sistema de
DTP DTP
ficheros ficheros
Conexión de
datos
En el lado contrario del enlace, el PI, además de su función de responder al protocolo TELNET, tiene que iniciar
la conexión de datos. Durante la transferencia del fichero, la gestión de los datos es realizada por los DTPs.
Cuando acaba la transferencia, la PI del servidor es el que se encarga de cerrar la conexión de control.
Con el protocolo FTP, el usuario puede realizar alguna de las siguientes operaciones:
 Conectarse a un dispositivo. En este caso, se debe enviar un login y un contraseña de forma que el otro
dispositivo lo reconozca y sepa a que parte del sistema de ficheros puede acceder.
 Seleccionar un directorio
 Listar ficheros
 Definir el modo de transferencia. Este modo consta por una parte si la transmisión de datos se debe
hacer en un mensaje o varios, y por otra la codificación de los caracteres (ASCII, EBCDIC)
 Copiar ficheros a o desde otro dispositivo
 Desconectarse de un dispositivo
15.2 TFTP - Trivial Transfer Protocol

TFTP es un protocolo muy simple de transferencia de ficheros, que se describe en la RFC 1350. Es un protocolo
que funciona a nivel de aplicación según el modelo de referencia OSI y emplea el protocolo UDP a nivel de red.
Como en el caso del protocolo FTP, se requiere de un servidor TFTP que esté en escucha y un cliente TFTP que
inicialmente envía una solicitud de lectura/escritura por el puerto 69 del protocolo UDP. A continuación el
servidor y el cliente negocian el puerto UDP que usarán para el resto de la conexión.
El protocolo TFTP carece de casi todas las características del FTP, solo tiene la posibilidad de enviar un fichero.
TFTP no tiene autenticación del usuario, por lo que no es un protocolo seguro.
Cualquier transferencia empieza con una solicitud de lectura o escritura de un fichero. Si el servidor lo acepta, se
abre una conexión y el fichero se envía en bloques de 512 octetos (longitud fija). Los bloques del fichero se
numeran consecutivamente empezando por 1. Cada mensaje de datos debe ser reconocido por un mensaje de
reconocimiento antes de poder enviar el siguiente. El final de la transferencia se consuma porque el tamaño del
último mensaje es inferior a 512 octetos.
Casi todos los errores harán que la conexión se termine. Si se pierde un mensaje por la red, se producirá el
vencimiento de un temporizador, que provocará que se vuelva a enviar el último mensaje.
15.3 TELNET
El protocolo TELNET se describe en la RFC 854 TELNET Protocol Specifications y la RFC 855 TELNET
Option Specifications. Es un protocolo de nivel de aplicación según el modelo de referencia OSI.
Este protocolo permite trabajar como terminal local pero de forma remota. Para ello se necesita que en el
dispositivo al que se quiere acceder remotamente, esté funcionando el programa TELNET, y que el cliente
también disponga de otro programa que se comunique con el remoto. El protocolo que se emplea en este caso se
llama TELNET.
Conexión TCP Sistema

Sdel Servidor
Cliente Servidor
El protocolo TELNET se puede usar tanto en WANs como en LANs.

El protocolo TELNET se basa en 3 ideas:

1. El concepto Network Virtual Terminal (NVT). Una Terminal Virtual de Red (NVT) es un dispositivo
imaginario con una estructura básica común a muchos terminales reales. Cada dispositivo mapea sus propias
características de terminal a las del NVT, y asume que cada dispositivo hará lo mismo.
2. Una vista simétrica de terminales y procesos.
3. Negociación de las opciones del terminal. El principio de las opciones negociadas se usa en el protocolo
TELNET, porque muchos dispositivos desean suministrar servicios adicionales, además de los propios de la
NVT.
La comunicación entre cliente y servidor se basa en unos comandos internos del propio protocolo y que son
accesibles a los usuarios. Estos comandos internos consisten en secuencias de 2 ó 3 octetos precedidos por el
carácter ESC.
El servidor y el cliente usan un conjunto de convenciones para establecer las características operacionales de su
conexión TELNET vía los mecanismos de “DO, DON'T, WILL, WON'T”.
Los dos dispositivos empiezan verificando su entendimiento mutuo. Una vez esta negociación inicial se
completa, ellos son capaces de trabajar en un nivel mínimo implementado por la Terminal Virtual de Red
(NVT). Una vez alcanzado este entendimiento mínimo, ellos pueden negociar las opciones adicionales con el fin
de ampliar las capacidades del NVT. Dada la simetría del modelo usado por TELNET, tanto el servidor como el
cliente pueden proponer el uso de opciones adicionales.
En cuanto a las opciones de la conexión, en el caso del protocolo TELNET, deben ser negociadas por ambos
extremos, es decir, el cliente y el servidor. Las opciones que en general siempre están implementadas son las
siguientes:
Nombre Código RFC Descripción

Transmisión binaria 0 856 Transmisión binaria a 8 bits
Eco 1 857 Permite a un extremo hacer eco de los datos recibidos
Estado 5 859 Solicitud de estado a un dispositivo remoto
Tipo de terminal 24 884 Intercambio de información sobre el modelo de terminal
End-of-record 25 885 Envío de un fin de transmisión de datos
Sin embargo hay posibilidad de muchas otras opciones.
15.4 DNS - Domain Name System

El protocolo DNS (Domain Name System) se describe en las RFC 1034 y 1035 y funciona a nivel de aplicación
según el modelo de referencia OSI.
Su funcionalidad principal consiste en el establecimiento de una tablas de equivalencia de direcciones IP con

nombres. Así las primeras configuraciones de Internet solo funcionaban con direcciones IP. Pero surgió la
necesidad de dar nombres a los dispositivos. Esto introdujo el problema de mantener estas tablas de direcciones
IP y nombres de forma coordinada y centralizada.
Inicialmente los nombres se guardaban en un fichero llamado HOSTS.TXT, que se transmitía vía FTP. Las
especificaciones de este fichero se definen en las RFCs 606 y 810.
Pero debido al crecimiento exponencial del número de dispositivos en Internet, su actualización era muy costosa
y así en 1984, fue sustituido por un nuevo concepto: el Domain Name System. Los dispositivos pueden
continuar usando su fichero local en el caso de pequeñas redes, pero hoy en día el Domain Name System es
imprescindible en Internet. El Domain Name System permite que un programa que corre en un dispositivo pueda
solicitar la equivalencia de un nombre a otro dispositivo, sin necesidad de disponer de la base de nombres
completa de todos los dispositivos.
Este protocolo DNS se apoya en los protocolos TCP o UDP a nivel de transporte y el puerto 53, por lo que
únicamente funciona en redes TCP/IP.
El proceso de resolución de nombres de dominio puede ser resumida en los pasos siguientes:
1. Un programa de usuario envía a nivel local, una petición de una dirección IP correspondiente a un nombre.
Esto se realiza con la función gethostbyname().
2. El programa del propio dispositivo intenta resolverlo con sus datos, ya sea con una consulta al fichero
HOST.TXT o equivalente.
3. Si el paso anterior no ha sido satisfactorio, se hace la solicitud a un servidor de nombres DNS, que comprueba
si lo tiene en su base de datos o en la caché. Si no lo encuentra, se lo preguntará a otro servidor de nombres, cuya
definición encuentra en su propia tabla.
4. Finalmente el servidor DNS responderá al solicitante con la correspondiente dirección IP o con un error si no
lo ha podido resolver. Normalmente el programa no dará una lista de todos los servidores de nombres que han
sido consultados con la pregunta.
15.4.1 Organización de los nombres
En principio en una red TCP/IP, los nombres de cada dispositivo puede ser cualquiera.
Sin embargo el origen de las redes TCP/IP es la red Internet. Por esta razón, cuando se implementaron los
nombres de los dispositivos en Internet, se tuvo que establecer una normalización. La estructura de nombres se
decidió que fuera jerárquica, y así se define en la RFC 952.
De esta forma tenemos una raíz y varias ramas, cuya forma de expresarlo es a base de separar cada elemento por
un punto (.)
En Internet, los nombres de las raíces principales está normalizado, y en todos los países excepto Estados
Unidos, es un indicativo del país. Así en España es es, en Francia, fr, etc.
A partir de aquí, el nombre de la primera rama también debe estar autorizado por los organismos o empresas
competentes, con el fin de que no haya nombres duplicados. El nombre de las demás ramas es responsabilidad
del propietario del nombre de la raíz. Hay países que dan a la primera rama, el mismo nombre que emplea
Estados Unidos como raíz.
En la actualidad las raíces utilizadas en Estados Unidos son:
gov Organismos gubernamentales

mil Organismos militares
edu Instituciones educativas
com Empresas comerciales
net Proveedores de Internet
int Organismos internacionales
org Otros organismos
En la actualidad, se va a autorizar otros nombres.
Así el concepto de dominio se define como cada uno de los nodos de la primera rama, por ejemplo,
microsoft.com
Las bases de datos con los nombres y direcciones IP, están contenidas en distintos ficheros de otros tantos
servidores DNS. Cada fichero de este tipo se le llama zona, es decir, es la identificación de un elemento físico.
La base de datos debe contener como mínimo las parejas de nombres de los dispositivos y sus direcciones IP. En
la realidad, se ha ampliado su contenido con información del tipo de dispositivo, de su sistema operativo y de su
correo electrónico.
Cada registro de la base de datos consta de 5 campos:

- nombre del dispositivo
- tiempo de vida. Tiempo durante el cual se guardará en la caché del dispositivo que haya
solicitado la información de este registro.
- clase. Es la clase del protocolo. En Internet es IN.
- Tipo. Sus principales tipos son:
SOA Start of Authority Indicación del primer registro con información

general
NS Name server Servidor de nombre de este dominio
A Alias Indicativo de dirección IP
CNAME Canonical name Indicativo de alias
MX Mail Exchanger Indicativo de un servidor de correo electrónico
- datos. Sus valores varían según del tipo de que se trate. Si es tipo A, contendrá la dirección IP, si
es tipo CNAME, un nombre, etc.
Hay 2 tipos de servidores en cuanto a la actualización de la base de datos:

- Primarios, en que su base de datos se actualiza a partir de otros primarios y
- Secundarios, cuya base de datos se actualiza por copia de un primario.
Los cambios siempre se realizan en las bases de datos de los servidores primarios.
15.4.2 Servidores de nombres
Se llaman así aquellos dispositivos que contiene una o varias zonas.
Hay varios tipos de servidores de nombres en función de su funcionalidad y que son:

- Principal. Este servidor de nombres obtiene los datos de sus zonas de archivos locales. Los
cambios en una zona se realizan en estos servidores.
- Secundario. En este caso el servidor obtiene los datos de sus zonas de otro servidor de nombres
de la red. Su razón de ser es para que haya redundancia de dispositivos, para disminuir el tráfico
reduciendo la dispersión geográfica y para reducir la carga de los servidores principales.
- Maestro. Son los servidores de los que toman los datos los servidores de nombres secundarios.
Estos servidores de nombres pueden ser primarios o secundarios.
- De reenvío. Son aquellos servidores de nombres que si no pueden resolver los nombres por ellos
mismos, pueden reenviar esta solicitud a otro servidor de nombres.
- Esclavo. Es un servidor de nombres configurado como servidor de reenvío y también para
devolver un mensaje de error si el propio servidor de reenvío no es capaz de resolver la consulta.
15.4.3 Resolución de nombres
Un cliente puede realizar tres tipos de consultas a un servidor de nombres,

- Recursiva. En este caso se pide al servidor de nombres que responda con los datos pedidos, o con
un error que indique que el nombre de dominio especificado o los datos del tipo pedido no
existen.
- Iterativa. En una consulta iterativa, el servidor de nombres consultado devuelve al solicitante la
mejor respuesta que tiene disponible. En este caso puede emplear solicitudes a otros servidores de
nombres.
- Inversa. Se trata de a partir de una dirección IP, obtener el nombre correspondiente.
15.4.4 Estructura del mensaje
La estructura de un mensaje de protocolo DNS es la siguiente:

Identificación Parámetro
Número de solicitudes Número de respuestas
Número de autoridades Número de informaciones adicionales
Sección de solicitudes
Sección de respuestas
Sección de autoridades
Sección de información adicional
Como se ve en la figura anterior, los mensajes del protocolo DNS constan de una cabecera fija formada por:
- una identificación, 16 bits, para encajar cada respuesta con su solicitud y
- un parámetro, 16 bits, que especifica la operación solicitada (solicitud o respuesta), el tipo de
solicitud y el tipo de respuesta.
La cantidad de los otros campos varía en función de la cantidad de información solicitada. El mensaje de
respuesta no solo contiene las solicitudes sino también las respuestas a las mismas.
15.4.5 DNS dinámico
Uno de los problemas del DNS es la actualización de las tablas. Este trabajo administrativo si debe hacerse
manual, es costoso porque la red es viva.
Por esta razón se define el DNS dinámico (DDNS) en las RFC 2136 y 2137. En este caso un servidor DDNS es
capaz de actualizar su tabla desde otro servidor DDNS o un servidor DHCP.
Por este motivo, si hay implementado en la red un servidor DHCP, es muy recomendable el empleo de un
servidor DDNS.
15.4.6 Consideraciones con Microsoft Windows
Microsoft con sus sistemas operativos Windows ha empleado fundamentalmente el protocolo NetBIOS. Sin
embargo, en las implementaciones de su TCP/IP también soporta la resolución de nombres.
La resolución de un nombre con el fin de encontrar su dirección IP, Windows la resuelve mediante su búsqueda
por el orden siguiente:
- Primero, mediante el uso del fichero hosts del propio dispositivo
- Segundo, mediante el uso del fichero lmhosts del propio dispositivo
- Tercero, mediante la solicitud a los servidores DNS si están especificados en las propiedades del
protocolo TCP/IP del propio dispositivo.
- Cuarto, mediante un servidor WINS. Este servicio WINS es propietario de Microsoft y mantiene
dinámicamente unas tablas de nombres y direcciones IP, pero con una estructura propietaria e
incompatible con el DNS estándar del TCP/IP
15.4.7 Referencias
- RFC 1034 Domain Names—Concepts and Facilities

- RFC 1035 Domain Names—Implementation and Specification
- RFC 1123 Requirements for Internet Hosts—Application and Support
- RFC 1886 DNS Extensions to Support IP Version 6
- RFC 1995 Incremental Zone Transfer in DNS
- RFC 1996 A Mechanism for Prompt DNS Notification of Zone Changes
- RFC 2136 Dynamic Updates in the Domain Name System (DNS UPDATE)
- RFC 2181 Clarifications to the DNS Specification
- RFC 2308 Negative Caching of DNS Queries (DNS NCACHE)
- Microsoft Windows 2000 DNS - White paper
15.5 LPDP - Line Printer Deamon Protocol

El protocolo LPDP (Line Printer Deamon Protocol) permite acceder a las impresoras de aquellos ordenadores,
con el deamon de impresora (LPD) activo siempre en una red TCP/IP. Su funcionamiento se detalla en la RFC
1179.
Es un protocolo a nivel de aplicación según el modelo de referencia OSI y consta de los módulos siguientes:
- LPR, asigna trabajos a la cola de salida
- LPQ, visualiza la cola de salida
- LPRM, cancela trabajos en la cola de salida y
- LPC, controla la cola de salida
En concreto el protocolo LPR está encapsulado en el protocolo TCP y escucha por su puerto 515. Los puertos de
salida son del 721 al 731, ambos inclusive.
En la RFC 1179, se especifica todos y cada uno de los comandos, así como su formato, que el cliente puede
enviar al servidor. Todos los comandos empiezan con un octeto, cuyo contenido es un número indicativo de la
función solicitada. A continuación se envía el nombre de la cola de la impresora, a la que se ha de aplicar lo
solicitado. Los demás operadores se distinguen entre si por un espacio en blanco como delimitador. Al final se
envía un salto de línea como indicativo de fin de comando.
15.6 NFS - Network File System

Network File System (NFS) utiliza el mecanismo RPC (Remote Procedure Call) con el fin de implementar un
sistema de ficheros distribuidos. Fue desarrollado por Sun, y permite a los usuarios autorizados, a acceder a
ficheros de sistemas remotos como si fueran en local.
La especificación actual del protocolo NFS se encuentra en la RFC 1813 NFS: NFS Version 3 Protocol
Specification y es un protocolo que funciona a nivel de aplicación según el modelo de referencia OSI, y utiliza el
protocolo UDP como protocolo de nivel de transporte.
En este sistema de ficheros se emplean dos protocolos:

1. El protocolo Mount para especificar el dispositivo remoto y el sistema de ficheros a acceder y
donde se encuentran los ficheros a los que se quiere acceder dentro de la jerarquía de ficheros
locales y
2. El protocolo NFS para hacer las lecturas y escrituras al sistema de ficheros remoto.
Protocolo Mount
El protocolo Mount es del tipo RPC y su número de programa es 100005. Se encapsula en los protocolos y
contiene los procedimientos siguientes:
- NULL. No hacer nada. Es útil para la respuesta del servidor ante una prueba.
- MNT. En este caso el Mount devuelve un puntero del fichero apuntando al directorio.
- DUMP. Devuelve una lista de todos los sistemas de ficheros montados.
- UMNT. Elimina una entrada de la lista anterior.
- UMNT ALL. Elimina todas las entradas de la lista.
- EXPORT. Devuelve información sobre la disponibilidad de los sistemas de ficheros.
El comando UMOUNT elimina el sistema de ficheros remoto del directorio del fichero local.
Protocolo NFS
El protocolo NFS también se basa en una aplicación del tipo RPC, y su misión es realizar las funciones de
lectura/escritura de ficheros al dispositivo remoto. Su número de programa es el 100003 y a veces usa el puerto
2049. No es un número de puerto oficial, por lo que hay versiones de NFS que utilizan otros puertos.
El programa NFS consta de 22 procedimientos, de los cuales los más importantes son:
- ACCESS. Resuelve los permisos de acceso, de acuerdo con los permisos del fichero para este
usuario.
- LOOKUP. Busca un fichero en el directorio actual y si lo encuentra, devuelve un apuntador más

los atributos del fichero.
- READ y WRITE. Son las primitivas de lectura/escritura para acceder al fichero.
- RENAME. Modificar el nombre del fichero.
- REMOVE. Borra el fichero.
- MKDIR y RMDIR. Crea y/o borra subdirectorios.
- GET y SET-ATTR. Obtiene y modifica los atributos de un fichero.
Estos procedimientos corresponden a las primitivas de entrada/salida más utilizadas en los sistemas operativos
para acceder a los ficheros locales. Para acceder a los directorios remotos, primero se montan en el directorio
local, y a partir aquí se pueden utilizar como si estuvieran en local.
El protocolo NFS es completamente transparente al usuario.
15.7 X- Windows
Es una aplicación que suministra simultáneamente vistas de procesos locales y remotos, permitiendo que corran
independientemente de la tecnología que sea en el dispositivo origen. Por ejemplo, con X-Windows pueden
correr terminales de DOS, OS/2 y X-Window en un mismo dispositivo.
El Sistema X-Window es uno de los más utilizados con interface GUI (Used Graphical User), o sistemas de
visualización bitmapped-window. Está soportado por todos los grandes fabricantes de estaciones de trabajo.
Los dos mensajes comerciales más importantes son el MOTIF de Open Software Foundation y el Open Look de
UNIX International.
Esta aplicación utiliza un protocolo a nivel de aplicación según el modelo de referencia OSI. En general se
utiliza en redes TCP/IP, por lo que el protocolo TCP es su protocolo de transporte. El puerto del protocolo TCP
siempre es x5800+N y x5900+N.
Básicamente el X-Window consta de 2 módulos que se comunican entre ellos:

1. La aplicación. Ésta obtiene una entrada del usuario, ejecuta el código correspondiente y devuelve el resultado
al usuario. En vez de leer y escribir directamente en la pantalla, la aplicación usa la interface de programación
Xlib para enviar y recibir datos hacia o desde la terminal del usuario. Este módulo de la aplicación se llama el
cliente X.
2. La terminal de usuario. Ésta se basa en un software de gestión de pantalla que envía /recibe datos hacia o
desde la aplicación y que se llama servidor X.
Funcionalidad
A continuación se describen las principales funcionalidades de esta aplicación:
- El cliente X y el servidor X en general son dispositivos distintos. Mediante el protocolo TCP/IP se
comunican entre ellos. Si es el mismo dispositivo, se usa IPC (inter-process communication) para
comunicarse entre sockets.
- Hay un solo servidor X por terminal. Varias aplicaciones cliente X se pueden comunicar con un único
servidor X. Es trabajo del servidor enviar a cada cliente la información de su aplicación.
- Es función del cliente mantener la ventana que creó. También de notificar al servidor de los cambios en su
display, pero no de actualizar la pantalla si es necesario una actualización.
- El servidor X hace el seguimiento de lo que se ve en las ventanas mediante la utilización de stacks.
- El servidor X no tiene funciones de gestión. Cada cliente es responsable de sus propias ventanas. El gestor
de ventanas es un programa del cliente X y no del servidor X.
- Las aplicaciones cliente envían mensajes de solicitud al servidor X, que contesta con un mensaje de
respuesta o con un mensaje de error.
Protocolo X-Window
El protocolo X Window System utiliza los 4 tipos de mensajes siguientes:
- Solicitud (Request). Son las solicitudes del cliente al servidor y tienen la estructura siguiente:
Major Longitud Minor Datos

donde los campos major y minor son de 1 octeto, el campo longitud de 2 octetos y el de datos es de longitud
variable.
- Respuesta (Reply). Bloque de 32 octetos.
- Error. Bloque de 32 octetos.
- Event. Bloque de 32 octetos.
Estos 3 últimos tipos son siempre enviados por el servidor al cliente.
La RFC 1013 X Window System Protocol, Version 11 contiene las especificaciones de este protocolo para
máquinas Alpha, versión 11. Sin embargo la documentación actualizada es suministrada por los propios
fabricantes.
15.8 DHCP - Dynamic Host Configuration Protocol

El protocolo DHCP se describe en las RFC 2131 - Dynamic Host Configuration Protocol y RFC 2132 - DHCP
Options and BOOTP Vendor Extensions. Es un protocolo de nivel de aplicación según el modelo de referencia
OSI. Los mensajes DHCP usan el protocolo UDP puertos 67 y 68.
El protocolo DHCP (Dynamic Host Configuration Protocol) se encarga de pasar información de configuración a
los dispositivos de una red, habitualmente de su dirección IP y de su máscara. Esta funcionalidad es exclusiva de
redes TCP/IP, es decir, en redes en que su protocolo de nivel de red sea IP.
El DHCP se basa en el protocolo BOOTP, y su funcionalidad principal es la que se conoce como asignación
automática de direcciones IP de red, aunque pueden pasarse otros parámetros de configuración.
El protocolo DHCP tiene 3 tipos de asignación de direcciones IP:

1. Configuración manual mediante la cual se pueden asignar direcciones fijas a determinados
dispositivos.
2. Configuración automática mediante la cual se asigna una dirección IP permanente a cada
dispositivo la primera vez que se conecta.
3. Configuración dinámica mediante la cual la dirección IP se asigna a cada dispositivo durante un
tiempo preestablecido. La posibilidad de trasladar un dispositivo de una red a otra y obtener
automáticamente los parámetros válidos de configuración en la nueva red, es algo muy
beneficioso en usuarios móviles. Por otro lado, con la configuración dinámica, sólo se asigna
direcciones IP a aquellos dispositivos que se conectan.
Esta última configuración es la más característica del DHCP, ya que facilita la administración de direcciones IP
de una red.
El protocolo DHCP consta de dos componentes:

1. Un protocolo que entrega los parámetros de configuración desde un servidor DHCP a un dispositivo.
2. Un mecanismo de asignación temporal o permanente de direcciones IP a los dispositivos.
Sin embargo, en la implementación del protocolo DHCP se debe tener en cuenta lo siguiente:
- el DHCP se basa en el protocolo UDP, un protocolo no fiable. En operación normal, un
dispositivo no autorizado se puede conectar a la red y obtener una dirección IP válida y su
configuración. Para prevenir esto, es posible asignar direcciones fijas a direcciones MAC
particulares, pero esto sobrecarga la administración de la red. Los servidores DHCP no
autorizados también pueden activarse con el consiguiente desbarajuste del sistema, es decir, dado
que este protocolo funciona con broadcast, no puede haber más de un servidor DHCP por
segmento de red.
- En un entorno DHCP con asignación automática o dinámica de direcciones, en general no es
posible identificar direcciones IP con clientes. En este caso, los clientes más importantes se les
pueden asignar direcciones fijas.
Estados de un dispositivo
Durante las fases de asignación de dirección IP a un dispositivo, este pasa por 6 estados:
- Inicialización. Es el momento en que el dispositivo arranca. Para detectar todos los servidores
DHCP de la red, envía un mensaje DHCPDISCOVER de tipo broadcast.
- Selección. En este estado, recibe la contestación del mensaje anterior con mensajes del tipo
DHCPOFFER. Puede recibir varias respuestas si hubiese más de un servidor DHCP.
- Solicitud. El dispositivo elige a uno de los servidores que le han contestado y a éste le envía un
mensaje de solicitud DHCPREQUEST.
Iniciali
DHCPDISCOVER
zación
DHCPNACK
Selec-
ción DHCPOFFER DHCPNACK
DHCPREQUEST
DHCPREQUEST Renew
Rebind
DHCPRELEASE
Solici- DHCPACK
DHCPACK
tud
DHCPREQUEST
DHCPACK
Bound
- Bound. A este estado se llega en el momento en que el dispositivo reconoce el DCHPREQUEST

mediante el envío de un mensaje DHCPACK. Es el estado normal de operación. Para volver al
estado de inicialización, debe enviar un mensaje DHCPRELEASE al servidor DHCP o quedar a
cero el temporizador correspondiente. También hay otros 2 temporizadores, cada uno de los
cuales cuando vencen se pasa al estado Rebind o Renovación.
- Renovación. En este estado, es necesario la renovación de la solicitud de la dirección IP al
servidor DHCP. Como en la fase inicial, consiste en enviar un mensaje DHCPREQUEST y el
consiguiente mensaje de respuesta DHCPACK.
- Rebind. Pasa a este estado, cuando estando en el estado Renovación, el servidor DHCP no
contesta. Si pasado un cierto tiempo el servidor DHCP no contesta, el dispositivo pasa al estado
de inicialización enviando un mensaje DHCPNACK, y de lo contrario pasa al estado bound
enviando un mensaje DHCPACK.

La estructura de los mensajes del protocolo DHCP es igual a los del protocolo BOOTP, por esta razón son
compatibles. Sus diferencias en cuanto a contenido son el campo flags y el opciones.
OP Tipo Longitud Saltos

ID transacción
Segundos Flags
Dirección IP del cliente
Tu dirección IP
Dirección IP del servidor
Dirección IP del enrutador
Dirección hardware del cliente
Nombre del servidor
Nombre del fichero boot
Opciones
Sus contenidos son:
- OP, 1 octeto. Si es una solicitud vale 1 y si es una respuesta vale 2.

- Tipo,1 octeto. Tipo de hardware, por ejemplo, 1 Ethernet, 6 IEEE 802
- Longitud, 1 octeto. Longitud de la dirección física de red, habitualmente 6.
- Saltos, 1 octeto. En este campo el cliente pone un cero, y su valor se incrementa cada vez que
salta un enrutador.
- ID transacción, 4 octetos. Un valor aleatorio entero que se usa para aparejar las solicitudes con las
respuestas.
- Segundos, 2 octetos. Es el número de segundos transcurridos desde el arranque del cliente.
- Flags, 2 octetos. Sólo se emplea el bit de la izquierda, para indicar si es de broadcast o no.
- Dirección IP del cliente, 4 octetos
- Tu dirección IP, 4 octetos, establecida por el servidor.
- Dirección IP del servidor, 4 octetos
- Dirección IP del enrutador, 4 octetos
- Dirección hardware del cliente, 16 octetos
- Nombre del servidor, 64 octetos
- Nombre del fichero boot, 128 octetos
- Opciones. En este caso, solo consta de 3 octetos. El primero contiene el número 53, el segundo un
1, y el tercero es el indicativo del tipo de mensaje y cuyos valores son los siguientes:
1 DHCPDISCOVER
2 DHCPOFFER
3 DHCPREQUEST
4 DHCPDECLINE
5 DHCPACK
6 DHCPNACK
7 DHCPRELEASE
15.9 BOOTP - Bootstrap Protocol

El protocolo BOOTP se especifica en la RFC 951 - Bootstrap Protocol y es un protocolo de nivel de aplicación
según el modelo de referencia OSI.
El protocolo BOOTP originalmente se desarrolló como un mecanismo que permite el arranque de dispositivos
sin disco duro, es decir, se trata de un arranque remoto. Solamente funciona en redes TCP/IP.
Permite que con una mínima información del protocolo IP sin información de su configuración, pueda empezar
el proceso de descarga del necesario código de arranque de un dispositivo. El protocolo BOOTP no define como
hacer la descarga, ya que para ello usa protocolo TFTP.
Aunque la finalidad del protocolo es ésta, el BOOTP también se usa como mecanismo de entrega de la
información de configuración a un cliente que no ha sido configurado manualmente, es decir, lo emplea el
protocolo DHCP como se ha mencionado anteriormente.
El proceso BOOTP consta de los siguientes pasos:

1. El cliente determina su propia dirección de hardware, que normalmente está en la ROM.
2. El cliente BOOTP envía su dirección hardware en un mensaje UDP al servidor, a través del
puerto 67. Si el cliente conoce su dirección IP y/o la dirección del servidor, se podrían usar para
la transmisión de los mensajes. Pero en general los clientes BOOTP no tienen ninguna
configuración IP, por lo que el cliente usa la dirección 0.0.0.0 como propia. Si el cliente no
conoce la dirección IP del servidor, usa la dirección de broadcast (255.255.255.255).
3. El servidor recibe el mensaje y busca la dirección de hardware del cliente en su fichero de
configuración, en el cual debe haber la dirección IP del mismo. El servidor llena los campos
restantes del mensaje del protocolo UDP y lo devuelve al cliente por el puerto 69 del protocolo
UDP. Para esto se utilizan uno de los 3 métodos siguientes:
a. si el cliente conoce su propia dirección IP, entonces el servidor envía los mensajes a esta
dirección.
b. Si el cliente no conoce su propia dirección IP, el servidor debe solucionarlo consultando a su

tabla ARP.
c. Si el ARP no puede resolver la situación anterior, hay 2 posibles salidas: o que el servidor
pueda actualizar su tabla ARP de otra forma o que el servidor envíe un mensaje de broadcast
para resolverlo.
4. Cuando recibe la respuesta, el cliente BOOTP grabará su propia dirección IP y empezará el

proceso de arranque previa solicitud del fichero de arranque al dispositivo que lo tiene
almacenado, que debe ser un servidor TFTP dado que para ello se emplea el protocolo TFTP.

La estructura de los mensajes del protocolo BOOTP es igual a los del protocolo DHCP, por esta razón son
compatibles. Sus diferencias en cuanto a contenido son el campo flags y el opciones.
OP Tipo Longitud Saltos

ID transacción
Segundos Sin uso
Dirección IP del cliente
Tu dirección IP
Dirección IP del servidor
Dirección hardware del cliente
Nombre del servidor
Nombre del fichero boot
Area específica del fabricante
Sus contenidos son:

- OP, 1 octeto. Si es una solicitud vale 1 y si es una respuesta vale 2.
- Tipo,1 octeto. Tipo de hardware, por ejemplo, 1 Ethernet, 6 IEEE 802
- Longitud, 1 octeto. Longitud de la dirección física de red, habitualmente 6.
- Saltos, 1 octeto. En este campo el cliente pone un cero, y su valor se incrementa cada vez que
salta un enrutador.
- ID transacción, 4 octetos. Un valor aleatorio entero que se usa para aparejar las solicitudes con las
respuestas.
- Segundos, 2 octetos. Es el número de segundos transcurridos desde el arranque del cliente.
- Dirección IP del cliente, 4 octetos
- Tu dirección IP, 4 octetos, establecida por el servidor.
- Dirección IP del servidor, 4 octetos
- Dirección IP del enrutador, 4 octetos
- Dirección hardware del cliente, 16 octetos
- Nombre del servidor, 64 octetos
- Nombre del fichero boot, 128 octetos
- Area específica del fabricante, 64 octetos.
15.10 SNMP - Simple Network Management Protocol

Simple Network Management Protocol (SNMP) es un protocolo de gestión de red basado en redes con protocolo
TCP/IP. A continuación se describe de una forma muy breve su funcionamiento, habiendo bibliografía muy
extensa y detallada de este protocolo.
El SNMP es un protocolo que funciona a nivel de aplicación según el modelo de referencia OSI y sus
especificaciones iniciales se detallan en la RFC 1157.
Se usa para la gestión de las redes de ordenadores e incluso las de sistemas de comunicaciones. Para ello, se debe
disponer de un dispositivo con una aplicación de gestión, que recoja la información de los distintos agentes
SNMP que funcionan en los dispositivos de las redes.
La transmisión de la información entre los agentes SNMP que corren en los dispositivos y la aplicación de
gestión que está instalada en el dispositivo gestor de la red se hace mediante el protocolo SNMP y una base de
datos MIB (Management Information Base) donde se almacena dicha información. Las aplicaciones de gestión
de red pueden modificar y pedir el contenido de las variables MIB (Management Information Base) definidas en
cada dispositivo de la red mediante la utilización de este protocolo SNMP. También los dispositivos de la red
pueden enviar alarmas o traps ante determinados sucesos a la aplicación de gestión de red.
Los agentes SNMP son módulos de software que corren en los dispositivos gestionados y que tienen acceso a su
base de datos MIB, y no sólo para obtener sus datos sino también para poder modificarlos, ya que muchos de
ellos son valores de contadores. Dado que estos dispositivos pueden ser de muy baja capacidad de proceso, estos
módulos son de un consumo mínimo y de aquí la necesidad de que hayan otros dispositivos que recojan esta
información, la recopilen y la gestionen.
Los tipos básicos de un mensaje de protocolo SNMP son:

- GetRequest. Mensaje de solicitud del contenido de una variable de la base de datos MIB
- GetNextRequest. Mensaje de solicitud del contenido de una variable de la base de datos MIB, que es la
siguiente en cuanto a su posición en la base de datos a la solicitada anteriormente.
- SetRequest. Mensaje de modificación del contenido de una variable de la base de datos MIB.
- GetResponse. Mensaje de respuesta a los tipos GetRequest, GetNextRequest y SetRequest.
- Trap. Mensaje que envía el agente SNMP de un dispositivo al gestor, para informarle de alguna anomalía o
suceso. Estos mensajes no exigen una respuesta por parte del gestor, por lo que no hay garantías de que éste
las reciba.
MIB – Management Information Base

Todos los objetos gestionados por el protocolo SNMP están contenidos en la MIB (Management Information
Base), que es una base de datos de tipo objetos. Tiene estructura de árbol y sus elementos equivalen a las hojas
de las ramas. Los identificadores únicamente identifican objetos MIB del árbol.
La raíz de esta tabla no tiene nombre, pero si a partir del primer nivel.
Los identificadores de más alto nivel han sido asignados por la ISO/TEC y los niveles siguientes por cada una de
las organizaciones asociadas. Así tenemos en el primer nivel : 1 para ISO, 2 para ITU/CCITT y 3 para Joint
ISO/ITU.
En el segundo nivel, el 3 es para otras organizaciones. En el cuarto nivel el 6 es para el Ministerio de Defensa de
Estados Unidos.
El árbol MIB es ampliable y así los fabricantes pueden definir sus propias ramas.
El extremo de cada rama contiene la información correspondiente a esta variable.
Así una variable se define por un conjunto de valores separados por puntos, por ejemplo, 1.3.6.1.2.1.4.20
significaría que esta variable se encuentra en la rama 20 del nivel 7, que a su vez corresponde a la rama 4 del
nivel 6, ésta a la rama 1 del nivel 5, etc.
Esta base de datos contempla la posibilidad de incluir cualquier información, ya sea genérica del dispositivo, de
cada una de sus interfaces, de los protocolos que emplea, etc. Así por ejemplo, en esta base de datos MIB, se
guardan las tablas de enrutamiento del protocolo TCP/IP incluso de los enrutadores.
Los datos más habituales que contiene son:
- estadísticas e identificación del protocolo de red
- identificación dinámica de dispositivos enlazados a la red (proceso de descubrimiento)
- datos de configuración de hardware y software
- estadísticas de uso y rendimiento de dispositivos
- mensajes de sucesos y error de dispositivos
- estadísticas de uso de aplicaciones y programas
A continuación en la figura siguiente, es la representación parcial del árbol de la base de datos MIB.
La rama iso es la de primer nivel, org es de segundo nivel, dod de tercer nivel, e internet de cuarto nivel.
De quinto nivel hay las ramas directory, mgmt, etc. De sexto nivel dentro de mgmt, está mib, y dentro de ésta
system, interfaces,at, ip,icmp, tcp, udp, etc.
SNMP Versión 2
Esta versión es una evolución de la versión 1.0 y se caracteriza porque se le han añadido características en
cuanto a una mayor seguridad, una mayor flexibilidad y al tamaño de los datos enviados.
Se desarrolla en varias RFCs, siendo las más importantes la siguientes:
- RFC 1901 - Introduction to Community-Based SNMPv2
- RFC 1902 - Structure of Management Information for Version 2 of the Simple Network
Management Protocol (SNMPv2). En ella se especifica la estructura de la base de datos SMI y el
empleo del estándar OSI ASN.1 para su definición.
- RFC 1903 - Textual Conventions for Version 2 of the Simple Network Management Protocol
(SNMPv2). Contiene la definición de las variables iniciales a contener siempre en la MIB.
- RFC 1904 - Conformance Statements for Version 2 of the Simple Network Management Protocol
(SNMPv2)
- RFC 1905 - Protocol Operations for Version 2 of the Simple Network Management Protocol
(SNMPv2). Definición de las operaciones de envío y recepción de mensajes del protocolo SNMP.
- RFC 1906 - Transport Mappings for Version 2 of the Simple Network Management Protocol
(SNMPv2). Contiene las especificaciones en cuanto a la relación del protocolo SNMP que
funciona a nivel de aplicación, con los protocolos de nivel de transporte y red que coexisten con
él.
- RFC 1907 - Management Information Base for Version 2 of the Simple Network Management
Protocol (SNMPv2). Definición de las MIB para la versión 2 del protocolo SNMP.
- RFC 1909 - An Administrative Infrastructure for SNMPv2
- RFC 1910 - User-Based Security Model for SNMPv2. Contiene las especificaciones referidas a la
seguridad del protocolo
También se añaden 2 nuevos comandos :
- InformRequest. Este mensaje sirve para que desde una aplicación se pueda solicitar una
información a transmitir a otra aplicación.
- GetBulkRequest. En la versión 1, solamente podía solicitarse la información de una variable.
Ahora la versión 2 con este nuevo comando permite solicitar el contenido de un bloque de
variables. Su especificación se recoge en la RFC 1905.
En esta versión 2 se contempla la posibilidad de incluir autenticación en los mensajes del protocolo SNMP. En la
versión 1 ya se emplea una clave de acceso pero su seguridad es mínima.
SNMP Versión 3
Esta versión se preocupa esencialmente del área de seguridad y del control remoto. Su introducción se explica en
la RFC 2570 – Introduction to Version 3 of the Internet-standard Network Management Framework.
Un mayor detalle de las mejoras en esta versión están contenidas en:
- RFC 2575 - View-based Access Control Model (VACM) for the Simple Network
Management Protocol (SNMP).
- RFC 2572 - Message Processing and Dispatching for the Simple Network Management
Protocol (SNMP).
15.11 LDAP - Lightweight Directory Access Protocol

El protocolo LDAP (Lightweight Directory Access Protocol) es un método estándar y abierto que permite el
acceso y la actualización de la información de un directorio. Se entiende como directorio, la información que
describe los usuarios, aplicaciones, ficheros, impresoras y otros recursos compartidos de una red. Para ello debe
estar implementado no solo en los servidores de directorio sino también en los clientes que acceden a ellos.
Es un protocolo que funciona a nivel de aplicación según el modelo de referencia OSI y cada día es soportado
por un mayor número de fabricantes.
Historia y referencias
En 1988, la CCITT creó el estándar X.500, con el uso del protocolo DAP. Sin embargo poco después fue
incorporada en Internet, una versión ligera que se le ha llamado LDAP.
Las especificaciones básicas actuales del protocolo LDAP se encuentran en la RFC 1777 y siguientes:
- RFC 1778 — The String Representation of Standard Attribute Syntaxes
- RFC 1779 — A String Representation of Distinguished Names
- RFC 1959 — An LDAP URL Format
- RFC 1960 — A String Representation of LDAP Search Filters
- Understanding LDAP de IBM (SG24-4986-00)
Más adelante apareció la actual versión 3 del protocolo LDAP, cuyas especificaciones se definen en la RFC
2251 Lightweight Directory Access Protocol (v3) y sus mejoras y ampliaciones se encuentran en:
- RFC 2252 — Lightweight Directory Access Protocol (v3) :Attribute Syntax Definitions
- RFC 2253 — Lightweight Directory Access Protocol (v3) :UTF-8 String Representation of
Distinguished Names
- RFC 2254 — The String Representation of LDAP Search Filters
- RFC 2255 — The LDAP URL Format
Descripción
LDAP es un protocolo de comunicación entre un cliente y un servidor de directorio, pero no se ha definido una
interface de programación para el cliente. El documento LDAP Application Program Interface define unas
API en lenguaje C para acceder a un directorio de un servidor que usa LDAP Versión 2. Sus especificaciones se
detallan en la RFC 1823 – The LDAP Application Program Interface.
El protocolo LDAP define el contenido de los mensajes intercambiados entre un cliente LDAP y un servidor
LDAP. Este servidor LDAP no tiene porque ser el dispositivo donde está físicamente el directorio al que se
quiere acceder, ya que en principio es un puente entre el cliente y el dispositivo donde está almacenada la
información.
Los mensajes especifican las operaciones solicitadas por el cliente (buscar, modificar, borrar, etc.), las respuestas
del servidor y el formato de los datos transportados en los mensajes. Los mensajes LDAP funcionan en redes
TCP/IP.
Es un protocolo orientado a conexión, razón por la cual hay una primera fase de establecimiento de la conexión,
una segunda de transmisión de los datos y una tercera de cierre de la conexión entre el cliente y el servidor.
La interacción general entre un cliente LDAP y un servidor LDAP se hace de la forma siguiente:
- El cliente establece una sesión con un servidor LDAP. Esto se conoce como binding al servidor.
El cliente especifica su nombre o su dirección IP y el número del puerto TCP por donde va a
escuchar el servidor LDAP. El cliente puede suministrar un nombre de usuario y contraseña para
su autenticación con el servidor, o se puede establecer una sesión anónima con derechos de
acceso por defecto. El cliente y el servidor también pueden establecer una sesión con métodos de
seguridad más fuertes tales como encriptación de datos.
- El cliente a continuación realiza las operaciones de gestión de datos del directorio. El protocolo
LDAP ofrece posibilidades de lectura y escritura. Esto permite que la información del directorio
sea gestionada como se quiera y ante cualquier solicitud. El protocolo LDAP también soporta
búsquedas en el directorio con cualquier criterio especificado por el usuario. Buscar es una
operación muy frecuente en LDAP. Un usuario puede especificar en que parte del directorio se
debe hacer la búsqueda y que información se debe devolver.
- Cuando el cliente acaba con sus solicitudes, se cierra la sesión con el servidor LDAP. A esto
también se le conoce como unbinding.
Aunque no está definido en el protocolo LDAP ni es su arquitectura, hay una API que permite que las
aplicaciones puedan interactuar fácilmente con los servidores LDAP. Esta API se puede considerar una
extensión de la arquitectura LDAP.
El protocolo LDAP define operaciones para acceder y modificar contenidos del directorio tales como:
- Búsqueda según un criterio dado por el usuario
- Añadir una entrada
- Borrar una entrada
- Modificar una entrada
- Modificar el nombre principal o relativo de una entrada (mover)
- Comparar una entrada
Modelos LDAP
El protocolo LDAP se basa en 4 modelos, que son los siguientes:
1. Información. Este modelo consiste en describir la estructura de la información almacenada en un
directorio LDAP.
2. Naming. En este caso el modelo describe como se organiza e identifica la información en un
directorio LDAP.
3. Funcional. Este modelo describe qué operaciones se pueden realizar con la información
almacenada en un directorio LDAP.
4. Seguridad. Este modelo describe como se puede proteger en cuanto a accesos no autorizados, la
información en un directorio LDAP.
Funcional
Las operaciones del protocolo LDAP se pueden agrupar en tres categorías:
- Query. Consiste en las operaciones de búsqueda y comparación al directorio.
- Update. Son las operaciones de añadir, borrar y modificar la información del directorio.
- Autenticación. Son las operaciones que delimitan los derechos de acceso al directorio.
Seguridad
En cuanto a la seguridad, el protocolo LDAP contempla los aspectos de autenticación, integridad y
confidencialidad, pero no el de autorización. Así hay varios métodos, siendo los más importantes:
- Sin autenticación. Este método solo debería usarse cuando la seguridad de los datos no sea un
hito, es decir, no se requieran permisos de control de acceso especiales. El servidor LDAP
entonces asume una sesión de usuario anónima y emplea para el control de acceso el definido
para este tipo de conexiones.
- Con autenticación básica. El mecanismo de seguridad en LDAP se negocia cuando se establece la
conexión entre cliente y servidor. Junto a la opción de no usar autenticación, el mecanismo de
seguridad más simple es el básico, que también se usa en protocolos de Internet como el HTTP.
- SASL (Simple Authentication and Security Layer). SASL es un marco que permite añadir
mecanismos de autenticación adicionales a los protocolos orientados a conexión. Esta facilidad se
ha añadido en la versión 3 del protocolo LDAP. Aunque los conceptos de SASL soportan
múltiples mecanismos, un producto en particular de un fabricante no tiene porque tenerlos todos.
Los mecanismos SSL o TLS se soportan de forma habitual y también el Kerberos, que utiliza el
DES (Data Encryption Standard) para la encriptación.
Convención de denominación
En el caso del protocolo LDAP se recomienda la convención de nombres de Internet que está especificada en la
RFC 1779 y consiste en lo que se llama nombres distinguidos.
Cada tipo de nombre distinguido (DN) se corresponde a una determinada identificación, como por ejemplo CN,
nombre común.
Los nombres distinguidos relativos, cuyo código es RDN, son parte de un nombre distinguido completo.
LDAP URLs
Las URLs (Uniform Resource Locators) permiten de una forma estándar referirnos a los recursos de Internet o
dentro de una red TCP/IP. Un ejemplo habitual es http://www.ibm.com/Products/index.html de una página web.
En este caso, http es el protocolo utilizado por el navegador, y www.ibm.com es el nombre del host y
Products/index.html el nombre del fichero del host. Usando esta URL, un navegador puede acceder a este
fichero y visualizarlo. Las URLs también definen el protocolo que se va a utilizar.
Desde que LDAP es un protocolo importante en Internet, se han definido un formato URL para recursos LDAP.
La RFC 2255 (The LDAP URL Format) describe este formato. Las URLs para LDAP empiezan con ldap:// o
ldaps:// si el servidor LDAP se comunica usando SSL.
La sintaxis de un URL LDAP es:
ldap[s]://[<host>[:<port>]] [/ [<dn> [? [<attributes>] [? [<scope>] \ [? [<filter>] [? <extensions>]]]]]]
donde:
ldap[s] ldap especifica una conexión usando el protocolo LDAP, y ldaps especifica una conexión SSL LDAP.
host El nombre o dirección IP del servidor LDAP. Host y port se pueden omitir.
port Número de puerto del servidor LDAP. Por defecto es el puerto 389 para LDAP y 636 para LDAPS.
dn El nombre principal usado como base de la búsqueda.
attributes Una lista de atributos separados por coma que sirve para dar formato al resultado de la búsqueda. Si no
se especifica nada, se visualizan todos.
scope El ámbito de la búsqueda, que por defecto es base, pero también puede ser one o rsub.
filter El filtro de búsqueda a aplicar
extensions Con esto se permite definir extensiones al URL de LDAP.
Protocolos de WAN 92
Capítulo 16. Protocolos de WAN
Dentro de este apartado se contemplan aquellos protocolos que se utilizan en el ámbito de las WAN. Las WAN
son entornos complejos que incorporan múltiples medios, múltiples protocolos, e interconexión con otras redes,
como Internet.
Los protocolos de WAN tienen funcionalidades de los tres primeros niveles, físico, enlace y red, según el
Los protocolos de comunicaciones más utilizados actualmente en las redes de datos son : RDSI, Frame Relay,
ADSL, ATM y X25
Relación con el modelo OSI

El modelo básico de referencia OSI es un modelo de capas que representa muy bien la interacción de los
protocolos en una red sin líneas de comunicaciones, es decir, una LAN (Local Area Network).
Sin embargo, cuando estamos en una WAN, es decir, en una red con líneas de comunicaciones, nos encontramos
que este modelo no se adapta exactamente. La razón es que hay una superposición de niveles, es decir, entre los
protocolos de LAN y los de WAN.
Así los protocolos de nivel 3 de las redes de datos tales como el IP y el IPX se transportan sobre otros protocolos
de red tales como el X.25, Frame Relay y ATM.
En la descripción de cada protocolo se irá detallando esta problemática.
Tipos de transmisión
Un concepto importante en WAN es el tipo de transmisión, es decir, como se transporta la información. Los
tipos más importantes son:
- Simplex. Se trata de una transmisión en un solo sentido y por tanto poco utilizado.
- Half duplex. Este tipo de transmisión consiste en enviar la información en los 2 sentidos en forma
alternada. En este caso hay un tiempo denominado turnover, necesario para permitir el cambio de
sentido. Es una transmisión muy utilizada porque tiene una buena relación entre prestaciones y
complejidad.
- Full duplex. En este caso, la transmisión fluye en los 2 sentidos de forma simultánea y puede ser a
2 ó 4 hilos.
Tipos de comunicaciones
Se pueden agrupar en dos tipos de opciones de enlaces WAN disponibles: líneas dedicadas y conexiones
conmutadas. A su vez las conexiones conmutadas, pueden ser conmutadas por circuito o conmutadas por
mensajes.
Las líneas dedicadas normalmente se utilizan para transportar datos, voz y, ocasionalmente, vídeo. En el diseño
de red de datos, las líneas dedicadas generalmente suministran conectividad de núcleo o de backbone entre sitios
o campus importantes, así como también conectividad LAN a LAN. Las líneas dedicadas también se denominan
enlaces punto a punto porque la ruta establecida es permanente y fija para cada red remota a la que se llega a
través de las instalaciones de la portadora.
La conmutación por mensajes es un método de conmutación WAN en el que los dispositivos de red comparten
un circuito virtual permanente (PVC), que es similar al enlace punto a punto para transportar mensajes desde un
origen hasta un destino a través de una red portadora. Las redes conmutadas por mensaje tradicionalmente han
ofrecido mayor flexibilidad y uso más eficiente del ancho de banda de red que las redes conmutadas por circuito.
La conmutación por circuito es un método de conmutación WAN en el que se establece, mantiene y termina un
circuito físico dedicado a través de una red portadora para cada sesión de comunicación. La conmutación por
circuito, que se utiliza ampliamente en las redes de las compañías telefónicas, opera de forma similar a una
llamada telefónica normal. RDSI es un ejemplo de una tecnología WAN conmutada por circuito. Las conexiones
conmutadas por circuito de un sitio a otro se activan cuando son necesarias y generalmente requieren poco ancho
de banda. Las conexiones conmutadas por circuito se utilizan principalmente para conectar usuarios remotos y
usuarios móviles a las LAN corporativas. También se utilizan como líneas de respaldo para circuitos de
velocidades más altas, como Frame Relay y otras líneas dedicadas.
Esquema
Cuando se explicó el concepto de WAN, ya se dijo que consistía en un conjunto de LANs conectadas entre sí
mediante líneas de comunicaciones.
De acuerdo con la figura, supongamos ahora que el ordenador A quiere transmitir información al ordenador B
que pertenecen a redes distintas conectadas entre si mediante una línea de comunicaciones.. El hecho de que hay
una línea de comunicaciones entre ellos, significa que pertenecen a distintas LANs, y su conexión se establece a
partir de unos enrutadores.
Ordenador A Ordenador B
Nivel 5,6,7 Nivel 5,6,7
Nivel 4 Nivel 4
Nivel 3 Nivel 3
Nivel 2 Nivel 2
Nivel 2 Nivel 2 Nivel 2 Nivel 2
Nivel 3 Nivel 3 Nivel 3 Nivel 3
Enrutador 1 Enrutador 2
Supongamos que se trata de una red TCP/IP, con lo que el mensaje completo sale del ordenador A y llega al
enrutador 1. Entra por la interface de LAN, y llega al nivel 3 del mismo, habitualmente protocolo IP. A
continuación el enrutador 1, mediante sus tablas de enrutamiento, decide que debe ser reenviado por la interface
WAN. Por ello lo pasa al protocolo de nivel 3 de WAN, este lo pasa a nivel 2 y a continuación al nivel físico.
Así el mensaje de LAN es encapsulado en los protocolos WAN (PPP, X.25, RDSI, ADSL, Frame Relay, ATM).
Cuando el mensaje llega al enrutador 2, se debe deshacer la operación anterior para que llegue al ordenador B.
Cada enrutador debe tener como mínimo 2 interfaces:
- una de LAN, con tarjeta de red Ethernet o Token Ring y
- otra de WAN, que corresponde a una interface serie y que es a través de la que se conecta a la
línea de comunicaciones, sea del tipo que sea, es decir, puede ser módem, adaptador RDSI,
adaptador ADSL, línea Frame Relay, X.25, etc.
Entonces por la parte del interface LAN, los protocolos son a nivel 2, Ethernet o Token Ring. A nivel 3 y 4 lo
habitual TCP/IP y a nivel aplicación los que se necesiten.
16.1 Sistemas de comunicaciones

Todos los sistemas de comunicaciones se agrupan en dos tecnologías:
 analógica y
 digital
En el ámbito analógico, se emplean los dispositivos conocidos como modelos. Estos dispositivos son los que
convierten las señales digitales de las redes en señales analógicas y viceversa. En este caso los protocolos, que
siempre son para transmisiones digitales, entre los dispositivos de LAN y el módem que se emplean son el SLIP
y el PPP.
En el ámbito digital, cada sistema de comunicaciones tiene sus propios protocolos, que son los que de forma
resumida se explican en las páginas siguientes. Los sistemas digitales más habituales son RDSI, Frame Relay,
ADSL, ATM, X.25 y SMDS.
16.2 Protocolos de nivel físico

Los protocolos de la capa física de las WAN describen cómo proporcionar conexiones eléctricas, mecánicas,
operacionales y funcionales para los servicios WAN. La mayoría de las WAN requieren una interconexión
proporcionada por el proveedor de servicios de comunicaciones, una portadora alternativa como un proveedor de
servicios de Internet o una entidad de administración postal, de telégrafos y teléfonos (PTT).
En cuanto a conectores los más utilizados son :

- el DB9 y DB25 para conexiones al puerto serie del PC. Es habitual en líneas telefónicas
analógicas.
- el RJ11 para las líneas telefónicas de voz
- el V35 en el caso de Frame Relay
- G.703 y X.21 entre otros.
En cuanto a los tipos de cables, los más habituales son

- el cable de 2 hilos
- el cable coaxial y
- la fibra óptica
El nivel físico de la WAN también describe la interfaz entre el DTE y el DCE. Normalmente el DCE es el
proveedor del servicio, mientras que el DTE es el dispositivo conectado.
Varios estándares del nivel físico definen las normas que rigen la interfaz entre el DTE y el DCE, siendo los más
importantes los siguientes:
 EIA/TIA-232: Estándar de la interfaz del nivel físico, desarrollado por EIA y TIA, que soporta circuitos no
balanceados a velocidades de señal de hasta 64 kbps. Se asemeja bastante a la especificación V.24. Su
antiguo nombre era RS-232. Este estándar se utiliza desde hace varios años.
 EIA/TIA-449: Interfaz popular del nivel físico desarrollado por EIA y TIA. Esencialmente, es una versión
más veloz (hasta 2 Mbps) de EIA/TIA-232, que admite tendidos de cable más extensos.
 EIA/TIA-612/613: Estándar que describe la Interfaz serial de alta velocidad (HSSI), que suministra acceso a
servicios a velocidades de T3 (45 Mbps), E3 (34 Mbps) y red óptica síncrona (SONET) STS-1 (51,84
Mbps). La velocidad real de la interfaz depende de la DSU externa y del tipo de servicio al que está
conectada.
 V.24: Estándar de UIT-T para una interfaz del nivel físico entre el DTE y el DCE.
 V.35: Estándar de UIT-T que describe un protocolo del nivel físico, síncrono, que se utiliza para las
comunicaciones entre un dispositivo de acceso de red y una red de mensajes. V.35 es el estándar de uso más
generalizado en los Estados Unidos y en Europa, y se recomienda para velocidades de hasta 48 kbps.
 X.21: Estándar de UIT-T para la comunicación serial a través de líneas digitales síncronas. El protocolo
X.21 se utiliza principalmente en Europa y Japón.
 G.703: Especificación mecánica y eléctrica de UIT-T para conexiones entre el equipo de la compañía
telefónica y el DTE que utiliza conectores BNC (British Naval Conector) y que opera a velocidades de datos
E1.
 EIA-530: Dos implementaciones eléctricas de EIA/TIA-449: RS-422 (para transmisión balanceada) y RS-
423 (para transmisión no balanceada).
16.3 Protocolos de enrutamiento

El concepto de enrutamiento aparece en el momento de que una red de datos está formada por varios segmentos,
siendo cada uno de ellos un dominio de broadcast. La razón de haber más de un segmento puede ser:
- porque el número de dispositivos a conectar en un segmento es limitado
- por dispersión geográfica, lo que obliga a disponer de líneas de comunicaciones entre los distintos
segmentos.
En estos casos, si 2 dispositivos que están en segmentos distintos se quieren transmitir mensajes, necesitan que
estos viajen a través de 1 o varios dispositivos que conectan a los segmentos entre si. A estos dispositivos se les
denomina enrutadores, y también puertas de enlace o pasarelas.
Así si observamos la figura, si el dispositivo origen envía un mensaje a la puerta de enlace de su segmento, este
mensaje será redirigido por este dispositivo en la dirección que por sus tablas de enrutamiento conoce. Este
funcionamiento es lo que se llama enrutamiento.
LAN WAN LAN

Origen Destino
1 2
Las tablas de enrutamiento de los enrutadores es exactamente igual a la que se ha explicado en el apartado
correspondiente al protocolo IP, teniendo en cuenta que en la actualidad este protocolo de red es el habitual en
las redes.
Por ejemplo supongamos un enrutador con 3 interfaces de las características siguientes:

- una interface de LAN, protocolo Ethernet, y dirección IP 192.168.0.1 y máscara 255.255.255.0
- una interface de tipo serie conectada a una línea RDSI mediante el adaptador correspondiente. Su
dirección IP es 212.0.1.1 y máscara 255.255.255.0
- una interface de tipo serie conectada a una red punto a punto con su módem correspondiente. Su
dirección IP es 202.2.3.1 y máscara 255.255.255.0
192.168.0.1
Enrutador 202.2.3.1
212.0.1.1
En principio su tabla de enrutamiento debe tener las entradas correspondientes a estas tres interfaces, cada una
conectada a su red y además su dirección interna o de localhost 127.0.0.1. Así contendrá

127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1
192.168.0.0 255.255.255.0 192.168.0.1 192.168.0.1
192.168.0.1 255.255.255.255 127.0.0.1 127.0.0.1
202.2.3.0 255.255.255.0 202.2.3.1 202.2.3.1
202.2.3.1 255.255.255.255 127.0.0.1 127.0.0.1
212.0.1.0 255.255.255.0 212.0.1.1 212.0.1.1
212.0.1.1 255.255.255.255 127.0.0.1 127.0.0.1
Supongamos que por la interface Ethernet llega un mensaje con dirección destino 202.2.3.50. En este caso el
enrutador aplicando las reglas que se explican en el apartado del protocolo IP en cuanto al manejo de las tabla de
enrutamiento, resulta que debe enviar este mensaje a la interface de dirección 202.2.3.1 ya que pertenece a la
misma red. Esta función también se llama de conmutación.
Sin embargo si la dirección destino no pertenece a ninguna red de sus interfaces, por ejemplo, la 210.4.5.100, el
dispositivo no procesa este mensaje. Ahora bien, si añadiesemos una entrada a la tabla de enrutamiento tal como

210.4.5.100 255.255.255.0 212.0.1.1 212.0.1.1
Entonces, este mensaje sería reenviado por la interface de dirección 212.0.1.1 del enrutador. De esta forma un
mensaje con protocolo IP o similar se puede dirigir por la red hasta alcanzar su destino.
Por tanto un protocolo de enrutamiento define el conjunto de reglas utilizadas por un enrutador cuando se
comunica con los enrutadores vecinos en lo que concierne a sus tablas de enrutamiento. Por ejemplo, un
protocolo de enrutamiento describe:
 Cómo se envían las actualizaciones de las tablas de enrutamiento
 Qué conocimiento contienen esas actualizaciones
 Cuándo enviar ese conocimiento
 Cómo ubicar a los destinatarios de las actualizaciones
Los protocolos de enrutamiento corresponden al nivel de red del modelo OSI, siendo los más utilizados lo
siguientes:
- GGP Gateway to Gateway Protocol
- RIP Routing Information Protocol
- IGRP Cisco Inter-Gateway Routing Protocol
- E-IGRP Cisco Enhanced Protocol
- OSPF Open Shortest Path First Protocol
- EGP Exterior Gateway Protocol
- BGP Border Gateway Protocol
- GRE Generic Routing Encriptation
Objetivos
 Ruta óptima : Ruta óptima se refiere a la capacidad del protocolo de enrutamiento para seleccionar la mejor
ruta. La mejor ruta depende de las métricas y de las asignaciones de valor de la métrica que se usan para
hacer el cálculo. Por ejemplo, un protocolo de enrutamiento puede usar el número de saltos y el retardo,
pero puede asignar un valor más importante al retardo en el cálculo.
 Simplicidad y eficiencia : El diseño de los protocolos de enrutamiento también busca que sean lo más
simples y eficientes que sea posible. La eficiencia es particularmente importante cuando el software que
implementa el protocolo de enrutamiento se debe ejecutar en un computador con recursos físicos limitados.
 Solidez: Los protocolos de enrutamiento deben ser sólidos. En otras palabras, deben ejecutarse
correctamente aún ante circunstancias inusuales o imprevistas, tales como fallas del hardware, condiciones
de carga elevada e implementaciones incorrectas. Como los enrutadores están ubicados en los puntos de
unión de la red, pueden provocar problemas considerables cuando fallan. Los mejores protocolos de
enrutamiento a menudo son aquellos que con el tiempo han demostrado su eficiencia y que se han
mantenido estables bajo una serie de diferentes condiciones de la red.
 Convergencia rápida: Los protocolos de enrutamiento deben convergir rápidamente. Convergencia es la
velocidad y la capacidad de un grupo de dispositivos de red que ejecutan un protocolo de enrutamiento
específico para concordar acerca de la topología de una red luego de que se produce un cambio en dicha
topología. Cuando se produce un problema en la red, tal como un cambio en la topología de la red, que hace
que las rutas dejen de funcionar o queden disponibles, los enrutadores distribuyen mensajes de actualización
de enrutamiento. Los mensajes de actualización de enrutamiento se envían a las redes, y de tal modo hacen
que las rutas óptimas se vuelvan a calcular y eventualmente hacen que todos los enrutadores concuerden en
estas rutas. Los protocolos de enrutamiento que convergen lentamente pueden provocar bucles de
enrutamiento o la interrupción del servicio de la red.
 Flexibilidad: Los protocolos de enrutamiento también deben ser flexibles. En otras palabras, deben
adaptarse de forma rápida y precisa a una serie de diferentes circunstancias de la red. Por ejemplo,
supongamos que un segmento de red deja de funcionar. Varios protocolos de enrutamiento rápidamente
seleccionan la segunda mejor ruta para todas las rutas que normalmente utilizan un segmento determinado.
Los protocolos de enrutamiento se pueden programar para adaptarse a los cambios en el ancho de banda de
la red, el tamaño de la cola del enrutador, el retardo de la red y otras variables.
16.3.1 Conceptos
Enrutamiento estático
El enrutamiento estático consiste en la configuración manual de las rutas, es decir, las tablas de enrutamiento se
rellenan manualmente por un administrador. Esto significa que el camino que deben seguir los mensajes de un
segmento a otro se establece por criterios no automáticos.
Su principal inconveniente es que conlleva una pesada carga de trabajo a los administradores de la red, porque la
entrada y mantenimiento de estos datos es delicado y un error puede ser caro, ya que se pueden canalizar los
mensajes por líneas de comunicaciones más caras.
El enrutamiento estático también tiene el inconveniente de que la accesibilidad de la red no depende en este caso
del estado de la misma. Si una línea de comunicación se avería, las rutas estáticas permanecen fijas, por lo que el
tráfico intenta pasar por una línea rota y por tanto no puede pasar. A lo mejor hay rutas alternativas y no es
posible su uso si el administrador no cambia las rutas en la tabla de enrutamiento, de todos y cada uno de los
enrutadores afectados.
Con el fin de simplificar la tarea de los administradores de la red, normalmente la configuración manual de rutas
no se realiza en el caso de redes grandes. Sin embargo, hay circunstancias que aconsejan un enrutamiento
estático. Por ejemplo, las rutas estáticas se pueden usar :
- para definir la ruta por defecto o una ruta no detectable en la red,
- complementar o sustituir protocolos de puertas de enlace exteriores,
- porque el tráfico de enrutamiento es caro,
- porque las políticas de enrutamiento son complejas, etc.
Enrutamiento dinámico
El enrutamiento dinámico al contrario del anterior, determina el establecimiento de las rutas en las tablas de
enrutamiento de forma automática y estas rutas se adaptan a los cambios de estado de las líneas de
comunicaciones.
El enrutamiento dinámico utiliza distintos algoritmos que permiten a los enrutadores intercambiar información
sobre rutas y enlaces, con lo que se obtienen mejores caminos para que los mensajes lleguen a sus destinos.
Métricas
Con el fin de optimizar las rutas, se emplea lo que se llaman las métricas y consiste en un valor que
normalmente, cuanto menor sea, mejor será la ruta, es decir, desde el punto de vista del usuario es más deseable.
Los valores de la métrica se calculan a partir de una fórmula con unos parámetros que afectan a un conjunto de
variables. Depende del algoritmo empleado y del usuario, se emplean más o menos variables, y sus pesos
también los establece el usuario.
Las variables más utilizadas en el cálculo de las métricas en los algoritmos de enrutamiento son las siguientes:
- Ancho de banda: Capacidad de datos de un enlace. Por ejemplo, normalmente un enlace Ethernet
de 10 Mbps es preferible a una línea arrendada de 64 kbps.
- Retardo: La cantidad de tiempo que se requiere para mover un mensaje desde el origen hasta el
destino.
- Carga: Cantidad de actividad en un recurso de red, como, por ejemplo, un enrutador o un enlace.
- Confiabilidad: Generalmente se refiere al índice de error de cada enlace de red.
- Número de saltos: Cantidad de enrutadores por los que debe pasar un mensaje.
- Tictacs: Retardo en un enlace de datos que utiliza los tictacs de reloj PC de IBM
(aproximadamente 55 milisegundos).
- Costo: Valor arbitrario, generalmente basado en el ancho de banda, el coste y otras mediciones,
asignado por un administrador de la red.
Protocolos de enrutamiento interior y exterior

Para poder establecer esta distinción, primero debemos conocer que se entiende por Sistema Autónomo (AS). Se
trata de un conjunto de redes bajo una administración común que comparten una estrategia de enrutamiento
común. Los sistemas autónomos se subdividen en áreas. Un sistema autónomo puede ser asignado un número de
16 bits exclusivo por la IANA. Por ejemplo, Cisco es un sistema autónomo, IBM es otro sistema autónomo.
Los protocolos de enrutamiento exterior son los que se utilizan para las comunicaciones entre sistemas
autónomos. Los protocolos de enrutamiento interior se utilizan dentro de un mismo sistema autónomo.
Los protocolos de enrutamiento interno más habituales son:
- RIP: Protocolo de enrutamiento vector distancia.

- IGRP: Protocolo de enrutamiento vector distancia, propietario de Cisco.
- OSPF: Protocolo de enrutamiento de estado de enlace.
- IGRP Mejorado: Protocolo de enrutamiento híbrido balanceado.
De enrutamiento externo, el protocolo más empleado es el BGP4.
16.3.2 Algoritmos de enrutamiento
La mayoría de los protocolos de enrutamiento se pueden clasificar dentro de uno de dos tipos básicos: vector de
distancia o estado de enlace El protocolo de enrutamiento con la utilización del algoritmo de vector de distancia
determina la dirección (vector) y distancia hacia cualquier enlace en la red. Un protocolo que emplee el
algoritmo de estado de enlace dispone en sus tablas de enrutamiento una representación de la topología exacta de
toda la red. Un tercer tipo de protocolo de enrutamiento, el protocolo híbrido balanceado, combina aspectos de
los algoritmos de estado de enlace y de vector de distancia.
Algoritmo de vector de distancia

El principio de este tipo de algoritmo es muy simple. En principio se entiende por distancia, el número de
segmentos que tiene que atravesar un mensaje para llegar a su destino.
Cada enrutador conoce la distancia entre él y cada uno de los destinos a donde dirigir los mensajes y esta
información la almacena en una tabla llamada de vector de distancia. Esta tabla consiste en un conjunto de
destinos (vectores) y costes (distancias) necesarios para llegar al destino. En cada momento, en función del
estado de la red y su tráfico, se calculan los saltos y se almacenan los más bajos. En este algoritmo como única
variable se emplea la cantidad de saltos de enrutadores, y en este caso salto es sinónimo de distancia.
Las distancias en las tablas se calculan en función de los datos que les suministran los enrutadores vecinos,
porque todos los enrutadores envían sus tablas de vector de distancia solamente a sus enrutadores vecinos de
forma periódica. La secuencia de operaciones para hacer esto es la siguiente:
- Cada enrutador inicializa su tabla de vector de distancia con ceros, uno para los enrutadores
vecinos e infinito para los demás.
- Cada enrutador periódicamente (normalmente 30 segundos) transmite su tabla de vector de
distancia a los enrutadores vecinos. También la envía cuando sabe de un cambio de estado de
alguna línea o dispositivo.
- Cada enrutador recalcula su tabla de vector de distancia en función del contenido de las tablas
recibidas de los enrutadores vecinos.
El algoritmo de vector de distancia produce una tabla de enrutamiento estable durante un período que varía en
función del número de enrutadores vecinos. En grandes redes, este tiempo de actualización puede que sea
demasiado grande para que sea útil.
Las tablas de enrutamiento se recalculan cuando se recibe una tabla de vector de distancia de un enrutador
vecino o cuando hay un cambio de estado de una línea a los enrutadores vecinos.
Cuando un enrutador cambia la métrica de una ruta en una tabla de vector de distancia, debe enviar la tabla
modificada inmediatamente a los enrutadores vecinos. Ésta es la forma de propagar los cambios en la red
inmediatamente independientemente de sus períodos de actualización.
La principal ventaja de este método es su facilidad de implementación pero sus desventajas son:
- La inestabilidad causada por las rutas que dejan de existir y se mantienen durante cierto tiempo en
las tablas de enrutamiento.
- Los largos tiempos de convergencia en las redes grandes.
- La limitación en el número de saltos.
Los inconvenientes son:
- Las tablas de vector de distancia se transmiten aunque no hayan cambios.
- Las tablas contienen todas las entradas posibles de la red, lo que penaliza de forma importante los
retardos de los mensajes en el caso de grandes redes.
Bucles de enrutamiento
Los bucles de enrutamiento se pueden producir si la convergencia lenta de una red en una nueva configuración
hace que las entradas de enrutamiento sean incorrectas.
Así también a este efecto se le llama conteo al infinito, porque hace que los mensajes recorran la red
continuamente, a pesar del hecho fundamental de que la red destino está caída. Mientras los enrutadores cuentan
al infinito, la información no válida permite que se produzca un bucle de enrutamiento.
Si no se toman medidas para detener el proceso, el vector de distancia (métrica) de número de saltos se
incrementa cada vez que el mensaje atraviesa otro enrutador. Estos mensajes recorren la red formando bucles
debido a la información incorrecta de las tablas de enrutamiento.
Con el fin de evitar estos inconvenientes, se han incorporado alguna de las siguientes funciones:
- Horizonte dividido (Split horizon)
- Temporizadores de espera (hold down)
- Poison reverse y
- Triggered updates
Horizonte dividido
Un posible de un bucle de enrutamiento es cuando información incorrecta que se ha enviado a un enrutador se
contradice con la información correcta que éste envió.
Así la técnica del horizonte dividido hace que un enrutador no propague su información hacia el enrutador que
ya se la había enviado. Al actuar de esta forma, si una parte de las red ha quedado aislada, rápidamente los
enrutadores lo detectan y actualizan su información.
El horizonte dividido reduce así la cantidad de información de enrutamiento incorrecta y reduce también el gasto
de enrutamiento.
Temporizadores de espera (Hold down).

Esta técnica obliga a un enrutador a ignorar la información de una red cuando ha transcurrido un tiempo
predeterminado después de recibir un dispositivo que no contesta. Normalmente son 60 segundos.
Esta técnica funciona de la siguiente manera:
1. Cuando un enrutador recibe una actualización por parte de un vecino indicando de que una red previamente
accesible ahora se encuentra inaccesible, el enrutador marca la ruta como inaccesible e inicia un temporizador de
espera. Si en algún momento, antes de que expire el temporizador de espera, se recibe una actualización por
parte del mismo vecino indicando que la red se encuentra nuevamente accesible, el enrutador marca la red como
accesible y elimina el temporizador de espera
2. Si llega una actualización desde un enrutador vecino distinto con una métrica más conveniente que la
originalmente registrada para la red, el enrutador marca la red como accesible y elimina el temporizador de
espera.
3. Si en algún momento antes de que expire el temporizador de espera se recibe una actualización de un
enrutador vecino diferente con una métrica inferior, se ignorará la actualización. El ignorar una actualización con
una métrica inferior mientras el temporizador de espera se encuentra activado, permite ganar más tiempo para
que el conocimiento de un cambio perjudicial se propague a través de toda la red.
Actualizaciones inversas (Poison Reverse Updates)

Mientras que los horizontes divididos deben prevenir los bucles de enrutamiento entre enrutadores adyacentes,
las actualizaciones inversas tienen como objetivo impedir que se produzcan bucles de enrutamiento más grandes.
El aumento en las métricas de enrutamiento generalmente indican que hay bucles de enrutamiento. Luego se
envían actualizaciones inversas para eliminar la ruta y colocarla en espera. El enrutador hace una actualización
inversa de la ruta enviando una actualización con una métrica de infinito a un enrutador que originariamente
publicó una ruta hacia una red. La actualización inversa de la ruta puede ayudar a la convergencia rápida.
Triggered updates.
Esta técnica consiste en obligar a enviar una actualización de la tabla de enrutamiento a sus vecinos ante
cualquier modificación de dicha tabla. Con esto se mejoran los tiempos de convergencia, ya que hay ningún
retardo en el envío de las actualizaciones.
Algoritmo de estado de enlace (Link-State)

Este enrutamiento de estado de enlace también es conocido por SPF (Shortest Path First)
El principio en que se basa el enrutamiento de estado de enlace es el siguiente:
- Los enrutadores son responsables de los contactos con sus vecinos y de conocer sus identidades.
- Los enrutadores construyen mensajes de estado de enlace con la lista de los enlaces de la red y
sus métricas asociadas.
- Los mensajes de estado de enlace se transmiten a todos los enrutadores de la red, y no solo a sus
vecinos, como sucede con el algoritmo de vector de distancia.
- Todos los enrutadores tienen listas idénticas y pueden construir mapas topológicos iguales.
- Los mapas se usan para obtener las mejores rutas a todos los destinos.
Así la primera fase consiste en darse a conocer los distintos enrutadores que conforman la red. Para ello, los
enrutadores contactan con sus vecinos enviando mensajes hello a sus interfaces. En las interfaces de LAN, los
mensajes hello se envían a un grupo predefinido o a una dirección IP multicast que pueda ser recibida por todos
los enrutadores. Los enrutadores vecinos replican con mensajes hello que contienen la identidad del enrutador
que lo envía. A partir de este momento ya pueden intercambiarse la información de estado de enlace.
Los mensajes hello también se emplean cuando entra a la red un enrutador nuevo, el cual debe darse a conocer a
los demás.
La información de estado de enlace se envía en forma de mensajes de estado de enlace (LSA – Link State
Advertisement) que contiene los datos para la base de datos y además permiten calcular a cada enrutador, la
topología de la red. Los mensajes de estado de enlace normalmente se envían solo bajo las circunstancias
siguientes:
- cuando un enrutador descubre a un nuevo vecino
- cuando cae un enlace a un vecino
- cuando cambia la métrica de un enlace
La distribución de los mensajes de estado de enlace (LSA) se basa en las tablas de enrutamiento y a la vez éstas
de la información recibida vía los LSAs.
Todos los LSAs cuando se envían, deben tener un reconocimiento satisfactorio de haber llegado y además llevar
la fecha y hora para evitar duplicidades.
Cuando un enrutador recibe un LSA, comprueba en su base de datos si el número de secuencia del último LSA
es del mismo origen. Si es igual o tiene fecha anterior, no lo procesa, por el contrario, añade la información a su
base de datos
Inconvenientes del algoritmo de estado de enlace

Existen dos aspectos del estado de enlace que son motivos de preocupación: los requisitos de procesamiento y
memoria y los requisitos de ancho de banda.
Requisitos de procesamiento y memoria. En la mayoría de los casos, ejecutar los protocolos de enrutamiento de
estado de enlace significa que los enrutadores deben utilizar más memoria y realizar más procesamiento que los
protocolos de enrutamiento por vector de distancia. Los administradores de red deben garantizar que los
enrutadores que seleccionen sean capaces de proporcionar estos recursos necesarios. Los enrutadores realizan el
seguimiento de todos los demás enrutadores dentro de un mismo grupo y de las redes que cada uno puede
alcanzar directamente. Para el enrutamiento por estado de enlace, la memoria debe tener la capacidad de
almacenar la información de varias bases de datos, del árbol de topología y de la tabla de enrutamiento. El uso
del algoritmo de Dijkstra para calcular la SPF requiere una tarea de procesamiento proporcional a la cantidad de
enlaces de la red, multiplicada por la cantidad de enrutadores de la misma.
Requisitos de ancho de banda. Otro punto que puede ser motivo de preocupación es el ancho de banda que se
debe utilizar para realizar la técnica de inundación inicial de mensajes de estado de enlace. Durante el proceso de
descubrimiento inicial, todos los enrutadores que utilicen protocolos de enrutamiento de estado de enlace envían
mensajes LSA a todos los demás enrutadores. Esta acción inunda la red a medida que los enrutadores demandan
ancho de banda en forma masiva y reducen temporalmente el ancho de banda disponible para el tráfico enrutado
que transporta los datos del usuario. Después de esta técnica de inundación inicial, los protocolos de
enrutamiento de estado de enlace generalmente requieren un ancho de banda mínimo para enviar mensajes LSA
no frecuentes o generados por sucesos que reflejen los cambios de topología.
16.3.3 GGP – Gateway-to-Gateway Protocol
El protocolo GGP fue el primer protocolo de enrutamiento que se empleó y que se basaba en el algoritmo de
vector de distancia.
En la actualidad ya no forma parte de los estándares de Internet ya que se considera un protocolo obsoleto.
Cada mensaje GGP tenía un formato de cabecera fijo, que contenía el tipo y el formato de los demás campos.
Solo participaban de este protocolo, los enrutadores que se habían definido como enrutadores principales de la
red. Así cuando se añadía un nuevo enrutador, se le tenía que notificar cuales eran sus enrutadores vecinos.
Las tablas de vector de distancia consistían en pares de valores, dirección IP y número de saltos o hops.
16.3.4 RIP - Routing Information Protocol
Routing Information Protocol (RIP) es un protocolo de enrutamiento originalmente diseñado por Xerox y para
implementarlo en sus redes XNS. RIP se asoció a UNIX y al protocolo TCP/IP en 1982 cuando la versión de
Berkele y Standard Distribution (BSD) la incluyó en su software para enrutamiento. Sus especificaciones están
desarrolladas en el RFC 1058.
Como todos los protocolos de enrutamiento, funciona a nivel de red según el modelo de referencia OSI y se
apoya en el protocolo UDP y su puerto 520.
Las tablas de enrutamiento son dinámicas, empleando para ello el algoritmo de vector de distancia. La
información entre enrutadores se realiza empleando el protocolo ICMP.
Sus principales características son las siguientes:

 Es un protocolo abierto
 Es un protocolo de enrutamiento por vector de distancia.
 Utiliza el número de saltos como métrica para la selección de rutas.
 El número de saltos máximo permitido es 15.
 Por defecto, se envía un broadcast de las actualizaciones de enrutamiento cada 30 segundos.
Debido a que no incluye espacio para máscaras, el RIP no soporta información de subredes.
Formato de la tabla de enrutamiento

Cada entrada de la tabla de enrutamiento del protocolo RIP contiene
 la identificación de la red de destino
 el nombre del enrutador vecino por esta interface y
 una métrica. Esta métrica indica la distancia en número de saltos hasta llegar al destino.
 También puede contener información de los temporizadores asociados a la ruta.
El protocolo RIP solo guarda la mejor ruta para llegar al destino. Cuando detecta una ruta mejor, sustituye la que
tiene por ésta. Los cambios en la topología de la red pueden provocar cambios en las rutas, haciendo que se
generen rutas mejores para ciertos destinos. Cuando hay cambios en la red, estos cambios se reflejan en los
mensajes de actualización de rutas.
Formato del mensaje

El protocolo RIP especifica 2 tipos de mensajes: de solicitud y de respuesta.
Un mensaje de solicitud es enviado a los enrutadores solicitando información completa o parcial de sus tablas de
enrutamiento.
Un mensaje de respuesta se envía a los enrutadores con la información de su tabla de vector de distancia en los
casos siguientes:
- Cada 30 segundos
- En respuesta a una solicitud
- Cuando ha habido cambios en la tabla de vector de distancia
La estructura del mensaje es la siguiente
Comando
Versión
Ceros ( 2 octetos)
Familia de la red 1
Ceros ( 2 octetos)
Dirección IP de la red 1
Ceros ( 4 octetos)
Distancia de la red 1
.....
donde
- Comando, 1 octeto. Este campo indica si se trata de una solicitud o una respuesta. La respuesta a una solicitud
consiste en enviar al sistema que lo solicita, toda o parte de la tabla de enrutamiento.
- Versión, 1 octeto. Este campo indica la versión RIP implementada.
- Identificador de la familia de direcciones, 2 octetos. En Internet, su valor es 2.
- Dirección IP, 4 octetos
- Métrica, 4 octetos. Es el número de saltos que puede dar hasta llegar al destino.
Estos 3 últimos campos se repiten tantas veces como entradas de la tabla de enrutamiento se transmiten.
Como otros protocolos de enrutamiento, el RIP usa algunos temporizadores para regular sus prestaciones, siendo
los más importantes los siguientes:
- El temporizador de actualización, que se establece en 30 segundos, así se asegura que como
máximo, es el tiempo que tarda en enviar su tabla de enrutamiento a todos sus enrutadores
vecinos, independientemente hayan habido cambios en la topología de la red o no..
- El tiempo que espera para validar las rutas malas, en general 90 segundos. Cuando una ruta cae,
los vecinos lo detectan. Estos enrutadores calculan rutas nuevas y envían mensajes de
actualización a sus enrutadores vecinos. Así se genera una ola de mensajes de actualización a
través de la red. Estos mensajes no llegan instantáneamente a todos los enrutadores. Así un
dispositivo puede disponer de información incorrecta durante un cierto tiempo.
- El tiempo que tarda en ser borrada una ruta de la tabla si no es actualizada. En general es de 270
segundos.
Con el fin de mejorar las prestaciones de este protocolo RIP, se pueden implementar las funciones siguientes:
- Temporizadores de espera (Hold-downs). Con esta funcionalidad, las rutas caídas no se da
instantáneamente de baja, sino que se tarda un cierto tiempo en hacerlo.
- Horizonte dividido (Split horizon). Consiste en que cuando un enrutador reciba información de
una nueva ruta, esta información la envíe a todos sus enrutadores vecinos excepto del enrutador
que lo informó.
- Actualizaciones inversas (Poison Reverse Updates). El aumento en las métricas de enrutamiento
generalmente indican que hay bucles de enrutamiento. Luego se envían actualizaciones inversas
para eliminar la ruta y colocarla en espera. El enrutador hace una actualización inversa de la ruta
enviando una actualización con una métrica de infinito a un enrutador que originariamente
publicó una ruta hacia una red.
RIP versión 2
Esta versión se describe en la RFC 1723 y tiene como características adicionales las siguientes:
- Posibilidad de incorporar las máscaras
- Posibilidad de empleo de autenticación
- Posibilidad de multicasting
Para ello, se emplean algunos de los campos con ceros, campos vacíos, de la estructura del mensaje de la versión
1.
Entonces el formato del mensaje queda así
Comando
Versión
Ceros ( 2 octetos)
X’FFFF’
Tipo de autenticación
Contraseña
Familia de la red 1
Ceros ( 2 octetos)
Dirección IP de la red 1
Máscara de la red 1
Próximo salto
Distancia de la red 1
.....
Si hay autenticación, sus datos se incorporan como primera línea, y para distinguirla de las demás la
identificación de la familia se rellena con unos. A continuación, se emplean 2 octetos para especificar el tipo de
autenticación y los 16 octetos restantes contienen el contraseña.
En cuanto a los campos de cada entrada de la tabla de enrutamiento, ahora son los siguientes:
- Identificador de la familia de direcciones, 2 octetos. En Internet, su valor es 2.
- Dirección IP, 4 octetos
- Máscara de la red, 4 octetos
- Próximo salto, 4 octetos
- Métrica, 4 octetos. Es el número de saltos que puede dar hasta llegar al destino.
16.3.5 RIP de Novell
RIP de Novell es un protocolo de enrutamiento que emplea el algoritmo de vector de distancia. RIP de Novell
usa dos métricas para tomar decisiones de enrutamiento:
- tictacs (una medida de tiempo) y
- número de saltos (recuento de la cantidad de enrutadores que se atraviesan).
RIP de Novell verifica sus dos variables de configuración de la métrica, comparando en primer lugar los tictacs
en busca de rutas alternativas. Si dos o más rutas poseen el mismo valor de tictacs, RIP de Novell compara el
número de saltos. Si dos o más rutas tienen el mismo número de saltos, el enrutador comparte la carga
Cada enrutador habilitado para IPX pasa copias periódicamente de su tabla de enrutamiento RIP de Novell, que
es distinta de su tabla de enrutamiento IP porque el enrutador mantiene una tabla de enrutamiento para cada
protocolo activado a su vecino directo. Los enrutadores IPX vecinos agregan vectores de distancia según se
requiera, antes de entregar copias de sus tablas RIP de Novell a sus propios vecinos.
La opción de horizonte dividido (split horizon) con la "mejor información" evita que el vecino realice el
broadcast de las tablas RIP de Novell hacia las redes de las cuales recibió la información.
RIP de Novell también utiliza un mecanismo de antigüedad de la información para manejar la situación en la que
un enrutador habilitado de IPX entra en colapso sin ningún mensaje explícito a sus vecinos. Las actualizaciones
periódicas reinician el temporizador de antigüedad.
Las actualizaciones de la tabla de enrutamiento se envían a intervalos de 60 segundos Esta frecuencia de

actualización puede provocar tráfico excesivo en algunas redes.
16.3.6 IGRP - Interior Gateway Routing Protocol
El Interior Gateway Routing Protocol (IGRP) es un protocolo de enrutamiento desarrollado a mediados de 1980
por Cisco. Su principal objetivo era disponer de un protocolo robusto de enrutamiento dentro de un sistema
autónomo con una topología compleja con diferentes aplicaciones corriendo en ella, distintos anchos de banda y
retardos.
A mediados de 1980, el protocolo de enrutamiento más usado era el RIP. Aunque es útil para redes homogéneas
pequeñas y medianas, las limitaciones del RIP crecen con el tamaño de las redes. El límite de 15 saltos y su
única métrica limita la flexibilidad en entornos complejos.
Tecnología
El protocolo IGRP en un protocolo de enrutamiento que utiliza la técnica del vector de distancia IGP (Interior
Gateway Protocol). Este tipo de protocolos envía a sus enrutadores vecinos toda o parte de su tabla de
enrutamiento a intervalos regulares. A medida que aumenta la información de enrutamiento, los enrutadores
pueden calcular las distancias a todos los nodos de la red.
Como protocolo de enrutamiento, su funcionalidad se corresponde con los protocolos de nivel de red según el
El protocolo de enrutamiento IGRP utiliza una combinación de variables para determinar una métrica
compuesta. Estas variables incluyen:
- ancho de banda. Puede tener valores que reflejen velocidades desde 1200 bps a 10 Gbps
- retardo. Rango de 1 a 224.
- carga. Rango de 1 a 255.
- confiabilidad. Rango de 1 a 255.
Todos estos valores con sus pesos se combinan con un fórmula establecida por el propio usuario, lo que permite
a los administradores influir en sus cálculos.
Para obtener mayor flexibilidad, el protocolo IGRP permite el enrutamiento por distintos caminos. Si hay 2
líneas en paralelo, se puede enviar su tráfico por la otra línea en el caso de fallo de la primera de forma
automática.
Formato del mensaje

El formato del mensaje es el siguiente:
Versión Opcode Edición AS Número de Número de Número de Control de

subredes redes redes externas error
principales
donde
- Versión. Indica la versión del IGRP que se usa.
- Opcode. Indica el tipo de mensaje. El valor 1 indica un mensaje de actualización y 2 uno de
solicitud. Estos últimos se emplean para solicitar la tabla de enrutamiento a un enrutador vecino.
Estos mensajes solo tienen los campos versión, opcode y número de Sistema Autónomo (AS).
- Edición. Contiene un número que aumenta con los cambios de la tabla de enrutamiento. Así se
evitan actualizaciones innecesarias.
- AS. Identificación del Sistema Autónomo.
- Número de subredes en el mensaje de actualización.
- Número de redes principales en el mensaje de actualización.
- Número de redes externas en el mensaje de actualización.
- Control de error.
A continuación viene la tabla de enrutamiento, con 7 valores para cada ruta y que son los siguientes:
- dirección IP
- retardo
- ancho de banda
- tamaño máximo del mensaje (MTU)
- confiabilidad (porcentaje de mensajes enviados y recibidos satisfactoriamente),
- carga y
- saltos. Este último valor no se emplea para el cálculo de la métrica, es sólo informativo.
Características de estabilidad
Dado de que se trata de un protocolo de enrutamiento que emplea el algoritmo de vector de distancia, con el fin
de mejorar sus prestaciones, soporta la funcionalidades siguientes:
- Temporizadores de espera (Hold-downs). Con esta funcionalidad, las rutas caídas no se da
instantáneamente de baja, sino que se tarda un cierto tiempo en hacerlo.
- Horizonte dividido (Split horizon). Consiste en que cuando un enrutador reciba información de
una nueva ruta, esta información la envíe a todos sus enrutadores vecinos excepto del enrutador
que lo informó.
- Actualizaciones inversas (Poison Reverse Updates). El aumento en las métricas de enrutamiento
generalmente indican que hay bucles de enrutamiento. Luego se envían actualizaciones inversas
para eliminar la ruta y colocarla en espera. El enrutador hace una actualización inversa de la ruta
enviando una actualización con una métrica de infinito a un enrutador que originariamente
publicó una ruta hacia una red.
En cuanto a los temporizadores de este protocolo IGRP, se debe tener en cuenta lo siguiente:
- El tiempo de actualización de las tablas de enrutamiento es del orden de 90 segundos, aunque no

haya sucedido nada.
- El tiempo que un enrutador declara una ruta como inaccesible si no recibe ninguna actualización
del primer enrutador de la ruta es del orden de 3 veces el tiempo de actualización.
- El tiempo que el enrutador elimina la ruta de la tabla de enrutamiento es del orden de 5 veces el
de actualización.
16.3.7 OSPF - Open Shortest Path First
El Open Shortest Path First (OSPF) es un protocolo de enrutamiento de redes y está diseñado para ser usado en
grandes redes heterogéneas.
Tiene 2 características principales,

- es un protocolo abierto y
- está basado en el algoritmo SPF (shortest path first), también llamado algoritmo Dijkstra. Sus
especificaciones se encuentran detalladas en la RFC 2328.
Tecnología básica
Es un protocolo que emplea el algoritmo de estado de enlace y como tal, solicita los cambios de estado de enlace
a los demás enrutadores de su nivel jerárquico. La información sobre interfaces, métricas y otras variables se
incluyen en los mensajes de estado de enlace (LSA) del OSPF. Esta información la usan los enrutadores junto a
un algoritmo SPF para calcular la ruta más corta para llegar a cada red.
El enrutamiento de estado de enlace utiliza:
 publicaciones de estado de enlace (LSA - Link-State Advertisements)
 una base de datos topológica
 el algoritmo SPF y el árbol SPF resultante
 una tabla de enrutamiento de rutas y puertos hacia cada red
En los protocolos de vector de distancia, la tabla de enrutamiento sólo se envía a los enrutadores vecinos, sin
embargo, en este caso los mensajes de estado de enlace (LSA) se intercambian entre todos los enrutadores de la
red.
El descubrimiento de red para el enrutamiento de estado de enlace utiliza los siguientes procesos:
1. Los enrutadores intercambian mensajes de estado de enlace (LSA) entre sí. Cada enrutador empieza con redes
directamente conectadas para las cuales posee información directa.
2. Cada enrutador en paralelo con los demás enrutadores genera una base de datos topológica que contiene todas
las rutas de la red.
3. El algoritmo SPF calcula la accesibilidad de la red. El enrutador construye esta topología lógica como un
árbol, con él mismo como raíz, y con todas las rutas posibles hacia cada red dentro de la red. Entonces clasifica
estas rutas, colocando la ruta más corta primero (SPF).
5. El enrutador hace una lista de sus mejores rutas y de los puertos que permiten acceder a estas
redes destino, dentro de la tabla de enrutamiento. También mantiene otras bases de datos con
detalles de elementos y estados de topología.
6.
Características
Este protocolo de enrutamiento OSPF permite a los administradores instalar varias rutas para un mismo destino,
estableciendo prioridades para cada una de ellas. Sin embargo es el propio algoritmo del OSPF, el que decide por
donde se debe dirigir el tráfico.
También suministra balanceo de carga, así si hay múltiples rutas para un mismo destino, se les puede dar el
mismo coste, con lo que el tráfico se distribuye.
Todos los intercambios de información con este protocolo pueden ser autenticados.
También soporta el reconocimiento de las subredes si las hay.
Minimiza los envíos de tipo broadcast mediante el uso del multicast.
Jerarquía de enrutamiento
A diferencia del protocolo RIP, el OSPF puede operar dentro de una jerarquía. La entidad principal dentro de
una jerarquía es el Sistema Autónomo (AS). Recordemos que un sistema autónomo es un conjunto de redes bajo
una administración común que comparte una estrategia común de enrutamiento. También a veces a un sistema
autónomo se le llama dominio.
Un Sistema Autónomo se puede dividir en areas. Una area es un grupo de redes contiguas con sus dispositivos
asociados. Los enrutadores con varias interfaces pueden participar en varias areas. A estos enrutadores se les
llama area border routers (AB), y en la figura aparecen como enrutadores AB y disponen de distintas bases de
datos topológicas, una para cada area.
Una base de datos topológica es la imagen de la red y de la relación entre enrutadores. Contiene la información
topológica a partir de todos los LSA recibidos de todos los enrutadores de su area. Todos los enrutadores de una
misma area, en la figura enrutadores IA, tienen su base de datos idéntica.
En el caso del sistema de la figura, un backbone OSPF es el encargado de distribuir la información de
enrutamiento entre las distintas areas.
Los enrutadores AS border, en la figura enrutadores ASB, aprenden las rutas exteriores mediante el protocolo
EGP o BGP y son los únicos que tienen enlaces externos.
El motivo de esta exposición es para demostrar que a diferencia del enrutamiento RIP o IGRP, con OSPF los
enrutadores no tienen todos la misma categoría, ni tampoco todos no tienen porque tener toda la información de
la red.
Algoritmo SPF
Este algoritmo es la base del protocolo OSPF. Cuando un enrutador con protocolo OSPF se inicializa, crea la
base de datos correspondiente y espera indicaciones de los protocolos de los niveles más bajos.
Una vez se ha asegurado de que las interfaces funcionan, envía un mensaje Hello para avisar a sus enrutadores
vecinos. Si recibe mensajes Hello, sabe que su enrutador vecino está activo.
En redes con múltiples accesos, se elige un enrutador como principal y otro de reserva.
Cuando las bases de datos de estado de enlace de dos enrutadores vecinos se sincronizan, se dice que los
enrutadores son adyacentes.
Cada enrutador envía periódicamente una mensaje de estado de enlace (LSA), y también cada vez que hay
cambios de estado en la red.
Formato del mensaje

La estructura de la cabecera del mensaje LSA es la siguiente:
Versión Tipo Longitud

Identificación del area
Control de error Tipo de autenticación
Autenticación
donde
- Versión, 1 octeto. Indica la versión del OSPF que se usa.
- Tipo, 1 octeto. Hay 5 tipos :
Hello Se emplea para saber si los enrutadores vecinos están

activos o no, contiene básicamente la dirección IP de los
mismos.
Descripción Descripción de la base de datos que contendrá las
características de los enlaces.
Solicitud Solicitud de estado de enlace que contendrá los datos del
enrutador al que va dirigida esta solicitud.
Actualización Actualización de estado de enlace que contendrá los mismos
valores que el tipo descripción.
Reconocimiento Reconocimiento de estado de enlace.
- Longitud del mensaje, 2 octetos

- Identificación del enrutador, 4 octetos
- Identificación del area, 4 octetos
- Control de error, 2 octetos
- Tipo de autenticación, 2 octetos
- Autenticación, 8 octetos
La parte de datos del mensaje del protocolo OSPF tiene una estructura variable según del tipo de mensaje de que
se trate.
16.3.8 EGP - Exterior Gateway Protocol
El EGP (Exterior Gateway Protocol) es un protocolo de enrutamiento dinámico, que utiliza un diseño muy
sencillo. No usa métricas y por lo tanto no puede tomar decisiones inteligentes. Sus tablas especifican que
enrutadores se han de emplear para alcanzar las redes. Sus especificaciones están publicadas en la RFC 904.
El protocolo EGP tiene 3 funciones primarias:

1) Los enrutadores con protocolo EGP establecen un conjunto de enrutadores vecinos.
2) Los enrutadores con protocolo EGP interrogan a sus enrutadores vecinos para ver si están activos.
3) Los enrutadores con protocolo EGP envían mensajes de actualización con información sobre
como llegar hasta ellos.
Este protocolo está obsoleto sin embargo es la base del protocolo de enrutamiento BGP que se emplea
actualmente
Formato del mensaje

El formato del mensaje es el siguiente:
Versión Tipo Código Estado Control de Sistema Número de Datos

error autónomo secuencia
Los campos son :

- Version, 1 octeto. Versión del protocolo EGP utilizado
- Tipo, 1 octeto. Hay 5 tipos, cada uno con su funcionalidad y son
Adquisición del vecino Establecer quienes son los enrutadores vecinos

Verificación del vecino Determinar si el enrutador vecino está activo
Poll Determinar el acceso a una red
Actualización Actualización de las tablas de enrutamiento
Error Indicación de las condiciones de error
- Código, 1 octeto. El valor de este campo permite distinguir los subtipos de mensajes.
- Estado, 1 octeto. Es indicativo del estado del dispositivo.
- Identificación del sistema autónomo (AS) del enrutador al que se le envía el mensaje, 2 octetos.
- Número de secuencia, 2 octetos, que permite aparejar las respuestas con sus solicitudes.
- Datos
16.3.9 BGP - Border Gateway Protocol
El protocolo BGP (Border Gateway Protocol) es una mejora del protocolo EGP, dado que éste es débil en cuanto
a su accesibilidad. Sus especificaciones se desarrollan en la RFC 1771.
modelo de referencia OSI. La implementaciones prácticas de BGP usan el protocolo TCP y su puerto 179 como
protocolo de transporte.
Características
Las más importantes son:
- Permite la comunicación entre Sistemas Autónomos. Así es habitual que dentro de los propios
sistemas autónomos se emplee como protocolos de enrutamiento RIP u OSPF, y BGP entre
enrutadores pertenecientes a distintos sistemas autónomos.
RIP/OSPF RIP/OSPF
BGP
Enrutador Enrutador
Sistema autónomo A Sistema autónomo B
- El protocolo BGP permite que un sistema autónomo conozca los dispositivos accesibles de otros
sistemas autónomos.
- Suministra la información del próximo salto como sucede con el algoritmo de vector de distancia.
- Permite la implementación de políticas para cada ruta.
- Es un protocolo fiable ya que emplea como transporte el protocolo TCP que es fiable.
- Además de los dispositivos a que puede llegar y la información del próximo salto, el protocolo
BGP incluye información del camino que sigue el mensaje.
- Para no colapsar las líneas de comunicaciones, en cada actualización no se transmite toda la
información, sino solamente las diferencias.
- Permite el conocimiento de las subredes con el empleo de las máscaras.

- Permite autenticación.

La estructura del mensaje de este protocolo es la siguiente:
Marcador Longitud Tipo Datos

Donde
- Marcador, 16 octetos. Se emplea para autenticación.
- Longitud, 2 octetos. Longitud total del mensaje en octetos.
- Tipo, 1 octeto. Hay 4 tipos de mensajes y su valor corresponde al de la tabla siguiente
1 Open
2 Update
3 Notification
4 Keepalive
- Datos
Mensaje OPEN
Tan pronto como dos dispositivos que emplean el protocolo BGP establecen una conexión TCP, se envían un
mensaje OPEN, dándose el número del sistema autónomo y otros parámetros.
Este mensaje además de la cabecera consta de los siguientes campos:
- Versión, 1 octeto
- Número del sistema autónomo, 2 octetos
- Tiempo máximo permitido entre la recepción de 2 mensajes, 2 octetos
- Identificador del emisor, 4 octetos
- Longitud del campo de parámetros opcionales, 1 octeto.
- Parámetros opcionales.
Cuando un enrutador recibe un mensaje OPEN, contesta con un mensaje KEEPALIVE, es decir, es lo mismo
que un mensaje de reconocimiento.
Mensaje UPDATE
Este mensaje se emplea para actualizar las tablas de enrutamiento entre enrutadores.
Además de la cabecera, consta de 2 partes, una primera con la información de las rutas a borrar y la segunda la
información de las rutas a añadir.
Dentro de esta información, no solo contiene las direcciones IP sino también las máscaras que permiten
distinguir a las distintas subredes.
Aparte de las rutas, también contiene este tipo de mensajes los atributos de la ruta como los números de los
sistemas autónomos que atraviesa la misma y la identificación del próximo salto.
Mensaje KEEPALIVE
Dos dispositivos que emplean el protocolo BGP periódicamente, se intercambian mensajes para conocer si el
otro dispositivo está activo. Estos mensajes son los llamados KEEPALIVE.
Su estructura es solo la cabecera, es decir, no lleva datos asociados.
Mensaje NOTIFICATION
Este tipo de mensaje sirve para el control o la detección de algún tipo de error. Cuando se detecta un problema,
el dispositivo envía un mensaje NOTIFICATION y a continuación cierra la conexión TCP.
Además de la cabecera, consta de los campos:
- Código de error, 1 octeto. Los más habituales son:
1 Error en la cabecera del mensaje

2 Error en el mensaje OPEN
3 Error en el mensaje UPDATE
4 Expiración del temporizador
6 Cierre de la conexión
- Subcódigo de error, 1 octeto

- Datos
16.4 RVSP - Resource Reservation Setup Protocol

El protocolo RSVP es un protocolo abierto y definido en el ámbito de Internet, estando sus especificaciones
detalladas en la RFC 2205. Es un protocolo de control de tráfico y no un protocolo de enrutamiento, por lo que
necesita de la existencia de algún protocolo de enrutamiento para poder operar.
El protocolo RSVP corre sobre UDP/IP y se le considera un protocolo de nivel de red en el modelo de referencia
OSI.
Este protocolo se emplea para el control de los flujos de información que transitan por las redes, principalmente
en ámbitos WAN, es decir, cuando hay líneas de comunicaciones. Se trata de alguna manera de priorizar dicho
tráfico en función de uno o varios parámetros. De esta manera también se puede realizar un control de la calidad
de servicio.
El protocolo RSVP es una de las herramientas que se han incorporado comercialmente para ello. Dado que el
control del flujo en la WAN se establece a partir de los enrutadores, es en estos dispositivos donde se ha de
implementar el protocolo RSVP.
Este protocolo contempla como elemento básico el flujo de datos, y por tanto se identifica un emisor con su
dirección IP y un receptor también con su dirección IP.
Dado que RSVP es un protocolo unidireccional, las reservas sólo se hacen en un sentido. Para las conexiones
duplex, tales como videoconferencias donde el que envía también es receptor, es necesario establecer 2 sesiones
RSVP, una en cada extremo.
La reserva con el protocolo RSVP se inicia siempre en el receptor, y para ello se emplean los mensajes de
señalización del protocolo RSVP. Estos mensajes de señalización se envían a los dispositivos intermedios, los
actuales hacen las reservas oportunas es el propio dispositivo.
Funcionamiento
Todos los mensajes que pertenecen a un flujo de datos determinado siguen el mismo camino. Esta es la filosofía
del protocolo RSVP. El dispositivo que envía los datos, periódicamente envía un mensaje de control llamado
path o de ruta, que viaja en la misma dirección que el flujo. Este mensaje contiene información del tráfico que
describe la calidad de servicio para este flujo específico.
Dado que el protocolo RSVP no enruta por si mismo, se usa la información de las tablas de enrutamiento de cada
enrutador para encaminar los mensajes RSVP.
Ahora si un receptor quiere reservar calidad de servicio para este flujo, envía un mensaje de reserva. Este
mensaje contiene la calidad de servicio solicitada desde este receptor para un flujo determinado. El receptor
envía un mensaje de reserva al último enrutador de la ruta con la dirección recibida del mensaje. Debido a que
los dispositivos que soportan el protocolo RSVP conocen la dirección de los equipos anteriores, los mensajes de
reserva pueden viajar en sentido contrario pero por el misma ruta que a la ida, y así establecer reservas de
recursos.
Tipos de reservas
Fundamentalmente son de 3 tipos:
- Wilcard-Filter (WF). Este tipo de reserva establece una reserva igual para todos los emisores de
una sesión, es decir, se trata de una reserva compartida. Así si entran nuevos miembros en una
videoconferencia con RSVP, la reserva incluye a los nuevos.
- Fixed-Filter (FF). En este caso, hay una reserva distinta para los mensajes enviados según
procedan de un emisor u otro. Los mensajes de distintos emisores que son de una misma sesión,
no comparten la reserva.
- Shared-Explicit (SE). Este tipo de reserva es distinta en función del emisor de que se trate, pero la
comparten con otros flujos de datos.
Los tipo WF y SE se emplean en general para aplicaciones multicast, ya que se trata de reservas compartidas.
Formato del mensaje

Como sucede con otros protocolos, en este caso todos los mensajes tienen una cabecera común, siendo su
estructura la siguiente:
Versión Flags Tipo Control de error

TTL Reservado Longitud
donde,
- Versión, 4 bits. Es la versión del protocolo RSVP
- Flags, 4 bits. Reservados.
- Tipo, 1 octeto. , donde se especifica el tipo de mensaje
1 Mensaje de ruta
2 Mensaje de reserva
3 Mensaje de error de ruta
4 Mensaje de error de reserva
5 Mensaje de eliminación de ruta
6 Mensaje de eliminación de reserva
7 Mensaje de confirmación a un mensaje de
reserva

- TTL, 1 octeto. Es el tiempo de vida correspondiente al protocolo IP
- Longitud, 2 octetos. Especifica la longitud total del mensaje en octetos.
En cuanto al campo de datos, se divide en objetos y cada uno de ellos también tiene una cabecera común que
consta de
Longitud Class-number C-Type

Datos
Donde
- Longitud, 2 octetos. Es la longitud de este objeto, es decir, su cabecera más sus datos y se expresa
en octetos.
- Class-number, 1 octeto. Es la identificación de la clase del objeto.
- C-Type, 1 octeto. Es la especificación del tipo de objeto.
- Datos, de longitud variable.
16.5 SLIP - Serial Link Internet Protocol

El protocolo SLIP se emplea para transmitir información entre un dispositivo de LAN, ya sea un ordenador o un
enrutador, y un módem, es decir, se emplea en el caso de líneas de comunicaciones analógicas.
Este protocolo SLIP encapsula los mensajes IP, siendo por tanto utilizado en las conexiones serie punto a punto
con TCP/IP. Sus especificaciones se encuentran documentadas en la RFC 1055.
El SLIP es un protocolo muy simple y consiste en transmitir una secuencia de caracteres al módem. Lo que no
tiene este protocolo es lo siguiente:
- Direccionamiento. Los dos ordenadores conectados mediante un enlace con protocolo SLIP, se
deben conocer por sus direcciones IP y los enrutamientos correspondientes. Además requiere de
direcciones IP fijas.
- Identificación del tipo de mensaje. El protocolo SLIP no puede soportar múltiples protocolos en
un enlace.
- Detección y corrección de errores. El protocolo SLIP no hace detección de errores. Los

protocolos de nivel superior deberían detectar los mensajes corruptos causados por errores en las
líneas con ruido. En este caso es necesaria una nueva retransmisión, que si lo hiciera el SLIP sería
más eficiente.
- Compresión. El protocolo SLIP no tiene ningún mecanismo de compresión. Así que aplicaciones
como Telnet, con mensajes en que los datos que se transmiten son pocos, el no poder comprimir
las cabeceras es un inconveniente. En la actualidad muchas implementaciones de SLIP
incorporan el uso de la compresión Van Jacobsen Header. Esta compresión reduce las cabeceras
de 40 octetos a 8 y es el llamado protocolo CSLIP que se describe en la RFC 1144.
- Solo es compatible con TCP/IP, es decir, no soporta IPX/SPX ni NetBEUI.
Este protocolo envía los caracteres uno tras otro, con la única excepción de los caracteres END (decimal 192) y
ESC (decimal 219), en cuyo caso lo envía 2 veces, es decir, no hay caracteres de inicio, ni de fin, ni de control.
En la actualidad, el protocolo SLIP prácticamente ha sido reemplazado por el protocolo PPP (Point-to-Point
Protocol).
16.6 PPP - Point to Point Protocol

Este protocolo PPP, igual que el SLIP, se emplea para transmitir información entre un dispositivo de LAN, ya
sea un ordenador o un enrutador, y un módem, es decir, se emplea en el caso de líneas de comunicaciones
analógicas.
El protocolo PPP (Point to Point Protocol) fue creado para mejorar el protocolo SLIP (Serial Line Internet
Protocol) en cuanto que éste únicamente soportaba el TCP/IP y no otros como IPX, NetBIOS, etc. Sus
especificaciones se detallan en la RFC 1331.
El protocolo PPP está compuesto por 3 protocolos:

- El HDLC como protocolo de nivel de enlace para encapsular mensajes que pertenecen a múltiples
protocolos sobre enlaces punto a punto.
- El LCP (Link Control Protocol) como protocolo de nivel de red. Contiene los procedimientos
para establecer, configurar y comprobar la conexión con la línea serie. Dentro de este protocolo
hay la fase de autenticación que es opcional.
- El NCP (Network Control Protocol) como protocolo de nivel de transporte, que es necesario para
establecer y configurar distintos protocolos de LAN. El protocolo PPP está diseñado para permitir
el uso simultáneo de múltiples protocolos de nivel superior incluyendo los siguientes:
BCP Protocolo de control de puente

IPCP Protocolo de control del protocolo IP
IPXCP Protocolo de control del protocolo IPX
La estructura del mensaje PPP es
Flag Dirección Control Protocolo Datos Control de error Flag
Donde
- Flag, dirección y control son valores fijos.
- Protocolo. Identificación de los protocolos de niveles superiores.
- Datos
- Control de error
Protocolo LCP
Este protocolo por su funcionalidad consta de tres clases de mensajes:
- Mensaje de establecimiento de enlace: Se utiliza para establecer y configurar un enlace.
- Mensaje de terminación del enlace: Se utiliza para terminar un enlace.
- Mensaje de mantenimiento del enlace: Se utiliza para administrar y depurar un enlace.
La estructura del mensaje LCP es
Código Identificador Longitud
donde
- Código. Identificación del tipo de mensaje.
- Identificador. Sirve para aparejar los mensajes de solicitud con los de respuesta.
- Longitud.
Funcionamiento
El protocolo PPP en su funcionamiento pasa por cuatro fases:
1. Establecimiento del enlace y negociación de la configuración. En esta fase, un nodo PPP origen envía
mensajes LCP para configurar y establecer el enlace de datos. Los mensajes LCP contienen un campo de opción
de configuración que permite que los dispositivos negocien el uso de opciones, como la unidad máxima de
transmisión (MTU), la compresión de determinados campos PPP y el protocolo de autenticación de enlace. Si no
se incluye ninguna opción de configuración en un mensaje LCP, se adopta el valor por defecto para esa
configuración.
2. Determinación de la calidad del enlace. En esta fase el enlace se prueba para determinar si su calidad es
suficiente para establecer los protocolos de capa de red. Una vez que se ha establecido el enlace y que se ha
elegido el protocolo de autenticación, se puede autenticar la estación de trabajo del cliente o usuario. La
autenticación, en caso de que se utilice, se lleva a cabo antes de que comience la fase de configuración del
protocolo de la capa de red. El protocolo LCP puede retardar la transmisión de la información del protocolo de la
capa de red hasta que esta fase se haya completado. En la fase de autenticación se pueden emplear distintos
protocolos tales como:
- PAP (Password Authentication Protocol)
- CHAP (Challenge Handshake Authentication Protocol)
- EAP (Extended Authentication Protocol)
3. Negociación de la configuración del protocolo de capa de red. En esta fase el nodo PPP origen envía mensajes
de protocolo NCP para seleccionar y configurar los protocolos de capa de red. Se configuran los protocolos de
capa de red seleccionados (como IP, Novell IPX y AppleTalk) y se pueden enviar los mensajes desde cada
protocolo de capa de red.
4. Terminación del enlace. En esta fase el enlace permanece configurado para la comunicación hasta que los
mensajes de los protocolos LCP o NCP cierran el enlace o hasta que se produzca algún hecho externo (por
ejemplo, el vencimiento de un temporizador de inactividad o la intervención de un usuario).
16.7 PAP - Password Authentication Protocol

El PAP (Password Authentication Protocol) es un protocolo de autenticación de usuario que se utiliza en el
protocolo PPP. Sus especificaciones se encuentran detalladas en la RFC 1334 - PPP Authentication Protocol.
El protocolo PAP emplea un método muy simple de autenticación usando un saludo de 2 vías. Después de la fase
de conexión, un par de datos identificación y contraseña son enviados por el usuario al autenticador para su
validez.
Este autenticación es muy vulnerable porque el contraseña se envía sin encriptar y además no hay control contra
los ataques de prueba y error.
El mensaje PAP se encapsula dentro del campo información del mensaje del protocolo PPP, siendo su tipo el
c023.
La estructura del mensaje PAP es
Código Identificador Longitud Datos
Donde
- Código, 1 octeto, identificador del tipo de mensaje PAP
1 Solicitud
2 Reconocimiento
3 No reconocimiento
- Identificador, 1 octeto. Su valor se emplea para aparejar las solicitudes y las respuestas.
- Longitud, 2 octetos
16.8 CHAP - Challenge Handshake Authentication Protocol

El CHAP (Challenge Handshake Authentication Protocol) es un protocolo de autenticación de usuario que se
utiliza en el protocolo PPP y está documentado en la RFC 1994. Funciona en la fase de autenticación del
protocolo PPP, es decir, mientras se envían los mensajes LCP.
El proceso de autenticación consta de un saludo de 3 vías:

- El autenticador envía un mensaje con una cadena de caracteres al usuario.
- El usuario devuelve el mensaje con otra cadena de caracteres que es consecuencia de un cálculo
de contraseña con la cadena recibida del autenticador. Esto es lo que se llama una función hash.
- El autenticador obtiene el contraseña del usuario a partir de la cadena de caracteres recibida,
porque conoce la cadena de caracteres utilizada. Si el contraseña está en su tabla, da la conexión
por buena.
- A intervalos aleatorios, se repiten los 3 pasos anteriores.
El inconveniente más importante de esta autenticación es que no hay posibilidad de encriptación.
El mensaje CHAP se encapsula dentro del campo información del mensaje del protocolo PPP, siendo su tipo el
c223.
La estructura del mensaje CHAP es
donde
- Código, 1 octeto, identificador del tipo de mensaje CHAP
1 Solicitud
2 Respuesta
3 OK
4 Fallo
16.9 EAP - Extended Authentication Protocol

EAP (Extended Authentication Protocol) es un protocolo de autenticación de usuario que se utiliza en la fase de
autenticación del protocolo PPP y está documentado en la RFC 2284.
El protocolo EAP no selecciona un mecanismo específico de autenticación en la fase de control del enlace del
protocolo PPP, sino que lo pospone a la fase de autenticación. Esto permite al autenticador solicitar más
información antes de determinar que mecanismo de autenticación se use. Esto también permite el uso de un
servidor de "back-end" que actualmente puede tener implementados varios mecanismos.
Las fases son:

1. Cuando la fase de establecimiento del enlace se ha completado, el autenticador envía una o más solicitudes
para autenticar el usuario. La solicitud tiene un campo que indica que lo es. Ejemplos de tipos de solicitudes
incluyen la identidad, MD5-challenge, One-Time Passwords, Generic Token Card, etc. El tipo MD5-challenge
se parece mucho al protocolo de autenticación CHAP. Típicamente, el autenticador enviará una solicitud inicial
de identidad seguido por una o más solicitudes para información de autenticación. Sin embargo, esta solicitud
inicial no es necesaria.
2. El usuario envía un mensaje de respuesta a cada solicitud, con una identificación específica a cada una de las
solicitudes.
3. El autenticador termina la fase de autenticación con un mensaje de OK o fallo.
Ventajas
El protocolo EAP puede soportar múltiples mecanismos de autenticación sin tener que pre-negociar uno en
concreto en la fase LCP del protocolo PPP. Algunos dispositivos no tienen necesariamente que entender cada
solicitud y pueden simplemente actuar como un agente de paso al servidor de "back-end" en un dispositivo. El
dispositivo solo necesita conocer el código de Ok o fallo para terminar la fase de autenticación.
Inconvenientes
El EAP requiere añadir un nuevo tipo de autenticación al protocolo LCP y así las implementaciones PPP se
habrán de modificar para poderlo usar.

El mensaje EAP se encapsula dentro del campo información del mensaje del protocolo PPP, siendo su tipo el
c227.
La estructura del mensaje EAP es
Donde
- Código, 1 octeto, identificador del tipo de mensaje EAP
-
1 Solicitud
2 Respuesta
3 OK
4 Fallo
16.10 RDSI - Red Digital de Servicios Integrados

Red Digital de Servicios Integrados (RDSI), en inglés ISDN, se basa en la tecnología de conmutación de
circuitos. Es un sistema de comunicaciones digital que permite el enlace entre distintas redes de datos. Este
sistemas de comunicaciones no solo permiten transmitir datos sino también voz.
Sus características principales son :

- Multiplexado por división de tiempo (TDM)
- Asignación estática de ancho de banda
- Time slots fijos
- Tiempo de latencia fijo, pequeño y predecible
- Tráfico isócrono
Componentes básicos
Los componentes de RDSI incluyen terminales, adaptadores de terminal (TA), dispositivos de terminación de
red (NT), equipo de terminación de línea y equipo de terminación de intercambio. La tabla suministra un
resumen de los componentes de RDSI.
Equipo de terminal tipo 1 (ET1) Designa un dispositivo que es compatible con la red
RDSI. Un ET1 se conecta a un TR1 o TR2.
Equipo de terminal tipo 2 (ET2) Designa un dispositivo que no es compatible con la red
RDSI y requiere un adaptador de terminal (AT).
Adaptador de terminal (AT) Convierte señales analógicas a digitales compatibles con
RDSI.
Terminación de red tipo 1 (TR1) Conecta el cableado de RDSI de 4 hilos a la instalación
convencional de 2 hilos.
Terminación de red tipo 2 (TR2) Es un dispositivo al que se pueden conectar uno o varios
equipos de terminal 1 (TE1) o adaptadores de terminal
(AT), y que realiza funciones de concentración y
conmutación.
Los terminales RDSI vienen en dos tipos, Tipo 1 o Tipo 2. Los terminales especializados RDSI se denominan
equipo de terminal de tipo 1 (ET1). Los terminales que no son RDSI, como el equipo terminal de datos (DTE),
más antiguos que los estándares RDSI, se denominan equipo de terminal de tipo 2 (ET2). Los ET1 se conectan a
la red RDSI a través de un enlace digital de par trenzado de cuatro cables. Los ET2 se conectan a la red RDSI a
través de un AT. El AT RDSI puede ser un dispositivo autónomo o una placa dentro del ET2. Si el ET2 se
implementa como un dispositivo autónomo, se conecta al AT a través de una interfaz estándar de la capa física.
Más allá de los dispositivos ET1 y ET2, el siguiente punto de conexión en la red RDSI es el dispositivo de
terminación de red de tipo 1 (TR1) o de terminación de red de tipo 2 (TR2). Estos son dispositivos de
terminación de red que conectan el cableado de cuatro cables del suscriptor con el bucle local de dos cables
convencional. En Estados Unidos, TR1 es un dispositivo del equipo terminal del abonado (CPE). En la mayoría
de los países del mundo, además de Estados Unidos, TR1 forma parte de la red suministrada por la portadora.
TR2 es un dispositivo más complicado, que habitualmente se encuentra en los intercambios privados de ramas
(PBX) digitales, que ejecutan servicios de protocolo de nivel 2 y nivel 3. También hay un dispositivo TR1/2, que
es un dispositivo único que combina las funciones de TR1 y TR2.
S T U
ET1 TR2 TR1
R S
ET2 AT
Puntos de referencia
Los puntos de referencia son un conjunto de especificaciones que definen la conexión entre dispositivos
específicos, según sus funciones en la conexión de extremo a extremo.
En la tabla siguiente se detalla cada uno de ellos.
R Punto de conexión entre un dispositivo no compatible con

RDSI y un adaptador de terminal (AT)
S Punto de conexión de un TR2 con los dispositivos
compatibles con RDSI, es decir, ET1 y ET2
T Punto de conexión de un TR2 con un TR1
U Punto de conexión entre un TR1 y la red RDSI de la
empresa de comunicaciones.
Canales: tipos
Este tipo de comunicaciones consta de 2 tipos de canales,
- el canal B que se emplea para la transmisión de datos y tiene un ancho de banda de 64 Kbps y
- el canal D que se emplea como canal de señalización con una velocidad de 16 Kbps.
El canal B funciona a nivel del red (3) según el modelo de referencia OSI, mientras que el canal D o de
señalización sólo funciona a nivel físico (1).
El RDSI define 2 tipos de accesos :
- el básico (BRI) (2B + D), que consta de 2 canales B y un canal D, con un ancho de banda total de
144 kbps y
- el primario (PRI) (30B + D), que consta de 30 canales B y un canal D, con un ancho de banda
total de 2 Mbps
En Estados Unidos, el tipo de acceso primario consta de 23 canales B y un canal D con un ancho total de 1,544
Mbps
Canal D
Este canal de señalización emplea protocolos que comprenden los 3 primeros niveles, físico, enlace y red, del
modelo de referencia OSI. Asimismo se basa en la recomendación SS7.
Las recomendaciones del CCITT empleadas en cada nivel son
Nivel red Q.930/I.450 y Q.931/I.451

Nivel enlace Q.920/I.440 y Q.921/I.441
Nivel físico I.430 para el acceso básico 0 I.431 para línea multiplex
primaria, con cable de cobre de 2 y 4 hilos
A nivel de enlace se utiliza el protocolo LAPD, protocolo orientado al bit. Se basa en los estándares (HDLC) de
la OSI (ISO 3309 a ISO 4355) y trabaja en modo de operación asíncrono balanceado.
El formato del mensaje LAPD es el siguiente
Flag Dirección Control Datos Control de error Flag
Donde
- los campos flag y control son los mismos que el protocolo HDLC
- la dirección comprende
SAPI Identificador del punto de acceso del servicio

C/R Un bit indicativo de si es solicitud o respuesta
EA Un bit de direccionamiento extendido
TEI Identificador de punto final de terminal
EA Un bit de direccionamiento extendido
Las terminales no pueden transmitir al canal D a menos que antes detecten una cantidad específica de unos (que
indica que no hay señal) correspondiente a una prioridad preestablecida.
Canal B
Este canal B solo se emplea en la transmisión de datos, por lo que solo se emplea el nivel físico, siendo sus
recomendaciones las mismas del canal D, es decir, I.430 para el acceso básico 0 I.431 para línea multiplex
primaria, con cable de cobre de 2 y 4 hilos.
Transmisión
En una transmisión de datos de RDSI, el flujo de bits que se transmite comprende no solo los de canal de datos B
y el de señalización D, sino también otros bits auxiliares o complementarios tales como bits de activación, de
alineación de trama, de equilibrado, de multitrama, etc.
Los bits del canal D se intercalan entre los octetos del canal B, y los octetos de los distintos canales B también
viajan intercalados, es decir, si es un acceso básico con 2 canales B, primero se envía un octeto del canal 1 del B,
luego un octeto del canal 2, otro del 1, y así sucesivamente.
Así el formato de transmisión de red a terminal es
F L B1 L D L F L B2 L D L B1 L D L B2 ...
Y el de terminal a red
F L B1 E D A F F B2 E D S B1 E D S B2 ...
Donde
- F es el bit de inicio
- L es el bit de balanceo de carga
- E es el echo del canal D
- D es la información del canal D
- A es el bit de activación
- S es un bit reservado
- B1 es la información del primer canal B
- B2 es la información del segundo canal B
16.11 ADSL - Asynchronous Digital Subscriber Line

El ADSL es un sistema de comunicaciones digital, que se emplea fundamentalmente para la transmisión de datos
mediante la utilización de los cables de cobre existentes para telefonía analógica o digital. Con los modems
habituales se llega como máximo a 56 Kbps y con la tecnología ADSL se sobrepasa en mucho este ancho de
banda.
Un circuito ADSL conecta un adaptador ADSL a cada extremo de una línea telefónica convencional, creando
tres canales de información:
- un canal de alta velocidad en dirección al usuario,
- un canal dúplex de velocidad media, que depende de la implementación de la arquitectura ADSL,
y
- un POTS (Plain Old Telephone Service) o un canal RDSI. El canal POTS/RDSI se separa del
adaptador digital mediante filtros, y así se garantiza una conexión POTS/ISDN, aunque el ADSL
falle.
La velocidad del canal rápido es de 1,5 a 6,1 Mbps, mientras que la del dúplex es de 16 a 832 Kbps. Cada canal
puede ser submultiplexado con el fin de generar múltiples canales de menor velocidad, dependiendo del sistema.
Los adaptadores ADSL tienen una configuración mínima de 1,5 o 2,0 Mbps en dirección al usuario y un canal
dúplex de 16 Kbps; otras empresas ofrecen velocidades de 6,1 Mbps y 64 Kbps para el dúplex. Los productos
que hay actualmente en el mercado soportan hasta 8 Mbps en una dirección y hasta 640 en el dúplex.
La velocidad máxima soportada depende de varios factores tales como la longitud de la línea de cobre, su
sección, la presencia de puentes y las interferencias existentes. La atenuación de la línea aumenta con la longitud
y la frecuencia y disminuye si aumenta la sección.
A continuación hay una tabla orientativa de las velocidades que se pueden llegar a obtener en función de estos
valores.
Velocidad Wire Gauge Longitud Sección Distancia
1,5 o 2 Mbps 24 AWG 18.000 ft 0,5 mm 5,5 km
1,5 o 2 Mbps 26 AWG 15.000 ft 0,4 mm 4,6 km
6,1 Mbps 24 AWG 12.000 ft 0,5 mm 3,7 km
6,1 Mbps 26 AWG 9.000 ft 0,4 mm 2,7 km
En el caso peor en cuanto a la existencia de ruido, se obtiene un caudal de 2 Mbps en sentido descendente y 0,9
Mbps en sentido ascendente hasta una distancia de 2,6 Km. de la central. Esto supone que en la práctica,
teniendo en cuenta la longitud media del bucle de abonado en las zonas urbanas, la mayor parte de los usuarios
están en condiciones de recibir por medio del ADSL un caudal superior a los 2 Mbps. Este caudal es suficiente
para muchos servicios de banda ancha, y desde luego puede satisfacer las necesidades de cualquier internauta,
teletrabajador así como de muchas empresas pequeñas y medianas.
Comparación con los modems

El ADSL es una técnica de modulación para la transmisión de datos a gran velocidad sobre el par de cobre. La
primera diferencia entre esta técnica de modulación y las usadas por los modems en banda vocal (V.32 a V.90)
es que estos últimos sólo transmiten en la banda de frecuencias usada en telefonía (300 Hz a 3400 Hz), mientras
que los modems ADSL operan en un margen de frecuencias mucho más amplio que va desde los 24 KHz hasta
los 1104 KHz, aproximadamente.
Otra diferencia entre el ADSL y otros modems es que el ADSL puede coexistir en un mismo bucle de abonado
con el servicio telefónico. Basta con ver que trabajan en bandas de frecuencia distintas, lo que no es posible con
un módem convencional ya que funciona en la banda vocal, la misma que la telefonía.
Tecnología
ADSL depende de los avances tecnológicos sobre el procesamiento de las señales digitales y los algoritmos para
transmitir la información sobre el par telefónico. Además se han requerido muchos avances en transformadores,
filtros analógicos y convertidores A/D. Las líneas telefónicas largas pueden atenuar las señales de hasta 1 Mhz
hasta 90 dB, forzando a que las partes analógicas de los adaptadores ADSL trabajen muy forzados, separando
canales y manteniendo valores bajos de ruido. Desde fuera, el ADSL parece sencillo, ya que consta de canales
transparentes de datos síncronos a distintas velocidades sobre las líneas telefónicas convencionales.
Para crear múltiples canales, los adaptadores ADSL dividen el ancho de banda disponible de una línea telefónica
de dos formas, por Frequency Division Multiplexing (FDM) o por Echo Cancellation. FDM asigna una banda en
un sentido y otra en el sentido contrario. En la dirección al usuario, se emplea multiplexación por TDM en uno o
más canales de alta velocidad. En el sentido desde el usuario, se multiplexa en los correspondientes canales de
baja velocidad. Con Echo Cancellation, se asigna la banda que viene del usuario encima de la que va hacia él, y
se separan ambas por medio de local echo cancellation, una técnica bien conocida en los modems V.32 y V.34.
Con cualquiera de estas técnicas, ADSL separa un canal de 4 kHz para POTS al final de la banda.
Un adaptador ADSL organiza el flujo de datos creado por multiplexación de los canales en dirección al usuario,
canales dúplex y canales de mantenimiento juntos en bloques, y añade un código de corrección de error a cada
uno de ellos. El receptor así puede verificar y corregir los errores generados durante la transmisión junto con la
longitud del mismo especificado en el bloque. También pueden crearse superbloques juntando subbloques. Así
permite una eficiente transmisión de señales de datos y vídeo.
Descripción de la modulación
Al tratarse de una modulación en la que se transmiten diferentes caudales en los sentidos Usuario -> Red y Red
-> Usuario, el módem ADSL situado en el extremo del usuario es distinto del ubicado al otro lado del bucle, es
decir, en la central local. Así en los modems situados en casa del usuario (ATU-R o "ADSL Terminal Unit-
Remote) y en los de la central (ATU-C o "ADSL Terminal Unit-Central"), se ha de colocar delante de cada uno
de ellos un dispositivo denominado "splitter". Este dispositivo no es más que un conjunto de dos filtros: uno paso
alto y otro paso bajo. La finalidad de estos filtros es la de separar las señales transmitidas por el bucle de
abonado, es decir, las señales de baja frecuencia (telefonía) de las de alta frecuencia (ADSL).
ATU-C Splitter Splitter ATU-R

Bucle de
abonado
de cobre
Voz Telefóno
Central telefónica Domicilio del usuario

Modulación
En una primera etapa, coexistieron dos técnicas de modulación para el ADSL:
- CAP ("Carrierless Amplitude/Phase") y
- DMT ("Discrete MultiTone").
Sin embargo los organismos de estandarización (ANSI, ETSI e ITU) se han decantado por la solución DMT.
Esta solución consiste básicamente en el empleo de múltiples portadoras y no sólo una, que es lo que se hace en
los modems de banda vocal. Cada una de estas portadoras (denominadas subportadoras) es modulada en
cuadratura (modulación QAM) por una parte del flujo total de datos que se van a transmitir. Estas subportadoras
están separadas entre sí 4,3125 KHz, y el ancho de banda que ocupa cada subportadora modulada es de 4 KHz.
El reparto del flujo de datos entre subportadoras se hace en función de la estimación de la relación Señal/Ruido
en la banda asignada a cada una de ellas. Cuanto mayor es esta relación, tanto mayor es el caudal que puede
transmitir por una subportadora. Esta estimación de la relación Señal/Ruido se hace al comienzo de la
transmisión, es decir, cuando se establece el enlace entre el ATU-R y el ATU-C por medio de una secuencia de
entrenamiento predefinida. La técnica de modulación usada es la misma tanto en el ATU-R como en el ATU-C.
La única diferencia estriba en que el ATU-C dispone de hasta 256 subportadoras, mientras que el ATU-R sólo
puede disponer como máximo de 32.
La modulación es bastante complicada, pero el algoritmo de modulación se traduce en una IFFT (transformada
rápida de Fourier inversa) en el modulador, y en una FFT (transformada rápida de Fourier) en el demodulador
situado al otro lado del bucle. Así el modulador del ATU-C, hace una IFFT de 512 muestras sobre el flujo de
datos que se ha de enviar en sentido "downstream". El modulador del ATU-R, hace una IFFT de 64 muestras
sobre el flujo de datos que se ha de enviar en sentido "upstream". El demodulador del ATU-C, hace una FFT de
64 muestras tomadas de la señal "upstream" que recibe. El demodulador del ATU-R, hace una FFT, sobre 512
muestras de la señal "downstream" recibida.
Los espectros nunca se solapan con la banda reservada para el servicio telefónico básico (POTS o "Plain Old
Telephone Service"), y en cambio sí que se solapan con los correspondientes al acceso básico RDSI. Por ello el
ADSL y el acceso básico RDSI son incompatibles.
DSLAM
Como antes se ha explicado, el ADSL necesita una pareja de modems por cada usuario: uno en el domicilio del
usuario (ATU-R) y otro (ATU-C) en la central local a la que llega el bucle de ese usuario.
Esto complica el despliegue de esta tecnología de acceso en las centrales. Para solucionar esto, surgió el
DSLAM ("Digital Subscriber Line Access Multiplexer"). Este dispositivo consiste en un chasis que agrupa gran
número de tarjetas, cada una de las cuales consta de varios modems ATU-C, y que además concentra el tráfico
de todos los enlaces ADSL hacia una red WAN.
16.12 Frame Relay

Es un protocolo de comunicaciones digital que se basa en la conmutación de mensajes.

- multiplexado estadístico
- orientado a la conexión
- asignación dinámica del ancho de banda
- mensajes de longitud variable
- tiempo de latencia alto e impredecible
Se trata de un protocolo que opera en las capas física y de enlace de datos del modelo de referencia OSI, pero
depende de los protocolos de capa superior como TCP para la corrección de errores.
Sus especificaciones se encuentran detalladas en:

- ANSI T1.606 Arquitectura Frame Relay
- ANSI T1.618 Protocolo de transferencia de datos

- ANSI T1.617 Protocolo de control
- CCITT I.122 Arquitectura Frame Relay
- CCITT Q.922 Protocolo de transferencia de datos
- CCITT Q.933 Protocolo de control
Hay 3 conceptos importantes en cuanto al protocolo Frame Relay y son :
- Data link connection identifier (DLCI). El DLCI es el identificador de cada enlace de
comunicación, es decir, es el equivalente a una dirección. Los mensajes Frame Relay contienen
esta información, así se sabe su origen y destino. El tráfico es multiplexado utilizando varios
DLCIs por cada enlace físico, es decir, un enlace físico puede soportar uno o más enlaces
virtuales.
- Circuitos virtuales permanentes (PVC). Los PVCs son enlaces predefinidos a través de la red Frame Relay y
que conectan dos sistemas finales. Son enlaces lógicos identificados cada uno de ellos por su DLCI. Estos
enlaces son de carácter permanente y se establecen de esta forma.
- Circuitos virtuales conmutados (SVC). A diferencia de los PVCs, los SVCs no están
permanentemente definidos en la red Frame Relay. El equipo terminal conectado requiere una
llamada de inicio para establecer un circuito virtual antes de una transmisión de datos. Las
características de esta transmisión se especifican en esta llamada. Asimismo cuando se termina la
transmisión, se cierra en enlace y el DLCI se libera para su uso posterior.
Una de las ventajas del Frame Relay es que los conmutadores utilizan una tabla de enrutamiento con el formato
siguiente
Puerto DLCI Puerto DLCI
entrada entrada salida salida
Esto ocupa muy poco espacio y por tanto cabe en memoria, y además como tiene pocos elementos, es de un
manejo extremadamente rápido, por lo que se introducen unos retardos mínimos en el tráfico Frame Relay.

Los mensajes del protocolo Frame Relay no son de longitud fija, con una longitud máxima de 8000 octetos,
aunque por defecto es de 1600 octetos.
La estructura del mensaje es la siguiente
Flags Dirección Datos Control de error Flags
Esta estructura es exactamente igual que la de los mensajes del protocolo HDLC que es el que lo soporta.
En cuanto al campo de dirección, de 2 octetos, consta de:
- El DLCI, 19 bits. Identificador del circuito virtual.
- FECN (Forward Explicit Congestion Notification), 1 bit. Si se activa, es para notificar al
dispositivo al que se le envían los mensajes de que el dispositivo emisor tiene problemas de
congestión. Cuando un switch Frame Relay detecta la existencia de congestión en la red, envía un
paquete FECN al dispositivo destino, indicando que se ha producido la congestión.
- BECN (Backward Explicit Congestion Notification, 1 bit. Si se activa, es para notificar al
dispositivo del que se reciben los mensajes de que el dispositivo receptor tiene problemas de
congestión. Cuando un switch Frame Relay detecta congestión en la red, envía un paquete BECN
al enrutador origen, instruyendo al enrutador para que reduzca la velocidad a la cual está
enviando los paquetes.
- DE (Discard Eligibility), 1 bit. Los mensajes con este bit activado, son susceptibles de ser
rechazados en caso de congestión. Cuando el enrutador detecta congestión de red, el switch
Frame Relay descarta en primer lugar los paquetes con el bit DE activo. El bit DE se activa,
cuando el nivel de tráfico es superior al ancho de banda contratado (CIR).
Gestión del tráfico

Con el fin de poder gestionar el tráfico de cada enlace, ya sea permanente PVC o temporal SVC), hay un
conjunto de parámetros que son los siguientes:
- Velocidad de la línea. Es la velocidad nominal de la línea.
- Commited Information Rate (CIR). Es el ancho de banda comprometido a utilizar en condiciones
normales. Esta velocidad es el promedio en un período de tiempo. El CIR también se refiere al
mínimo ancho de banda aceptable. El CIR puede ser inferior o igual a la velocidad de la línea, es
decir, el DTE puede enviar mensajes a mayor velocidad que el CIR.
- Burst Commited (BC). Es la cantidad máxima comprometida de datos que un usuario puede
enviar a la red en un tiempo dado y que la red garantizará la entrega de los mensajes en
condiciones normales.
- Burst Exceeded (BE). Es la cantidad de datos que un usuario puede exceder del BC durante un
período de tiempo dado. Si hay capacidad sobrante en la red, este exceso se entregará al destino.
Para evitar congestión, una implementación práctica es que todos estos mensajes tengan el bit DE
a 1. Sin embargo, durante un segundo, el CIR más el BE no pueden exceder de la velocidad de la
línea.
- Local Management Interface (LMI). El LMI es un conjunto de procedimientos y mensajes que se
intercambiarán entre los enrutadores y el conmutador Frame Relay con el fin de conocer el estado
de la red, es decir, el estado de la línea, la notificación de PVCs y SVCs añadidos y borrados y los
mensajes de estado sobre la disponibilidad de la línea.
Operación del LMI

Las principales funciones del proceso LMI son las siguientes:
- Determinar el estado operacional de distintos PVCs que el enrutador conoce.
- Transmitir mensajes de actividad para garantizar que el PVC permanezca activo y no se inhabilite
por inactividad
- Comunicarle al enrutador que los PVC están disponibles
Además de las funciones básicas del protocolo Frame Relay para realizar la transferencia de datos, la
especificación Frame Relay incluye extensiones LMI que permiten soportar más fácilmente redes grandes y
complejas. Algunas extensiones LMI se denominan comunes y otras funciones LMI se consideran opcionales
Las LMI más empleadas son:
- Mensajes de estado de circuito virtual (común): Proporcionan comunicación y sincronización
entre la red y el dispositivo de usuario, informando periódicamente acerca de la existencia de
nuevos PVC y la eliminación de PVC existentes, y brindando información general acerca de la
integridad del PVC. Los mensajes de estado de circuito virtual evitan el envío de datos a través de
PVC que ya no existen.
- Multicast (opcional): Permite al emisor transmitir un sol mensaje pero que sea entregada por la
red a múltiples receptores. Así, el multicast soporta la distribución eficiente de mensajes de
protocolo de enrutamiento y protocolos de resolución de direcciones que normalmente se deben
enviar a varios destinos simultáneamente.
- Direccionamiento global (opcional): Otorga a los DLCIs significación global más que local,
permitiendo que se puedan usar para identificar una interfaz específica en relación con la red
Frame Relay. El direccionamiento global hace que la red Frame Relay se parezca a una red de
área local (LAN) en términos de direccionamiento. Los protocolos de resolución de direcciones,
por lo tanto, ejecutan su función en Frame Relay exactamente de la misma manera que en una
LAN.
- Control de flujo simple (opcional): Proporciona un mecanismo de control de flujo XON/XOFF
(de conexión/desconexión) que se aplica a toda la interfaz Frame Relay. Está destinado a
dispositivos cuyas capas superiores no pueden utilizar los bits de notificación de congestión y que
necesitan algún nivel de control de flujo.
La especificación Frame Relay también incluye procedimientos de LMI. Los mensajes LMI se envían en
mensajes que se distinguen por un DLCI específico del LMI. Es habitual utilizar el DLCI = 1023.
El formato de un mensaje LMI es el siguiente:
Señalador LMI DLCI Indicación de Discriminador Referencia Tipo de Datos Control Señalador
información de protocolo de llamada mensaje de error
sin numerar
Donde
- Señalador, 1 octeto
- LMI DLCI, 2 octetos. Número de DLCI empleado con LMI
- Indicación de información sin numerar, 1 octeto. Tiene el mismo formato que el indicador de
trama de información sin número (UI) de LAPB, con el bit de sondeo/final en cero.
- Discriminador de protocolo, 1 octeto.
- Referencia de llamada, 1 octeto. Su contenido son ceros.
- Tipo de mensaje, 1 octeto. Se han definido dos tipos de mensajes: mensajes de estado y mensajes
de petición de estado. Los mensajes de estado responden a los mensajes de petición de estado.
Ejemplos de estos mensajes son (1) mensajes de actividad (mensajes enviados a través de una
conexión para asegurar que ambos lados sigan considerando la conexión como activa) y (2) un
mensaje de estado de un informe individual sobre cada DLCI definido para el enlace.
- Datos
16.13 X.25
Es un protocolo de una red de comunicación digital de conmutación de mensajes orientado a la conexión.

- mensajes de longitud variable
- tiempo de latencia alto e impredecible
Es un protocolo que trabaja hasta nivel de red (3) según el modelo de referencia OSI. El nivel físico se basa en
las recomendaciones X21 y X21bis del CCITT.
La comunicación extremo a extremo se denomina circuito virtual y puede ser de 2 tipos:

- permanente. Es el caso de existencia de un tráfico muy frecuente.
- conmutado o temporal.
Nivel 3
Como en el protocolo Frame Relay, por cada interface física se pueden establecer uno o más enlaces lógicos, así
los tipos definidos son:
Enlaces permanentes Corresponde a la unión permanente entre dos dispositivos DTE, por
lo que no hay necesidad de iniciar una llamada
Enlaces de entrada Enlaces por los que sólo se pueden recibir llamadas.
Enlaces normales Enlaces por los que sólo se pueden recibir y efectuar llamadas.
Enlaces de salida Enlaces por los que sólo se pueden efectuar llamadas.
En este nivel hay cuatro tipos de mensajes distintos:

- Mensajes de establecimiento y liberación de llamada
- Mensajes de datos e interrupción
- Mensajes de control de flujo y reinicio
- Mensajes de rearranque.
La estructura del mensaje a este nivel es
GFI Número de grupo de Número de Identificador de Identificador Datos

canales lógicos canal lógico tipo de mensaje adicional de
control
Donde
- GFI (General Format Identifier), 4 bits.
- Número de grupo de canales lógicos, 4 bits
- Número de canal lógico, 1 octeto.
- Identificador de tipo de mensaje, 1 octeto. También se emplean los 2 primeros bits del campo
GFI.
- Identificador adicional de control, 1 octeto
- Datos
Nivel 2
Sus funciones son de:
- sincronización
- establecimiento y desconexión del enlace
- control de flujo
- detección y recuperación de errores
A este nivel de control de enlace, se emplea el protocolo LAPB (Link Access Procedure Balanced). Es un
protocolo con modo de operación asíncrono balanceado y se corresponde con el protocolo HDLC en la
modalidad AMB.
Las estaciones son de tipo combinada y utiliza líneas de comunicación del tipo full dúplex para datos.
Es un protocolo simétrico, porque ambos extremos tienen las mismas funciones y en cuanto al polling,
únicamente hay cuando las tramas de datos no suministran la aceptación del nivel de enlace necesario.
No tiene algoritmos de encaminamiento.
La estructura del mensaje a este nivel es
Flag Dirección Control Datos Control de error Flag
Donde
- Flag, 1 octeto. Su contenido es 0x7E
- Dirección, 1 octeto. Si el dispositivo que envía el mensaje es un DTE, contiene un 1 y si es DCE
un 3.
- Control, 1 octeto. Contiene la solicitud, la respuesta o en las tramas de información, la cuenta de
las tramas enviadas y recibidas.
- Datos. En este campo va el mensaje entero de nivel 3, como corresponde a todas las
encapsulaciones.
En este nivel hay tres tipos de mensajes:
- Mensajes de información.
- Mensajes de supervisión. Se utilizan para funciones de control en la fase de transmisión de datos.
Sin el campo de datos.
- Mensajes no numerados. Se utilizan para funciones adicionales de control fuera de la fase de
transmisión de datos Sin el campo de datos.
Nivel 1
Como en todos los protocolos, en este nivel se especifican las características mecánicas y eléctricas.
Las recomendaciones que se usan en este nivel son:
- X.21 (X24, X26, X27)
- X21 bis (V24, V28, V35), similar a la RS-232-C
- X32 para conexión a través de circuitos conmutados
16.14 ATM - Asynchronous Transfer Mode

ATM (Asynchronous Transfer Mode) es un protocolo basado en la conmutación de celdas. Para conocer y
seguir la evolución de este protocolo es fundamental acceder a la documentación del ATM Fórum.
Las características principales de este protocolo ATM son :

- orientado a conexión
- celdas de longitud pequeña y fija
- tiempo de latencia pequeño y predecible
- velocidades de hasta 622 Mbps (OC-12)
Su modelo de referencia es distinto al modelo OSI, sin embargo, sus niveles son equivalentes a los de enlace y
red de este modelo como corresponde a los protocolos de los sistemas de comunicaciones.
El principal objetivo de este protocolo es:

- conseguir que los retardos entre mensajes sean lo más iguales posibles y
- la posibilidad de establecer controles de calidad de servicio.
Ello se consigue con

- un protocolo orientado a conexión
- unos protocolos de señalización
- un tamaño de mensaje muy pequeño, 53 octetos, de los cuales 5 son de cabecera y
- una gestión de prioridades de los mensajes.
En cuanto a las interfaces que soporta, hay 2 tipos básicos:

- UNI (User-network interface). Esta interface conecta un dispositivo final a un dispositivo
intermedio. Sus estándares soportan E1/T1, 25 Mbps, OC-3 (155 Mbps) y OC-12 con OC-48 (2,4
Gbps). La interface de OC-3 es para cable UTP y fibra óptica.
- NNI (network-network interface). Es la interface entre dispositivos intermedios, como por
ejemplo conmutadores.
El esquema básico es el siguiente
UNI
NNI
NNI UNI
NNI
UNI
Este protocolo emplea lo que se llama canales virtuales. Antes de que un transmisor empiece a enviar celdas al
destino, la red ATM primero debe establecer un canal virtual (VC) del origen al destino. Un canal virtual no es
más que un circuito virtual. Cada VC es un camino que consiste en una secuencia de enlaces entre origen y
destino. En cada enlace, el VC tiene un identificador de circuito virtual (VCI). Cuando se establece un VC, sus
tablas en los conmutadores son actualizadas. Estos VC pueden ser permanentes o dinámicos.
En cuanto a los enlaces, pueden ser de 2 tipos:

- VPC (Virtual Path Connection), e identificados por su VPI (Virtual Path identifier).
- VCC (Virtual Channel Connection) que son contenidas en VPCs, y que por tanto son sus
unidades básicas. Cada uno de ellos se identifica por su VCI (Virtual Channel Identifier).
Sin embargo de acuerdo con los 2 extremos también hay los tipos siguientes:
- Private UNI. Conexión entre un UNI y un NNI.
- Private NNI. Conexión entre dos NNI correspondientes a sistemas privados.
- Public UNI. Conexión entre un NNI de un sistema privado y un NNI de un sistema público.
En cuanto a los conmutadores utilizan una tabla de conmutación con el formato siguiente
Puerto VPI/VCI Puerto VPI/VCI

entrada entrada salida salida
Esta tabla ocupa muy poco espacio y por tanto cabe en memoria, y además como tiene pocos elementos, es de un
manejo extremadamente rápido, por lo que se introducen unos retardos mínimos dentro del conmutador con
protocolo ATM.
Por otro lado, estos circuitos virtuales pueden ser permanentes (PVC) o conmutados (SVC).
También los enlaces pueden ser punto a punto o punto a multipunto.
Clases de servicios
Hay 5 clases de servicios y cada uno permite un control de calidad de servicio distinto. Estas clases de servicios
son:
 CBR (constant bit rate). La velocidad de las celdas es constante en el tiempo. Este tipo de servicio es
necesario en videoconferencia, tráfico telefónico y televisión, en que los datos deben fluir de forma
uniforme y con un retardo mínimo. Esta clase se usa para emular conmutación.
 VBR - NRT (variable bit rate - non-real time). Esta clase permite a los usuarios una velocidad variable en el
tiempo en función de la importancia de la información. La multiplexación estadística hace un uso óptimo de
los recursos de las redes. Un ejemplo es e-mail multimedia.
 VBR - RT (variable bit rate - real time). Como el anterior pero que en este caso el tráfico es sensible al
retardo de celdas, como puede ser la voz y vídeo interactivo comprimido.
 ABR (available bit rate). Se basa en la capacidad de flujo y es el caso del tráfico de transferencia de ficheros
y correo electrónico. Este tráfico es insensible a los retardos y no es prioritario. En el caso de aplicarlo entre
conmutadores, es conveniente reducir su retardo al máximo. En función de la congestión existente, la fuente
debe controlar el flujo. Los usuarios pueden establecer un mínimo caudal.
 UBR (unspecified bit rate). Es el más general y es el habitual en redes con protocolo TCP/IP.
Parámetros técnicos
Los parámetros técnicos asociados a un enlace ATM son:
- CLR (cell loss ratio). Es el porcentaje de celdas no entregadas a su destino porque se perdieron
por haber congestión.
- CTD (cell transfer delay). Es el retardo experimentado por una celda entre su entrada y salida de
la red. Incluye los retardos de propagación, la de las colas de espera de los conmutadores
intermedios y los tiempos de servicios de los puntos de colas de espera.
- CDV (cell delay variation). Es el valor de la varianza del retardo de una celda.
- PCR (peek cell rate). Es la máxima velocidad de transmisión. Este valor es el inverso del tiempo
transcurrido entre la salida y la llegada.
- SCR (sustained cell rate). Es la velocidad media de transmisión.
- BT (burst tolerance). Es el valor máximo de ancho de banda.
Estructura de la celda
La celda ATM tiene una longitud total fija de 53 octetos, 5 de cabecera y 48 de datos. Su estructura es la
siguiente
Cabecera Datos
Modelo ATM y el modelo OSI

Una cuestión que a menudo causa gran confusión es pensar en que capa del modelo OSI corresponde el
protocolo ATM. La adopción de un modelo de capas superpuestas por el fórum ATM hace que se pueda pensar
que ATM es un protocolo de nivel 2 y de nivel 3 según el modelo OSI, porque posee muchas de las
características de este nivel, incluido el direccionamiento y el enrutamiento.
En la práctica la cuestión es discutible y se debe a las limitaciones del modelo OSI. El modelo básico OSI no
incorpora el concepto de redes superpuestas, donde un nivel de red se superpone a otro. Así hoy los protocolos
de nivel 3 tales como el IP y el IPX se transportan sobre otros protocolos de red tales como el X.25 y el Frame
Relay.
El modelo de capas superpuestas de ATM se eligió para separar y por lo tanto facilitar a los técnicos la tareas de
trabajar con los protocolos de ATM y facilitar la tarea de los que trabajan con protocolos que operan con ATM.
Lo que hace que ATM sea un protocolo de nivel de red es la complejidad de su direccionamiento y
enrutamiento, y que es independiente del hecho de que otros protocolos de nivel de red corran sobre ATM.
Direccionamiento
El fórum ATM ha definido dos modelos en cuanto a direccionamiento:
- Modelo peer. Uso de los mismos esquemas que el direccionamiento de los protocolos de nivel de
red tales como IP, IPX, etc.
- Modelo subnetwork o overlay. Un modelo distinto de los protocolos IP, IPX, etc., igual que han
hecho otros protocolos de comunicaciones como el X.25
Este último modelo es el que se recomienda y sus sintaxis se basa en el direccionamiento NSAP del modelo OSI,
no es NSAP. Estas direcciones emplean 20 octetos y solo se emplean dentro de las redes ATM. Esta direcciones
constan de tres componentes:
AFI (Authority and Format Identifier) Identificación del tipo y formato del IDI
IDI (Initial Domain Identifier) Identificación del dominio
DSP (Domain Specific Part) Contiene la información de enrutamiento.
El protocolo Q.2931 define los campos de la dirección origen y destino a efectos de señalización, y también la
definición de los campos de subdirecciones.
Aunque la estructura de las direcciones es la mencionada, hay tres formatos posibles de uso en cuanto al IDI
Formato NSAP El IDI es un número de E.164

Format DCC El IDI es una identificación del país
Format ICD El IDI se rige por la ISO 6523
En cuanto al DSP (Domain Specific Part), se subdivide en:

- RD (Routing Domain), dominio de enrutamiento
- AREA, identificación del área
- ESI (End System Identifier), identificador de sistema final y coincide con la dirección MAC de
LAN.
Señalización
En cuanto a señalización, el protocolo ATM se basa en la especificación UNI 3.1 y consiste en el método one-
pass, que es el habitual en las redes de telecomunicaciones.
Este método consiste en que es dispositivo origen el que solicita la conexión, propagándose esta solicitud hasta
el dispositivo destino. Los protocolos de enrutamiento de ATM serán los encargados de que los paquetes sigan
esta ruta. En este establecimiento de la ruta, se incluyen los parámetros de tráfico y de calidad de servicio,
solicitado asimismo por el dispositivo origen.
Así la solicitud de establecimiento de conexión consiste en un mensaje setup enviado por el dispositivo origen,
que contiene la dirección del dispositivo destino y los parámetros de tráfico y calidad de servicio. La aceptación
de la conexión por parte del dispositivo destino se realiza mediante el envío de un mensaje connect. Tan pronto
lo ha recibido el dispositivo origen, empieza a transmitir datos.
El mensaje release proveniente del dispositivo destino provoca la cancelación de la conexión.
Protocolos
El esquema de protocolos de ATM es
Señalización y Clase A Clase B Clase C Servicios Clase D
control CBR VBR orientados a conexión Servicios sin
conexión
AAL 1 AAL 2 AAL 3/4
AAL 5
Nivel de Adaptación ATM Subnivel CS
Subnivel SAR
Nivel ATM
Nivel físico ATM Subnivel TC
Subnivel PMD
La función del nivel AAL (ATM Adaptation Layer) es realizar el mapeo de los mensajes en el campo de
información de la celda ATM y viceversa. Hay 4 tipos diferentes de AAL : AAL1, AAL2, AAL3/4 y AAL5.
Estos AALs ofrecen distintos servicios para los protocolos de más alto nivel.
La RFC1483 determina como encapsular los protocolos de enrutamiento mediante el protocolo de nivel 5 de
ATM (AAL-5).
Normalmente ATM se usa en la tecnología a nivel de enlace dentro de Internet. Un tipo especial de AAL, el
AAL5, ha sido desarrollado para permitir al TCP/IP interfasear con ATM. A la interfase IP a ATM, el AAL5
prepara los datagramas IP para poder ser transportados por ATM; en la interfase ATM a IP, AAL5 reensambla
las celdas ATM en datagramas IP. En la figura siguiente se ve la pila de protocolos en las regiones de Internet
que usan ATM. En esta configuración, los tres niveles de ATM han sustituído a los dos niveles inferuiores de la
pila de protocolos de Interenet. En particular, el nivel de red de Internet ve TM como un protocolo de nivel de
enlace.
Nivel aplicación (HTTP,FTP,...)
Nivel transporte (TCP,UDP,...)
Nivel red (IP)
AAL5
Nivel ATM
Nivel físico ATM
Nivel físico ATM

El nivel físico se preocupa del envío de una celda ATM sobre el medio de transmisión. Este nivel consta de dos
subniveles: el subnivel PMD (Physical Medium Dependent) y el subnivel TC (Transmission Convergence).
Subnivel Responabilidad
TC (Transmission Convergence) Inserción de una celda vacía
Delineación de celdas
Adaptación de la trama de transmisión.
PMD (Physical Medium Dependent) Medio físico
Voltajes y tiempos de bit
Estructura de trama
El subnivel PMD (Physical Medium Dependent) es el último nivel de la pila de protocolos ATM. Como indica
su nombre, el nivel PMD depende del medio físico del enlace; en particular las especificaciones del subnivel son
diferentes según el medio (fibra, cobre, o lo que sea). También es responsabilidad de este subnivel la generación
y delineación de los bits. Hay dos clases de subniveles PMD: los subniveles PMD que tienen una estructura de
trama de transmisión (por ejemplo, T1, T3, SONET o SDH) y los que no la tienen. Si el PMD tiene una
estructura de trama, entonces es de su responsabilidad la generación y delineación de ellas. El subnivel PMD no
reconoce celdas. Algunos subniveles PMD incluyen:
- SONET/SDH sobre fibra monomodo. Como T1 y T3, SONET y SDH tienen estructuras de trama
que establecen la sincronización de bit entre el transmisor y el receptor de los dos extremos del
enlace. Hay varias velocidades estandarizadas: OC-1 (51,84 Mbps), OC-3 (155,52 Mbps) y OC-
12 (622,08 Mbps)
- Las tramas T1/T3 sobre fibra, microondas y cobre.
- Basado en celdas sin tramas. En este caso el reloj del receptor se obtiene de la señal transmitida.
En cuanto al subnivel TC (Transmission Convergence), debe realizar las funciones necesarias teniendo en cuenta
que las especificaiones del nivel ATM son independientes del nivel físico, es decir, no conoce lo que es SONET,
T1 o medio físico. Por tanto este subnivel por la parte del enlace debe aceptar las celdas ATM del nivel ATM y
prepararlas para la transmisión por el medio físico y por el otro lado, agrupar los bits que le llegan del medio
físico en celdas y pasarlas al nivel ATM. Estos son los trabajos del subnivel TC, que está por encuma del
subnivel PMD y debajo del nivel ATM. El subnivel TC también depende del medio físico, así si cambiamos el
mdio físico o la estructura de trama subyacente, debemos cambiar el subnivel TC.
El subnivel TC también realiza funciones de correción de error de la cabecera (HEC – Header Error Correction)
y también realiza las tareas siguientes:
- En el lado transmisor, el subnivel TC genera el byte HEC para cada celda ATM que es
transmitida. En el lado receptor, el subnivel TC usa el byte HEC para corregir todos los errores de
un bit y algunos eroores de más de un bit de la cabecera, reduciendo la posibilidad de enrutar
celdas incorrectas. El HEC solo computa los primeros 32 bits de la cabecera de la celda, mediante
la técnica polinomial de 8 bits.
- En el lado receptor, el subnivel TC delinea celdas. Si el subnivel PMD está basado en celdas sin
tramas, entonces esta delineación se hace normalmente corriendo el HEC en todos los conjuntos
contiguos de 40 bits, es decir, 5 bytes. Cuando hay un encaje, se delinea una celda. Cuando han
encajado 4 celdas consecutivas, se declara una sincronización de celda y las celdas subsiguientes
se pasan al nivel ATM.
- Si el subnivel PMD se basa en celdas sin tramas, el subnivel envía una celda vacía cuando el
nivel ATM no ha suministrado una celda, de este modo se genera un flujo continuo de celdas. El
subnivel TC del lado receptor no pasa celdas vacías al nivel ATM. Las celdas vacías tienen una
marca en el campo PT de la cabecera ATM.
Nivel ATM
Cuando IP corre sobre ATM, la celda ATM juega el papel de la trama del nivel de enlace. El nivel ATM define
la estructura de la celda ATM y su significado dentro de la misma. La estructura de la cabecera es la siguiente:
VCI Tipo de Prioridad Control de

celda error
Donde
- VCI (Virtual Channel Identifier), 28 bits. Identificador del canal virtual que pertenece la celda.
- Tipo de celda, 3 bits. Pueden ser por datos, por mantenimiento o si es una celda vacía.
- Prioridad, 1 bit. Se utiliza para distinguir entre el tráfico de alta prioridad y el de baja prioridad.
También si hay congestión, permite al conmutador empezar a descatar las celdas de baja
prioridad.
- Control de error (HEC), 8 bits.
Nivel de adaptación ATM

El propósito de este nivel de adaptación ATM (AAL) es permitir que los protocolos y aplicaciones existentes
puedan correr sobre ATM. AAL se eimplementa solamente en los extremos de la red ATM. Un punto extremo
puede ser un host de sistema o un enrutador IP si ATM se emplea para conectar dos enrutadores IP. En este caso,
el nivel AAL es análogo al nivel de transporte de la pila de protocolos Internet.
El subnivel AAL tiene sus campos de cabecera específicos y que forman parte del campo de datos de la celda. El
ITU y el forum ATM han estandarizado varias AALs. Algunas de las más importantes AALs y clases de servicio
ATM que son soportadas incluyen
AAL1 : Para servicios CBR y emulación de circuito.
AAL2: Para servicios VBR
AAL5 : Para datos, por ejemplo, datagramas IP
En cuanto a la estructura AAL, tiene dos subniveles: el nivel de segmentación y reensamblaje (SAR) y el
subnivel de convergencia (CS). El subnivel SAR está por encima del nivel TM y el subnivel CS entre la
aplicación del usuario y el subnivel SAR. El nivel más alto de datos, por ejemplo un datagrama IP, es primero
encapsulado en un subnivel de convergencia común (CPCS – Common Part Convergence Sublayer) en el
subnivel de Convergencia. Este PDU puede tener una cabecera CPCS y una cola CPCS. Tipicamente el CPCS-
PDU es mucho más largo que la longitud del campod e datos de la celda ATM; así el CPCS-PDU se debe
segmentar en el origen ATM y reensamblarlo en el destino ATM. El subnivel SAR segmenta el CPCS-PDU y
añade la cabecera AAL y los bits de cola para formar el campo de datos de la celda ATM. De pendiendo del tipo
de AAL, las cabeceras y colas de Aal y CPCS pueden estar vacías.
AAL5
El AAL5 es un AAL de bajo “overhead” que se usa para transportar datagramas IP sobre redes ATM. Con
AAL5, la cabecera y la cola AAL están vacías; asi todos los 48 bytes de datos de la celda ATM se usan para
trasnportar los segmentos del CPCS-PDU. Un datagrama IP ocupa los datos del CPCS-PDU, que puede tener
una longitud de 1 a 65535 bytes.
Datos CPCS-PDU PAD Longitud CRC
El campo PAD asegura que el CPCS-PDU es un múltuple entero de 48 bytes, de aquí que su longitud sea de 0 a
47 bytes.
El campo longitud identifica el tamaño del campo de datos CPCS-PDU, de forma que así se determina el tamaó
del PAD en destino.
El campo CRC es el mismo que se usa en Ethernet, Tiken Ring y FDDI.
En el origen ATM, el SAR de AAL5 trocea el CPCS-PDU en segmentos de 48 bytes. El tercer bit del campo PT
de la cabecera de la celda ATM, que normalmente es 0, si es 1 indica que es la última celda de una
segmentación.
En el destino ATM, el nivel ATM envía las celdas con un VCI específico al buffer del subnivel SAR. Las
cabeceras de la celda ATM se eliminan y el tercer bit del campo PT de la cabecera se usa para delinear las
CPCS-PDUs. Una vez el CPCS-PDU es delineado, se pasa al subnivel de convegencia de AAL. En el subnivel
de convergencia, se usa el campo longitud para extraer los datos CPCS-PDU, que son pasados al nivel superior.
16.15 SMDS - Switched Multimegabit Data Service

SMDS (Switched Multimegabit Data Service) es un sistema de comunicaciones digital que se emplea en Estados
Unidos. Se trata de un servicio de conmutación de mensajes con velocidades de 1,544 Mbps sobre DS-1 (Digital
Signal level 1) o 44,736 Mbps sobre DS-3 (Digital Signal level 3) con previsión de llegar a los 155,520 Mbps
con OC-3c. Su equivalente en Europa es el CBDS (Connectionless Broadband Data Service).
El SMDS opera con mensajes de longitud variable, máximo 9188 octetos, que los fracciona en celdas de 53
octetos, las cuales son ensambladas en la recepción.
El protocolo SIP (SMDS Interface Protocol) es el protocolo de este sistema de comunicaciones, no está
orientado a conexión y consta de 3 niveles, físico, enlace y red, según el modelo de referencia OSI.
El nivel 2 se basa en el estándar IEEE 802.6 DQDB y el nivel 1 en el protocolo PLCP (Physical Layer
Convergency Protocol).
El SMDS se encapsula en los protocolos de nivel enlace (2) del modelo OSI, 802.3, 802.4, 802.5 y FDDI.
El esquema básico del SMDS es el siguiente:
Router Switch SMDS Switch Router
Como se ve en la figura consiste en comunicar dos enrutadores con conexión a una LAN mediante este sistema
de comunicaciones SMDS. Para ello cada enrutador debe estar conectado a un switch SMDS y soportar a su vez
este protocolo.
El protocolo SMDS soporta hasta 5 clases de acceso con velocidades de 4, 10, 16, 25, y 34 Mbps.
Utiliza un direccionamiento propio, en que cada dirección consta de 10 dígitos, con posibilidad de multicast.
Protocolo SIP – nivel 3

El mensaje de este nivel consta de la estructura siguiente:
Cabecera Información PAD Control de error Cola
La estructura de la cabecera con una longitud de 36 octetos consta de los campos siguientes:
- Marca de inicio, 1 octeto
- Longitud, 2 octetos. Es un valor en octetos correspondiente al número de octetos desde el campo
de dirección de destino hasta el de control de error.
- Dirección de destino, 8 octetos
- Dirección de origen, 8 octetos
- Identificación del protocolo de nivel superior, 6 bits
- Longitud del PAD, 2 bits
- Calidad de servicio, 4 bits
- Datos
- Relleno
- Control de error

La longitud de los mensajes de este nivel es de 53 octetos y cada uno de ellos tiene la estructura siguiente
Control de Información de Tipo Identificación Datos Longitud Control de

acceso control de red error
Donde
- Control de acceso, 1 octeto. Su contenido depende del origen o destino del flujo de datos.
- Información de control de red, 4 octetos.
- Tipo, 2 bits. Es un indicativo si es el primer mensaje, el último o uno intermedio.
- Identificación, 14 bits. Es un indicativo asociarlo con el mensaje de nivel 3.
- Datos, 352 bits
- Longitud, 6 bits
- Control de error, 10 bits

Es el protocolo de nivel físico y que opera entre el dispositivo del usuario y la red. Este nivel consta de 2 partes:
un subnivel de transmisión del sistema y el protocolo PLCP (Physical Layer Convergence Protocol).
Protocolos de Internet 133
Capítulo 17. Protocolos de Internet
Dentro de este apartado se contemplan aquellos protocolos de nivel de sesión, presentación y aplicación según el
modelo de referencia OSI, que se utilizan en el ámbito de Internet. En realidad, podrían formar parte del
apartado de protocolos de aplicaciones, pero dada su trascendencia actual, se ha decidido crear un apartado
donde se contemplen de forma específica.
Así por una parte tenemos el protocolo HTTP, básico de las páginas Web, y por otra protocolos que se usan en
correo electrónico como el SMTP y el POP3. No hay duda, de que estos protocolos hoy en día forman parte de
las redes TCP/IP, no solo en Inetrenet sino también en redes TCP/IP internas de una empresa.
No se trata de un desarrollo exhaustivo, sino de explicar de forma breve los protocolos que se utilizan de forma
más extensa.
17.1 Protocolos de correo electrónico

El correo electrónico consiste en el envío y la recepción de mensajes entre distintos usuarios de una red de datos.
En Internet, se emplean para ello 3 protocolos:

- SMTP (Simple Mail Transfer Protocol), para enviar mensajes desde un usuario a un servidor de
correo y también entre servidores de correo.
- POP3 (Post Office Protocol), para que los usuarios puedan recoger sus mensajes del servidor de
correo.
- IMAP4 (Internet Message Access Protocol) , también para recoger mensajes de un servidor de
correo.
Inicialmente en las redes TCP/IP se empleaba la codificación de caracteres en 7 bits, lo cual era suficiente en
cuanto solo se empleaba el idioma inglés. Pero la internacionalización de Internet ha hecho necesario enviar
textos con caracteres codificados con 8 bits, tales como el código ASCII. Por ello se han tenido que incorporar
unas extensiones para soportar esta codificación de 8 bits y así se han especificado las llamadas MIME.
En cuanto al formato de las direcciones de correo electrónico es el siguiente
nombre @ servidor
donde
- nombre es el nombre del usuario.
- servidor es el nombre del servidor de correo SMTP en el cual el usuario esté dado de alta y tenga
su buzón de correo.
17.1.1 SMTP - Simple Mail Transfer Protocol
El protocolo SMTP es un protocolo que se emplea para enviar mensajes de correo electrónico desde un usuario a
otro usuario. Para ello el usuario origen enviará el mensaje a un servidor de correo SMTP. Este servidor puede
contener el buzón del usuario destino o no. En caso negativo, lo reenviará a otro servidor de correo SMTP hasta
que llegue a su destino, es decir, el buzón del usuario destino.
Este protocolo SMTP se corresponde al nivel de aplicación según el modelo de referencia OSI. Sus
especificaciones se encuentran detalladas en la RFC 821.
En la RFC 822, en cuanto al formato de los mensajes de correo se describe la sintaxis de la cabecera, sus campos
y el significado de cada uno de ellos. La RFC 1049 describe que tipos de documentos pueden formar parte del
cuerpo del mensaje de correo. Los estándares son: PostScript, Scribe, SGML, TEX, TROFF y DVI.
Las Extensiones de Servicio SMTP se describen en 3 RFCs:

- RFC 1869. Describe un estándar para que el servidor SMTP pueda informar al destinatario de las
extensiones que soporta.
- RFC 1652. Describe un protocolo para la transmisión de caracteres de 8 bits, que permite a un
servidor SMTP indicar que acepta caracteres de 8 bits. Las MIME y las extensiones de SMTP son
complementarias. Cuando un cliente SMTP intenta enviar datos de 8 bits a un servidor de correo
que no soporta esta extensión, el cliente SMTP debe codificar el contenido de su mensaje con
caracteres de 7 bits o de lo contrario el servidor de correo contestará con un mensaje de error.
- RFC 1870. Describe una extensión para la declaración del tamaño del mensaje que permite a un
servidor de correo informar al usuario del tamaño máximo que acepta.
Funcionamiento
El protocolo SMTP se basa en una entrega de mensajes extremo a extremo, así el usuario SMTP entregará el
mensaje al servidor SMTP del dispositivo de destino. El usuario guarda el mensaje hasta que sabe que ha llegado
a su servidor de destino.
En algunas implementaciones, hay la posibilidad de intercambiar correo entre el sistema SMTP y otros correos
locales. Para ello se utilizan pasarelas de correo. En estos casos, la transmisión sigue siendo del tipo extremo a
extremo, ya sea de dispositivo a pasarela, de pasarela a dispositivo o de pasarela a pasarela.
El protocolo SMTP es un protocolo cliente/servidor, por lo que siempre es el usuario SMTP el que inicia la
sesión y el servidor de correo el que contesta.

Cada mensaje de correo consta de:
- Una cabecera que siempre termina con una línea nula y
- Un contenido que es el cuerpo del mensaje formado por un conjunto de caracteres.
La cabecera consta de varios campos, cada uno en una línea distinta y que son:
- TO. Indicativo de la dirección de correo electrónico de los destinatarios principales.
- CC. Indicativo de la dirección de correo electrónico de los destinatarios que tienen que recibir una
copia del mensaje.
- FROM. Indicativo de la dirección de correo electrónico del remitente.
- REPLY-TO. Indicativo de la dirección de correo electrónico del usuario en el caso de respuesta
de este mensaje. Por defecto es el propio remitente.
- RETURN-PATH. Ruta a seguir del mensaje de respuesta.
- SUBJECT. Título del mensaje.
Operación
La secuencia que se sigue cuando se envía un mensaje es la siguiente:
- El remitente SMTP establece una conexión TCP con el servidor SMTP destino y espera que el
servidor le envíe un mensaje del tipo 220 Service ready o 421 Service not available. El primero es
de conformidad y el segundo es de rechazo de la solicitud.
- A continuación el remitente envía un mensaje HELO con su identificación. Si el remitente SMTP
soporta las extensiones SMTP definidas en la RFC 1869, puede enviar un mensaje EHLO en vez
de un HELO. Si el servidor SMTP no soporta estas extensiones, enviará un mensaje del tipo 500
Syntax error, indicativo de la existencia de un error.
- El remitente envía ahora un mensaje MAIL con la identificación del destinatario (campo FROM).
Este mensaje también contiene el campo REVERSE-PATH para poder informar de posibles
errores por parte del servidor destinatario. Si todo es correcto, el servidor envía un mensaje del
tipo 250 OK.
- Ahora el remitente envía una serie de mensajes RCPT con la identificación de los destinatarios.
De cada uno de ellos debe recibir un mensaje del tipo 250 OK o 550 No such user. El primero es
de conformidad y el segundo se genera si no encuentra el destinatario.
- A continuación el remitente envía un mensaje DATA con todos los datos del mensaje. El servidor
de correo responde con un mensaje del tipo 354 Start mail input y especifica la secuencia de
caracteres empleados para terminar el mensaje.
- Ahora el cliente envía los datos línea a línea y el servidor de correo debe responder a cada una de
ellas con un mensaje del tipo 250 OK.
- Si el remitente no tiene más mensajes que enviar, enviará un mensaje QUIT, que será contestado
con un mensaje del tipo 221 Service closing transmission, cerrándose así la conexión entre el
usuario y el servidor de correo.
17.1.2 MIME - Multipurpose Internet Mail Extensions
El protocolo SMTP tiene las siguientes limitaciones:

- no puede transmitir ficheros ejecutables o similares, tales como utilidades UNIX Uuencode y
Uudecode.
- no puede transmitir texto con caracteres ASCII, cuyo código sea superior al 128 porque solo
emplea 7 bits por carácter. Es el caso de los caracteres especiales de muchos idiomas.
- los servidores SMTP pueden rechazar mensajes de correo superiores a un cierto tamaño.
- las pasarelas SMTP que traducen de ASCII a EBCDIC y viceversa no tienen tablas completas
para ello.
Para solventar estas limitaciones, se han definido las MIME (Multipurpose Internet Mail Extensions), que no es
un protocolo sino unas extensiones de correo electrónico y que también se usan en otros protocolos tales como el
HTTP.
Las MIME fueron definidas básicamente para poder enviar mensajes de correo electrónico con caracteres no-
ASCII. Las MIME no sustituyen ni el protocolo SMTP ni el POP3. Las MIME permiten enviar datos codificados
en ASCII y transmitirlos dentro de un mensaje de correo estándar. Para ello es necesario que cada mensaje tipo
MIME contenga no solo la información a transmitir sino también el tipo de datos y la representación de los
mismos.
La información de las MIME reside en una cabecera donde se especifica la versión de las MIME, el tipo de datos
y el código a utilizar para la conversión de datos a ASCII. Por ejemplo el envío de una imagen GIF puede
contener los campos:
From: [email protected]
To: [email protected]
MIME-version: 1.0
Content-Type: image/gif
Content-Transfer-Encoding: base64
... datos de la imagen gif ...
Como se ve en el ejemplo, la cabecera MIME consta de los campos:

- MIME-version. Contiene la versión de las extensiones MIME empleadas en el mensaje.
- Content-Type Contiene la especificación del tipo de fichero, en este ejemplo es un fichero de
imagen y tipo GIF
- Content-Transfer-Encoding. Especifica el tipo de codificación empleada. Las codificaciones
posibles son: 7-bit por defecto, 8-bit, binario y Base64.
El campo Content-Type consta de 2 identificadores, un tipo y un subtipo relacionado con el anterior. Los tipos
estándar son:
Text Caso de que se transmita texto

Image Si los datos del mensaje corresponden a formato de imagen.
Audio Formatos de audio
Video Formatos de vídeo
Application Datos para un programa
Multipart Caso de un mensaje con varias partes y cada una de ellas con tipo y codificación
distinta.
Message Un mensaje completo
Mensajes Multipart
El campo Content-Type si es multipart, permite que un mensaje conste de varias partes, con lo que se consigue
una mayor flexibilidad.
Este tipo tiene 4 subtipos posibles:
- Mixed. Este subtipo permite que en un solo mensaje contenga varios submensajes independientes,
cada uno con su tipo y su codificación. De esta forma se pueden incluir en un mensaje, imágenes,
audio, vídeo, etc.
- Alternative. Permite que en un mismo mensaje se pueda incluir una única información en
distintos formatos. Esto es importante cuando los destinatarios tienen distinto hardware y/o
sistema operativo.
- Parallel. Permite incluir en un mensaje subpartes que se pueden ver juntas, por ejemplo,
reproducir audio y vídeo simultáneamente.
- Digest. Este subtipo incluir en un mensaje otros mensajes.
A continuación hay un ejemplo de un mensaje multipart.
From - Tue Jan 08 19:06:08 2002

X-UIDL: 36e5bfce00001b38
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
Return-path:<[email protected]>
Received: from listas.intercom.es ([212.66.160.7]) by mail.hotmail.com (Sun Internet Mail Server
sims.3.5.2000.03.23.18.03.p10) with SMTP id <[email protected]> for usuario@sims-
ms-daemon; Tue, 8 Jan 2002 03:29:00 +0100 (MET)
Received: (qmail 4852 invoked by uid 0); Tue, 08 Jan 2002 03:00:31 +0000
Received: (qmail 3776 invoked from network); Tue, 08 Jan 2002 00:13:05 +0000
Date: Mon, 07 Jan 2002 22:39:34 +0100
From: "Sololinux.com" <[email protected]>
Subject: Sololinux.com - Martes, 8 de Enero de 2002
To: =?iso-8859-1?Q?Boletin_S=F3lo_Linux?= <[email protected]>
Message-id: <003201c197c3$dfe07290$0d0314ac@teresa> MIME-version: 1.0
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
Content-type: MULTIPART/related;
BOUNDARY="Boundary_(ID_n+HzxHu0skkVB9AbIpE/eg)"; type="multipart/alternative"
Precedence: bulk
Delivered-to: mailing list [email protected]
Delivered-to: moderator for [email protected]
Mailing-List: contact [email protected]; run by ezmlm
X-No-Archive: yes
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
X-Priority: 3
This is a multi-part message in MIME format.
--Boundary_(ID_n+HzxHu0skkVB9AbIpE/eg)
Content-type: MULTIPART/ALTERNATIVE;
BOUNDARY="Boundary_(ID_Zl6wJjt5b1l34ISR7bdI6A)"
--Boundary_(ID_Zl6wJjt5b1l34ISR7bdI6A)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: quoted-printable
SOLOLINUX.COM - El d=EDa a d=EDa con la actualidad sobre Linux - =

Edita Noticias.com -=20
Martes, 08 de Enero de 2002=20
Lanzamiento del kernel 2.5.2 pre9=20

R=E1pida actualizaci=F3n para mencionar el lanzamiento de la =

=FAltima actualizaci=F3n del kernel Linux, concretamente la 2.5.2 pre 9.
--Boundary_(ID_Zl6wJjt5b1l34ISR7bdI6A)
Content-type: text/html; charset=iso-8859-1
Content-transfer-encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-
equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1"> <META content=3D"MSHTML 5.50.4522.1800" name=3DGENERATOR>
<STYLE></STYLE> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT face=3DArial size=3D2><FONT
-------------------------------------------------
-[Grupo=20
Intercom]- Todos los derechos reservados<BR></FONT><FONT =
face=3DVerdana=20
color=3D#b01838=20
size=3D1> </FONT></B></P></TD></TR></TBODY></TABLE></FONT></DIV></BO=
DY></HTML> --Boundary_(ID_Zl6wJjt5b1l34ISR7bdI6A)--
--Boundary_(ID_n+HzxHu0skkVB9AbIpE/eg)
Content-type: image/gif; name=capceleralinux.gif
Content-disposition: ATTACHMENT; FILENAME=capceleralinux.gif
Content-transfer-encoding: base64
Content-Location: http://www.noticias.com/noudisseny/linux/capceleralinux.gif
R0lGODlhkAFJAPcAAAAAAP/////7zgAAfLi2t7KwsRkYGYiFiL27vSMgJElCUDMwN6akqbi2u5eU
nrSyuWxqcxEQFTctZ6+tuC0mV6mntqCesiMeb4iGqoyKq4+NrJKQrpWTrgwIaxYUSHRyoYB+po2M
q5mYsAIBfgIBfQIBewIBdwQDdgUEfQYFewoJeQ8MdhEQfhQSdRkXfBQSYSAfgicmhj49jlNSllhX
R0lGODlhCgAJAKIAAAAAAP///wAAY2Njzs7O/zplXsDAwP///yH5BAEAAAcALAAAAAAKAAkAAAMc
OLprQzAS4WCR9JFyYbacV23dNJamJqVC67ZGAgA7
El mensaje del ejemplo anterior consta de 3 partes:

- la primera corresponde a texto plano
- la segunda a texto en formato HTML
- la tercera es una imagen con formato GIF
17.1.3 POP3 - Post Office Protocol version 3
El POP3 es un protocolo de correo electrónico con funciones de usuario (enviar/recibir) y de servidor de correo
(almacén). Sólo soporta las funciones básicas (obtener y borrar) de recepción de correo electrónico.
El protocolo POP3 (Post Office Protocol, Version 3) es un protocolo que funciona a nivel de aplicación según el
modelo de referencia OSI y sus especificaciones se describen en la RFC 1939.
Método de operación
Una sesión POP3 consta de 3 fases:
- Autorización. En esta fase se entra después de establecer la conexión TCP, en general por el
puerto 110, y de que el servidor POP3 ha enviado su conformidad. En esta fase, el usuario debe
identificarse al servidor POP3, empleando para ello un mensaje APOP.
- Transacción. En esta fase, el usuario solicita alguna actuación al servidor POP3. Y se termina
cuando el usuario envía el mensaje QUIT.
- Actualización. En esta fase el servidor POP3 elimina cualquier mensaje marcado como borrado
del buzón y responde de acuerdo con el resultado de esta operación. Independientemente de que
el borrado se haya llevado a cabo con éxito o no, el servidor POP3 libera el acceso exclusivo
sobre el buzón y cierra la sesión TCP.
Dado que el servidor POP3 funciona a base de comandos, es posible acceder a él mediante un Telnet. Los
principales comandos que soporta este protocolo son:
USER Especificación del nombre del usuario

PASS Especificación del contraseña del usuario
STAT Orden para conocer el número de mensajes en el buzón y el tamaño total.
LIST El resultado de esta orden es la lista de los mensajes del buzón,
especificando de cada uno de ellos su número y su tamaño.
RETR Se emplea para obtener el mensaje.
DELE Orden para el borrado de mensajes.
NOOP El servidor no hace nada pero contesta OK. Sirve para verificar el correcto
funcionamiento del servidor.
RSET Elimina la marca de borrado de un mensaje.
QUIT Cierra la sesión.
17.1.4 IMAP4 - Internet Message Access Protocol version 4
IMAP4 es un protocolo de mensajería electrónica con funciones de usuario y servidor de correo. De forma
similar a los servidores POP, los servidores IMAP4 guardan los mensajes de correo de muchos usuarios y los
pueden enviar a los mismos cuando éstos los solicitan.
El protocolo IMAP4 (Internet Message Access Protocol, Version 4) es un protocolo de nivel de aplicación según
el modelo de referencia OSI y sus especificaciones están descritas en la RFC 2060.
El protocolo IMAP es mejor que el protocolo POP en cuanto a que:

- Permite a los usuarios tener múltiples buzones de donde coger los mensajes y elegir solo algunos
de ellos.
- Los usuarios del IMAP4 pueden especificar criterios de selección, tales como limitar el tamaño
de los mensajes a obtener.
- El IMAP4 siempre guarda los mensajes en el servidor de correo y sólo envía copias a los
usuarios.
Modelos
El IMAP4 soporta los 3 modelos principales de correo electrónico, que son los siguientes:
- Offline. Un usuario periódicamente se conecta al servidor de correo y se baja sus mensajes. Los
mensajes de correo son borrados del servidor. Su funcionamiento es exactamente igual que en el
caso del protocolo POP3.
- Online. Los usuarios hacen cambios en el servidor de correo, es decir, el correo se procesa
remotamente en el servidor y los mensajes no se transmiten al cliente. Es el caso de los sistemas
NFS.
- Uso desconectado. Es un modelo compuesto de los modelos offline y online. En este modelo, un
usuario se baja los datos, los actualiza y más tarde los vuelve a enviar al servidor. Es el caso del
Lotus Notes Mail.
Dado que el IMAP4 soporta los 3 modelos de forma simúltanea, el usuario puede pasar de un modelo a otro en
cualquier momento.
Método general de operación

Los usuarios del protocolo IMAP4 establecen una conexión TCP en general por el puerto 143. Una vez
establecida la conexión, el servidor envía un mensaje de OK. A continuación, el usuario y el servidor se
intercambian los datos de forma interactiva. Cada vez que el usuario envía un mensaje de solicitud, el servidor
envía un mensaje de respuesta completo. El servidor también puede enviar mensajes sin atender a ninguna
solicitud del usuario.
Todos los mensajes enviados por el usuario llevan una identificación, que se debe corresponder con la del
mensaje de la respuesta. Esta identificación permite aparejar los mensajes de solicitud y respuesta aunque no
lleguen en orden.
Números de los mensajes

Hay 2 métodos de identificación de los mensajes:
- Método del identificador único (UID). En este caso, cada mensaje tiene un identificador de 32
bits, que combinado con un valor de validación único forma un valor de 64 bits. Cuando un
nuevo mensaje se añade al buzón, se le asigna un UID mayor que el del último mensaje, no
necesariamente contiguo. De esta forma, si los usuarios se desconectan, en la próxima sesión el
usuario puede usar los mismos valores que en la sesión anterior.
- Método secuencial. En este caso el número de cada mensaje se corresponde a la posición relativa
del mismo dentro del buzón. Este número puede cambiar durante la sesión y en las siguientes.
Estados
Durante una sesión del protocolo IMAP, el usuario puede estar en algunos de los estados siguientes:
- No-autenticado. En este estado, el usuario envía su identificación al servidor.
- Autenticado. El usuario selecciona el buzón sobre el que quiere actuar.
- Seleccionado. El buzón ha sido seleccionado satisfactoriamente.
- Desconexión. La conexión ha finalizado.
Las fases de una sesión completa del protocolo IMAP son:
- Establecimiento de la conexión TCP y paso a la fase de no-autenticado.
- Envío de la identificación del usuario al servidor y paso a la fase de autenticado.
- Selección del buzón y paso a la fase de seleccionado.
- Ahora hay 2 posibilidades:
- Volver a seleccionar otro buzón, en cuyo caso debe volverse a la
fase de autenticado o
- Salir y desconectarse con paso al estado de desconexión.
Mensajes
Los mensajes asociados a cualquier estado son:
- CAPABILITY. Este mensaje envía una solicitud al servidor con el fin de conocer sus
funcionalidades.
- NOOP. Este mensaje no hace nada, pero sirve para conocer si el servidor funciona.
- LOGOUT. Este mensaje solicita el fin de la conexión.
Los mensajes en la fase de no-autenticado son:
- AUTHENTICATE. Este mensaje requiere de un mecanismo de autenticación del servidor
mediante un argumento. Si el servidor no lo soporta, el servidor envía un mensaje de error.
- LOGIN. Este mensaje envía el nombre de usuario y contraseña sin encriptar al servidor.
Los mensajes en la fase de autenticado son:
- SELECT. Este mensaje selecciona un buzón.
- EXAMINE. Este mensaje también selecciona un buzón pero solo permite acceso de lectura.
- CREATE. Este mensaje crea un buzón con un nombre.
- DELETE. Este mensaje borra un buzón de forma permanente.
- RENAME. Este mensaje cambia el nombre de un buzón.
- SUBSCRIBE. Este mensaje añade un buzón a la lista de suscripción obtenida con el mensaje
LSUB.
- UNSUBSCRIBE. Este mensaje borra el nombre del buzón de la lista de suscripción.
- LIST. Este mensaje solicita una parte de todos los nombres que hay en el servidor.
- LSUB. Este mensaje solicita una parte de todos los nombres que hay en la lista de suscripción.
- STATUS. Este mensaje solicita el estado de un buzón determinado.
- APPEND. Este mensaje añade un mensaje de correo a un buzón, es decir, se genera un nuevo
mensaje.
Los mensajes en la fase de seleccionado son los generales, los de la fase de autenticado y además:
- CHECK. Este mensaje solicita la comprobación del estado de un buzón en memoria y disco.
- CLOSE. Este mensaje borra de forma permanente todos los mensajes del buzón seleccionado y
que previamente fueron marcados como borrados, y vuelve al estado de autenticado.
- EXPUNGE. Este mensaje borra de forma permanente todos los mensajes del buzón seleccionado
y que previamente fueron marcados como borrados.
- SEARCH. Este mensaje realiza la búsqueda de aquellos mensajes que corresponden al criterio
solicitado.
- FETCH. Este mensaje visualiza los datos de un mensaje del buzón seleccionado.
- STORE. Este mensaje actualiza el mensaje con los datos obtenidos con el comando FETCH.
- COPY. Este mensaje copia un mensaje de correo a otro buzón como mensaje nuevo.
- UID. Este mensaje devuelve el UID en vez del número de secuencia identificativo de cada
mensaje.
17.2 HTTP - Hypertext Transfer Protocol

El protocolo HTTP es un protocolo de transferencia de hipertextos basado fundamentalmente en el lenguaje
HTML. Este protocolo fue implementado inicialmente por el World Wide Web en 1991 como una iniciativa de
software y se denominó HTTP 0.9. El protocolo completo fue definido en 1992 e implementado en marzo de
1993.
La versión 1.0 del HTTP define las características básicas del protocolo y fue desarrollado por Tim Berners-Lee,
Roy T. Fielding, y Henrik Frystyk Nielsen. La última versión es la 1.1 y está desarrollada en la RFC 2616.
El protocolo HTTP es un protocolo que funciona a nivel de aplicación según el modelo de referencia OSI.
Este protocolo se basa en el modelo cliente/servidor, es decir, consiste en un intercambio de mensajes entre dos
dispositivos:
- El cliente, que es el que solicita servicios a un servidor. Su aplicación es lo que se conoce en
Internet como navegadores.
- El servidor, que es el dispositivo que responde a las solicitudes de los clientes. Usualmente se les
conoce como servidor Web, aunque en realidad son servidores de protocolo HTTP.
El protocolo HTTP emplea como protocolo de transporte TCP y por defecto la puerta 80. A veces se emplean
también las puertas 1080 y la 8080. El protocolo HTTP también se utiliza como transporte de otras protocolos
tales como SMTP, NNTP, FTP, Gopher, WAIS entre otros.
El intercambio de mensajes de solicitud y de respuesta entre el cliente y el servidor consta de 4 fases:

 Apertura de la conexión mediante el empleo del navegador por parte del usuario.
 Petición de una solicitud al servidor por parte del usuario desde su navegador. Esto incluye la versión del
protocolo, el método, el URI y otros parámetros tales como las MIME y la información del usuario.
 El servidor envía la respuesta al usuario, con los mensajes de error si son necesarios.
 Cierre de la conexión.
Los métodos y cabeceras de este protocolo HTTP lo permiten. La identificación de nombres está tipificada así
como la posibilidad de que un mensaje conste de varias partes, lo que se llama multiparte y que para ello se
emplea las MIME.
Parámetros del protocolo

Este protocolo HTTP emplea diversos parámetros, siendo los más importantes los siguientes:
- Versión. En este campo se indica la versión del protocolo que emplea el cliente que envía el mensaje. Su
formato es
HTTP-Version = "HTTP" "/" 1*número "." 1*número
- URI. El Uniform Resource Identifier es la identificación del servidor al que se le hace la solicitud.
Consta del URL (Uniform Resource Locator) y el nombre (URN). Su formato es
http-URL = "http:" "//" servidor [ ":" puerto ] [ directorio [ "?" solicitud ]]
- Conjunto de caracteres. El protocolo HTTP emplea las MIME para la definición del conjunto de caracteres.
- Tipo de fichero. El protocolo HTTP emplea estos tipos en los campos Content-Type y Accept de
la cabecera.
media-type = tipo "/" subtipo *( ";" parámetro )
- Multipart. Las MIME provee un número de los tipos "multipart", que son encapsulaciones de
varias partes en un único cuerpo de un mensaje. En general, el protocolo HTTP trata un mensaje
multipart como una sola entidad.
Estructura y tipos de mensaje

Como ya se ha dicho, el protocolo HTTP emplea 2 tipos de mensajes : de solicitud y de respuesta.
Ambos tipos de mensajes constan de:
- una o más cabeceras, en función del tipo de mensaje de que se trate
- un campo de datos o cuerpo del mensaje
- un campo indicativo de la longitud del mensaje
- una cabeceras generales
Mensajes de solicitud
Un mensaje de solicitud de un cliente a un servidor incluye, en la primera línea del mensaje, el método a aplicar,
el identificador del recurso y la versión del protocolo.
Los campos de cabecera de una solicitud permiten al cliente pasar información adicional de la solicitud y del
propio cliente al servidor.
Mensajes de respuesta
La primera línea de un mensaje de respuesta es una línea de estado, que consta de la versión, un código de
estado y su texto asociado con cada elemento separado por espacios en blanco.
Los campos de la cabecera del mensaje de respuesta permiten al servidor enviar información que no cabe en la
línea de estado.
Conexiones
Una diferencia significativa entre el HTTP/1.1 y las versiones anteriores es que por defecto se presuponen que
las conexiones son permanentes. Este tipo de conexiones tienen un mecanismo por el cual el cliente y el servidor
pueden cerrar la conexión TCP. Esta señalización se hace utilizando el campo Connection de cabecera. Una vez
iniciado el cierre, el cliente no debe enviar ninguna solicitud por esta conexión.
Un cliente HTTP/1.1 siempre debe estar controlando el estado de errores de la conexión mientras envía
solicitudes. Si el cliente ve algún error, inmediatamente debe cesar de enviar datos. Si estos datos estaban
precedidos de una cabecera Content-Length, el cliente debe cerrar la conexión.
Definiciones del método

Se entiende por métodos los distintos tipos de acciones que se pueden desarrollar. Los más importantes son:
 OPTIONS. Este método consiste en la solicitud de información de las opciones de comunicación de un
servidor. Este método permite al cliente determinar las opciones y/o los requerimientos asociados con el
servidor, o las capacidades del mismo, sin necesidad de emprender ninguna acción de transmisión de
información.
 GET. Este método se emplea para obtener información de un servidor. Si la solicitud es de obtención de
datos, los datos resultantes de la solicitud vuelven al cliente en el mensaje de respuesta.
 HEAD. Este método es idéntico al GET excepto que el servidor no debe enviar nada en el cuerpo del
mensaje de respuesta.
 POST. Este método se emplea con el fin de solicitar al servidor, que procese los datos que se le envían en el
mensaje de solicitud. Si el nombre del servidor que debe procesar estos datos no es él mismo, debe enviarlos
al URI indicado en el mensaje de solicitud.
 PUT. Este método se emplea para almacenar información en un URI. Esta información se envía en el propio
mensaje de solicitud. Si la información ya existía, será actualizada con la información enviada.
 DELETE. Este método se emplea para decirle al servidor que borre el recurso identificado en el URI. En
este caso, el cliente nunca tiene la seguridad de esta acción, aunque se le haya contestado con un mensaje sin
errores.
 TRACE. Este método se emplea para solicitar el estado de una aplicación de un servidor. TRACE permite al
cliente ver que lo que está recibiendo del otro extremo de la cadena y utilizar estos datos como diagnóstico.
Autenticación
El protocolo HTTP opcionalmente tiene mecanismos de autenticación, que permiten a un cliente ser reconocido
por el servidor o no. En principio los 2 métodos empleados son:
- Basic Access Authentication. El protocolo HTTP/1.0 incluye esta autenticación, que consiste en
intercambiar entre el cliente y el servidor, un nombre y un contraseña. El principal defecto de este
método es que estos datos viajan sin encriptación.
- Digest Access Authentication. La respuesta a validar contiene un control de error (por defecto se
emplea el método MD5), el contraseña, el nombre, un valor especial, el método HTTP y el URI
solicitado. El contraseña nunca se envía tal cual. Una vez el servidor recibe la cabecera de
autorización, verifica su validez contrastando el contraseña y el nombre. A continuación hace la
misma operación MD5 que hizo el cliente, y compara su resultado con el recibido por el cliente.
Campos de cabecera
Los más importantes y significativos son:
- Accept. Esta cabecera de un mensaje de solicitud y se emplea como aceptación de una respuesta.
- Age. Es una cabecera de un mensaje de respuesta y es el tiempo aproximado que se tardó en
responder.
- Allow. Esta cabecera de entidad lista los métodos soportados por el recurso identificado en el
URI.
- Authorization. Esta cabecera contiene todos los datos necesarios para una autenticación.
- Connection. Es una cabecera de tipo general, y permite al solicitante especificar las opciones que
desea emplear en una conexión.
- Content-Encoding. Es una cabecera de entidad y su contenido está relacionado con el media-type.
Es opcional y está relacionado con la cabecera Content-Type para saber el tipo de codificación
que debe aplicarse.
- Content-Language. Esta cabecera de entidad describe el lenguaje a emplear para tratar la
información.
- Content-Length. También es una cabecera de entidad y especifica el tamaño del cuerpo de la
entidad en octetos.
- Content-Location. Esta cabecera de entidad se puede usar para pasar la ubicación del recurso a la
entidad en cuestión y a su vez puede ser distinta de la general.
- Content-MD5. Esta cabecera de entidad se emplea en la autenticación por el método MD5 digest.
- Content-Type. Esta cabecera de entidad especifica el tipo de fichero.
- Date. Es una cabecera general que representa la fecha y hora en que se originó el mensaje.
- Expect. Es una cabecera de solicitud mediante el cual el cliente hace algunas indicaciones al
servidor.
- From. Es una cabecera de solicitud que debería contener la dirección de correo electrónico del
usuario que controla el agente del recurso solicitado.
- Host. Es una cabecera de solicitud que especifica el dispositivo y el número de puerta del recurso
solicitado.
- Last-Modified. Esta cabecera de entidad indica la fecha y hora de la última modificación en el
servidor origen.
- Location. Esta cabecera de respuesta se usa para redirigir al destinatario a una ubicación distinta
de la indicada en el URI.
- Max-Forwards. Esta cabecera de solicitud se emplea en los métodos TRACE y OPTIONS para
limitar el número de saltos o dispositivos hasta llegar a su destino.
- Pragma. Esta cabecera general se usa para incluir directivas específicas que se pueden aplicar a la
cadena solicitud-respuesta.
- Proxy-Authenticate. Es una cabecera de respuesta relacionada con la fase de autenticación.
- Proxy-Authorization. Esta cabecera de respuesta permite que el cliente se identifique al proxy con
la autenticación requerida.
- Server. Esta cabecera de respuesta contiene información del software utilizado por el servidor
para responder a la solicitud.
- Transfer-Encoding. Esta cabecera general indica que tipo, si procede, de transformación ha sido
aplicada la cuerpo del mensaje con el fin de transmitir de forma segura.
- Upgrade. Es una cabecera general que permite al cliente especificar que protocolos de
comunicación adicionales soporta y desearía utilizar.
- User-Agent. Esta cabecera de solicitud contiene información del agente del usuario que generó la
solicitud.
- Via. Esta cabecera general debe ser utilizada por las pasarelas y proxies con el fin de conocer los
protocolos intermedios y dispositivos que han intervenido en la transmisión de la respuesta.
- Warning. Es una cabecera general usada para transmitir información adicional del estado de
transformación del mensaje.
17.3 Protocolos de seguridad

El tema de la seguridad es algo que siempre ha preocupado en la transmisión de la información en las redes,
principalmente cuando se trata del empleo de redes públicas. Es un aspecto muy a tener en cuenta ya que puede
acarrear importantes perjuicios económicos a las empresas.
Una técnica muy empleada es la criptografía, es decir, se trata de transmitir la información encriptada, de forma
que quien la quiera leer, necesita de una contraseña.
En el ámbito de los protocolos, hay algunos diseñados pensando en la seguridad y a continuación se desarrollan
los que se emplean en el ámbito de Internet.
Se pueden agrupar en:

- Los protocolos PPTP, L2F y L2TP están relacionados con las comunicaciones vía puerto serie y utilizan
técnicas de tunneling y
- El Kerberos, el IPSec y el RADIUS son protocolos que conllevan métodos de seguridad asociados.
17.3.1 Comunicación remota
Es muy habitual la necesidad de comunicación de:

- un ordenador a una red a través de una línea de comunicaciones y
- la conexión de dos redes mediante una línea de comunicaciones
Si esta línea de comunicaciones es privada, el riesgo de copiar los datos que circulan, es bajo. Sin embargo, si se
utiliza una red de comunicaciones tan pública como Internet, es riesgo aumenta mucho.
Ésta es la razón por la cual no es aconsejable el uso del protocolo PPP en ámbitos vulnerables, ya que no
incorpora ninguna medida de seguridad.
17.3.2 PPTP - Point-to-Point Tunneling Protocol
Uno de los protocolos más utilizados en el establecimiento de conexiones remotas mediante líneas de
comunicaciones es el PPTP (Point-to-Point Tunneling Protocol). Las especificaciones de este protocolo PPTP se
encuentran detalladas en la RFC 2637.
El PPTP fue creado por el foro PPTP formado por Microsoft, Ascend, 3Com, ECI y US Robotics.
Sus principales características son:

- Es una ampliación del protocolo básico PPP
- No soporta múltiples conexiones.
- Usa una conexión TCP para el mantenimiento del canal.
- Usa las tramas PPP encapsuladas con el protocolo de enrutamiento GRE modificado para los datos.
- Soporta únicamente los protocolos de nivel de red IP, IPX y NetBEUI
- Emplea las técnicas del tunneling, es decir, encapsulamiento.
- Los canales PPTP se autentican mediante el uso de los mismos mecanismos de autenticación del protocolo
PPP, tales como PAP, MS-CHAP, CHAP y EAP.
Sistema de
comunicaciones PA PA
Túnel
C S
Funcionamiento
Una conexión PPTP se establece siempre entre dos dispositivos que tienen que tener instalado este protocolo.
Estos dispositivos son:
- Un servidor, que en adelante lo identificaremos por PNS, siglas de PPTP Network Server.
- Un cliente, que en adelante lo identificaremos por PAC, siglas de PPTP Access Concentrator.
Cada conexión PPTP consta de:
- Una conexión de control entre cada pareja PAC-PNS sobre TCP.
- Un túnel IP operando entre la misma pareja PAC-PNS y que se usa para transportar los mensajes PPP
encapsulados en GRE (Generic Routing Encapsulation).
Conexión de control
La conexión de control se debe establecer antes del túnel IP entre un PAC y un PNS, siendo sus características
las siguientes:
- Emplea una sesión TCP mediante la cual el protocolo PPTP controla y gestiona la transmisión de la
información.
- Se asocia lógicamente con el túnel IP, por tanto por cada pareja PAC-PNS existe un túnel y una conexión de
control.
- Es responsable del establecimiento, gestión y liberación de las sesiones que van a través del túnel. De esta
forma un PNS sabe que un PAC lo está llamando y éste como hacer la llamada.
- Mediante los parámetros de velocidad y buffering, regula el flujo de mensajes PPP para una sesión en
concreto a través del túnel.
La conexión de control puede iniciarla el PNS o el PAC, mediante los mensajes de solicitud de inicio de la
conexión de control y el mensaje de respuesta correspondiente. Estos mensajes también se usan para
intercambiar información sobre las capacidades básicas operativas del PAC y del PNS.
La conexión de control puede comunicar cambios en las características operativas de una sesión mediante los
mensajes correspondientes. Las sesiones Individuales se liberan por el PAC o el PNS también mediante
mensajes de la conexión de control.
El mantenimiento de la conexión de control se hace mediante el empleo de mensajes eco con tiempo de vida. De
esta forma se sabe cuando hay un fallo de conectividad entre el PNS y el PAC . Los demás fallos se informan
mediante el mensaje de notificación del error de línea, y también de la conexión de control.
Los mensajes de la conexión de control también se emplean para establecer y borrar las sesiones de usuario.
Operación del túnel

El protocolo PPTP necesita del establecimiento de un túnel para establecer la comunicación entre la pareja PNS-
PAC. Este túnel se emplea para transmitir los mensajes PPP correspondientes a una sesión de usuario. Una
contraseña existente en la cabecera GRE indica a que sesión pertenece el mensaje PPP en cuestión.
De esta forma, los mensajes PPP son multiplexados y desmultiplexados utilizando un único túnel entre la pareja
PNS-PAC. Este valor se determina cuando se inicia la sesión mediante la conexión de control.
La cabecera GRE también contiene información de reconocimiento y secuencia que se emplea para la detección
de la congestión y los errores.
Los mensajes de datos del usuario son en realidad mensajes PPP aunque estén manejados por el protocolo PPTP.
Los mensajes PPP se transmiten entre el PAC y el PNS y viceversa, encapsulados en mensajes GRE (Generic
Routing Encapsulation) y éstos a su vez en mensajes IP.
El mensaje IP transmitido por el túnel entre un PAC y un PNS tiene la estructura siguiente:
Cabecera Cabecera Cabecera Cabecera Datos Cola

Nivel 2 IP GRE PPP Nivel 2
17.3.3. L2F - Layer 2 Forwarding
El protocolo L2F (Layer 2 Forwarding) fue desarrollado por Cisco Systems al mismo tiempo que se desarrollaba
el protocolo PPTP. Es otro protocolo que permite que los dispositivos remotos accedan a la red TCP/IP de la
organización a través de Internet, con seguridad y control.
Cisco sometió esta tecnología al Internet Engineering Task Force (IETF) para que fuera aprobado como un
estándar, y así se publicó en la RFC 2341.
Como con el protocolo PPTP, el protocolo L2F permite acceso privado seguro a través de redes públicas,
mediante un túnel entre el cliente y el servidor. La diferencia entre el PPTP y el L2F es que el tunneling del
protocolo L2F no depende del protocolo IP; es decir, permite trabajar con otros protocolos de red, tales como
Frame Relay, ATM o FDDI.
El protocolo L2F permite definir las conexiones dentro del túnel. Esto es especialmente útil en situaciones donde
más de un usuario está localizado remotamente, y sólo se necesita conexión mediante llamada.
El protocolo L2F usa los mismos sistemas de autenticación que en el protocolo PPP y además soporta
TACACS+ y RADIUS. La autenticación en el protocolo L2F consta de dos niveles:
1) cuando el usuario remoto se conecta al proveedor de Internet (ISP), y
2) cuando se hace la conexión a la pasarela de la red TCP/IP de la organización.
El protocolo L2F envía mensajes a través del túnel virtual entre los extremos de la conexión a nivel de protocolo.
Cuando se recibe un mensaje del dispositivo remoto al ISP, se eliminan los octetos correspondientes con lo que
el mensaje se hace transparente. A continuación el mensaje se encapsula en el protocolo L2F y se envía al túnel
correspondiente. La pasarela de la organización acepta el mensaje L2F, elimina la encapsulación L2F y procesa
el mensaje entrante. Debido a que el L2F es un protocolo a nivel enlace, puede ser utilizado con otros protocolos
como el IP, IPX y NetBEUI.
17.3.4 L2TP - Layer 2 Tunneling Protocol
El protocolo L2TP (Layer 2 Tunneling Protocol) se utiliza para encapsular el protocolo PPP en una conexión
entre dos dispositivos con el fin de darle seguridad con el empleo de autenticación. Este protocolo es una
combinación del PPTP (Point-to-Point Tunneling Protocol) y el L2F (Layer 2 Forwarding). Sus especificaciones
se encuentran en la RFC 2661.
El L2TP suministra una técnica de tunneling a una conexión Point-to-Point Protocol (PPP) y el túnel se puede
iniciar en cualquiera de ambos extremos, es decir, en la estación remota o en el propio proveedor. El protocolo
L2TP puede soportar acceso remoto a LAN utilizando protocolo PPP con tunneling, y ser controlado como si
fuera una conexión PPP.
El protocolo L2TP encapsula los mensajes PPP sobre distintos protocolos de redes y comunicaciones, tales como
IP, X.25, Frame Relay y ATM.
L2TP usa el protocolo UDP como protocolo de transporte y una serie de mensajes L2TP para el mantenimiento
del canal.
La estructura del mensaje es la siguiente:
Cabecera Cabecera IP Cabecera Cabecera Cabecera PPP Datos Cola nivel

nivel 2 UDP L2TP 2
Comparación con PPTP

Sus diferencias son:
- PPTP sólo funciona en redes IP, en cambio L2TP también se puede emplear en redes X.25, Frame Relay y
ATM.
- PPTP solo soporta un túnel entre los dos extremos. L2TP soporta múltiples túneles entre los mismos
extremos.
- L2TP soporta compresión de cabecera y el PPTP no.
- L2TP soporta autenticación del túnel y el PPTP no.
El túnel del protocolo L2TP se establece entre dos extremos que son:
1) El cliente o LAC (L2TP Access Concentrator), que está localizado en el proveedor que suministra la conexión
física al usuario remoto. El medio físico del LAC se puede conectar a líneas telefónicas convencionales o a
líneas RDSI.
2) El servidor o LNS (L2TP Network Servers), que es el otro extremo de la conexión L2TP. Unicamente una
sola conexión se puede utilizar en el LNS para terminar múltiples llamadas de los usuarios remotos, con distintos
sistemas de telefonía.
Las fases de establecimiento de la sesión y el tunneling son:
- El usuario remoto inicia una conexión PPP al servidor de la red a la que quiere acceder.
- El servidor de la red acepta la llamada.
- La autenticación del usuario final se realiza mediante un servidor de autorización al servidor de la red.
- El cliente LAC se arranca cuando el usuario intenta arrancar una conexión con el servidor LNS mediante un
túnel al otro extremo que es el cliente del túnel. Cada intento de establecimiento de una conexión extremo a
extremo es controlado por el cliente LAC con una llamada de sesión. Los mensajes son enviados con el
túnel LAC-LNS. Cada dispositivo LAC y LNS controla el estado del usuario conectado.
- El usuario remoto es autenticado también por el servidor de autenticación de la pasarela LNS antes de
aceptar la conexión túnel.
- El servidor LNS acepta la llamada y construye el túnel L2TP.
- El servidor de la red registra la aceptación.
- El servidor LNS intercambia la negociación PPP con el usuario remoto.
- Los datos extremo a extremo son ahora enviados mediante el túnel entre el usuario remoto y el LNS.
El L2TP puede soportar las siguientes funciones:
- Tunneling de un solo usuario cliente.
- Tunneling de pequeños enrutadores.
- Llamadas entrantes a un servidor LNS desde un cliente LAC.
- Múltiples llamadas por túnel.
- Autenticación mediante los protocolos PAP y CHAP.
Mensajes
El protocolo L2TP utiliza 2 tipos de mensajes:
- Los mensajes de control se usan en el establecimiento, mantenimiento y liberación de los túneles y las
llamadas. Estos mensajes usan un canal de control fiable con L2TP con todas las garantías.
- Los mensajes de datos se usan para encapsular los mensajes PPP que son transmitidos por el túnel. Estos
mensajes no se retransmiten si el mensaje se pierde.
Mensajes PPP
Mensajes de datos L2TP Mensajes de control L2TP
Canal de datos L2TP (no seguro) Canal de control L2TP (seguro)
Transporte de mensajes (UDP, FR, ATM, etc.)
En la figura anterior se representa las relaciones de los mensajes PPP y los mensajes del protocolo L2TP. Los
mensajes PPP se transmiten a través de un canal de datos no seguro, a continuación se encapsulan con una
cabecera L2TP y son transmitidos a través de los protocolos UDP, Frame Relay, ATM, etc. Los mensajes de
control se transmiten a través de un canal L2TP de control seguro y a partir de aquí con el protocolo de
transporte correspondiente.
Se necesitan números de secuencia en todos los mensajes de control con el fin de garantizar su recepción. Los
mensajes también pueden usarlos para reordenar los mensajes y detectar la pérdida de alguno de ellos.
17.3.5 RADIUS - Remote Authentication Dial-In User Service
RADIUS es una aplicación que permite la autenticación de un cliente que accede de forma remota a una red. De
esta forma se garantiza la seguridad de esta red y se asegura de que los clientes que acceden a la misma son los
clientes autorizados.
Sus especificaciones están descritas en la RFC 2138 y también en las

- RFC 2865 Remote Authentication Dial in User Service (RADIUS)
- RFC 2866 RADIUS Accounting y
- RFC 2869 RADIUS Extensions
El protocolo de esta aplicación RADIUS es un protocolo que funciona a nivel de aplicación según el modelo de
referencia OSI, y se apoya en el protocolo de transporte UDP, empleando para ello el puerto 1812 y 1813.
Antiguamente se utilizaban los puertos 1645 y 1646.
Esta aplicación consta de 3 componentes:

- El cliente o dispositivo remoto desde el que se quiere acceder a la red. Este cliente se define como
usuario que utiliza este dispositivo.
- El servidor de la red o NAS (Network Access Server) al que el cliente se conecta mediante el
sistema de comunicaciones correspondiente. Este servidor es el que dará acceso al cliente a la red
en cuestión.
- El servidor RADIUS que autenticará la solicitud de conexión de este usuario y le autorizará o no
a acceder a la red a través del NAS.
Cliente NAS Servidor

RADIUS
El servidor RADIUS soporta distintos métodos para autenticar al usuario, tales como PAP, CHAP, login de
UNIX, y otros mecanismos de autenticación.
Operación
Las fases de una conexión con RADIUS son las siguientes:
- El usuario se conecta a un servidor a través de un módem y una vez realizada la conexión, el
servidor solicitará al usuario su nombre y contraseña.
- El cliente RADIUS recibirá el detalle del usuario y encriptará su contraseña. Entonces la solicitud
de autenticación será recibida por el servidor RADIUS que la validará y desencriptará los datos.
- El nombre y contraseña del usuario se enviarán para su verificación al sistema de seguridad, y
entonces si los datos son correctos, el servidor enviará un reconocimiento de autenticación que
incluye los datos de los requerimientos de servicio y sistema del usuario. El proceso de
autenticación limitará a los usuarios a unos recursos concretos de la red, y sólo podrá usar a los
que esté autorizado.
- Una vez toda la información es recibida por el servidor, el usuario recibirá el servicio de red con
acceso a los recursos autorizados. Mientras el usuario está conectado al servidor, el cliente
RADIUS enviará los datos al servidor para su control y facturación.
Configuración
La configuración del servidor RADIUS debe contener la información de los usuarios autorizados a acceder a la
red.
Los datos que debe tener de cada usuario serán:
- la dirección IP del dispositivo desde el que accede el usuario
- la clave compartida de acceso RADIUS
- el tipo de dispositivo al que accede a la red
- el puerto UDP que emplea para el envío y recepción de los mensajes de autenticación y
contabilidad de RADIUS.
En cuanto al cliente, su configuración debe contener información del servidor RADIUS al que debe acceder para
su autenticación. Para ello necesitará:
- la dirección IP del servidor RADIUS
- la clave compartida de acceso RADIUS
- los puertos UDP a emplear en el envío y recepción de los mensajes de autenticación y
contabilidad.
Las claves compartidas deben transmitirse de forma segura entre el dispositivo remoto y el servidor RADIUS.
Por esta razón lo habitual es el empleo de los protocolos de autenticación PAP, CHAP, MS-CHAP o
equivalentes.

La estructura del mensaje es la siguiente:
Código Identificador Longitud

Autenticador
Atributos
donde
- Código, 8 bits. Identifica el tipo de mensaje RADIUS y son los siguientes:
1 Solicitud de acceso Lo envía el cliente RADIUS y contiene el nombre del usuario y

su contraseña encriptados.
2 Aceptación de acceso Lo envía el servidor RADIUS en respuesta a un solicitud de
acceso si el usuario es autorizado.
3 Rechazo de acceso Lo envía el servidor RADIUS en respuesta a un solicitud de
acceso si el usuario no es autorizado.
4 Solicitud de contabi-lidad Lo envía el cliente RADIUS cuando los usuarios se conectan, se
desconectan o son desconectados.
5 Respuesta de contabi-lidad Lo envía el servidor RADIUS en respuesta a una solicitud de
contabilidad.
- Identificador, 8 bits. Usado para aparejar los mensajes de solicitud y respuesta.

- Longitud, 16 bits. Indica la longitud total del mensaje .
- Autenticador, 16 bits. Este valor se usa para autenticar la respuesta del servidor RADIUS, y se
usa en el algoritmo de generación de contraseña. Estos códigos especiales llamados claves son los
que usan el cliente RADIUS y el servidor para garantizar que los mensajes que reciben, vienen de
la fuente autorizada.
- Atributos. Los atributos de RADIUS contienen los detalles específicos de autenticación,
autorización y contabilidad de las solicitudes y respuestas.
- Tipo, 8 bits.
- Longitud, 8 bits. Es la longitud de los campos tipo, longitud y valores.
- Valores. Contiene la información concreta del atributo.
Nombre del atributo Descripción

1 Nombre de usuario Nombre del usuario autenticado. Solo se emplea en los mensajes de
solicitud de acceso.
2 Contraseña de usua-rio Contraseña encriptado suministrado por el usuario.
3 Contraseña CHAP Valor respuesta dado por el CHAP.
4 Dirección IP del clien-te Dirección IP del cliente RADIUS.
5 Puerto del cliente Número de puerto serie del usuario.
6 Tipo de servicio Los tipos de servicio posibles relacionados con la conexión.
7 Protocolo Protocolo empleado : PPP, SLIP, ARAP (AppleTalk Remote Access)
8 Dirección IP Indica la dirección IP a configurar para el usuario.
9 Máscara IP Indica la máscara IP a configurar para el usuario.
10 Tipo de enrutamiento Indica el método de enrutamiento para el usuario. Los posibles son:
ninguno, broadcast, de escucha, broadcast-listen.
11 Filtro Nombre del filtro IP para este usuario.
12 MTU Valor del MTU para el usuario.
13 Compresión Protocolo de compresión empleado.
14 IP login Dirección IP del dispositivo al que quiere conectarse el usuario.
15 Servicio de login Servicio de conexión empleado : Telnet , Rlogin.
16 Puerto de login Puerto TCP por el que se conectará el usuario cuando se use Login-
Service Attribute.
18 Mensaje de respues-ta Indica el texto que se puede dar a visualizar al usuario.
19 Número para el callback Número de teléfono para el callback.
20 Identificación del callback Identificación de callback a interpretar por el NAS.
22 Ruta a seguir Lista de dispositivos que marcan la ruta de los mensajes.
23 Número de red IPX Número de red IPX a usar por el usuario.
24 Estado Este atributo indica que el servidor lo ha de enviar al cliente en un
Access-Challenge y debe ser contestado por el cliente en una respuesta a
un Access-Request si lo hay.
25 Clase Este atributo indica que el servidor lo ha de enviar al cliente en un
mensaje de aceptación de acceso y debe ser contestado por el cliente en
una respuesta a un mensaje de solicitud de contabilidad si lo hay.
26 Fabricante Este atributo permite a los fabricantes incorporar sus propios atributos.
27 Tiempo de sesión Número máximo de segundos de una sesión, antes de terminarla de forma
automática.
28 Tiempo muerto Número máximo de segundos de una sesión sin ser usada, antes de
terminarla de forma automática.
29 Acción de cierre Indica que acción de NAS se debe emplear para completar el servicio
especificado.
32 Identificador NAS Identificador del NAS en un mensaje de solicitud de acceso.
17.3.6 Kerberos
El Kerberos es un sistema de autenticación y autorización para el reconocimiento seguro de los usuarios de las
redes. Está basado en un sistema de seguridad con encriptación y como aplicación que es, emplea un protocolo
de aplicación según el modelo de referencia OSI, que a su vez se apoya en el protocolo de transporte UDP y el
puerto 88.
Las especificaciones de la versión 5 se encuentran detalladas en la RFC 1510.
El Kerberos se basa en el protocolo de autenticación de Needham y Schroeder con modificaciones sugeridas por
Denning y Sacco. El diseño original y la implementación de las versiones 1 al 4 de Kerberos fue un trabajo de 2
antiguos miembros del Proyecto Athena, Steve Miller de Digital Equipment Corporation y Clifford Neuman,
junto con Jerome Saltzer, Director técnico del mismo proyecto y Jeffrey Schiller, MIT Campus Network
Manager. También muchos otros miembros del mencionado proyecto han contribuido al desarrollo del Kerberos.
Las bases de esta aplicación son :

- la autenticación para prevenir solicitudes y respuestas fraudulentas entre usuarios y servidores.
Estos mensajes deben ser confidenciales.
- la autorización que puede ser implementada de forma independiente de la autenticación.
- permitir la implementación de un sistema contable integrado, seguro y fiable, con grupos
modulares y soporte con vistas a facturación.
Kerberos presupone que:

- La localización física donde se usará este sistema de seguridad incluirá dispositivos que pueden
estar en áreas con una seguridad física mínima y también que sea una red compuesta por varias
redes dispersas conectadas mediante enlaces sin encriptación.
- Uno de los sistemas de encriptación utilizado es el DES (Data Encryption Standard), método
modular y reemplazable y que ha sido diseñado por Kerberos.
Elementos de este sistema

Esta aplicación consta de los elementos siguientes:
- Los clientes o usuarios. Éstos se identifican por un nombre único para cada uno de ellos.
- El servidor Kerberos de autenticación (KAS)
- El servidor Kerberos que da los billetes (TGS) y
- Una base de datos Kerberos de clientes y servidores.
El servidor de autenticación KAS y el de billetes TGS pueden estar instalados en un mismo ordenador o no y
ubicados en espacios físicamente seguros. La base de datos está ubicada en el servidor de autenticación KAS.
Proceso de autenticación
El proceso de autenticación consta de las fases siguientes:
1) El cliente envía un mensaje al servidor de autenticación KAS que contiene su identidad, la fecha
y hora actual, y la solicitud de un billete para acceder al servidor TGS. La fecha y hora es para
asegurarse de que este mensaje no es copia de otro que pudiera haber sido interceptado.
2) El servidor de autenticación KAS verifica el nombre del cliente en su base de datos, así como el
servicio solicitado. Si todo es correcto, crea una clave de encriptación para el cliente y otra para el
servidor de billetes TGS. A continuación responde al cliente con un billete para que dicho cliente
pueda acceder al servidor de billetes TGS. También genera una clave de sesión.
Cliente Servidor
6
1
4
2 3
KAS TGS
3) Una vez el cliente ha recibido el mensaje del servidor de autenticación KAS, lo desencripta con
su clave secreta. A continuación envía un mensaje al servidor de billetes TGS. Este mensaje
contiene el billete inicial, el nombre del servidor al que el cliente quiere acceder, y la fecha y hora
actual.
4) El servidor de billetes TGS desencripta el mensaje recibido del cliente con su clave y con ello
obtiene además la clave de sesión. Verifica que todos los datos recibidos son correctos y si es así,
obtiene la clave de encriptación para el servicio solicitado. También genera una nueva clave de
sesión y todo ello es enviado al cliente.
5) Una vez el cliente recibe el mensaje, y lo descifra con la clave de sesión que solo conocen él y el
servidor de billetes TGS. De este mensaje obtiene una nueva clave de sesión que comparte con el
servidor y un billete de aprobación que no puede descifrar porque para ello es necesaria la clave
del servidor que el cliente no posee. Con este billete de aprobación, el cliente envía un mensaje al
servidor de cuyos servicios necesita. Con todo esto, el servidor en cuestión valida o no el mensaje
del cliente.
6) El servidor al que el cliente quiere acceder, devuelve el mensaje al cliente con la fecha y hora
actual. Este mensaje está encriptado con la clave de sesión que el cliente envió al servidor.
Base de datos
Cada registro de la base de datos del servidor contiene como campos principales:
- El nombre de identificación de cada cliente
- La clave secreta de cada cliente
- La versión de la clave secreta
- El tiempo máximo de vida de los billetes
- El tiempo máximo de vida transcurrido el cual se deben renovar los billetes
y además hay espacio para otros campos adicionales.
Sistemas de encriptación
Los principales sistemas de encriptación soportados por Kerberos son:
- Sistema de encriptación nula, es decir, cuando no se usa encriptación. En estos casos no hay ni
control de errores.
- DES en modo CBC con control de errores CRC-32 (des-cbc-crc). Este sistema encripta la
información con el DES (Data Encription Standard) y emplea un control de errores CRC-32. Los
bloques DES son de 8 octetos. Los detalles de esta encriptación son los mismos que el modo des-
cbc-md5.
- DES en modo CBC con control de errores MD4 (des-cbc-md4). Este sistema encripta la
información con el DES (Data Encription Standard) y un control de errores MD4. Los bloques
DES son de 8 octetos. Los detalles de la encriptación son los mismos del modo des-cbc-md5.
- DES en modo CBC con control de errores MD5 (des-cbc-md5). Este sistema encripta la
información con el DES (Data Encription Standard) y un control de errores MD5. Los bloques
DES son de 8 octetos.
La clave DES consta de 8 octetos, lo que corresponde a una clave de 56 bits y 8 bits de paridad. En este caso, la
clave DES se genera a partir del contraseña del cliente.
17.3.7 IPSec - Internet Protocol Security
El protocolo IPSec es un protocolo de nivel de red según el modelo de referencia OSI y consta de una conjunto
de estándares que soportan la transmisión segura de información a través de una red IP.
En realidad no es protocolo propiamente dicho, sino que ofrece servicios de autenticación y cifrado al protocolo
IP.
Sus especificaciones se encuentran detalladas en las:

- RFC 2401 Security Architecture for the Internet Protocol.
- RFC 2402 IP Authentication Header.
- RFC 2406 IP Encapsulating Security Payload (ESP).
Consta de 2 protocolos:
- el AH (Authentication Header) que solo contempla autenticación y
- el ESP (Encapsulating Security Payload) con cifrado y autenticación.
En cuanto a su transporte hay 2 posibilidades:

- mediante túnel y
- sin túnel
Como consecuencia de ello, las combinaciones posibles de funcionamiento son:

Modo
Transporte AH sólo ESP sólo AH después de aplicar ESP
Túnel AH sólo ESP sólo
AH - Sólo autenticación
En este caso lo que se hace es añadir una cabecera de autenticación entre las dos cabeceras de los protocolos
TCP y IP, y para que el protocolo IP lo reconozca se define un nuevo número 51 identificativo de este nuevo
protocolo IPSec.
En consecuencia la estructura del mensaje es
Cabecera IP Cabecera AH Cabecera TCP Datos
La cabecera de autenticación consta de los campos siguientes:

- Próxima cabecera. Especifica del tipo que es la cabecera de autenticación.
- Longitud de la cabecera de autenticación.
- Número de secuencia identificativo de cada mensaje.
- Información del esquema de seguridad empleado. Incluye la identificación del algoritmo de
autenticación empleado, sus claves, tiempos de vida de validez de esta información, etc.
- Datos del esquema de seguridad empleado.
ESP - Cifrado y autenticación

Si se requiere cifrado y autenticación, se utiliza lo que se conoce con la abreviatura ESP (Encapsulation Security
Payload), siendo 50 el número de protocolo identificativo en la cabecera IP.
En este caso, se añade una cabecera ESP entre las dos cabeceras de los protocolos TCP y IP y se añade una cola
formada por una parte encriptada y otra sin encriptar.
La estructura del mensaje es el siguiente:
Cabecera Cabecera Cabecera Datos Cola Cola de

IP ESP IPSec TCP ESP autenticación
IPSec ESP IPSec
La cabecera TCP, el campo de datos y la cola ESP viajan encriptadas.

La cabecera ESP y los campos encriptados requieren autenticación para poder ser interpretados. La información
de la autenticación está en la cola de autenticación ESP.
La cabecera ESP consta de 8 octetos y contienen un índice de los parámetros de seguridad y un número de
secuencia.
La cola ESP contiene los parámetros necesarios para la desencriptación.
Con túnel
En este caso también hay las 2 posibilidades: con AH y con ESP.
Con AH, es decir, sólo autenticación, la estructura del mensaje es
Cabecera IP Cabecera AH Datos correspondiente al mensaje IP
y con ESP, es decir, autenticación y encriptación, la estructura del mensaje es
Cabecera Cabecera Datos correspondiente al Cola Cola de

IP ESP IPSec mensaje IP ESP autenticación
IPSec ESP IPSec
En este caso los campos de datos y cola ESP se transmiten encriptados y la autenticación corresponde a los
campos
- cabecera ESP IPSec
- Datos
- Cola ESP IPSec
17.3.8 SSL – Secure Sockets Layer
Esta tecnología SSL fue desarrollada originalmente por Netscape. El objetivo principal del protocolo SSL es el
de proveer un canal privado entre aplicaciones, que asegure la privacidad de los datos, su autenticación y su
integridad.
El protocolo SSL funciona en el nivel de aplicación según el modelo de referencia OSI y se apoya en el
protocolo de transporte TCP, empleando el puerto 443 del mismo.
El protocolo SSL toma los datos del nivel de aplicación, los formatea y los transmite al protocolo del nivel de
transporte TCP.
El emisor realiza las tareas siguientes:

- Toma el mensaje del nivel de aplicación.
- Fragmenta los datos si es necesario.
- Opcionalmente puede aplicar compresión.
- Aplica autenticación.
- Encripta los datos.
- Envía el resultado al protocolo de nivel de transporte TCP.
En cuanto al receptor, las tareas que realiza son:

- Toma los datos del protocolo de nivel de transporte TCP.
- Desencripta los datos
- Verifica la autenticación de los datos con la clave de autenticación.
- Opcionalmente descomprime los datos
- Recompone los datos si había fragmentación.
- Transmite el mensaje al protocolo del nivel de aplicación correspondiente.
El protocolo SSL se compone en realidad de 2 protocolos:

- En la capa inferior, corre el SSL Record Protocol, que cripta y autentica los datos transmitidos.
Una vez establecida la clave principal, el cliente y el servidor la pueden emplear para encriptar
los datos.
- En la capa superior, corre el SSL Handshake Protocol, que se emplea para la autenticación inicial
y la transmisión de las claves de encriptación.
Proceso de comunicación
Consta de los siguientes pasos:
- El cliente pide canal seguro al servidor
- El servidor contesta al cliente, enviando certificados y solicitando autenticación mutua.
- El cliente verifica los certificados y responde con el certificado de autenticación mutua.
- El cliente genera una clave de sesión y la envía cifrada con el certificado de servidor al servidor.
- Quedan establecidas todas las comunicaciones cifradas con la clave de sesión.
SSL Handshake Protocol

El SSL Handshake Protocol permite al cliente y al servidor determinar los parámetros necesarios para una
conexión SSL como son la versión, los algoritmos criptográficos, la autenticación opcional del cliente o el
servidor y los métodos de encriptación de clave pública que se emplean. En esta fase todos los mensajes viajan
encapsulados.
El proceso que se sigue es el siguiente:
- El cliente envía una solicitud de conexión al servidor.
- El servidor evalúa los parámetros enviados por el cliente y contesta al cliente con un certificado del servidor
si se ha requerido autenticación. Si no se requiere autenticación, se intercambian las claves para el
intercambio de los mensajes siguientes.
- El cliente envía los mensajes siguientes:
 si el servidor ha enviado una solicitud de certificado, el cliente debe enviar un certificado o
un mensaje sin certificar.
 si el servidor ha enviado un mensaje de intercambio de claves, el cliente contesta con un

mensaje basado en el algoritmo de clave pública.
 si el cliente ha enviado un certificado, el cliente verifica el certificado del servidor y envía
el resultado de la verificación del mismo. El cliente envía entonces un mensaje de
finalización indicando que la parte de negociación se ha completado.
- El servidor envía un mensaje de finalización indicando que la parte de negociación se ha completado.
- El cliente y el servidor de esta sesión generan una clave de encriptación cada uno en su dispositivo, y la
sesión queda establecida.
SSL Record Protocol

El SSL Record Protocol especifica el formato de los mensajes de este protocolo. Por lo general incluyen un
mensaje tipo digest mediante el cual se puede verificar que el contenido del mensaje no ha sido alterado durante
la transmisión.
Una vez ha sido determinada la clave principal con el protocolo SSL Handshake, todos los mensajes se encriptan
con la misma clave.
Los algoritmos recomendados son el RC2 o RC4, pero también soporta el DES, el triple-DES y el IDEA.
17.4 IGMP - Internet Group Management Protocol

El protocolo IGMP se emplea en los procesos de multicast fundamentalmente con el fin de que un dispositivo
entre a formar parte de uno de sus grupos o deje de pertenecer a él. Se describe en la RFC 2236.
En las redes, lo habitual es que un dispositivo envíe un mensaje a otro dispositivo. A esto se le llama unicast.
El multicast consiste en que un dispositivo quiere enviar un mismo mensaje a varios dispositivos. Si para ello,
debe generar tantos mensajes como dispositivos, es un despilfarro de tiempo y recursos y a su vez genera
muchísimo tráfico. Por esta razón, se ha diseñado esta funcionalidad en algunos protocolos de forma que el
dispositivo que envía el mensaje, solo envíe uno, pero que los destinatarios sean varios.
El protocolo Ethernet y el IP están preparados para esta funcionalidad, así las características generales del
multicast IP son las siguientes:
- Dirección del grupo. Cada grupo multicast se identifica por una dirección IP de clase D, que
corresponde al ámbito 224.0.0.0 – 239.255.255.254
- Número de grupos. Su número máximo es de 228 grupos de multicast simultáneos, aunque está
muy restringido por las tablas de enrutamiento.
- Miembro de un grupo. Un dispositivo puede darse de alta o de baja en un grupo de multicast.
- Posibilidad de atravesar enrutadores, con lo que éstos deben estar preparados para el multicast.
- Un dispositivo siempre puede enviar mensajes a grupos multicast, pero sólo recibirá mensajes de
este tipo si pertenece a algún grupo.
Los dispositivos pueden participar en un IP multicast de 3 formas distintas:
0 El dispositivo ni envía ni recibe

1 El dispositivo envía pero no recibe
2 El dispositivo puede enviar y recibir
En un proceso IP multicast, el protocolo IGMP se emplea en la gestión de los grupos de multicast, es decir, en
hacer que un dispositivo entre a formar parte de un grupo multicast, o dejar de pertenecer al mismo.
Si el proceso de multicast es entre dispositivos de un mismo segmento de red, no se necesita nada más, pero si es
una red con varios segmentos, el proceso se complica ya que en este caso a un mismo dispositivo le pueden
llegar un mensaje repetido.
En principio los enrutadores han de estar preparados para trasladar los mensajes de multicast de un segmento a
otro si es necesario, así como participar en la gestión de los grupos multicast con el protocolo IGMP. Hay varios
algoritmos que permiten una gestión óptima en el caso de redes multisegmento y son los siguientes:
- Reverse Path Forwarding (RPF) y su variante Truncated Reverse Path Forwarding (TRPF).
- Reverse Path Multicast (RPM)
- Core Based Trees (CBT)
- Distance Vector Multicast Routing Protocol (DVMRP)
- Multicast OSPF (MOSPF)
- Protocol Independent Multicast (PIM)
Descripción del protocolo

El protocolo IGMP es análogo al protocolo ICMP y funciona por tanto al nivel de red según el modelo de
referencia OSI. En IPv6, el IGMP se integra en ICMPv6 ya que todos los dispositivos con protocolo IPv6
soportan multicast. En IPv4, el soporte al IP multicast es opcional.
Los mensajes IGMP se encapsulan en mensajes IP. La cabecera IP siempre tendrá un 2 indicativo de IGMP y
tipo de servicio cero. La longitud de un mensaje IGMP es de 8 octetos y su estructura es la siguiente:
Versión Tiempo de respuesta Control de error

Dirección IP clase D
donde
- Tipo, 4 bits. Pueden ser los siguientes:
0x11 Solicitud de pertenencia a un grupo

0x16 Informe de pertenencia
0x17 Dejar el grupo
0x12 Informe de pertenencia (versión 1)
- Tiempo de respuesta, 12 bits. Se emplea para generar un retardo aleatorio, de forma que ante una
solicitud, no haya una respuesta simultánea de varios dispositivos.
- Control de error, 16 bits.
- La dirección clase D. Un cero es una solicitud genérica y si se rellena con una dirección válida,
solo deben responder los de este grupo.
Funcionamiento
Los sistemas que participan en el protocolo IGMP son de 2 tipos: dispositivos y enrutadores multicast. Para que
un dispositivo reciba mensajes multicast debe pertenecer a un grupo. Cuando un dispositivo es multi-homed, es
decir, tiene más de una tarjeta de red, se puede unir a uno o más grupos de acuerdo con sus interfaces. Los
mensajes multicast que el dispositivo recibe del mismo grupo de las 2 subredes pueden ser distintos.
Para unirse a un grupo, el dispositivo envía un mensaje a través de una interface. El mensaje se envía al grupo
multicast de interés. Los enrutadores multicast del mismo segmento reciben el mensaje y se activa la señal que
indica que al menos un dispositivo del segmento es un miembro de ese grupo. Los enrutadores multicast tienen
que escuchar a todas las direcciones multicast, es decir, a todos los grupos, con el fin de detectar estos mensajes.
La otra alternativa sería el uso de broadcasts o configurar los dispositivos con direcciones unicast para los
enrutadores multicast.
Regularmente los enrutadores multicast envían una petición a la dirección multicast de todos los dispositivos.
Cada dispositivo que quiere ser miembro de uno o más grupos, contesta una vez a cada grupo de interés, pero
nunca el grupo de todos los dispositivos, porque su pertenencia es automática. Cada contestación se envía
después de un retardo aleatorio con el fin de no causar sobrecarga en la red. Si no hay contestación de ningún
dispositivo en un intervalo establecido, el enrutador multicast decide que ningún dispositivo pertenece al grupo.
17.5 IPv6 - Internet Protocol version 6

La versión 4 del protocolo IP tiene entre otros problemas que:
- el número actual de direcciones IP está saturado y
- no contempla la implantación de ningún tipo de seguridad.
Por esta razón se ha definido la versión 6, con unas especificaciones bastantes diferenciadas y que se encuentran
detalladas en la RFC 2460.
El protocolo IPv6 tiene como características más significativas:

- Un mayor espacio de direcciones
- Globalmente un direccionamiento único y jerárquico, basado en prefijos más que en clases de
direcciones, permitiendo así unas tablas de enrutamiento más pequeñas y eficientes.
- Un mecanismo para la autoconfiguración de las interfaces de las redes.
- Soporte para encapsulación propia y de otros productos.
- Clases de servicios que distinguen los tipos de datos.
- Soporte de enrutamiento multicast mejorado, preferentemente frente al broadcast.
- Lleva incorporado autenticación y encriptación.
- Métodos de transición desde IPv4.
- Métodos de compatibilidad para coexistir y comunicar con IPv4.

El formato del mensaje del protocolo IPv6 es muy diferente del de la versión 4 del protocolo IP. En principio
como todos los protocolos, consta de una cabecera y un campo de datos.
Sin embargo en este protocolo, la cabecera consta de una parte básica y fija en cuanto a estructura, y de varias
cabeceras adicionales y opcionales.
La estructura de la cabecera principal es
Versión Clase de Etiqueta de flujo
tráfico
Longitud Cabecera Límite de
siguiente saltos
Dirección IP origen
Dirección IP destino
Datos
donde
- Versión, 4 bits. Contiene el número 6 indicativo de esta versión.
- Clase de tráfico, 4 bits.
Clase de tráfico de 0 a 7. Los mensajes con esta prioridad no se envían si hay

congestión.
Clase de tráfico de 8 a 15. Se intentan enviar estos mensajes aunque haya
congestión.
- Etiqueta de flujo, 24 bits. Se emplea para etiquetar los distintos tipos de flujo, con el fin de darles
un tratamiento diferencial.
- Longitud, 16 bits. Es la longitud del mensaje en octetos exceptuando esta cabecera.
- Cabecera siguiente, 8 bits. Indica el tipo de cabecera que hay a continuación de la principal. Los
posibles valores entre otros son
0 Opciones Hop-by-Hop
41 IPv6
43 Enrutamiento IPv6
44 Fragmento Ipv6
45 Protocolo IRP (Interdomain Routing Protocol)
46 Protocolo RSVP (Resource Reservation Protocol)
50 Protocolo ESP (Encapsulating Security Payload)
51 Autenticación Ipv6
58 Mensaje ICMP IPv6
59 Sin cabecera
60 Opciones de destino
-Límite de saltos, 8 bits. Equivale al tiempo de vida de la versión 4, pero ahora en cantidad de
saltos.
- Dirección IP origen, 128 bits.
- Dirección IP destino, 128 bits.
- Datos, que incluyen más cabeceras.
Se puede observar si se compara con la estructura del mensaje del protocolo Ipv4 que:
- La alineación ha pasado de 32 bits a múltiplos de 64.
- El campo de longitud de cabecera ha desaparecido y es reemplazado por otro de longitud del
mensaje (2 octetos) sin la cabecera. La longitud de la cabecera principal es fija y consta de 40
octetos.
- El tamaño del campo de direcciones pasa de 4 a 16 octetos cada uno de ellos.
- La información de la fragmentación pasa a formar parte de las cabeceras auxiliares.
- El campo tiempo de vida se sustituye por un campo de limitación de número de saltos (1 octeto).
- El campo tipo de servicio es reemplazado por 2 campos: uno de clase de tráfico y otro de etiqueta
de flujo. El campo clase de tráfico permite a los enrutadores clasificar los mensajes y establecer
prioridades.
- El campo protocolo es reemplazado por un campo que especifica el tipo de cabecera adicional o
extendida (1 octeto).
Cabecera opcionales
Su estructura básica es la siguiente:
Cabecera siguiente Longitud

Datos
donde
- Cabecera siguiente, 8 bits. Identificación del tipo de cabecera que está a continuación de ésta.
- Longitud, 8 bits. Longitud de esta cabecera opcional.
- Datos. La estructura de este campo es variable en función del tipo de cabecera de que se trate.
Direccionamiento
Sus especificaciones se encuentran detalladas en la RFC 2373. Cada dirección IP consta de 128 bits (16 octetos)
y su sintaxis es igual a la de la versión 4, es decir, 16 números del 0 al 255 separados por un punto, o también en
hexadecimal, como 8 valores separados por dos puntos(:).
Como los números de teléfono, es habitual el dividir la dirección en dos, un prefijo y la dirección IP propiamente
dicha.
La dirección IP interna equivalente a la 127.0.0.1 deIPv4 es ::1 y la de una dirección IPv4 es ::dirección IPv4.
Hay un rango reservado a direcciones globales con estructura jerarquizada y consiste en el prefijo 001.
17.6 WAP - Wireless Aplication Protocol

WAP (Wireless Aplication Protocol) es un protocolo de aplicaciones inalámbricas, que proporciona mecanismos
para acceder a la información y servicios de Internet desde un teléfono móvil.
Para ello es necesario que todos los terminales móviles incorporen un navegador, que sirve para poder acceder a
la información deseada utilizando el lenguaje WML.
El esquema de protocolos es el siguiente:
Entorno de Aplicaciones Inalámbricas (WAE)

Nivel de Sesión (WSP)
Nivel de Transacciones (WTP)
Nivel de Seguridad (WTLS)
Nivel de Transporte (WDP)
Portadores :
SMS, USSD, CSD, IS-136, CDMA, CDPD, PDC-P, etc.
Para establecer una transacción, es necesario el empleo de una pasarela ya que entre el servidor y el cliente hay
un medio con otro protocolo.
Los pasos para establecer una transacción WAP son los siguientes :
1) el usuario utiliza su teléfono móvil compatible WAP para solicitar la página.
2) El navegador del teléfono móvil crea una petición que contiene la URL de la página solicitada, y
además información acerca del abonado solicitante. Esta petición se envía a la pasarela WAP.
3) La pasarela examina la petición recibida, y si es conforme, genera una petición convencional de
HTTP o HTTPS, que debe ser enviada al servidor Web.
4) El servidor Web examina la petición y determina qué información debe devolver. Podría tratarse
de una página estática, que simplemente se busca en el directorio adecuado y se envía; o bien de
una página dinámica, generada sobre la marcha por un programa CGI, Java, una página ASP, o
técnicas similares, utilizadas en general para consultas a bases de datos donde se encuentra
almacenada la información de interés para el usuario.
5) El servidor Web añade la cabecera HTTP o HTTPS pertinente al fichero estático o a la salida del
programa que ha generado la página dinámica, y la envía de vuelta a la pasarela.
6) En la pasarela se examina la respuesta del servidor, se valida el código WML en busca de errores,
y se genera la respuesta que es enviada al teléfono móvil solicitante.
7) El navegador del terminal móvil examina la respuesta recibida y si el código es correcto la
muestra en pantalla.
Bibliografía 159
Apéndice A. Bibliografía
Cisco - Internetworking Technology Overview
Cisco - ATM Internetworking, Anthony Alles
L&M - TCP/IP Seminario práctico
IBM - TCP/IP Tutorial and Technical Overview
IBM - IP Network Design Guide
IBM - Learning LPAD
Internetworking with TCP/IP - Douglas E.Comer Ed.Prentice Hall

Bibliografía 160
Referencias RFCs 161
Apéndice B. Referencias RFCs
0768 User Datagram Protocol. J. Postel. Aug-28-1980. (También STD0006)
0791 Internet Protocol. J. Postel. Sep-01-1981. (También STD0005)
0793 Transmission Control Protocol. J. Postel. Sep-01-1981. (También STD0007)
0821 Simple Mail Transfer Protocol. J. Postel. Aug-01-1982. (También STD0010)
0822 Standard for the format of ARPA Internet text messages. D. Crocker. Aug-13-1982. (Updated by
RFC1123, RFC1138, RFC1148, RFC1327, RFC2156) (También STD0011)
0854 Telnet Protocol Specification. J. Postel, J.K. Reynolds. May-01-1983. (También STD0008)
0855 Telnet Option Specifications. J. Postel, J.K. Reynolds. May-01-1983. (También STD0008)
0904 Exterior Gateway Protocol formal specification. D.L. Mills. Apr-01-1984.
0906 Bootstrap loading using TFTP. R. Finlayson. Jun-01-1984.
0919 Broadcasting Internet Datagrams. J.C. Mogul. Oct-01-1984 (También STD0005)
0922 Broadcasting Internet datagrams in the presence of subnets. J.C. Mogul. Oct-01-1984. (También STD0005)
0950 Internet Standard Subnetting Procedure. J.C. Mogul, J. Postel. Aug-01-1985. ( También STD0005)
0951 Bootstrap Protocol. W.J. Croft, J. Gilmore. Sep-01-1985. (Updated by RFC1395, RFC1497, RFC1532,
RFC1542)
0959 File Transfer Protocol. J. Postel, J.K. Reynolds. Oct-01-1985. (Updated by RFC2228, RFC2640) (También
STD0009)
0974 Mail routing and the domain system. C. Partridge. Jan-01-1986. (También STD0014)
1001 Protocol standard for a NetBIOS service on a TCP/UDP transport: Concepts and methods. NetBIOS
Working Group in the Defense Advanced Research Projects Agency, Internet Activities Board, End-to-End
Services Task Force. Mar-01-1987. (También STD0019)
1002 Protocol standard for a NetBIOS service on a TCP/UDP transport: Detailed specifications. NetBIOS
Working Group in the Defense Advanced Research Projects Agency, Internet Activities Board, End-to-End
Services Task Force. Mar-01-1987. (También STD0019)
1034 Domain names - concepts and facilities. P.V. Mockapetris. Nov-01-1987. (Updated by RFC1101,
RFC1183, RFC1348, RFC1876, RFC1982, RFC2065, RFC2181, RFC2308, RFC2535) (También STD0013)
1035 Domain names - implementation and specification. P.V. Mockapetris. Nov-01-1987. (Updated by
RFC1101, RFC1183, RFC1348, RFC1876, RFC1982, RFC1995, RFC1996, RFC2065, RFC2181, RFC2136,
RFC2137, RFC2308, RFC2535, RFC2845) (También STD0013)
1049 Content-type header field for Internet messages. M.A. Sirbu. Mar-01-1988. (También STD0011)
1055 Nonstandard for transmission of IP datagrams over serial lines: SLIP. J.L. Romkey. Jun-01-1988.
(También STD0047)
1058 Routing Information Protocol. C.L. Hedrick. Jun-01-1988. (Updated by RFC1388, RFC1723) (También
STD0034)
1112 Host extensions for IP multicasting. S.E. Deering. Aug-01-1989. (Updated by RFC2236) (También
STD0005)
1144 Compressing TCP/IP headers for low-speed serial links. V. Jacobson. Feb-01-1990.
1179 Line printer daemon protocol. L. McLaughlin. Aug-01-1990.
1334 PPP Authentication Protocols. B. Lloyd, W. Simpson. October 1992. ( Obsoleted by RFC1994)
1349 Type of Service in the Internet Protocol Suite. P. Almquist. July 1992. (Obsoleted by RFC2474)
1388 RIP Version 2 Carrying Additional Information. G. Malkin. January 1993. (Updated by RFC1723 and
RFC2453) (También STD0056)
1395 BOOTP Vendor Information Extensions. J. Reynolds. January 1993. (Obsoleted by RFC1497, RFC1533)
(Updates RFC0951)
1497 BOOTP Vendor Information Extensions. J. Reynolds. August 1993. (Obsoleted by RFC1533) (Updates
RFC0951)
1510 The Kerberos Network Authentication Service (V5). J. Kohl, C. Neuman. September 1993.
1532 Clarifications and Extensions for the Bootstrap Protocol. W. Wimer. October 1993. (Obsoleted by
RFC1542)
1542 Clarifications and Extensions for the Bootstrap Protocol. W. Wimer. October 1993.
1652 SMTP Service Extension for 8bit-MIMEtransport. J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker.
July 1994.
1723 RIP Version 2 - Carrying Additional Information. G. Malkin. November 1994. (Obsoleted by
RFC2453) (También STD0056)
1771 A Border Gateway Protocol 4 (BGP-4). Y. Rekhter, T. Li. March 1995.
1795 Data Link Switching: Switch-to-Switch Protocol AIW DLSw RIG: DLSw Closed Pages, DLSw
Standard Version 1. L. Wells, Chair, A. Bartky, Editor. April 1995.
1813 NFS Version 3 Protocol Specification. B. Callaghan, B. Pawlowski, P. Staubach. June 1995.
1869 SMTP Service Extensions. J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker. November 1995.
1870 SMTP Service Extension for Message Size Declaration. J. Klensin, N. Freed, K. Moore. November 1995.
1994 PPP Challenge Handshake Authentication Protocol (CHAP). W. Simpson. August 1996.(Updated by
RFC2484)
2045 Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies. N. Freed &
N. Borenstein. November 1996. (Updated by RFC2184, RFC2231)
2046 Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types. N. Freed & N. Borenstein.
November 1996. (Updated by RFC2646)
2047 MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII
Text. K. Moore. November 1996. (Updated by RFC2184, RFC2231)
2048 Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures. N. Freed, J. Klensin &
J. Postel. November 1996.
2049 Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples. N. Freed
& N. Borenstein. November 1996.
2060 Internet Message Access Protocol - Version 4rev1. M. Crispin. December 1996.
2131 Dynamic Host Configuration Protocol. R. Droms. March 1997.
2132 DHCP Options and BOOTP Vendor Extensions. S. Alexander, R. Droms. March 1997.
2184 MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations.
N. Freed, K. Moore. August 1997. (Obsoleted by RFC2231)
2228 FTP Security Extensions. M. Horowitz, S. Lunt. October 1997.
2231 MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations.
N. Freed, K. Moore. November 1997.
2236 Internet Group Management Protocol, Version 2. W. Fenner. November 1997.
2328 OSPF Version 2. J. Moy. April 1998.
2341 Cisco Layer Two Forwarding (Protocol) "L2F". A. Valencia, M. Littlewood, T. Kolar. May 1998.
2453 RIP Version 2. G. Malkin. November 1998. (También STD0056)
2474 Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers. K. Nichols, S.
Blake, F. Baker, D. Black. December 1998.
2484 PPP LCP Internationalization Configuration Option. G. Zorn. January 1999.
2640 Internationalization of the File Transfer Protocol. B. Curtin. July 1999.
2646 The Text/Plain Format Parameter. R. Gellens. August 1999.

Ebook en PDF Redes de Ordenadores Protocolos

Cargado por

Copyright:

Formatos disponibles

Ebook en PDF Redes de Ordenadores Protocolos

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Ebook en PDF Redes de Ordenadores Protocolos

Cargado por

Copyright:

Formatos disponibles

LOS PROTOCOLOS

Antonio Salavert Casamor

Registro General de la propiedad Intelectual

CAPÍTULO 2. LOS PROTOCOLOS EN LAS REDES......................................................................................3

CAPÍTULO 4. MODELO OSI...............................................................................................................................7

CAPÍTULO 6. COMUNICACIONES ENTRE ORDENADORES DE UNA RED........................................13

CAPÍTULO 7. RELACIÓN MODELO OSI Y COMUNICACIÓN ENTRE ORDENADORES.................15

CAPÍTULO 9. ORGANISMOS DE NORMALIZACIÓN................................................................................23

CAPÍTULO 10. DIRECCIONAMIENTO..........................................................................................................25

CAPÍTULO 12. PROTOCOLOS DE NIVEL ENLACE (2).............................................................................29

APÉNDICE B. REFERENCIAS RFCS............................................................................................................161

Capítulo 2. Los protocolos en las redes

Protocolo propietario o estándar

Todos los mensajes de los protocolos constan de 3 partes:

Capítulo 3. Definiciones básicas

Capítulo 4. Modelo OSI

Este modelo consta de 7 niveles y son los siguientes :

7 Sistemas Operativos Apple

4.1 Nivel físico (1)

4.2 Nivel de enlace (2)

Sus funciones son :

El protocolo más extendido de este nivel es el 802.3 o Ethernet.

Hay dos formatos para las direcciones MAC: 0000.0c12.3456 y 00-00-0c-12-34-56.

4.3 Nivel de red (3)

4.4 Nivel de transporte (4)

4.5 Nivel de sesión (5)

4.6 Nivel de presentación (6)

4.7 Nivel de aplicación (7)

Capítulo 5. Conceptos de LAN y WAN

Ethernet 10 Mbps, 100Mps, 1 Gbps, 10 Gbps

Siendo las unidades bits por segundo.

Capítulo 6. Comunicaciones entre ordenadores de una red

Los ordenadores constan de 3 partes :

A nivel de aplicaciones, también hay sus protocolos.

Capítulo 7. Relación modelo OSI y comunicación entre ordenadores

Cabecera Datos Control de error

Cabecera Cabecera Datos Control

Cabecera Cabecera Cabecera Datos Control

Cabecera Cabecera Cabecera CabeceraNiv Datos Control

Así llega finalmente la información a la aplicación correspondiente del sistema B.

A continuación se detalla la estructura de un mensaje, obtenida de un analizador de redes, correspondiente a una

7.1 Caso de 2 ordenadores conectados en red sin línea de comunicaciones

Nivel Aplicación Nivel Aplicación

7.2 Caso de 1 ordenador conectado a Internet

A nivel 3 y 4, se debe instalar el protocolo TCP/IP que es el que se emplea en Internet.

7.3 Caso de 2 redes conectadas por una línea de comunicaciones a través de 2

En este caso, cada red dispone de un enrutador con un mínimo de 2 interfaces:

Cabecera Cabecera Cabecera Datos Control de

Capítulo 8. Proyecto IEEE 802

El subnivel de control de acceso al medio (MAC) proporciona:

Capítulo 9. Organismos de normalización

ANSI (American National Standards Institute)

CCITT (Consultative Commitee for International Telegraph and Telephone)

ECMA (European Computer Manufacturers Association)

EIA (Electronic Industries Association)

IAB (Internet Activities Board)

IEEE (Institute of Electrical and Electronic Engineers)

ISO (International Standard Organization)