CENTRO DE CIÊNCIAS EXATAS
DEPARTAMENTO DE COMPUTAÇÃO
REDES DE COMPUTADORES
HTTP
Metro Ethernet
André Ricardo Gonçalves
Daniel César Romano Luvizotto
Heber A. A. do Nascimento
Luiz Gustavo de Andrade dos Santos
Prof. Dr. Mário Lemes Proença Júnior
LONDRINA - PR
2007
Sumário
1 Hypertext Transfer Protocol
p. 4
1.1
Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
p. 4
1.2
Uniform Resource Locator . . . . . . . . . . . . . . . . . . . . . . .
p. 4
1.3
HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
p. 5
1.4
Caracterı́sticas do protocolo . . . . . . . . . . . . . . . . . . . . . .
p. 6
1.5
Como funciona . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
p. 8
1.6
Requisição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
p. 9
1.6.1
Métodos Seguros e Idempotentes . . . . . . . . . . . . . . . p. 10
1.6.2
Definição dos Métodos de Requisição . . . . . . . . . . . . . p. 10
1.7
Resposta do Servidor . . . . . . . . . . . . . . . . . . . . . . . . . . p. 11
1.8
HTTPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 14
1.9
1.8.1
SSL e TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 14
1.8.2
HTTP sobre TLS . . . . . . . . . . . . . . . . . . . . . . . p. 15
Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 16
2 Metro Ethernet
p. 17
2.1
Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 17
2.2
Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 18
2.3
Serviços Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 19
2.3.1
Parâmetro de Tráfego (Bandwidth Profile) . . . . . . . . . . p. 20
2.4
Identificadores de Classes de Serviços (CoS) . . . . . . . . . . . . . p. 22
2.5
Carrier Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 22
2.6
Aspectos Básicos de QoS . . . . . . . . . . . . . . . . . . . . . . . p. 23
2.7
Provider Bridge (PB) ou Q-in-Q
2.8
Provider Backbone Bridge (PBB) ou MinM . . . . . . . . . . . . . . p. 25
2.9
Provider Backbone Transport (PBT) . . . . . . . . . . . . . . . . . p. 25
. . . . . . . . . . . . . . . . . . . p. 23
2.10 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 26
Referências
p. 28
4
1
Hypertext Transfer Protocol
1.1
Introdução
A Internet é basicamente constituı́da por milhões de web pages, as conhecidas páginas de internet, que podem ser publicadas e acessadas de qualquer parte do mundo.
Essas páginas podem conter textos, imagens, filmes, sons, entre outros, que em conjunto com uma linguagem de marcação denominada HyperText Markup Language
(HTML), formam um página. As páginas são requisitadas por meio de um navegador (browser) que o usuário utiliza para solicitar e posteriormente apresentar a página
solicitada, do outro lado está o servidor que contém a página, ele é quem recebe a
solicitação envia a página que será interpretada pelo navegador, mostrando então a página ao usuário. A partir deste contexto o HyperText Transfer Protocol (HTTP) vêm
com o intuito de definir as regras de requisição/resposta e como deve ser transmitidos
esses dados.
1.2
Uniform Resource Locator
Para identificar cada página (recurso) na internet é atribuı́do a ela um nome, o
chamado URL (Uniform Resource Locators), que é utilizado com um esquema para
acessar um item, o URL é um subconjunto da URI (Uniform Resource Identifiers). Este
esquema define todos os atributos necessários para acessar aquela página na internet.
Abaixo é mostrado um exemplo de um esquema:
1.3 HTTP
5
http:
// hostname [: port] / path [:parameters][?query]
A parte em itálico denota o item a ser fornecido, e as partes entre colchetes “[...]”
denotam itens opcionais.
http: identifica o protocolo que esta utilizando;
hostname: é o nome do domı́nio ou o IP do servidor que contém o item solicitado;
port: é utilizado caso o servidor não utilize a porta padrão 80;
path: é o caminho que identifica o recurso no servidor;
parameters: são algum parametros adicionais fornecidos pelo cliente;
? query: é uma string opcional informando que o cliente está ouvindo uma questão.
Existem outras duas definições sobre a URL que são a URL Absoluta e Relativa.
URL absoluta é a especificação completa, exemplo
http://www.uol.com.br/esportes/formula1
e a URL relativa é a forma que omite o endereço do servidor, somente usado quando
o servidor é implicitamente conhecido.
1.3
HTTP
O HyperText Transfer Protocol que a partir daqui chamaremos de HTTP é um
protocolo da camada de aplicação do modelo OSI que é responsável por definir as
regras de emissão e recebimento de dados pela World Wide Web. A utilização do
protocolo é definida pela string http: na URL.
Segundo (COMER, 2006) o intuito original era de prover uma maneira de publicar
e resgatar páginas de hipertexto na web, o HTTP foi inicialmente apresentado em
1990, com nome de HTTP/0.9 que apenas transmitia dados no formato texto ASCII.
Este protocolo é classificado como um protocolo orientado a conexão, pois necessita
1.4 Caracterı́sticas do protocolo
6
estabelecer uma conexão para iniciar a troca de mensagens. Para que isso seja possı́vel o HTTP utiliza um protocolo para realizar esta tarefa, o TCP (Transfer Control
Protocol) é geralmente utilizado e usa como padrão a porta 80.
No inı́cio da era da Internet o intuito era apenas utilizar a rede para realizar trocas
de mensagens, mas com a explosão da internet foi necessitando o envio não somente de
textos, mas também de imagens, vı́deos e sons, tendo em vista esta necessidade surgiu
o HTTP/1.0 em 1996, descrito por meio da RFC 1945 por (BERNERS-LEE, 1996), que a
partir deste nova versão o protocolo passou a enviar mensagens no mesmo formato que
era utilizado para envio de e-mail e também da Multipurpose Internet Mail Extensions
(MIME). Segundo (BERNERS-LEE, 1996) o HTTP/1.0 utiliza muitas das construções
definidas pelo MIME, as poucas diferenças estavam ligadas a questão da otimização da
performance sobre as conexões binárias, para fornecer maior liberdade para os novos
tipos de mı́dias.
A versão utilizada atualmente é o HTTP/1.1 que foi apresentado em 1999 por
meio da RFC 2616 por (FIELDING, 1999). Esta versão do protocolo implementa alguns
outros recursos não suportados pela até então atual versão, segundo (FIELDING, 1999)
os procotolo HTTP1.0 não era suficiente para considerar os efeitos dos proxys, cache,
conexões persistentes e hosts virtuais. O HTTP também é utilizado como um protocolo
genérico para comunicação entre os agentes utilizadores e proxies/gateways para outros
sistemas, incluindo aqueles suportados pelo SMTP, NNTP, FTP, Gopher e WAIS,
permitindo o acesso à recursos disponı́veis em aplicações diversas (FIELDING, 1999).
As requisições são feitas a partir de métodos, que serão discutidos na secção 1.6.
Os métodos vão identificar que tipo de requisição o cliente esta realizando ao servidor.
E a resposta do servidor em relação à requisição é apresentado na seção 1.7.
1.4
Caracterı́sticas do protocolo
Algumas das principais caracterı́sticas da versão atual do HTTP (HTTP/1.1) são
apresentadas por (COMER, 2006) as quais são descritas abaixo:
1.4 Caracterı́sticas do protocolo
7
Nı́vel de Aplicação O protocolo HTTP trabalha no nı́vel de aplicação do modelo
OSI, sendo assim ele utiliza um protocolo de transporte orientado á conexão
como o TCP.
Requisição/Resposta Considerando a conexão já estabelecida, um cliente solicita
uma requisição HTTP para o um servidor que envia uma resposta a esta requisição.
Sem preservação de estado As requisições são independentes. Um servidor não
mantém as informações das requisições realizadas anteriormente.
Transferência Bi-direcional A transferência de dados é realizada de uma forma bidirecional, ou seja, tanto podem ser enviados dados do servidor para cliente,
exemplo o envio de uma página para o cliente, como do cliente para o servidor,
exemplo o envio de dados de um formulário.
Capacidade de Negociação O HTTP permite ao servidor e cliente a negociação de
detalhes como o conjunto de caracteres que serão utilizados durante a transferência. O emissor pode especificar suas capacidades oferecidas e o receptor as
suas capacidades aceitáveis.
Suporte à cache Para melhorar o tempo de resposta, o navegador armazena uma
cópia de todas as páginas recebidas. Caso o cliente solicitar uma página já
acessada anteriormente, o HTTP permite o navegador perguntar ao servidor se
a página foi alterada desde que a cópia foi armazenada.
Suporte à intermediários O HTTP permite as máquinas que estão entre o servidor
e o cliente, armazenar uma cópia das páginas que passam por ela, como se fosse
um servidor proxy e responde a uma requisição do cliente à esta cache.
1.5 Como funciona
1.5
8
Como funciona
O protocolo HTTP é definido principalmente para determinar como será o processo de requisição e resposta do cliente e servidor respectivamente. Entende-se por
requisição o ato de um cliente solicitar dados, uma página por exemplo, de um servidor
e por resposta entende-se como o retorno do servidor a esta solicitação.
A RFC 2616 (FIELDING, 1999) apresenta o processo de transmissão de dados utilizando o HTTP, inicialmente o cliente estabelece uma conexão com o servidor, após
estabelecida a conexão o cliente envia uma requisição em forma de método de requisição, o identificador do servidor (o Uniform Resource Identifier, URI), a versão do
protocolo que está sendo utilizada, seguido pela mensagem a ser enviada para o servidor. Após o recebimento desta requisição o servidor envia uma resposta que contém
uma linha de status, que inclui a versão do protocolo e o status-line que é um código
de retorno e a mensagem que contém informações sobre o servidor.
Até a versão HTTP/1.0, após este procedimento a conexão era encerrada, na
versão atual, HTTP/1.1, foi implementada o conceito de conexão persistente, que
mantém a conexão estabelecida, encerrando-a caso uma requisição incluir em seu
cabeçalho uma operação de fechamento de conexão, outra maneira é se a conexão
ficar ociosa por um determinado perı́odo de tempo.
A figura 1 apresenta o esquema de requisição/resposta definido pelo HTTP.
Figura 1: Esquema do funcionamento do procedimento requisição/resposta.
1.6 Requisição
1.6
9
Requisição
Para que um programa cliente (navegador) possa acessar uma página na internet,
ele solicita ao servidor uma cópia da mesma para apresentá-la na tela. Esta solicitação
é feita por meio de requisições, que são cabeçalhos que vão informar ao servidor qual
página ele deseja e algumas de suas caracterı́sticas.
Uma requisição é composta básicamente por 4 partes:
1. o método de definição da ação a ser realizada pelo servidor,
2. a URI que define o endereço do recurso que deve ser realizado a ação,
3. a versão do HTTP que utilizado (1.0 ou 1.1),
4. informações adicionais sobre o recurso e sobre o cliente.
Os métodos de definição da ação são discutidos na seção 1.6.2. A URI utilizada
pelo HTTP é a URL que define a localização do servidor e do caminho do recurso no
servidor, a URL foi apresentada na seção 1.2. Abaixo é apresentado um exemplo de
uma requisição.
GET /internet/index.html HTTP/1.0
User-agent: Mozilla/4.5b1 [en] (WinNT; I)
Accept: text/plain, text/html, image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png
Accept-Charset: iso-8859-1,*,utf-8
Accept-Encoding: gzip
Accept-Language: en
O exemplo acima é uma requisição que solicita uma cópia da página que está na
URL relativa
/internet/index.html
, a versão do HTTP utilizada é a HTTP/1.0 e abaixo
algumas informações sobre o cliente, como o browser utilizado (Mozilla), o sistema
operacional utilizado (Windows NT), além de outras informações.
1.6 Requisição
1.6.1
10
Métodos Seguros e Idempotentes
A RFC 2616 (FIELDING, 1999) apresenta a definição de métodos seguros e idempotentes. Essas definições apresentam algumas caracterı́sticas dos métodos de requisição.
Um método seguro não deve ser utilizado para realizar mudanças nos dados contidos no servidor. Alguns exemplos de métodos seguros são os métodos GET e HEAD
que serão apresentados na seção 1.6.2. Um método é dito ser idempotente se o resultado de múltiplas requisições de um mesmo recurso for o mesmo resultado de uma
única requisição a este mesmo recurso. Alguns métodos que possuem esta caracterı́stica são GET, HEAD, PUT e DELETE.
1.6.2
Definição dos Métodos de Requisição
Abaixo serão apresentados os principais métodos de requisição presentes na versão
atual do protocolo, a HTTP/1.1, segundo a RFC 2616 (FIELDING, 1999).
GET Este solicita a recuperação de um determinado recurso. É o método mais utilizado, é um método não seguro, assim não pode ser utilizado para atualizar dados
em um servidor por exemplo e também é um método idempotente.
HEAD Este método é idêntico ao método GET, a exceção é que o servidor não retorna
o recurso, ele apenas retorna as informações do recurso.
POST É utilizado para requisitar que o servidor de origem utilize as informações
presentes no corpo da mensagem para criar um novo recurso subordinado ao
recurso especificado na URI. É responsável também em realizar processamento
que não são diretamente relacionadas ao recurso.
PUT É utilizado para atualizar um recurso especificado. Caso o recurso não exista,
um novo recurso é criado e o código de retorno 201 (Created) é emitido pelo
servidor indicando a ação executada. A principal diferença entre POST e o PUT
1.7 Resposta do Servidor
11
é forma que cada um interpreta o recurso especificado na URI, no caso do POST
a URI identifica o recurso que manipulará o recurso enviado, este recurso pode
ser um validador, um gateway pra outro protocolo e o PUT apenas identifica o
recurso incluido na requisição.
DELETE Utilizado para remover um recurso especificado pela URI. Caso não exista
nenhum recurso o servidor deve retornar o código de status 204 (Not Found)
informando que este recurso não existe.
OPTIONS Este método é utilizado para retornar informações sobre as opções da
comunicação, como os requerimentos associados a um recurso, as capacidades
do servidor, sem implicar em uma ação ou recuperação do recurso.
TRACE Utilizado para ecoar a requisição recebida, para o cliente saber o que os
servidores intermediários estão adicionando e/ou alterando na requisição.
CONNECT É usado com um proxy para que possa ser realizado um túnel, exemplo
para estabelecer uma conexão segura.
1.7
Resposta do Servidor
Quando o servidor recebe uma requisição de um cliente ele a analisa e tenta
executa-lá, após esta tentativa ele retorna uma reposta para o cliente informando
qual foi o resultado da ação. A resposta é um cabeçalho basicamente divido em três
partes:
• o código do status, que indicará ao cliente o resultado da execução,
• descrição da informação sobre o recurso solicitado,
• o recurso solicitado, um exemplo o código HTML de uma página.
Abaixo é apresentado um exemplo de uma resposta enviada pelo servidor após a
execução de uma requisição, esta requisição foi exemplificada na seção 1.6.
1.7 Resposta do Servidor
12
HTTP/1.0 200 Document follows
Date: Thu, 20 Aug 1998 18:47:27 GMT
Server: NCSA/1.4.2
Content-type: text/html
Last-modified: Fri, 14 Aug 1998 20:14:23 GMT
Content-length: 5807
Na primeira linha o código 200 identifica que a requisição foi executada com sucesso
e que a informação será retornada, nas linhas seguintes algumas caracterı́sticas do
servidor e do recurso solicitado. Na segunda linha a data da resposta, na terceira há
informações sobre o servidor e sua versão, na linha quatro o tipo do recurso solicitado
(um arquivo html), na quinta linha a data da última alteração do arquivo solicitado e
por fim o tamanho do documento que está sendo retornado.
Segundo (FIELDING, 1999) o código de status é um número de 3 dı́gitos, sendo que
o primeiro dı́gito corresponde a classe de respostas que o código pertence. As classes
definem uma curta descrição textual do código, e os dois últimos dı́gitos definem o
resultado mais detalhadamente. Há 5 classes distintas que são apresentadas abaixo:
1xx Informacional, a requisição foi recebida e o processo continua;
2xx Sucesso, a ação foi recebida com sucesso, compreendida e aceita;
3xx Redirecionamento, mais uma ação dever ser recebida em ordem para completar a
requisição;
4xx Erro no cliente, a requisição contém um erro de sintaxe ou não pôde ser completada;
5xx Erro no servidor, o servidor falhou em completar uma requisição aparentemente
válida.
1.7 Resposta do Servidor
13
Os valores dos principais códigos de status definido pelo HTTP/1.1 estão definidos
abaixo, a lista completa de todos os códigos de status suportados pelo HTTP/1.1 pode
ser vista em (FIELDING, 1999).
200 OK A requisição foi executada com sucesso.
201 Created A requisição foi completada e resultado em um novo foi criado.
202 Accepted A requisição foi aceita para processamento, mas o processamento não
foi completado.
301 Moved Permanently O recurso foi movido permanentemente para outra URI.
302 Found O recurso foi movido temporariamente para outra URI.
304 Not Modified O recurso não foi alterado.
401 Unauthorized A URI especificada exige autenticação do cliente. O cliente pode
tentar fazer novas requisições.
403 Forbidden O servidor entende a requisição, mas se recusa em atendê-la. O
cliente não deve tentar fazer uma nova requisição.
404 Not Found O servidor não encontrou nenhuma URI correspondente.
405 Method Not Allowed O método especificado na requisição não permitido para
o recurso indentificado pela URI. A resposta deve incluir um cabeçalho Allow
com uma lista dos métodos aceitos para aquele recurso.
410 Gone O recurso solicitado está indisponı́vel mas seu endereço atual não é conhecido.
500 Internal Server Error O servidor não foi capaz de concluir a requisição devido
a um erro inesperado.
502 Bad Gateway O servidor, enquanto agindo como proxy ou gateway, recebeu
uma resposta inválida do servidor upstream a que fez uma requisição.
1.8 HTTPS
14
503 Service Unavailable O servidor não é capaz de processar a requisição pois está
temporariamente indisponı́vel.
1.8
HTTPS
Inicialmente o HTTP foi criado para definir um simples esquema de requisição/resposta
que era suficiente até então. Quando começaram a surgir aplicações mais complexas, como vendas pela internet, foram surgindo necessidades de atribuir segurança a
este esquema, a partir disto foi apresentado o HyperText Transfer Protocol Security
(HTTPS), que nada mais é que o HTTP sobre uma camada de transporte segura,
como o Secure Sockets Layer (SSL) ou seu sucessor o Transport Layer Security (TLS).
O HTTPS não é um protocolo separado, mas sim uma referência a uma combinação de dois protocolos, o HTTP sobre um protocolo de segurança. A string https:
no inı́cio da URL indica que se trata de um esquema de comunicação de dados segura.
Na seção 1.8.1 serão apresentados os protocolos SSL e TSL e na seção 1.8.2 como
é usado o HTTP sobre o TLS.
1.8.1
SSL e TLS
O protocolos SSL e TLS são protocolos que proveêm comunicação segura na
internet. Segundo (COMER, 2006) o protocolo SSL foi originalmente desenvolvido pela
Netscape e atua na mesma camada como um API de socket.
O SSL funciona da seguinte maneira, suponhamos que um cliente utiliza o SSL
para conectar com o servidor, o SSL permite que ambos os lados se autentiquem, após
a autenticação os lados escolhem um algoritmo de encriptação de dados suportado por
ambos os lados. Finalmente o SSL permite que os dois lados estabeleçam um conexão
criptografada.
Definido inicialmente na versão 1.0 por meio da RFC 2246 por (DIERKS, 1999) em
1.8 HTTPS
15
1999, atualmente na versão o TLS/1.1 definido pela RFC 4346 por (DIERKS, 2006) o
protocolo TLS é o sucessor do SSL, que permite aplicações cliente/servidor se comunicarem de maneira que previne o eavesdropping (escuta), tampering (adulteração) e
message forgery (falsificação de mensagem).
1.8.2
HTTP sobre TLS
O HTTP sobre TLS é conceitualmente muito simples, ele usa o HTTP sobre o
TLS assim como usa-se o HTTP sobre o TCP (RESCORLA, 2000).
No HTTP sobre SSL utiliza-se portas TCP diferentes para identificar uma conexão
segura, a porta padrão é 443 e é adicionada uma camada de encriptação/autenticação
entre HTTP e o TCP, já no HTTP sobre TLS ele utiliza a mesma porta 80. A figura
2 apresenta o esquema do HTTP sobre TLS.
Figura 2: Esquema do HTTP sobre TLS
A conexão é inicializada quando o cliente envia um TLS ClientHello para iniciar o
processo de verificação da autenticidade handshake, após a autenticação o cliente pode
1.9 Conclusão
16
então enviar a primeira requisição HTTP. Todos os dados HTTP devem ser enviados
como se fossem dados de aplicação TLS.
Para o fechamento da conexão o TLS deve iniciar uma troca de alertas de fechamento, antes do real fechamento da conexão. O TLS também pode, depois de
enviadas alertas de fechamento, fechar a conexão mesmo antes do outro lado (servidor
ou cliente) ter enviado seu alerta, caracterizando o fechamento incompleto. Outro
caso chamado de fechamento prematuro ocorre quando um lado fecha a conexão sem
receber nenhum alerta.
1.9
Conclusão
O HTTP está atendendo bem até agora as necessidades da web, mesmo com seu
rápido crescimento, mas um projeto está sendo desenvolvido paralelamente, o protocolo
chamado HTTP-NG (HTTP New Generation), que está sendo desenvolvido a partir
do zero, mas utilizando a experiência que foi obtida até agora com o HTTP. O HTTPNG tem como objetivo diminuir o overhead, aumento da confiabilidade, aumento da
velocidade de acesso, entre outros. Em um futuro breve muitos conceitos devem mudar
na World Wide Web.
17
2
Metro Ethernet
2.1
Introdução
O mercado de redes cada vez mais busca por soluções com custo baixo e que
garantem qualidade de serviço. Com isso aumenta-se a interconexão entre as redes
corporativas distribuı́das geograficamente e com a Internet. Com isso Metro Ethernet
tem sido bastante visada, pois tem fácil interconexão, administração, boa granularidade
e é claro baixo custo.
Com o aparecimento de novos protocolos, visando aumentar a qualidade de serviço,
segurança para deixar semelhante as redes de circuito tradicionais, mas com as vantagens de rede de pacotes. O protocolo Ethernet tem sido dominante em redes LAN,
segundo (FRAULOD; PIACENTINI, 2006) mais de 98% do tráfego corporativo passa por
interfaces Ethernet, isto se deve por causa da facilidade de execução e o preço. Mas
isso não ocorre nas redes MAN e WAN, que usam serviços em ATM, Frame Relay e
linhas linhas privativas, todos um razoavelmente mais complicados e mais caros.
A definição de uma rede Metro Ethernet (Metropolitan Ethrnet Network) é uma
rede que interconecta LANs separadas geograficamente, e também interconectando-se
a uma rede WAN ou backbone operados através do provedor de serviços. Ilustrando
na figura 3.
As principais vantagens da utilização de uma rede Metro Ethernet estão descritas
abaixo:
2.2 Arquitetura
18
Figura 3: Esquema da rede Metro Ethernet
• Custo de planejamento e operacional mais baixo que redes comutadas tradionais;
• Equipamentos de menor custo;
• Facilidade de aumento de banda, melhor granularidade comparando com redes
de circuito comutado (E1/T1, E3/T3, SDH/SONET), por exemplo aumento da
banda de 1 Mbps a 1 Gbps em passos de 1 Mbps;
• Transmissão baseada em pacotes que comparada com transmissão em circuitos
é significativamente melhor;
• Permite a interconexão direta com as redes LAN (Interoperabilidade), não necessitando de protocolos, pois quase todas as redes Lan são baseadas em Ethernet.
2.2
Arquitetura
É utilizado um modelo genérico para descrever os componentes de externos e
internos da rede Metro Ethenet.
O fluxo Ethernet flow mostrado na figura 4 mostra o tráfego de dados fim-a-fim
entre dois equipamentos terminais, nos quais mostram o inı́cio e termino dos quadros
Ethernet. O interface que interliga o cliente à rede é chamado de UNI (User Network
Interface) e parte do cliente de UNI-C (User Network Interface Client) e do provedor
UNI-N (User Network Interface Network).
2.3 Serviços Ethernet
19
Figura 4: Arquitetura da rede Metro Ethernet
Um conceito muito importante em redes Metro Ethernet é a EVC conexão Ethernet
virtual (it Ethernet Virtual Connection), pois associa 2 ou mais UNIs, com o objetivo
de passar fluxo entre dois ou mais clientes, além de ajudar a visulaizar o conceito de
conexões eles podem ser comparados com os PVS no ATM. Existem dois tipos de
EVCs, o ponto-ponto (E-Line) e o multiponto-multiponto (E-LAN).
2.3
Serviços Ethernet
Os três principais fatores que influenciam na escolha de serviços Ethernet são:
1. Facilidade de uso através de uma interface padrão e bem conhecida;
2. Baixo custo por causa da produção dos equipamentos em larga escala;
3. Flexibilidade: modificação da banda em minutos ao contrário de dias e semanas
em outras redes.
4. Pode-se realizar diversos tipos de serviços utilizando a mesma interface.
O modelo básico para o serviços Ethernet é apresentado na 5, o equipamento do
cliente (CE = Customer Equipment) se interconecta à rede por meio da UNI através
de uma interface Ethernet padrão 10Mbps, 100Mbps, 1Gbps ou 10Gbps.
2.3 Serviços Ethernet
20
Figura 5: Modelo Básico
A figura 6 mostra os dois serviços Ethernet reconhecidos pelo Metro Ethernet
Forum MEF 1 , que consiste em uma aliança global de indústrias na área de comunicação
de dados, que possui como intuito desenvolver especificações técnicas na área de redes
Metro, e um resumo dos atributos e parâmetros.
2.3.1
Parâmetro de Tráfego (Bandwidth Profile)
O Bandwidth Profile diz o limite da taxa média de quadros de serviços Ethernet
que podem entrar na rede do provedor de serviços através de uma UNI. O MEF tem
definido três atributos de ıBandwidth Profile:
Perfil por UNI aplicados a todos os serviços que entram na rede pelo provedor UNI;
Perfil por EVC aplicados a quadros que passam por determinado EVC dentro da UNI;
Perfil por Indentificador CoS aplica-se a todos os quadros de um EVC identificados
pelos bits de prioridade da marcação (tag).
Cada um dos atributos possui 4 parâmetros de tráfegos:
1
www.metroethernetforum.org
2.3 Serviços Ethernet
21
Figura 6: Serviços Ethernet reconhecidos pelo MEF
1. Committed Information Rate (CIR): taxa média de desempenho de acordo com
desempenhos contratados (atraso, etc.) especificados por um SLA (Service Level
Agreement).
2. Committed Burst Size (CBS): define o número máximo de bytes permitidos por
quadros de serviços e são contados pelo CIR.
3. Excess Information Rate (EIR): taxa média excedente ao CIR, no qual o quadros
são entregues sem garantia.
4. Excess Burst Size (EBS): define o número máximo de bytes permitidos por quadros de serviços, e são contados pelo EIR.
Um meio eficiente de descrever se os quadros de serviços estão na média é através
do uso de cores, verde se estiver dentro do contrato SLA, amarelo não está de acordo,
mas não serão descartados imediatamente e vermelho que não está de acordo e serão
descartados imediatamente.
2.4 Identificadores de Classes de Serviços (CoS)
2.4
22
Identificadores de Classes de Serviços (CoS)
As redes Metro Ethernet necessitam oferecer várias classes de serviço (Cos) distintas, as quais são identificados através de:
• Porta fı́sica: apenas uma classe de serviço pode ser fornecida nesse caso;
• CE-VLAN CoS (802.1p): classe de serviço identificada pelas tags de VLAN do
cliente.
• DiffServ/IP TOS: neste caso o segundo byte do cabeçalho IP pode ser usado
para definir classes de serviço e que podem ser definidas até 8 classes.
2.5
Carrier Ethernet
O termo Carrier Ethernet significa oferecer serviços através de uma rede Metro
Ethernet Global com uma qualidade similar as encontradas nas redes comutadas, tentando manter o mesmo grau de simplicidade e o baixo custo que são encontrados nas
tı́picas redes LAN (FRAULOD; PIACENTINI, 2006).
O Metro Ethernet Fórum (MEF) propõem cinco atributos que distinguem uma
rede Carrier de uma rede LAN. São elas:
QoS : garantir um bom desempenho do tráfego com qualidade similar ao das redes
tradicionais;
Confiabilidade : capaz de se recuperar de falhar com tempo abaixo de 50ms; proteção
de caminho fia-a-fim;
Escalabilidade : suportar mais de 100.000 clientes;
Gerencia de serviços : monitorar, diagnosticar e centralizar a gerencia de redes,
configuração rápida e fácil da rede;
Serviços Padronizados : serviços globais com equipamentos padronizados.
2.6 Aspectos Básicos de QoS
2.6
23
Aspectos Básicos de QoS
Obtém-se qualidade se serviço através de uma combinação de técnicas que objetiva
garantir nı́veis de confiabilidade referente às necessidades dos clientes. O cliente vê a
qualidade de serviços como uma especificação técnica e operacional de nı́vel de serviço
(FRAULOD; PIACENTINI, 2006).
O protocolo Ethernet possui como uma de suas caracterı́sticas, proverem a cada
usuário um acesso compartilhado e semelhante à rede, de maneira que ocorra uma
mı́nima implementação nos equipamentos. Nas redes LAN, isto não é novidade, o
tráfego entre departamentos é separado através do uso de LANs virtuais VLANs.
2.7
Provider Bridge (PB) ou Q-in-Q
Segundo (FRAULOD; PIACENTINI, 2006) a forma mais simples e segura de assegurar
o isolamento de tráfego dentro da rede é através da utilização de VLANs. No padrão
802.1Q é encontrada a definição do funcionamento de VLAN, que resumidamente pode
ser definido como a utilização de um identificador para cada VLAN, este método de
utilização de identificador já vem sendo muito utilizado, assim está seria uma maneira
natural para as redes Metro Ethernet proverem o isolamento de tráfego entre os diversos
clientes. Mas, a utilização da norma 802.1Q em redes Metro Ethernet esbarra no
problema da quantidade e administração dos VLAN-IDs. Não há como o operador de
serviços gerenciar e assegurar que cada cliente utilize identificar de VLAN (VLAN-ID)
diferente dentro da rede metropolitana. Outro problema é a quantidade máxima de
identificadores oferecidos que é de 4096, este número é uma quantia muito limitada
em relação às dimensões da rede metropolitana, alem do fato de limitar o cliente na
criação de suas próprias VLANs internas.
Para solucionar tal problema, foi criado o conceito de tunelamento de VLANs que
esta na norma 802.1ad (FRAULOD; PIACENTINI, 2006). Este conceito é um mecanismo
muito simples, no qual uma VLAN é encapsulada dentro de outra VLAN conforme
2.7 Provider Bridge (PB) ou Q-in-Q
24
mostrado na 7. Este tunelamento permite uma completa separação do tráfego do
cliente. Assim o cliente conta com total liberdade de gerenciar suas C-VLANs. O
provedor tem à sua disposição até 4096 S-VLANs, suportando até 4k clientes/serviços.
Figura 7: Exemplo de tunelamento VLAN 34 dentro de uma VLAN 2
Conforme observado na 8 o formato cabeçalho do 802.1ad é bem parecido com
o do 802.1Q. A implementação da S-VLAN ocorre através da adição de quatro bytes
ao cabeçalho Ethernet após os campos de MAC de origem e destino, são inseridos
dois bytes correspondentes ao TCI (Tag Control Information). Diferentemente do
802.1Q, o bit quatro do primeiro byte do campo TCI, passa a ser chamado de DEI
(Drop Eligeble Indicator) (FRAULOD; PIACENTINI, 2006). A combinação dos três bits
de prioridade mais o bit DEI formam o conceito de PCP (Priority Code Point), que é
utilizado dentro da rede como parâmetro de descarte ou não dos pacotes.
Figura 8: Formato do frame 802.1Q
Pelo motivo de inserção ou remoção destes quatro bytes do cabeçalho, o 802.1ad
2.8 Provider Backbone Bridge (PBB) ou MinM
25
exige o recalculo do checksum do campo CRC do quadro Ethernet.
2.8
Provider Backbone Bridge (PBB) ou MinM
Como visto anteriormente, com o QinQ, o provedor de serviços tem apenas 4096
S-VLANs a sua disposição, este é um número muito reduzido tratando-se de redes
metropolitanas. Juntamente a isto surge o problema do tamanho das tabelas de roteamento que os switches da rede Metro Ethernet tem que manter.
O MinM é um padrão que é encontrado na norma 802.1ah que esta sendo desenvolvido para resolver o problema das tabelas (FRAULOD; PIACENTINI, 2006). No MinM,
os pacotes de S-VLAN são encapsulados por um novo cabeçalho, que possui um novo
MAC (B-MAC - Backbone MAC). Assim, os switches intermediários na rede Metro
Ethernet não precisam aprender todos os MACs de uma determinada S-VLAN, mas
somente os B-MAC que pertencem à rede do provedor. Então o funcionamento deste
novo padrão seria desta forma: acrescenta-se o novo cabeçalho os pacotes oriundos
de uma S-VLAN ao entrarem no backbone e na outra ponta, assim quando deixarem
o backbone, o cabeçalho acrescido é removido.
O uso do padrão MinM traz algumas vantagens como pro exemplo: simplifica
a operação, ou seja, o provedor pode planejar sua rede sem ter a preocupação de
conflitos relacionados a identificadores de VLANs ou de endereços MAC de seus clientes
(FRAULOD; PIACENTINI, 2006).
2.9
Provider Backbone Transport (PBT)
Segundo (FRAULOD; PIACENTINI, 2006) o conceito de PBT é similar ao PBB, à
diferença é que o PBT propicia túneis ponto-a-ponto entre localidades disjuntas, ele
pode ser usado para rodar paralelamente ao PBB ou pode substituı́-lo. Atualmente os
switches Ethernet encaminham pacotes baseados em uma tabela de encaminhamento
de 60 bits que inclui a marcação de VLAN (VID - 12 bits) e o endereço MAC (48 bits).
2.10 Conclusão
26
Assim quando um endereço não é conhecido, o switch faz um broadcast para todas as
portas, ao receber uma resposta por uma determinada porta, o switch associa este MAC
destino a essa porta e acrescenta esta informação a sua tabela de encaminhamento.
A idéia principal do PBT é justamente desabilitar a funcionalidade do Ethernet
relacionada ao broadcast, quando o destino não é conhecido. Agora no PBT se usa
o VID em conjunto com o MAC para resultar em um caminho pré-determinado com
caracterı́sticas previsı́veis.
Com o PBT o operador da rede pode correlacionar um VID com um caminho
principal na rede e um outro VID com um caminho de proteção. Assim se ocorrer
alguma falha no caminho principal o roteador começa a passar os pacotes pelo caminho
de proteção. A proposta de monitoramento do estado da conexão é utilizar o protocolo
802.1ag (FRAULOD; PIACENTINI, 2006). Uma sessão de conectividade (Connectivity
Check - CC) é estabelecida em ambos os caminhos. Ambas as pontas do enlace
enviam mensagens CC em intervalos regulares de 10ms (configurável) e ouvem as
mensagens que chegam da outra ponta. Se três mensagens CC não chegarem, o
enlace é considerado com falha e o caminho de proteção é ativado.
Assim, mecanismos de proteção com tempos inferiores a 50ms (padrão do SDH/SONET)
são possı́veis. O uso do PBT trás benefı́cios como: a rede torna-se mais robusta e
isolada de tempestades de broadcast, os roteadores do provedor não precisam aprender
endereços MAC dos clientes, permitindo assim, uma redução dos custos de equipamentos.
2.10
Conclusão
Hoje em dia os mais serviços requeridos pela área corporativa e que tem crescido
são as interconexões das redes LAN geograficamente distribuı́das e a conectividade com
a Internet. Assim, as redes Metro Ethernet tem se mostrado uma solução, devido as
grandes exigências de Qualidade de Serviço (QoS). Por este motivo novos protocolos
estão sendo desenvolvidos para suportar as redes Metro Ethernet com segurança e
2.10 Conclusão
27
muitos provedores de serviços já estão desenvolvendo ou pesquisando o seu uso, tanto
da rede Metro Ethernet quanto seus protocolos.
28
Referências
BERNERS-LEE, T. Hypertext Transfer Protocol – HTTP/1.0. IETF, maio 1996. RFC
1945. (Request for Comments, 1945). Disponı́vel em: <http://www.ietf.org/rfc/rfc1945.txt>.
COMER, D. E. Internetworking with TCP/IP, Priciples, Protocols and Architecture.
5. ed. Upper Saddle River, NJ: Pearson Prentice Hall, 2006. 487-497 p.
DIERKS, T. The TLS Protocol Version 1.0. IETF, jan. 1999. RFC 2246. (Request for
Comments, 2246). Disponı́vel em: <http://www.ietf.org/rfc/rfc2246.txt>.
DIERKS, T. The Transport Layer Security (TLS) Protocol Version 1.1. IETF, abr.
2006. RFC 4346. (Request for Comments, 4346). Disponı́vel em: <http://www.ietf.org/rfc/rfc4346.txt>.
FIELDING, R. Hypertext Transfer Protocol – HTTP/1.1. IETF, jun. 1999. RFC 2616.
(Request for Comments, 2616). Disponı́vel em: <http://www.ietf.org/rfc/rfc2616.txt>.
FRAULOD, D. M.; PIACENTINI, E. J. Metro ethernet. Pontı́fica Universidade
Católica do Paraná. Nov 2006. Disponı́vel em: <http://www.ppgia.pucpr.br/˜jamhour/Download/pub/Mestrado/Metro%20Ethernet.pdf>.
RESCORLA, E. HTTP Over TLS. IETF, maio 2000. RFC 2818. (Request for
Comments, 2818). Disponı́vel em: <http://www.ietf.org/rfc/rfc2818.txt>.