IP reference

Referencia Técnica de Redes, Protocolos, Modelo OSI, TCP/IP, y otras tecnologías.

Posts Tagged ‘TCP/IP’

Subneteo (subnetting,subnet)

Posted by Luis R. en 2009/05/31

Subnetting es la técnica para crear múltiples redes lógicas dentro de una red Clase A, B ó C; sin esta herramienta sólo podríamos usar una red por cada red clase A, B o C, lo cual haría que desaprovecháramos los espacios de direcciones.

Cada enlace de datos en una red debe tener un identificador único de red, y cada nodo en ese enlace debe ser miembro de la misma red. Si dividimos una red mayor (Clase A, B o C) en redes más pequeñas, te permite crear una red que interconecta subredes. Cada enlace de datos en esta red tendría entonces un identificador de red o de sub-red único. Cualquier dispositivo o gateway que conecta n redes o subredes tiene n distintas direcciones IP, una por cada red o sub-red que interconecta.

Continúa leyendo en la nueva dirección del blog:

http://ipref.blogspot.com/2009/05/subneteo-subnettingsubnet.html

Anuncios

Posted in A-Bases, CCNA, Internetworking | Etiquetado: , , , , , , , , , , , | 1 Comment »

Direccionamiento IP

Posted by Luis R. en 2009/05/28

Una dirección IP es un número único de identificación de dispositivo en una red. La dirección se compone de 32 bits, que se agrupan en 4 octetos cuyo valor puede oscilar entre 0 y 255, y que usualmente se dividen en una porción de red y una porción de host por medio de una máscara de red. Cada octeto se convierte a decimal y se separa por un punto, y así tenemos la forma comúnmente conocida:

Binario: 10101100.00010000.00011100.00101101

decimal: 172.16.28.45

——Seguir leyendo en el nuevo blog—–

Posted in CCNA, Cisco docs, Internetworking | Etiquetado: , , , , | Leave a Comment »

Implementando firewalls en la organización

Posted by Luis R. en 2009/05/15

Evitar las intrusiones requiere filtrado de firewalls en múltiples perímetros, tanto internos como externos.

Los firewalls han sido la primera línea de defensa en las infraestructuras de defensa de las redes, y cumplen este objetivo comparando las políticas acerca de los derechos de acceso de red de los usuarios con la información de cada intento de conexión. Las políticas de usuario y la información de conexión deben coincidir, o el firewalll no dará acceso a los recursos de red; así se previenen las intrusiones.

En años recientes, una de las mejores prácticas más aceptadas es implementar firewalls no sólo en los perímetros de red tradicionales, donde la red corporativa y la Internet se encuentran, sino también a través de la red corporativa en ubucaciones internas clave, así como en las fonteras de las oficinas remotas con la WAN. Esta estrategia de firewalls distribuidos ayuda a protegernos contra amenazas itnernas, las cuales han sido históricamente causantes de un enorme porcentaje de cyber-pérdidas, de acuerdo al estudio anual que conduce el Computer Security Institute (CSI).

El crecimiento de las amenazas internas se ha acelerado por el surgimiento de nuevos perímetros de red que se han formado al interior de las LAN corporativas. Algunos ejemplos de esos perímetros o fronteras de confianza, están entre los switches y los servidores de respaldo, entre diferentes departamentos, y donde una red inalámbrica se encuentra con la red cableada. El firewall previene la existencia de brechas de acceso en estas coyonturas de red claves, asegurando, por ejemplo, que el departamento de ventas no podrá entrar al sistema de finanzas.

continúa leyendo este artículo en la nueva dirección:

http://ipref.blogspot.com/

Posted in Security | Etiquetado: , , , , , , | Leave a Comment »

Three-way handshake

Posted by Luis R. en 2009/03/30

del artículo de Microsoft:
Explanation of the Three-Way Handshake via TCP/IP

El nivel del protocolo de transporte comprendido en TCP (transport control protocol) es orientado a conexión; lo que significa que antes de poder transmitir datos, se debe obtener una conexión confiable y reconocida (con acknowledge). Las transmisiones de datos a nivel TCP, los establecimientos de conexión y terminación de conexión, mantienen parámetros específicos de control que gobiernan el proceso completo. Los bits de control son:

  • URG: Urgent Pointer field significant
  • ACK: Acknowledgement field significant
  • PSH: Push Function
  • RST: Reset the connection
  • SYN: Synchronize sequence numbers
  • FIN: No more data from sender

Hay dos escenarios donde un proceso de three-way handshake tendrá lugar:

  • Estableciendo una conexión (apertura activa)
  • Terminando una conexión (cierre activo)

La información de muestra fue obtenida de un captura de un Monitor de red (analizador de protocolos que puede obtenerse de un Microsoft Systems Management Server).

Estableciendo una conexión

La siguiente secuencia muestra el proceso de una conexión de TCP siendo establecida:

Frame1:

Como podemos ver en el primer frame, el cliente NTW3 envía un segmento SYN (TCP…S); esto es una petición al servidor para sincronizar los números de secuencia. Especifica el número de secuencia inicial (ISN) que se incrementa por 1 (8221821+1=8221822) y es enviado al servidor. Para iniciar una conexión, el cliente y el servidor deben sincronizar sus respectivos números de secuencia. También hay una opción para el tamaño máximo de segmento (MSS) que debe acordarse, y se define en la longitud (length, len: 4). Esta opción comunica el tamaño máximo de segmento que el transmisor quiere recibir. El campo de reconocimiento o acuse de recibo (acknowledge, ack: 0) se fija en cero porque es la primera parte del proceso de three-way handshake.

1    2.0785 NTW3 --> BDC3 TCP ....S., len: 4, seq: 8221822-8221825, ack: 0,
win: 8192, src: 1037  dst:  139 (NBT Session)  NTW3 -->  BDC3 IP

TCP: ....S., len: 4, seq: 8221822-8221825, ack: 0, win: 8192, src: 1037
dst:  139 (NBT Session)

   TCP: Source Port = 0x040D
   TCP: Destination Port = NETBIOS Session Service
   TCP: Sequence Number = 8221822 (0x7D747E)
   TCP: Acknowledgement Number = 0 (0x0)
   TCP: Data Offset = 24 (0x18)
   TCP: Reserved = 0 (0x0000)
   TCP: Flags = 0x02 : ....S.

      TCP: ..0..... = No urgent data
      TCP: ...0.... = Acknowledgement field not significant
      TCP: ....0... = No Push function
      TCP: .....0.. = No Reset
      TCP: ......1. = Synchronize sequence numbers
      TCP: .......0 = No Fin

   TCP: Window = 8192 (0x2000)
   TCP: Checksum = 0xF213
   TCP: Urgent Pointer = 0 (0x0)
   TCP: Options

         TCP: Option Kind (Maximum Segment Size) = 2 (0x2)
         TCP: Option Length = 4 (0x4)
         TCP: Option Value = 1460 (0x5B4)

   TCP: Frame Padding

00000:  02 60 8C 9E 18 8B 02 60 8C 3B 85 C1 08 00 45 00   .`.....`.;....E.
00010:  00 2C 0D 01 40 00 80 06 E1 4B 83 6B 02 D6 83 6B   .,..@....K.k...k
00020:  02 D3 04 0D 00 8B 00 7D 74 7E 00 00 00 00 60 02   .......}t~....`.
00030:  20 00 F2 13 00 00 02 04 05 B4 20 20                .........


Frame 2:

En el segundo frame, el servidor BDC3 envía un ACK y un SYN en este segmento (TCP .A..S.) En este segmento el servidor está acusando de recibida la petición del cliente para sincronizar. Al mismo tiempo, el servidor también envía su petición al cliente para sincronizar sus números de secuencia. Hay una diferencia importante en este segmento. El servidor transmite un número de acuse (acknowledgement number 8221823) al cliente. El acknowledgement es sólo la prueba para que el cliente sepa que el ACK es la respuesta al SYN que el cliente inició. El proceso de acuse de recibo que el cliente requirió permite al servidor incrementar el número de secuencia del cliente por uno y lo usa como su número de acknowledgement.

2   2.0786 BDC3 --> NTW3  TCP .A..S., len: 4, seq: 1109645-1109648, ack:
8221823, win: 8760, src: 139 (NBT Session)  dst: 1037 BDC3 --> NTW3  IP

TCP: .A..S., len:    4, seq:   1109645-1109648, ack:   8221823, win: 8760,
src:  139 (NBT Session)  dst: 1037

   TCP: Source Port = NETBIOS Session Service
   TCP: Destination Port = 0x040D
   TCP: Sequence Number = 1109645 (0x10EE8D)
   TCP: Acknowledgement Number = 8221823 (0x7D747F)
   TCP: Data Offset = 24 (0x18)
   TCP: Reserved = 0 (0x0000)
   TCP: Flags = 0x12 : .A..S.

      TCP: ..0..... = No urgent data
      TCP: ...1.... = Acknowledgement field significant
      TCP: ....0... = No Push function
      TCP: .....0.. = No Reset
      TCP: ......1. = Synchronize sequence numbers
      TCP: .......0 = No Fin

   TCP: Window = 8760 (0x2238)
   TCP: Checksum = 0x012D
   TCP: Urgent Pointer = 0 (0x0)
   TCP: Options

         TCP: Option Kind (Maximum Segment Size) = 2 (0x2)
         TCP: Option Length = 4 (0x4)
         TCP: Option Value = 1460 (0x5B4)

   TCP: Frame Padding

00000:  02 60 8C 3B 85 C1 02 60 8C 9E 18 8B 08 00 45 00   .`.;...`......E.
00010:  00 2C 5B 00 40 00 80 06 93 4C 83 6B 02 D3 83 6B   .,[.@....L.k...k
00020:  02 D6 00 8B 04 0D 00 10 EE 8D 00 7D 74 7F 60 12   ...........}t`.
00030:  22 38 01 2D 00 00 02 04 05 B4 20 20               "8.-......

Frame 3:
En el tercer frame, el cliente envía un ACK en el segmento (TCP .A….) y el cliente está confirmando la petición del servidor para sincronizar. El cliente usa el mismo algoritmo que el servidor implementó para dar un número de confirmación. La confirmación del cliente está completando el proceso de establecer una conexión confiable, a través del Three-Way Handshake.

3   2.787 NTW3 --> BDC3  TCP .A...., len: 0, seq: 8221823-8221823, ack:
1109646, win: 8760, src: 1037  dst:  139 (NBT Session)  NTW3 --> BDC3  IP

TCP: .A...., len:    0, seq:   8221823-8221823, ack:   1109646, win: 8760,
src: 1037  dst:  139 (NBT Session)

   TCP: Source Port = 0x040D
   TCP: Destination Port = NETBIOS Session Service
   TCP: Sequence Number = 8221823 (0x7D747F)
   TCP: Acknowledgement Number = 1109646 (0x10EE8E)
   TCP: Data Offset = 20 (0x14)
   TCP: Reserved = 0 (0x0000)
   TCP: Flags = 0x10 : .A....

      TCP: ..0..... = No urgent data
      TCP: ...1.... = Acknowledgement field significant
      TCP: ....0... = No Push function
      TCP: .....0.. = No Reset
      TCP: ......0. = No Synchronize
      TCP: .......0 = No Fin

   TCP: Window = 8760 (0x2238)
   TCP: Checksum = 0x18EA
   TCP: Urgent Pointer = 0 (0x0)
   TCP: Frame Padding

00000:  02 60 8C 9E 18 8B 02 60 8C 3B 85 C1 08 00 45 00   .`.....`.;....E.
00010:  00 28 0E 01 40 00 80 06 E0 4F 83 6B 02 D6 83 6B   .(..@....O.k...k
00020:  02 D3 04 0D 00 8B 00 7D 74 7F 00 10 EE 8E 50 10   .......}t....P.
00030:  22 38 18 EA 00 00 20 20 20 20 20 20               "8....


Terminando una conexión

Aunque el proceso three-way handshake solo requiere 3 paquetes para ser transmitido sobre nuestro medio de red, la terminación de esta conexión confiable necesitará la transmisión de 4 paquetes. Debido a que una conexión TCP es Full Duplex (fluye información en cada dirección de manera independiente de la otra) cada dirección debe ser terminada de manera independiente.

Frame 4
En esta sesión de frames, podemos ver alcliente enviando un FIN que es acompañado por un ACK (TCP.A…F) Este segmento tiene dos funciones básicas; primero, cuando el parámetro FIN es fijado, informará al servidor que no hay más datos que enviar; segundo, el ACK es esencial para identificar la conexión específica que ellos establecieron.

4   16.0279 NTW3 --> BDC3 TCP .A...F, len: 0, seq: 8221823-8221823,
ack:3462835714, win: 8760, src: 2337  dst: 139 (NBT Session)  NTW3 --> BDC3
IP

TCP: .A...F, len:   0, seq: 8221823-8221823, ack:  1109646, win: 8760, src:
1037  dst:  139 (NBT Session)

   TCP: Source Port = 0x040D
   TCP: Destination Port = NETBIOS Session Service
   TCP: Sequence Number = 8221823 (0x7D747F)
   TCP: Acknowledgement Number = 1109646 (0x10EE8E)
   TCP: Data Offset = 20 (0x14)
   TCP: Reserved = 0 (0x0000)
   TCP: Flags = 0x11 : .A...F

      TCP: ..0..... = No urgent data
      TCP: ...1.... = Acknowledgement field significant
      TCP: ....0... = No Push function
      TCP: .....0.. = No Reset
      TCP: ......0. = No Synchronize
      TCP: .......1 = No more data from sender

   TCP: Window = 8760 (0x2238)
   TCP: Checksum = 0x236C
   TCP: Urgent Pointer = 0 (0x0)

00000:  00 20 AF 47 93 58 00 A0 C9 22 F5 39 08 00 45 00   . .G.X...".9..E.
00010:  00 28 9B F5 40 00 80 06 21 4A C0 5E DE 7B C0 5E   .(..@...!J.^.{.^
00020:  DE 57 09 21 05 48 0B 20 96 AC CE 66 AE 02 50 11   .W.!.H. ...f..P.
00030:  22 38 23 6C 00 00                                 "8#l..

Frame 5:
Aquí no se ve nada especial, excepto el servidor confirmando el FIN que envió el cliente.

5    16.0281 BDC3 --> NTW3 TCP .A...., len:    0, seq: 1109646-1109646,
ack: 8221824, win:28672, src: 139  dst: 2337 (NBT Session) BDC3 -->  NTW3
IP

TCP: .A...., len:    0, seq: 1109646-1109646, ack: 8221824, win:28672, src:
139  dst: 2337 (NBT Session)

   TCP: Source Port = 0x040D
   TCP: Destination Port = NETBIOS Session Service
   TCP: Sequence Number = 1109646 (0x10EE8E)
   TCP: Acknowledgement Number = 8221824 (0x7D7480)
   TCP: Data Offset = 20 (0x14)
   TCP: Reserved = 0 (0x0000)
   TCP: Flags = 0x10 : .A....

      TCP: ..0..... = No urgent data
      TCP: ...1.... = Acknowledgement field significant
      TCP: ....0... = No Push function
      TCP: .....0.. = No Reset
      TCP: ......0. = No Synchronize
      TCP: .......0 = No Fin

   TCP: Window = 28672 (0x7000)
   TCP: Checksum = 0xD5A3
   TCP: Urgent Pointer = 0 (0x0)
   TCP: Frame Padding

00000:  00 A0 C9 22 F5 39 08 00 02 03 BA 84 08 00 45 00   ...".9........E.
00010:  00 28 D2 82 00 00 3F 06 6B BD C0 5E DE 57 C0 5E   .(....?.k..^.W.^
00020:  DE 7B 05 48 09 21 CE 66 AE 02 0B 20 96 AD 50 10   .{.H.!.f... ..P.
00030:  70 00 D5 A3 00 00 90 00 01 00 86 00               p...........

Frame 6
Después de recibir el paquete FIN desde el cliente, el servidor confirmará. Aún cuando TCP ha establecido conexiones entre esas dos computadoras, las conexiones son aún independientes una de otra; así que el servidor debe transmitir también un paquete FIN (TCP .A…F) al cliente.

6   17.0085 BDC3 --> NTW3 TCP .A...F, len: 0, seq: 1109646-1109646, ack:
8221824, win:28672, src: 139 dst: 2337 (NBT Session) BDC3 -->  NTW3   IP

TCP: .A...F, len:  0, seq: 1109646-1109646, ack: 8221824, win:28672, src:
139  dst: 2337 (NBT Session)

   TCP: Source Port = 0x0548
   TCP: Destination Port = 0x0921
   TCP: Sequence Number = 1109646 (0x10EE8E)
   TCP: Acknowledgement Number = 8221824 (0x7D7480)
   TCP: Data Offset = 20 (0x14)
   TCP: Reserved = 0 (0x0000)
   TCP: Flags = 0x11 : .A...F

      TCP: ..0..... = No urgent data
      TCP: ...1.... = Acknowledgement field significant
      TCP: ....0... = No Push function
      TCP: .....0.. = No Reset
      TCP: ......0. = No Synchronize
      TCP: .......1 = No more data from sender

   TCP: Window = 28672 (0x7000)
   TCP: Checksum = 0xD5A2
   TCP: Urgent Pointer = 0 (0x0)
   TCP: Frame Padding

00000:  00 A0 C9 22 F5 39 08 00 02 03 BA 84 08 00 45 00   ...".9........E.
00010:  00 28 D2 94 00 00 3F 06 6B AB C0 5E DE 57 C0 5E   .(....?.k..^.W.^
00020:  DE 7B 05 48 09 21 CE 66 AE 02 0B 20 96 AD 50 11   .{.H.!.f... ..P.
00030:  70 00 D5 A2 00 00 02 04 05 B4 86 00               p...........

Frame 7
El cliente responde en la misma manera que el servidor, confirmando el paquete de FIN que recibió e incrementando el número de secuencia por 1.

7   17.0085 NTW3 --> BDC3 TCP .A...., len: 0, seq: 8221824-8221824, ack:
1109647, win: 8760, src: 2337  dst: 139 (NBT Session) NTW3 --> BDC3 IP

TCP: .A...., len:    0, seq: 8221824-8221824, ack: 1109647, win: 8760, src:
2337  dst: 139   (NBT Session)

   TCP: Source Port = 0x0921
   TCP: Destination Port = 0x0548
   TCP: Sequence Number = 8221824 (0x7D7480)
   TCP: Acknowledgement Number = 1109647 (0x10EE8F)
   TCP: Data Offset = 20 (0x14)
   TCP: Reserved = 0 (0x0000)
   TCP: Flags = 0x10 : .A....

      TCP: ..0..... = No urgent data
      TCP: ...1.... = Acknowledgement field significant
      TCP: ....0... = No Push function
      TCP: .....0.. = No Reset
      TCP: ......0. = No Synchronize
      TCP: .......0 = No Fin

   TCP: Window = 8760 (0x2238)
   TCP: Checksum = 0x236B
   TCP: Urgent Pointer = 0 (0x0)

00000:  00 20 AF 47 93 58 00 A0 C9 22 F5 39 08 00 45 00   . .G.X...".9..E.
00010:  00 28 BA F5 40 00 80 06 02 4A C0 5E DE 7B C0 5E   .(..@....J.^.{.^
00020:  DE 57 09 21 05 48 0B 20 96 AD CE 66 AE 03 50 10   .W.!.H. ...f..P.
00030:  22 38 23 6B 00 00                                 "8#k..

El cliente confirmando la notificación de FIN del servidor identifica el cierre de una conexión de TCP.

Para mayor información, referirse al RFC793, el cual describe a fondo el proceso estandarizado de establecimiento de conexión de TCP.

Posted in Cisco docs | Etiquetado: , , , , , , , , , , , , , , , | Leave a Comment »

Movilidad IPv6

Posted by Luis R. en 2009/03/18

del documento de cisco: IPv6 Mobility At-a-Glance

Los objetivos de la movilidad de IPv6 son:

  • no estar limitado a una ubicación
  • tener siempre conectividad IP
  • que sea independiente del transporte
  • conexiones en roaming robustas
  • movilidad de las aplicaciones
  • continuidad de las aplicaciones
  • que un server pueda ser un dispositivo móvil

Mobile IPv6 (MIPv6) se define en:

  • RFC 3775: Mobility Support in IPv6
  • RFC 3776: Using IPSec to Protect Mobile IPv6 Signalling between Mobile Nodes and Home Agents

Existen los mismos componentes básicos en MIPv6 como en MIPv4, excepto que no hay agentes externos en MIPv6.

figura 1 Lee el resto de esta entrada »

Posted in Cisco docs | Etiquetado: , , , , , , , , , , , , , , , , , , , | Leave a Comment »

Encabezado IPv6

Posted by Luis R. en 2009/02/20

Del documento de Cisco IPv6 Headers

Hay varios cambios al formato de encabezados de IPv6. Los diagramas describen en alto nivel la comparación entre IPv4 e IPv6.

IPv6 Headers

IPv6 Headers

Lee el resto de esta entrada »

Posted in Cisco docs | Etiquetado: , , , , , , , , , | Leave a Comment »

Internet Protocol version 6

Posted by Luis R. en 2009/02/12

Del Cisco’s Internetworking Techonology Handbook

IPv6

Uno de los mayores estándares en el horizonte es IPv6, aunque no se ha vuelto un estándar oficial, vale la pena revisarlo un poco, y es muy posible que esta información cambie mientras se libera una versión definitiva, por lo que este documento debe ser sólo una guía.

Hay una gran variedad de libros y RFCs disponibles que hablan sobre IPv6, con los grandes rasgos de cómo se desarrolla el estándar, aunque son documentos difíciles de interpretar con un vistazo y requieren un poco de dedicación para poder analizar todos los temas relacionados al desarrollo de IPv6.

IPv4 (Internet Protocol version 4) es el protocolo más popular usado hoy, aunque hay serias dudas acerca de su utilidad para la comunidad de Internet a largo plazo. IPv4 fue terminado en 1970 y ha comenzado a mostrar los signos de su edad. El principal problema es el direccionamiento, o la falta de espacio en el mismo, porque muchos expertos creen que están casi agotadas las 4mil millones de direcciones disponibles para IPv4. Y aunque parece un número enorme, enormes bloques han sido dados a las agencias de gobierno y organizaciones grandes. IPv6 podría ser la solución a muchos problemas, pero no está totalmente desarrollado y no es un estándar aún.

Ha habido muchos desarrolladores e ingenieros trabajando en IPv6 desde principios de los 90’s. Cientos de RFCs se han escrito y se han detallado algunas áreas importantes, incluyendo el direccionamiento expandido, el formato de encabezado simplificado, el etiquetado de flujo (flow labeling), autenticación, y privacidad.

El direccionamiento expandido nos lleva de 32 a 128 bits de direccionamiento y nos da nuevos métodos de broadcast y de unicast; inyecta hexadecimales en la dirección IP y cambia el delimitador “.” por “:“, en la figura 32-1 se muestra el formato de encabezado del paquete de IPv6.

IPv6 Header

IPv6 Header

El encabezado simplificado es de 40 bits y el formato consiste de:

  • Version
  • Class
  • Flow Label
  • Payload length
  • Next Header
  • Hop Limit
  • Source Address
  • Destination Address
  • Data
  • Payload Fields

Lee el resto de esta entrada »

Posted in Cisco docs, Internetworking | Etiquetado: , , , , , , , , | Leave a Comment »

VoIP

Posted by Luis R. en 2008/12/15

La Voz sobre IP se refiere a la transmisión de llamadas telefónicas sobre el protocolo IP, ésto sin importar que tipo de equipo tradicional, computadoras o equipo dedicado tome parte en el proceso, o incluso sin importar si la llamada es transportada en su totalidad por IP o no.

La VoIP es uno de los desarrollos tecnológicos que más rápido se han adoptado por las compañías. Una de las razones principales es que hace más fácil integrar todo tipo de comunicaciones, de medios de comunicación y de dispositivos y medios de transmisión. Así, un usuario puede estar en comunicación constante, sin importar su ubicación, en tiempo real; y es el primer paso hacia las comunicaciones unificadas. Esta disponibilidad reduce costos y aumenta la productividad de un empleado.

La VoIP comenzó en 1995, cuando Vocaltech lanzó su primer teléfono para internet; previo a ese hecho, todo lo que se refería a VoIP era hehco por investigadores, pero desde que se probó que no sólo es técnicamente factible, sino comercialmente viable, muchas compañías han entrado al mercado de la VoIP tratando de tomar la ventaja, lo cual ha fomentado el desarrollo y competencia necesarias para abaratar los costos.

Cómo trabaja la VoIP

La configuración más básica es cuando un usuario ya cuenta con una computadora que tiene capacidad de audio (sound card), así, el usuario puede iniciar y terminar llamadas a través de un software llamado Softphone. Hay una gran variedad de opciones disponibles, algunos incluso totalmente gratuitos.

Este escenario es de telefonía IP pura, y se beneficia de los demás servicios de internet, como el e-mail y la mensajería instantánea.

También existe el escenario donde mezclamos servicios de VoIP con la telefonía tradicional y conectamos a través de un Gateway de voz las líneas” normales”. El Gateway de voz hace la conversión de paquetes de IP (transportados en UDP generalmente) hacia la telefonía basada en TDM (time division multiplexing).

Es importante este punto, porque las redes IP trabajan con conmutación de paquetes, es decir, cada paquete es enviado a su destino a través de múltiples circuitos que se comparten entre paquetes de distintos orígenes y con distintos destinos, así como múltiples protocolos o aplicaciones. En el caso de los circuitos conmutados (TDM) el canal se establece físicamente y es usado mientras la llamada está activa, y sólo es ocupado por la aplicación que lo genera; es el caso de la transmisión de datos por ISDN por ejemplo, o de una simple llamada de voz.

VoIP to PSTN

VoIP to PSTN

Entendiendo ésto, tenemos que: se inicia la llamada por el softphone, que usando SIP o H.323 o algún otro protocolo de señalización, se comunicará con el gateway de voz (un router, un IP-PBX, un servidor SIP, etc) y le hará una petición de inicio de llamada; el gateway verificará que puede entregar el servicio hacia la PSTN, y responderá positivamente al IP-phone y se iniciará la comunicación; aquí, la voz se convierte en paquetes de IP con un protocolo (G.729 por ejemplo) que se transportan en datagramas de UDP (encapsulamiento), y se entregarán al gateway, que los decodificará y traducirá a una señal analógica o digital, según el acceso a la PSTN, para poder hacer uso de una línea TDM tradicional.

También tenemos el caso donde tenemos dos gateways de voz, y se inicia la llamada desde un teléfono normal hacia un gateway, y éste a su vez hace el transporte hacia el gateway remoto a través de internet; una vez que el gateway remoto tiene la llamada, la decodifica y la entrega a la PSTN nuevamente, con lo que tenemos un ahorro en las largas distancias. Este caso es muy común en ambientes corporativos donde el volumen de llamdas justifica el uso de enlaces privados o públicos para hacer el transporte de voz y datos.

Los beneficios de la VoIP son que se incrementa la movilidad y la flexibilidad; así como una integración de la voz y los datos, y una reducción de costos para el usuario final.

Posted in Internetworking | Etiquetado: , , , , , , , , , | Leave a Comment »

VoIP – definiciones

Posted by Luis R. en 2008/12/01

VoIP – Voice over Internet Protocol (a veces llamado telefonía IP, telefonía sobre internet), y es el enrutamiento de conversaciones de voz sobre el internet o sobre otra red basada en IP (MPLS por ejemplo).

SIP – Session Initiation Protocol, es un protocolo desarrollado por el grupo de trabajo IETF MMUSIC y es el estándar propuesto para iniciar, modificar y termina una sesión de usuario interactiva que involucra elementos multimedia, como video, voz, mensajería instantánea, juegos online, y realidad virtual.

PSTN – Public Switched Telephony Network (red pública de telefonía conmutada), es la concentración mundial de redes de telefonía de circuitos conmutados, muy parecido a la concentración de redes IP públicas de paquetes conmutados que es el internet.

ISDN – Integrated Services Digital Network (red digital de servicios integrados), es un tipo de sistema de red telefonía de circuitos conmutados, diseñada para permitir la transmisión digital de voz y datos sobre pares de cobre ordinarios de telefonía, resultando en mejor calidad y velocidades más altas que con los sistemas analógicos.

PBX – Private branch eXchange, es un intercambiador de telefonía que es propiedad de una empresa privada como complemento a los que posee un carrier o una compañía telefónica.

IVR – Interactive Voice Response, es un sistema computarizado que permite a una persona (usualmente al que llama), seleccionar una opción de un menú de voz y hasta conectarse a una computadora.

DID – Direct Inward Dialing, es la característica ofrecida por una compañía telefónica el uso de los PBX de los clientes, donde la compañía de teléfonos (telco) ubica un rango de números que se conectarán al PBX de un cliente, es decir, la asignación de rangos de numeración.

RFC –  Request for Comments, es una serie de documentos informativos numerados sobre Internet, y estándares ampliamente aceptados por entidades como comunidades de UNIX, de Internet, fabricantes de software comercial y gratuito, etc. Por ejemplo, el RFC 1166 describe el direccionamiento IP de las redes Públicas y Privadas

Posted in Cisco docs | Etiquetado: , , , , , | Leave a Comment »

La Capa de Aplicación

Posted by Luis R. en 2008/09/17

Application Layer, OSI layer 7

La capa de aplicación es donde ocurre toda la interacción del usuario con la computadora, y por ejemplo, cualquier browser funciona aún sin el stack de TCP/IP instalado, sin embargo, el browser (google chromemozilla firefoxinternet exploreropera) no es parte de la capa de aplicación, sino que es el programa que se comunica con dicha capa.
Por ejemplo, al hacer la consulta de un documento local de html con el browser no hay comunicación hacia el exterior, sin embargo, al hacer la consulta de un documento remoto se hace uso del protocolo http (hyper text transfer protocol); o podemos transferir archivos por medio de FTP (file transfer protocol) o por medio de TFTP (trivial file transfer protocol). Cada vez que solicitamos una comunicación de ese tipo, el browser interactúa con la capa de aplicación que a su vez sirve de interfase entre las aplicaciones del usuario y el stack de protocolos que le va a proveer la comunicación con ayuda de las capas inferiores.

Lee el resto de esta entrada »

Posted in A-Bases, CCNA, Internetworking | Etiquetado: , , , , , , , | 12 Comments »