|
RED PRESTADORA DE SERVICIOS TELEMÁTICOS
|
CARACTERISTICAS
|
|
X.25
|
·
Recuperación de Errores.
·
Identificación de paquetes
procedentes de ordenadores y terminales concretos.
·
Asentimiento de paquetes.
·
Rechazo de paquetes.
·
El control de Flujo.
|
|
FRAME RELAY
|
·
Proporciona conexiones entre
usuarios a través de una red pública.
·
Las redes Frame Relay se
construyen partiendo de un equipamiento de usuario que se encarga de
empaquetar todas las tramas de los protocolos existentes en una única trama
Frame Relay. También incorporan los nodos que conmutan las tramas Frame Relay
en función del identificador de conexión, a través de la ruta establecida
para la conexión en la red.
·
Circuito Virtual Permanente
(PVC), cada conexión virtual entre dos abonados es establecido por el operador
de la red en el momento de la subscripción y solo puede ser modificado por
este.
·
Circuito Virtual Conmutado
(SVC), los usuarios pueden establecer y liberar las conexiones a voluntad.
·
Se adapta mejor a las
características de las infraestructuras de telecomunicaciones actuales.
|
|
RDSI
|
·
ISDN es un complejo sistema
de procesamiento de llamadas que permiten transportar por la red telefónica
voz y datos en el mismo "chorro" digital.
·
ISDN es totalmente digital
que permite el transporte de voz y de datos (textos, gráficas,
videoconferencia, etc.) todo transmitido desde una única interfaz de red.
·
Las ventajas más
sobresalientes que tiene ISDN con respecto a las conexiones por modem conocidas
por nosotros, son la velocidad y confiablidad de la conexión. Usando ISDN se
pueden lograr conexiones a más de 64 kbps lo cual significa un aumento de más
del 50% sobre la velocidad de las conexiones típicas que tenemos con los módems
actuales.
·
Hay equipos ISDN en el
mercado para todas las necesidades, equipos para el hogar en los cuales se
conecta un sólo micro y el teléfono, equipos para la pequeña oficina (SOHO),
donde se utiliza una misma conexión ISDN para comunicar varios estaciones de
trabajo a una red remota, hasta llegar a equipos que soportan gran cantidad
de tráfico y numerosos esquemas de enrutamiento orientados a las grandes
corporaciones.
|
|
ATM
|
·
Transmitir la información en
paquetes pequeños, de tamaño fijo, permite que cada conmutador sepa como
enviar cada celda entrante. Además cada recurso en la ruta del paquete pueden
saber que celdas pertenecen a que conexiones.
·
Tener celdas de tamaño fijo permite
que sea fácil construir conmutadores de hardware para manejarlas haciendo el
proceso un poco más rápido.
·
El hardware puede
configurarse para enviar una celda entrante a múltiples líneas de salida
(multiplexacion), propiedad necesaria para el manejo de programas de
televisión.
·
ATM facilita la garantía en
la calidad de servicio, esto se debe a que las celdas pequeñas no bloquean ninguna
línea por mucho tiempo.
·
Garantiza el orden de llegada
de las celdas debido a que siguen la misma ruta destino.
·
Las velocidades más comunes
de las redes ATM son de 155 y 622 Mbps (aunque también soportan velocidades más
altas).
·
ATM tan solo especifica que
las celdas ATM se pueden enviar por cualquier medio de transporte. No
prescribe un conjunto particular de reglas. Esto significa que está diseñado
para ser independiente del medio de transmisión.
·
La Capa ATM es una
combinación de capas de enlace de datos y de red del modelo OSI, no hay
división en subcapas.
La entrega de celdas no está garantizada.
|
jueves, 9 de mayo de 2013
Cuadro Comparativo de las Características de las Redes Prestadoras de Servicios
Cuadro Comparativo de las Ventajas y Desventajas entre Redes Prestadoras de Servicios
|
Red Prestadora De Servicios Telemáticos
|
Ventajas
|
Desventajas
|
|
X.25
|
·
X.25 trabaja sobre servicios
basados en circuitos virtuales (VC).
·
Para identificar las
conexiones en la red de los distintos DTE, en X.25 se emplean números de
canal lógico (LCN). Pueden asignarse hasta 4095 canales lógicos y sesiones de
usuario a un mismo canal físico.
·
La adopción de un estándar
común a distintos fabricantes nos permite conectar fácilmente equipos de
distintas marcas.
·
La norma X.25 ha experimentado
numerosas revisiones y hoy por hoy puede considerarse relativamente madura.
·
El empleo de una norma tan
extendida como X.25 puede reducir sustancialmente los costes de la red.
·
Es mucho más sencillo
solicitar a un fabricante una red adaptada a la norma X.25 que entregarle un
extenso conjunto de especificaciones.
|
·
El nivel físico de X.25 no
desempeña funciones de control significativas. Se trata más bien de un
conducto pasivo, de cuyo control se encargan los niveles de enlace y de red.
·
X.25 se utiliza como
infraestructura de Red de Área Extensa (WAN).
|
|
FRAME RELAY
|
·
El principal objetivo de
Frame Relay es la interconexión de redes LAN.
·
Alta velocidad y bajo retardo.
·
Soporte eficiente para
tráficos a ráfagas.
·
Eficiencia.
·
Buena relación
coste-prestaciones.
·
Transporte integrado de
distintos protocolos de voz y datos.
·
Conectividad "todos con
todos".
·
Simplicidad en la gestión.
·
Interfaces estándares.
·
Puede ser implementado en
software, y por tanto puede ser mucho más barato.
·
Está orientado a conexiones,
como la mayoría de las WAN.
·
Puede "empaquetar"
tramas de datos de cualquier protocolo de longitud variable.
·
La "carga del
protocolo" de Frame Relay es menor de un 5%.
·
Desventajas De Frame Relay
|
·
Carece de flexibilidad para
alterar la topología de la red.
·
Sólo ha sido definido para
velocidades de hasta 1,544/2,048 Mbps.
·
No soporta aplicaciones
sensibles al tiempo, al menos de forma estándar.
·
No garantiza la entrega de
los datos.
|
|
RDSI
|
·
Fácil instalación y
configuración del adaptador RDSI.
·
Mayor velocidad de acceso.
Utilizando los canales por separado a 64 kbps o conjuntamente a 128 kbps.
·
Compatibilidad de servicios.
Podemos conectarnos por un canal y hablar por el otro al tener dos líneas.
·
Sistema digital, con todas
las ventajas que conlleva la transmisión discreta de los datos.
·
Accesos gratuitos a Internet,
al igual que en las líneas RTC.
|
·
Mayor coste de mantenimiento.
Esto se debe al mayor coste del alquiler de la línea.
·
Mayor coste de utilización.
Al ser un servicio de mayor calidad, el coste del mismo también es algo
superior al de las RTC, aunque cada vez es menor esta diferencia, llegando a
tener el mismo coste en algunos operadores.
|
|
ATM
|
·
Una única red ATM dará cabida
a todo tipo de tráfico.
·
ATM mejora la eficiencia y
manejabilidad de la red.
·
Capacita nuevas aplicaciones,
debido a su alta velocidad y a la integración de los tipos de tráfico.
·
Compatibilidad, porque ATM no
está basado en un tipo específico de transporte físico, es compatible con las
actuales redes físicas que han sido desplegadas.
·
ATM puede ser implementado
sobre par trenzado, cable coaxial y fibra óptica.
·
Simplifica el control de la
red. ATM está evolucionando hacia una tecnología estándar para todo tipo de
comunicaciones. Esta uniformidad intenta simplificar el control de la red
usando la misma tecnología para todos los niveles de la red.
·
Largo periodo de vida de la
arquitectura. Los sistemas de información y las industrias de
telecomunicaciones se están centrando y están estandarizado el ATM. ATM ha
sido diseñado desde el comienzo para ser flexible en:
o Distancias
geográficas
o Número
de usuarios
o Acceso
y ancho de banda (hasta ahora, las velocidades varían de Megas a Gigas).
|
·
ATM es radicalmente distinto
a las tecnologías LAN de hoy en día, lo cual hace que muchos conceptos tomen
años en ser estandarizados. Los sistemas operativos actuales y las familias
de protocolos en particular, requerirán de modificaciones significativas con
el fin de soportar ATM. Esto será muy costoso, molesto y consumirá tiempo.
·
Algunas personas pagarán
mucho por estar en la punta de la tecnología, pero por los momentos, las
actuales tecnologías de alta velocidad como FDDI, Fast Ethernet e Ehernet
Switched proveerán rendimiento a precios que los productos ATM no serán capaz
de competir. Sólo una vez que las ventas de ATM alcancen volúmenes
significativos el costo de los productos podrán competir con la tecnología de
hoy en día.
|
jueves, 2 de mayo de 2013
Protocolos Router
PROTOCOLO IPX/SPX
IPX/SPX (del
inglés Internetwork Packet Exchange/Sequenced Packet Exchange), Protocolo
Novell o simplemente IPX es una familia de protocolos de red desarrollados por
Novell y utilizados por su sistema operativo de red NetWare.
IPX: Protocolo Intercambio de Paquetes Entre Redes (IPX) es la implementación del protocolo IDP (Internet Datagram Protocol) de Xerox. Es un protocolo de datagramas rápido orientado a comunicaciones sin conexión que se encarga de transmitir datos a través de la red, incluyendo en cada paquete la dirección de destino. Pertenece a la capa de red (nivel 3 del modelo OSI) y al ser un protocolo de datagramas es similar (aunque más simple y con menor fiabilidad) al protocolo IP del TCP/IP en sus operaciones básicas pero diferente en cuanto al sistema de direccionamiento, formato de los paquetes y el ámbito general Fue creado por el ing. Alexis G.Soulle.
SPX: Protocolo Intercambio de Paquetes en Secuencia (SPX) es la implementación del protocolo SPP (Sequenced Packet Protocol) de Xerox. Es un protocolo fiable basado en comunicaciones con conexión y se encarga de controlar la integridad de los paquetes y confirmar los paquetes recibidos a través de una red. Pertenece a la capa de transporte (nivel 4 del modelo OSI) y actúa sobre IPX para asegurar la entrega de los paquetes (datos), ya que IPX por sí solo no es capaz. Es similar a TCP ya que realiza las mismas funciones. Se utiliza principalmente para aplicaciones cliente/servidor.
Sistema de direccionamiento IPX: Se utilizan tres componentes básicos para identificar un proceso en la red:
Dirección de red que identifica la red a la que pertenece, número de nodo que indica el dispositivo conectado a la red y número de socket que indica el proceso en el nodo.
·
Network Address Number 32 bits
·
Nodo Number 48 bits
·
Socket Number 16 bits
PROTOCOLO TCP/IP
Su función principal es permitir que la información sea enviada a un sistema a otro, sin importar que ambos sistemas sean de la misma marca o el mismo fabricante.
Su arquitectura del protocolo TCP / IP
La arquitectura del TCP/ IP consta de cuatro capas en las que se agrupan los protocolos, y que se relacionan con los niveles de modelo OSI.
·
Aplicación:
Corresponden con los niveles OSI de la aplicación, presentación y sesión aquí
se incluyen protocolos destinados a proporcionar servicios como correo electrónico
(SMTP), trasferencia de ficheros(FTP), conexión remota (TELNET) y otros más
recientes como el protocolo HTTP (Hypertex transfer protocol).
·
Transporte:
Coincide con el nivel de trasporte del modelo OSI. Los protocolos de este
nivel, como TCP y UDP, se encargan de manejar los datos y proporcionar la
fiabilidad necesaria en su trasporte.
·
Internet:
Es el nivel de red del modelo OSI. Incluye el protocolo IP, que se encarga de
enviar los paquetes de información a sus destinos correspondientes. Los
protocolos de nivel de trasporte los usan con esta finalidad (maneja la comunicación
de una maquina a otra).
·
Red:
Es la interfaz de la red real. TCP /IP no especifica ningún protocolo concreto,
así que corre por las interfaces conocidas, por ejemplo: 802.2, CSMA/CD, X.25.
·
Es lento en redes con un tráfico
de volumen algo bajo, sin embargo puede ser más rápido en redes con un volumen
de tráfico alto.
PROTOCOLO DEC NET
DECnet, al igual que la ASR de IBM, define un marco general tanto para la red de comunicación de datos como para el procesamiento distribuido de datos. El objetivo de DECnet es permitir la interconexión generalizada de diferentes computadoras principales y redes punto a punto, multipunto o conmutadas de manera tal que los usuarios puedan compartir programas, archivos de datos y dispositivos de terminales remotos.
DECnet soporta la norma del protocolo internacional X.25 y cuenta con capacidades para conmutación de paquetes. Se ofrece un emulador mediante el cual los sistemas de la Digital Equipment Corporation se pueden interconectar con las macro computadoras de IBM y correr en un ambiente ASR. El protocolo de mensaje para comunicación digital de datos (PMCDD) de la DECnet es un protocolo orientado a los bytes cuya estructura es similar a la del protocolo de Comunicación Binaria Síncrona (CBS) de IBM.
El DECnet primero fue anunciado a mediados de los años setenta junto con la introducción de la DEC VAX 11/780. Fue diseñado originalmente para las interfaces paralelas que conectaron sistemas próximos. El DECnet también define redes de comunicaciones sobre redes del área metropolitana del FDDI (Fiber Distributed Data Interface), y las redes de área amplia que utilizan instalaciones de transmisión privadas o públicas de datos.
Se han lanzado al mercado varias versiones del DECnet. Primero el utilizado para la comunicación entre dos microcomputadoras directamente unidas. Los lanzamientos siguientes ampliaron la funcionalidad del DECnet agregando la ayuda para los protocolos propietarios y estándares adicionales, manteniendo también la compatibilidad con los protocolos anteriores a su lanzamiento.
Estas versiones se han desarrollado en forma de fases. La fase III del DECnet puso muchas características avanzadas del establecimiento de una red en ejecución, incluyendo el encaminamiento adaptante que podría detectar faltas del acoplamiento y reencaminar tráfico cuanto sea necesario. Fase IV del DECnet, introducida en 1982, con varias características, incluyendo las siguientes:
·
Un
terminal virtual que permitía al usuario iniciar una sesión en un nodo alejado
·
Ayuda
para hasta 64.000 nodos (1.023 nodos en 63 áreas)
·
Puesta
en práctica del RASGÓN (Routing Information Protocol), un algoritmo de
encaminamiento de distancia-vector
·
Una
entrada de IBM SNA (Systems Network Architecture)
PROTOCOLO APPLE TALK
AppleTalk
es un conjunto de protocolos desarrollados por Apple Inc. para la conexión de
redes. Fue incluido en un Macintosh en 1984 y actualmente está en desuso en los
Macintosh en favor de las redes TCP/IP.
Direccionamiento
Una dirección de AppleTalk constaba de 4 bytes. Un número de red de dos bytes, un número de nodo de un byte y un número de socket de un byte. De éstos, solamente el número de red requería configuración y era obtenido de un enrutador. Cada nodo elegía dinámicamente su propio número del nodo, según un protocolo que manejaba la contención entre diversos nodos que elegían accidentalmente el mismo número. Para los números del socket, algunos números conocidos eran reservados para los propósitos especiales específicos de AppleTalk.
Debido a esto, los usuarios no podían esperar tener acceso a servicios especificando su dirección. En lugar de direcciones, todos los servicios tenían nombres que intentaban ser significativos a los usuarios, y también eran suficientemente largos para reducir al mínimo los conflictos de conexión.
PROTOCOLO XNS
Durante los 80, XNS fue usado por 3Com y (con algunas modificaciones) otros sistemas comerciales que se volvieron más comunes que el XNS en sí mismo, incluyendo Ungermann-Bass Net/One, Novell NetWare, y Banyan VINES.
Fue
desarrollado por Xerox PARC a principios de los 80, basado en el protocolo PUP
(terminado a finales de los 70). Algunos de los protocolos en XNS eran ligeras
modificaciones a aquellos del PUP.
PROTOCOLO HTTP
Cómo funciona el protocolo HTTP: El protocolo HTTP funciona a través de solicitudes y respuestas entre un cliente (por ejemplo un navegador de Internet) y un servidor (por ejemplo la computadora donde residen páginas web). A una secuencia de estas solicitudes se le conoce como sesión de HTTP. La información que el navegador de Internet está presentando en un momento dado, se identifica en la llamada “barra de navegación”, que comienza con http y se le conoce como URL.
Sesiones seguras HTTPS: Cuando un URI comienza con HTTPS en lugar de HTTP, significa que el navegador está usando un esquema seguro para proteger la información que está siendo transferida. Este esquema HTTPS es el que toda transacción comercial en Internet debe de usar. A este esquema se le conoce como SSL.
VERSIONES
HTTP ha pasado por múltiples versiones del protocolo, muchas de las cuales son compatibles con las anteriores. El RFC 2145 describe el uso de los números de versión de HTTP. El cliente le dice al servidor al principio de la petición la versión que usa, y el servidor usa la misma o una anterior en su respuesta.
- · 0.9 Obsoleta. Soporta sólo un comando, GET, y además no especifica el número de versión HTTP. No soporta cabeceras. Como esta versión no soporta POST, el cliente no puede enviarle mucha información al servidor.
- · HTTP/1.0 (mayo de 1996): Esta es la primera revisión del protocolo que especifica su versión en las comunicaciones, y todavía se usa ampliamente, sobre todo en servidores proxy.
- · HTTP/1.1 (junio de 1999)1 2: Versión actual; las conexiones persistentes están activadas por defecto y funcionan bien con los proxies. También permite al cliente enviar múltiples peticiones a la vez por la misma conexión (pipelining) lo que hace posible eliminar el tiempo de Round-Trip delay por cada petición.
- · HTTP/1.2: Los primeros borradores de 1995 del documento PEP — an Extension Mechanism for HTTP (el cuál propone el Protocolo de Extensión de Protocolo, abreviado PEP) los hizo el World Wide Web Consortium y se envió al Internet Engineering Task Force. El PEP inicialmente estaba destinado a convertirse en un rango distintivo de HTTP/1.2.3 En borradores posteriores, sin embargo, se eliminó la referencia a HTTP/1.2. El RFC 2774 (experimental), HTTP Extension Framework, incluye en gran medida a PEP. Se publicó en febrero de 2000.
PROTOCOLO DHCP
El protocolo DHCP sirve principalmente para distribuir direcciones IP en una red, pero desde sus inicios se diseñó como un complemento del protocolo BOOTP (Protocolo Bootstrap), que se utiliza, por ejemplo, cuando se instala un equipo a través de una red (BOOTP se usa junto con un servidor TFTP donde el cliente encontrará los archivos que se cargarán y copiarán en el disco duro). Un servidor DHCP puede devolver parámetros BOOTP o la configuración específica a un determinado host.
Funcionamiento del protocolo DHCP
Primero, se necesita un servidor DHCP que distribuya las direcciones IP. Este equipo será la base para todas las solicitudes DHCP por lo cual debe tener una dirección IP fija. Por lo tanto, en una red puede tener sólo un equipo con una dirección IP fija: el servidor DHCP.
El sistema básico de comunicación es BOOTP (con la trama UDP). Cuando un equipo se inicia no tiene información sobre su configuración de red y no hay nada especial que el usuario deba hacer para obtener una dirección IP. Para esto, la técnica que se usa es la transmisión: para encontrar y comunicarse con un servidor DHCP, el equipo simplemente enviará un paquete especial de transmisión (transmisión en 255.255.255.255 con información adicional como el tipo de solicitud, los puertos de conexión, etc.) a través de la red local. Cuando el DHCP recibe el paquete de transmisión, contestará con otro paquete de transmisión (no olvide que el cliente no tiene una dirección IP y, por lo tanto, no es posible conectar directamente con él) que contiene toda la información solicitada por el cliente.
Se podría suponer que un único paquete es suficiente para que el protocolo funcione. En realidad, hay varios tipos de paquetes DHCP que pueden emitirse tanto desde el cliente hacia el servidor o servidores, como desde los servidores hacia un cliente:
·
DHCPDISCOVER (para ubicar servidores DHCP
disponibles)
·
DHCPOFFER (respuesta del servidor a un
paquete DHCPDISCOVER, que contiene los parámetros iniciales)
·
DHCPREQUEST (solicitudes varias del
cliente, por ejemplo, para extender su concesión)
·
DHCPACK (respuesta del servidor que
contiene los parámetros y la dirección IP del cliente)
·
DHCPNAK (respuesta del servidor para
indicarle al cliente que su concesión ha vencido o si el cliente anuncia una
configuración de red errónea)
·
DHCPDECLINE (el cliente le anuncia al
servidor que la dirección ya está en uso)
·
DHCPRELEASE (el cliente libera su dirección
IP)
·
DHCPINFORM (el cliente solicita parámetros
locales, ya tiene su dirección IP)
El primer
paquete emitido por el cliente es un paquete del tipo DHCPDISCOVER. El servidor
responde con un paquete DHCPOFFER, fundamentalmente para enviarle una dirección
IP al cliente. El cliente establece su configuración y luego realiza un
DHCPREQUEST para validar su dirección IP (una solicitud de transmisión ya que
DHCPOFFER no contiene la dirección IP) El servidor simplemente responde con un
DHCPACK con la dirección IP para confirmar la asignación. Normalmente, esto es
suficiente para que el cliente obtenga una configuración de red efectiva, pero
puede tardar más o menos en función de que el cliente acepte o no la dirección
IP.
PROTOCOLO FTP
El servicio FTP es ofrecido por la capa de aplicación del modelo de capas de red TCP/IP al usuario, utilizando normalmente el puerto de red 20 y el 21. Un problema básico de FTP es que está pensado para ofrecer la máxima velocidad en la conexión, pero no la máxima seguridad, ya que todo el intercambio de información, desde el login y password del usuario en el servidor hasta la transferencia de cualquier archivo, se realiza en texto plano sin ningún tipo de cifrado, con lo que un posible atacante puede capturar este tráfico, acceder al servidor y/o apropiarse de los archivos transferidos.
Para
solucionar este problema son de gran utilidad aplicaciones como scp y sftp,
incluidas en el paquete SSH, que permiten transferir archivos pero cifrando
todo el tráfico.
Estas órdenes FTP especifican parámetros para la conexión de datos (puerto de datos, modo de transferencia, tipo de representación y estructura) y la naturaleza de la operación sobre el sistema de archivos (almacenar, recuperar, añadir, borrar, etc.). El proceso de transferencia de datos (DTP) de usuario u otro proceso en su lugar, debe esperar a que el servidor inicie la conexión al puerto de datos especificado (puerto 20 en modo activo o estándar) y transferir los datos en función de los parámetros que se hayan especificado.
Vemos también en el diagrama que la comunicación entre cliente y servidor es independiente del sistema de archivos utilizado en cada computadora, de manera que no importa que sus sistemas operativos sean distintos, porque las entidades que se comunican entre sí son los PI y los DTP, que usan el mismo protocolo estandarizado: el FTP.
También hay
que destacar que la conexión de datos es bidireccional, es decir, se puede usar
simultáneamente para enviar y para recibir, y no tiene por qué existir todo el
tiempo que dura la conexión FTP. Pero tenía en sus comienzos un problema, y era
la localización de los servidores en la red. Es decir, el usuario que quería
descargar algún archivo mediante FTP debía conocer en qué máquina estaba
ubicado. La única herramienta de búsqueda de información que existía era
Gopher, con todas sus limitaciones.
PROTOCOLO SMTP
El nombre del servidor de correo saliente (SMTP) y su puerto:
El nombre
del servidor de correo saliente, o SMTP, que en inglés significa "Simple
Mail Transfer Protocol" o Protocolo de transferencia de mails simples, se
refiere al nombre específico de la computadora o servidor que procesará los
mensajes que nosotros enviemos. Ese nombre se obtiene consultando con el
proveedor de correo. En nuestro ejemplo, el nombre del servidor de correo
saliente es el siguiente: smtp.mail.yahoo.com.ar Normalmente el puerto del
correo saliente es el puerto 25.
PROTOCOLO SNMP
SNMP puede también dispositivos no-SNMP utilizando agentes proxy. Un agente proxy es un conversor de protocolo que traduce las órdenes SNMP a las comprensibles por el protocolo de gestión propio del dispositivo. Actualmente SNMP está soportado en muchos sistemas distintos tales como puentes, PC’s, estaciones de trabajo, encaminadores, terminales, servidores, hubs, concentradores, y tarjetas avanzadas ethernet, token ring y FDDI.
SNMP se basa en un sistema de petición-respuesta. La autoridad gestora no es la red como sistema sino una o varias estaciones distinguidas (NMS).
La arquitectura SNMP consta de los siguientes componentes:
·
Gestores (NMS’s).
·
Agentes (nodos administrados).
·
MIB (base de datos con
información).
·
SMI (administración de la base
de datos).
·
Protocolos (órdenes).
PROTOCOLO ARP
El protocolo ARP es un protocolo
estándar específico de las redes. Su status es electivo.
El protocolo de resolución de
direcciones es responsable de convertir las dirección de protocolo de alto nivel
(direcciones IP) a direcciones de red físicas. Primero, consideremos algunas
cuestiones generales acerca de Ethernet.
ARP se emplea en redes IEEE 802 además
de en las viejas redes DIX Ethernet para mapear direcciones IP a dirección
hardware. Para hacer esto, ha de estar estrechamente relacionado con el
manejador de dispositivo de red. De hecho, las especificaciones de ARP en RFC
826 sólo describen su funcionalidad, no su implementación, que depende en gran
medida del manejador de dispositivo para el tipo de red correspondiente, que
suele estar codificado en el micro código del adaptador.
Si una aplicación desea enviar datos a
una determinado dirección IP de destino, el mecanismo de encaminamiento IP
determina primero la dirección IP del siguiente salto del paquete (que puede
ser el propio host de destino o un "router") y el dispositivo
hardware al que se debería enviar. Si se trata de una red 802.3/4/5, deberá
consultarse el módulo ARP para mapear el par <tipo de protocolo, dirección
de destino> a una dirección física.
El módulo ARP intenta hallar la
dirección en su caché. Si encuentra el par buscado, devuelve la correspondiente
dirección física de 48 bits al llamador (el manejador de dispositivo). Si no lo
encuentra, descarta el paquete (se asume que al ser un protocolo de alto nivel
volverá a transmitirlo) y genera un broadcast de red para una solicitud ARP.
ARP y subredes
El protocolo ARP es el mismo aunque
haya subredes. Recordar que cada datagrama IP pasa primero por el algoritmo de
encaminamiento IP. Este algoritmo selecciona el manejador de dispositivo que
debería enviar el paquete. Sólo entonces se consulta al módulo ARP asociado con
ese manejador.
Bibliografía:
- · http://protocoloredes.wikispaces.com/IPX+SPX
- · http://protocoloredes.wikispaces.com/TCP+y+IP
- · http://es.wikipedia.org/wiki/DECnet
- · http://es.wikipedia.org/wiki/AppleTalk
- · http://www.alegsa.com.ar/Dic/xns.php
- · http://aprenderinternet.about.com/od/ConceptosBasico/a/Que-Es-Http.htm
- · http://es.wikipedia.org/wiki/Hypertext_Transfer_Protocol
- · http://es.kioskea.net/contents/261-el-protocolo-dhcp
- · http://es.wikipedia.org/wiki/File_Transfer_Protocol
- · http://servilinux.galeon.com/cvitae1495470.html
- · http://neo.lcc.uma.es/evirtual/cdd/tutorial/aplicacion/snmp.html
- · http://neo.lcc.uma.es/evirtual/cdd/tutorial/red/arp.html
Suscribirse a:
Entradas (Atom)