Seção: Tutoriais
|
|
||
IP (Internet Protocol)
O protocolo IP - Internet Protocol - é o protocolo da camada de rede que foi projetado para conectar computadores em redes de comunicação chaveadas por pacotes que possui duas funções básicas : endereçamento e fragmentação de datagramas.
Segundo Tanembaum (2003), os endereços IP têm 32 bits e são usados nos campos Source address e Destination address dos pacotes IP. É importante observar que um endereço IP não se refere realmente a um host. Na verdade, ele se refere a uma interface de rede; assim, se um host estiver em duas redes, ele precisará ter dois endereços IP.
Os endereços de rede, que são números de 32 bits, são escritos em notação decimal com pontos. Nesse formato, cada um dos 4 bytes é escrito em notação decimal, de 0 a 255. Por exemplo, o endereço hexadecimal de 32 bits C0290614 é escrito como 192. 41. 6. 20. O endereço IP mais baixo é 0. 0. 0. 0 e o mais alto é 255. 255. 255. 255.
O IP possui classes que separam seus endereços e estão mostrados na tabela 1:
Tabela 1: Classes de endereçamento IP Fonte: Tanembaum (2003)
SIP (Session Initiation Protocol)
De acordo com Martins Soares (2008), o protocolo SIP (Session Initiation Protocol) é um protocolo de sinalização para estabelecimento, controle e encerramento de chamadas sobre redes IP. Pode utilizar tanto TCP (Transport Control Protocol) como UDP (User Datagram Protocol) como protocolo de transporte. Ele usa o protocolo SDP (Session Description Protocol) para a descrição das comunicações de mídia. SIP é um protocolo c1iente-servidor, é implementado através de linguagem de programação em modo texto.
Cada requisição SIP consiste de um conjunto de campos de cabeçalho que descrevem a chamada, seguidos por uma mensagem que descreve uma sessão individual que está sendo realizada pela chamada. Geralmente as requisições são geradas pelo cliente, a (User Agent Client), e enviadas para um servidor, a UAS (User Agent Server). A comunicação é estabelecida entre o cliente e o servidor utilizando requisições denominadas transações. O SIP chama cada transação de pedido e cada pedido provoca uma ou mais respostas.
Inicialmente, em uma comunicação SIP é necessário criar uma conexão de sinalização entre os pontos de origem e de destino da chamada, podendo ser usado como protocolo de transporte, o TCP ou o UDP. Utilizando o protocolo UDP, o endereço e a porta a serem utilizados para as respostas aos pedidos SIP estarão contidos no parâmetro de cabeçalho denominado Via do pedido SIP, (figura 5).
Figura 5: Mensagem de pedido SIP Fonte: Martins Soares (2008)
A linha de inicio do pedido SIP contém o tipo de pedido enviado pelo cliente SIP, o endereço SIP do usuário destino e a versão SIP utilizada.
O cabeçalho geral, encontrado tanto nos pedidos como nas respostas, contém os seguintes campos:
Uma mensagem de pedido também pode transportar campos com informações específicas, como o campo Accept (é utilizado para indicar os tipos de mídia aceitáveis na resposta) e o campo Subject (para transportar informações sobre a natureza da chamada).
Os pedidos SIP podem representar diferentes funções, como:
As mensagens de resposta SIP sempre contêm um código de status e uma frase de justificativa inteligível. Foram definidas seis classes de respostas, que são: Classe 1xx-informativo, Classe 2xx-sucesso, Classe 3xx-redirecionamento, Classe 4xx-erro de cliente, Classe 5xx-erro do Servidor e Classe 6xx-falha global.
Alguns exemplos de respostas são descritos abaixo:
Figura 6: Resposta 200 OK Fonte: Martins Soares (2008)
Um cliente SIP pode contatar outro terminal SIP enviando um simples pedido INVITE. Essa mensagem INVITE contém informação suficiente para permitir que o terminal convidado estabeleça uma comunicação de mídia com o chamador.
Essa informação lista os vários tipos de mídia que o terminal chamador pode receber e enviar, assim como o endereço de transporte (endereço IP e porta) sobre aquela chamada para que possa estabelecer a conexão de mídia usando o protocolo RTP (Real-time Transport Protocol).
O terminal chamado precisa então indicar que aceita o pedido. Como o pedido foi um convite, a aceitação é necessária (mensagem OK), contendo também suas capacidades e o endereço no qual receberá os dados de mídia. O terminal chamador conclui essa troca de mensagens com uma mensagem de confirmação (mensagem ACK) (figura 7).
A arquitetura do SIP tem base em relações c1iente/servidor. Seus principais componentes são o terminal SIP (User Agent), o servidor Proxy, o servidor Redirect e o servidor Registrar (figura 8).
Os terminais são considerados como clientes quando efetuam um pedido e como servidores quando respondem a esses pedidos. Os terminais podem se comunicar diretamente entre si ou por intermédio de outros servidores. Os servidores intermediários SIP podem se comportar como servidor Proxy ou servidor de redirecionamento (servidor Redirect).
O servidor Proxy executa a função de servidor de um lado (recepção dos pedidos) e de um usuário no outro lado (envio de pedidos). Um servidor Proxy pode transmitir um pedido, sem alteração, a seu destino final ou, se necessário, modificar certos parâmetros. Ele informa o campo Via cada vez que um pedido passa por ele de maneira que a resposta possa retornar pelo mesmo caminho, o que não seria possível com o protocolo UDP.
Figura 7: Pedidos e respostas em uma chamada SIP Fonte: Martins Soares (2008)
Figura 8: Componentes de uma arquitetura SIP Fonte: Martins Soares (2008)
Um servidor Redirect responde a um pedido SIP INVITE. Ele estabelece uma correspondência entre o endereço do terminal chamado e os endereço onde efetivamente esse terminal possa ser encontrado. O servidor Redirect não tem a incumbência de aceitar chamadas e nem de emitir pedidos, ele simplesmente responde aos pedidos emitidos pelos terminais SIP que o solicitam (figura 9)
Figura 9: Servidor Redirect Fonte: Soares (2008)
Como exemplo de respostas do servidor Redirect tem-se:
Um Registrar é um servidor que trata os pedidos Register e pode também ter a função de Proxy (figura 10). Sua função é saber o lugar onde um usuário está e fornecer essa informação aos servidores Proxy e Redirect. De fato, para que um usuário possa ser encontrado a partir de um endereço SIP, é necessário fazer a correspondência do mesmo com um endereço IP, que pode ser variável (mobilidade IP).
Figura 10: Servidor Registrar Fonte: Martins Soares (2008)
A localização física de um usuário é executada em duas etapas. A URL (Uniform Resource Locator) SIP permite ao usuário chamador localizar a servidor SIP, que será o destino da mensagem INVITE inicial. Isso significa que a servidor conhece o endereço físico do usuário chamado e permitirá a estabelecimento de uma conexão, ou seja, ele redireciona o pedido para outro local onde a parte chamada possa ser encontrada. O fato da URL SIP apontar para um servidor e não para um usuário final proporciona a esse último uma grande mobilidade, aliviando o servidor DNS (Domain Name Server), que não precisa conhecer os endereços do servidor e de todos os terminais conectados a esse servidor.
O protocolo SDP (Session Description Protocol), RFC 2237, é um protocolo que descreve as sessões de áudio, vídeo e multimídia. SDP utiliza os caracteres ASCII e fornece as informações necessárias ao estabelecimento de uma comunicação multimídia, como a identificação do iniciador da sessão, a banda passante disponível e os codificadores utilizados.
Quando uma chamada é estabelecida, a mensagem de pedido INVITE contém os parâmetros SDP com as capacidades do originador da chamada. No caso da resposta SIP, os parâmetros são modificados trazendo as capacidades do destino que responde ao pedido.
SIP-I e SIP-T (Session Initiation Protocol for Telephone)
Segundo o site Tekelec (2011), SIP-I e SIP-T referem-se a duas abordagens semelhantes para o interfuncionamento entre as redes ISUP e as redes SIP. Em particular, eles fornecem os meios para a transmissão de parâmetros ISUP específicos através de uma rede SIP para que as chamadas com origem e destino na rede ISUP transite por uma rede SIP, sem perda de informação.
O SIP-T foi desenvolvido pelo IETF, o mesmo grupo que se desenvolveu o protocolo SIP em si, ao mesmo tempo em que a versão mais recente do SIP estava sendo desenvolvido (em meados de 2002). É definido pela RFC 3372, RFC 3398, RFC 3578 e RFC 3204.
O SIP-I foi desenvolvido pela UIT em 2004, e fez uso da maioria das construções definidas no esforço IETF SIP-T. É definida pela Q. 1912. 5 da ITU-T.
O SIP-I e SIP-T definem o mapeamento de mensagens, parâmetros e códigos de erro entre SIP e ISUP. Ambos são totalmente interoperáveis com componentes de rede compatível com SIP na rede SIP.
As principais diferenças entre o SIP-I e SIP-T são:
O SIP-I e SIP-T também definem mapeamentos um pouco diferente de informações entre os protocolos, sobretudo em termos de conversão de códigos de erro SIP para causas do códigos ISUP.
A forma como o SIP-I e SIP-T permite o trânsito transparente dos parâmetros ISUP através de uma rede SIP é anexando uma cópia literal da mensagem ISUP na mensagem SIP no ingresso do gateway PSTN, esta mensagem ISUP aparece como um outro corpo sobre as mensagens SIP (geralmente, um ponto para um corpo SDP).
A rede SIP ignora o corpo ISUP extra, processa a mensagem SIP como faria normalmente. Após a rede SIP realizar as modificações necessárias para a mensagem SIP, essas chegam ao gateway de saída da PSTN. Este gateway de saída usa a mensagem ISUP como a base para a mensagem ISUP que vai ser enviar, no entanto, primeiro ele faz as modificações necessárias para corresponder as mudanças feitas para a mensagem SIP durante a sua passagem da rede SIP.
Como mencionado antes, com o SIP-T, as mensagens também poderão encerrar nos terminais SIP nativo na rede, o qual irá ignorar o corpo ISUP extra. Além disso, as mensagens podem ser provenientes desses telefones SIP e terminar nos gateways PSTN, que irá gerar uma nova mensagem ISUP para a PSTN.
Se colocarmos isto em um fluxo de chamada, uma configuração típica de chamada bem sucedida a partir de um terminal PSTN para outro terminal PSTN através de uma rede SIP pode parecer algo conforme a figura 11 a seguir:
Figura 11: Chamada ISUP sobre rede SIP Fonte: Site Tekelec (2011)
MGCP (Media Gateway Control Protocol)
De acordo com Martins Soares (2008), o protocolo MGCP (Media Gateway Control Protocol), definido pelo IETF, foi concebido para redes de telefonia IP utilizando gateways VoIP. Ele gerencia a comunicação entre os media gateways e o controlador de media gateway. Esse protocolo trata da sinalização e do controle das chamadas por um lado, e dos fluxos de mídia por outro lado. Os elementos que utilizam esse protocolo são:
Megaco/H. 248 (Media Gateway Control Protocol)
De acordo com Martins Soares (2008), o grupo de trabalho Megaco foi constituído em 1998 para completar os trabalhos sobre o protocolo MGCP dentro do IETF. Após 1999, o ITU e o IETF trabalharam em conjunto no desenvolvimento do protocolo Megaco/H. 248, o qual é um padrão que permite a comunicação entre o MGC e os MG. Foi derivado do MGCP e possui algumas melhorias com relação a este, como suporte para serviços multimídia e de videoconferência, possibilidade de utilização de UDP ou TCP e possibilidade de codificação em modo texto ou binário.
Uma primeira versão do H. 248 foi elaborada em junho de 2000. A implementação do H. 248 permite uma grande modularidade, pois o mesmo pode ser estendido por "pacotes" de acordo com necessidades específicas. Esse sistema permite cobrir um grande número de aplicações. Assim, um fabricante pode realizar implementação agrupando os "pacotes" de acordo com suas necessidades. A figura 12 mostra o posicionamento do MGCP e do H. 248/Megaco em uma rede convergente.
Figura 12: 248/Megaco Fonte: Martins Soares (2008)
VPN (Virtual Private Network)
De acordo com a Cisco (2011), uma VPN (Rede Privada Virtual) é uma rede privada construída em uma infraestrutura de rede pública, como a Internet. As empresas podem usar uma VPN para conectar com segurança escritórios remotos e usuários remotos usando acesso à Internet de baixo custo, em vez de links WAN caros e dedicados ou links de discagem remota de longa distância.
Uma VPN fornece elevado nível de segurança através de IPsec (IP seguro) criptografado ou túneis VPN de SSL (Secure Sockets Layer) e tecnologias de autenticação. Elas protegem dados que atravessam a VPN de acesso não autorizado. As empresas podem aproveitar a infraestrutura da Internet de fácil provisão da VPN para adicionar rapidamente novos pontos ou usuários. Elas também podem aumentar drasticamente o alcance da VPN sem expandir consideravelmente a infraestrutura.
IPsec / MPLS
A VPN SSL e a VPN IPsec são soluções de VPN para conectar escritórios remotos, usuários remotos e parceiros comerciais porque fornecem:
Existem dois tipos de VPNs criptografadas:
A solução VPN MPLS centra-se no provisionamento, auditoria e monitoramento das ligações entre os roteadores do cliente através da rede do provedor. Trata somente os roteadores de borda. Um roteador de borda do cliente (CE- Costumer Edge) é conectado a um roteador de borda do provedor (PE – Provider Edge) de tal forma que o tráfego do cliente é encapsulado e enviado de forma transparente para outros CEs, criando assim uma rede privada virtual. CEs anunciam rotas para a VPN para todos os dispositivos em seu site. O mecanismo de provisionamento acessa os arquivos de configuração, tanto no CE e PE para calcular as mudanças necessárias para os arquivos que são necessários para suportar o serviço no link PE-CE.
Usando o software de VPN MPLS, prestadores de serviços podem fazer o seguinte:
Uma VPN MPLS consiste em um conjunto de sites que são interligados por meio de uma rede de provedor MPLS. Em cada local, há um ou mais EC, que ligam a um ou mais PEs. PEs usam o Border Gateway Protocol-multiprotocolo (MP-BGP) para comunicar dinamicamente uns com os outros.
Não é necessário que o conjunto de endereços IPv4 usado em qualquer VPNs sejam mutuamente exclusivos, pois os PEs traduzem os endereços IPv4 em entidades VPN IPv4 usando MP-BGP com as extensões dos atributos das communitys.
O conjunto de endereços IP usados em uma VPN, porém, deve ser exclusivo do conjunto de endereços usados na rede do provedor. Todo CE deve ser capaz de endereçar os PEs o quais estão diretamente ligados. Assim, os endereços IP do PEs não devem ser duplicados em qualquer VPN.
A figura 13 representa a VPN na visão do usuário.
A figura 14 representa a VPN na visão do provedor.
Figura 13: VPN na visão do usuário Fonte: Site Cisco (2011)
Figura 14: VPN na visão do provedor Fonte: Site Cisco (2011)
Benefícios
VPNs baseada em MPLS fornecem os seguintes benefícios:
|
|||
