A Camada de Rede

Finalmente chegámos  ao reino do Senhor IP (Internet Protocol).

O IP é o protocolo da camada de rede na Internet e não tem concorrente.  É ao IP que compete prover os pacotes com os elementos necessários para que eles encontrem o seu destino. Quando um pacote viaja de um remetente para um destinatário, como é evidente não segue um percurso direto. Ele não é como o TGV, sendo mais como o comboio correio que pára em todas as estações.

Lembram-se dos carrinhos que transportavam as folhas da nossa mensagem?

É o IP que coloca o endereço do destino e do remetente no pacote que entrega aos carrinhos que levam as folhas da carta que enviámos e que os envia para o caminho. Pelo caminho eles vão encontrar muitos cruzamentos (as estações do comboio) e estradas de tamanhos e velocidades diferentes. Mas, quando chegam ao cruzamento precisam de saber por que estrada seguir.

Por isso, em cada cruzamento se encontra um sinaleiro, a que chamamos Roteador (Router).

As estradas entre o nosso computador e o primeiro sinaleiro, entre os diversos sinaleiros que os carrinhos vão encontrar ao longo do seu caminho e entre o último sinaleiro e o destinatário, chamam-se enlaces (links).

Na análise que fizemos da camada aplicação e do protocolo HTTP, executámos uma consulta DNS para saber qual era o endereço de determinado nome de servidor a que pretendíamos pedir uma página. Era concretamente o condominiopartners.pt e fomos informados que era o seu endereço era 188.72.202.158, o que para nós, na altura não trouxe grande coisa de novo. Estava reservado para agora ser utilizado nesta camada pelo Sr IP.

O Sr. IP pega nesse endereço e coloca-o no endereço de destino dos pacotes que levam as folhas da nossa carta.

Agora imaginem os pobres dos motoristas dos carrinhos, tendo que entregar os pacotes só com endereços deste tipo.

Para nós é simples irmos a um local desde que nos indiquem a morada correta (o continente, o país, a cidade, a rua, o número de porta e o andar). Consultamos o mapa, algo que inventámos e que localiza todos os pontos da terra relacionados uns com os outros. Mostra-nos onde estamos e como é que o lugar para onde vamos se relaciona com esse. Mas os coitados dos motoristas não têm um mapa desses para esse tipo de endereços, até porque esses endereços não referem no seu código locais específicos.

Eles vão precisar de perguntar pelo caminho, desde o seu ponto de partida, subindo e  descendo na hierarquia (aldeia, vila, cidade, país, continente, país, cidade, vila, aldeia) até chegarem ao destinatário.

É o Sr. IP que vai ajudar os motoristas nessa tarefa, ensinando aos sinaleiros quais os endereços a que os seus vizinhos conduzem (roteamento), para que eles  possam orientar os motoristas. Os sinaleiros vão encaminhar os motoristas de acordo com as rotas que conhecem e até ao seu destino.

Vamos ver como.

Como já foi referido, o protocolo IP é baseado no modelo de serviço Best Effort ou Melhor Esforço. O IP não garante largura de banda, não garante entrega pela ordem, não garante sequer entrega. Todo o seu esforço vai no sentido de conduzir, conforme em cada ocasião lhe é possível, os pacotes até ao seu destino. Para o resto existem as outras camadas, de que temos vindo a falar.

Estão envolvidos no protocolo IP conceitos fundamentais na Internet, como o Endereçamento, o Encaminhamento e o Roteamento.

Vamos tentar deixar uma ideia de como funciona cada um destes processos:

• O Endereçamento, corresponde à atribuição de um número como o da Figura 1, exclusivo de cada máquina em cada momento.

  

• O Roteamento, determina a melhor rota para  ir do ponto de partida até ao ponto de chegada em cada momento.
• O Encaminhamento, trata do direcionamento do pacote nos roteadores  por onde vai passar, isto é, encaminhá-lo da porta de entrada até à porta de saída certa. Este direcionamento já se passa nos switch, na camada abaixo desta.

Um endereço IPv4, tal como representado na Figura 1, é constituído por 32 bits divididos em conjuntos de 8 bits separados por pontos. A sua representação é feita sob o formato decimal. Como funciona é algo que veremos em breve.

Cabeçalho IP

Vamos então passar à análise dos campos de um cabeçalho IP, representado na Figura 2. Uma vez colocado o cabeçalho no segmento, o novo pacote passa a ter a designação de Datagrama.

Versão – Os primeiros 4 bits descrevem a versão do IP utilizada no datagrama. A versão que vamos analisar é a 4 (IPv4), utilizada até agora em todos os computadores ligados à Internet, embora em lenta substituição pela versão 6 (IPv6), pois a primeira tem a gama de endereços disponível praticamente esgotada.

Comprimento do cabeçalho  –  Os segundos 4 bits do cabeçalho referem o número de palavras de 32 bits que compõem o cabeçalho. Normalmente serão 5 palavras, caso o campo de opções esteja vazio, o que corresponde a 20 Bytes. O número máximo indicado por 4 bits é 15, pelo que o cabeçalho nunca poderá ter mais do que 60 Bytes de comprimento. A dimensão do cabeçalho será sempre um múltiplo de 32 bits ou 4 Bytes.

DSCP (Differentiated Services Code Point) ou Tipo de Serviço (Type of Service) – É  um campo importante para informar o IP sobre o tipo de serviço a que se destinam, para que possam ter formas de processamento diferenciadas conforme o seu tipo.

Por exemplo, se o datagrama se destinar a uma aplicação em tempo real como Voice over IP (VoIP), Vídeo e/ou Áudio online sobre SCTP (Stream Control Transmission Protocol) ou UDP, o seu processamento será diferente do que terá o datagrama se se destinar a uma aplicação não em tempo real, como WEB, e-mail, a transferência de um ficheiro sobre TCP ou um Vídeo e/ou Áudio sem leitura em tempo real (só para guardar em arquivo). Uma aplicação em tempo real é aquela que executa um ficheiro que está a ser recebido (um programa de rádio, um programa de TV, vídeo online como p.e. You Tube, etc.).

ECN (Explicit Congestion Notification) – Estes dois bits são usados pelo ECN, que corre sobre IP. Como já dissemos, é através destes dois bits que a camada de rede informa o equipamento terminal recetor sobre a situação de congestionamento (CE=11), o qual depois a inscreve no segmento da camada TCP do pacote de reconhecimento que envia ao remetente, implementando a flag ECE.

Comprimento total – O comprimento total do datagrama, incluindo cabeçalho, é indicado por este campo de 16 bits. O valor máximo indicável é de 65.535 Bytes e o valor mínimo que qualquer Hospedeiro é obrigado a suportar é de 576 Bytes. Atualmente a maioria dos Hospedeiros já suporta pacotes bem maiores, mas podem sempre existir troços de rede que o datagrama vai atravessar que não suportem tais valores. Por isso está prevista a possibilidade de fragmentação e reconstrução do datagrama em elementos deste cabeçalho. Já lá vamos.

Identificação – Este campo é usado para, em caso de necessidade de fragmentação, identificar inequivocamente os fragmentos de um datagrama original.

Flags – Este campo de 3 bits é usado para controlar a fragmentação de datagramas, quando existir:

• Bit 0 – Reservado. Deve ser 0.
• Bit 1 – (DF) Datagrama não deve ser fragmentado. Se DF estiver a 1 e o datagrama precisar de fragmentação, é deixado cair e é enviada ao remetente uma mensagem ICMP descritora do evento.
• Bit 2 – (MF) Indica se existem mais fragmentos. Se MF for zero é porque o datagrama não é fragmentado. Se MF for 1, significa que existem mais fragmentos do mesmo datagrama, até que volte a ser zero, o que significa que não há mais para além deste fragmento. Nesta situação o campo Offset do fragmento deve ser diferente de zero, razão porque o hospedeiro o distingue da situação em que indica que um pacote não é fragmentado.

Offset do fragmento – Este campo de 13 bits representa o valor, medido em unidades de blocos de 8 Bytes, do início do fragmento em questão. Parte do valor zero para o primeiro fragmento e representa até 65.528 Bytes ( (2¹³-1) x 8), o que excede o comprimento máximo do pacote de 65.535 Bytes.

Tempo de vida – É um campo com 8 bits onde é implementado o número máximo de roteadores por que o datagrama pode passar. Por cada roteador por que o datagrama passa o valor de TTL é decrementado. Quando atinge zero o pacote é descartado. A ideia é evitar que um pacote ande para sempre perdido na Internet metido em loops infindos. Quando é descartado é enviada ao remetente uma mensagem ICMP descritora do evento.

Protocolo  – Este código define o protocolo usado na parte dos dados transportados, isto é, o protocolo da camada acima desta.

Checksum – Para este campo estão destinados 16 bits. O seu funcionamento já foi descrito atrás, na camada transporte. Nesta camada o Checksum é destinado a verificar a integridade dos dados do cabeçalho. Em cada roteador é verificado se houve alguma alteração. Em caso afirmativo o datagrama é descartado. Note-se que, porque de cada vez que passa por um roteador o TTL é decrementado, o valor de Checksum tem que ser de novo computado para que possa estar certo na nova leitura.

Endereço de origem – Este campo contém o endereço IPv4 do remetente, de 32 bits.

Endereço de destino – Este campo contém o endereço IPv4 do destinatário, de 32 bits.

Opções – O datagrama poderá conter opções neste campo, as quais deverão sempre ser múltiplas de 32 bits, utilizando um padding (preenchimento dos bits em falta a zero) para esse efeito se necessário.

Uma vez preenchido o cabeçalho, o datagrama está pronto para ser enviado à camada de enlace, para prosseguir o seu caminho.

Quem quiser pode seguir com ele, mas aconselho vivamente que se mantenham por aqui até perceberem como é que o protocolo IP resolve as principais tarefas que lhe competem.

Falámos durante a descrição do cabeçalho do datagrama em fragmentação do mesmo e também em mensagens ICMP. Mais duas questões que vamos abordar de seguida.

ICMP (Internet Control Message Protocol)

O ICMP (Protocolo de Mensagens de Controlo da Internet) é usado pelos equipamentos terminais e pelos roteadores para poderem trocar mensagens de rede entre si. Como os roteadores não sobem ao nível do protocolo de transporte, este tipo de mensagens permite que os roteadores troquem mensagens com os equipamentos terminais.

São mensagens muito pequenas, essencialmente sobre erros e definidas por códigos e tipos. Pode parecer que este protocolo funciona ao nível da rede, mas não é bem assim. Para todos os efeitos uma mensagem ICMP é enviada sobre IP e no cabeçalho IP leva indicação de que o protocolo de nível superior é o ICMP.

Uma mensagem ICMP utiliza o cabeçalho IP, preenchendo os campos de acordo com o caso, isto é, o código de protocolo é ICMP, o destino é a origem do datagrama a quem se quer transmitir o erro e a origem é o roteador que emite a mensagem.

Acompanhemos com a Figura 1.

A mensagem propriamente dita vai na zona de dados do datagrama IP. O primeiro Byte contém o tipo, o segundo Byte contém o código e os dois Bytes seguintes contêm o Checksum para a mensagem. O segundo bloco de 32 bits depende do tipo e do código.

Nos restantes blocos de 32 bits aparecem o cabeçalho IP da mensagem original e os primeiros 64 bits do seu campo de dados.

Porquê os primeiros 64 bits?

O cabeçalho permite ao emissor identificar o datagrama e os primeiros 64 bis do campo de dados, que correspondem aos primeiros 64 bits do segmento, contendo o início do cabeçalho TCP com informação sobre o número de sequência do segmento e os portos dos terminais emissor e recetor, permitem caso chegue ao terminal emissor, subir a camadas superiores se necessário.

Por exemplo:

• Uma mensagem tipo 11 com o código 0 indica ao remetente que a mensagem se perdeu porque o TTL expirou, como verificámos atrás na descrição do cabeçalho IP.
• Uma mensagem tipo 3 com o código 4, avisa o remetente que deixou cair um datagrama porque precisava de o fragmentar mas tinha o DF marcado e portanto não o podia fazer, mais uma questão que vimos no cabeçalho do IP.
• O tipo 3, conforme os diferentes códigos que utiliza, indica a impossibilidade de prosseguir com o envio do datagrama por desconhecer ou não poder alcançar a rede, o hospedeiro, o porto ou o protocolo.

Mas o ICMP serve para outros fins que não as mensagens de erro. É através do ICMP que os Sistemas Operativos executam os comandos  PING e TRACERT.

Quando um hospedeiro pretende verificar a rede e a ligação com outro hospedeiro, envia um PING ao endereço desse outro hospedeiro. O que o SO faz é enviar uma mensagem ICMP com tipo 8 e código 0, que é o equivalente a pedir um echo a esse hospedeiro. Esse hospedeiro por sua vez envia em resposta outra mensagem ICMP com o tipo 0 e o código 0 correspondente ao envio de um echo de resposta ao Ping.

Quando um hospedeiro pretende saber a rota que um pacote seguiu até ao destino e os RTT até cada um desses pontos, o seu SO executa o comando TRACERT.  Este comando corresponde ao envio de uma sucessão de mensagens  ICMP com o TTL iniciado a 1 e  incrementado para cada uma que se segue.

O resultado deste procedimento é que o TTL se vai esgotar no primeiro, segundo, terceiro, … , enésimo roteador por que passe, até chegar ao seu destino. As mensagens ICMP de retorno de cada um dos pacotes enviados dá indicações sobre os roteadores que as enviam e as temporizações que as mesmas têm no remetente dão indicação do RTT de cada pacote após a sua chegada.

Se se sente à vontade para trabalhar com linha de comandos, experimente introduzir por exemplo os comandos (para um SO Windows):

ping www.google.com
tracert www.google.com

e veja o resultado que obtém.

Fragmentação de um datagrama

Um pacote vai atravessar uma série de enlaces para ir da sua origem até ao seu destino (por exemplo de Lisboa a Sidney). Vai encontrar enlaces mais modernos e enlaces menos atuais, enlaces por cabo, enlaces por fibra ótica, enlaces por satélite, enlaces por feixes Hertzianos, roteadores mais sofisticados, roteadores mais simples, etc.

Enlace é o conjunto remetente, ligação física e recetor de cada parte do percurso. Essas diferenças vão ser sensíveis no facto de a dimensão inicialmente atribuída ao pacote por vezes não ser compatível com a dimensão máxima admitida por um enlace (MTU). Nesta situação o mais simples seria deixar cair o pacote e enviar uma mensagem ICMP indicadora. Mas, precisamente para que isto não aconteça, foi criada a nível do IP (camada de rede) a possibilidade de fragmentar os datagramas.

E porquê ao nível desta camada se isso já é feito ao nível do TCP (camada de transporte)?

Porque se pretende que tal possa ser feito ao nível dos roteadores que, como já foi dito, não abrem o pacote para além da camada de rede.

Assim sendo, quando um roteador pretende passar um pacote da interface de entrada para uma interface de saída cujo MTU é inferior ao seu tamanho, tem que o fragmentar. Para isso vai utilizar os campos do cabeçalho IP do datagrama original destinados às situações de fragmentação e construir datagramas que se insiram nas dimensões máximas permitidas pelo enlace que se segue. A forma como preenche e usa os campos para esse efeito, já foi descrita aquando da análise dos campos do cabeçalho IP.

Chegados os fragmentos ao destino, há que reconstruir o datagrama original. Esta operação é feita pelo recetor, que junta todos os fragmentos com o mesmo ID e com a flag MF a 1, mais o último fragmento com a flag MF a 0 e com o campo offset preenchido, colocando-os pela devida ordem, retirando os cabeçalhos dos fragmentos e colocando o cabeçalho único do datagrama original.

A Figura 2 tenta ilustrar o que acabámos de descrever. Pode-se verificar a evolução dos valores de comprimento total, da flag MF e do offset do fragmento.

O Offset do fragmento indica sempre o primeiro Byte de cada datagrama, numa escala de 8 Bytes, referindo-se unicamente à carga de dados. Assim 0, 185(1480/8), 370(2960/8) e 555(4440/8) são as posições de início (o offset) de cada um dos fragmentos. Note-se que a última flag MF já vai a zero, mas como o offset é diferente de zero, indica que se trata de um último fragmento. É com base nestes pressupostos que é feita a regeneração do datagrama original, no destinatário.

O datagrama original não volta a ser reconstruído senão no hospedeiro final. Pretendeu-se com isto evitar ainda mais complicações no protocolo dos roteadores e mais trabalho para os mesmos.

Para ilustrar aquilo que acabámos de descrever juntamos a Figura 3 que pretende mostrar a viagem de um datagrama que é desfragmentado algures num roteador durante o seu percurso.