CENTRO DE CIÊNCIAS EXATAS
DEPARTAMENTO DE COMPUTAÇÃO
REDES DE COMPUTADORES
HTTP
Metro Ethernet
André Ricardo Gonçalves
Daniel César Romano Luvizotto
Heber A. A. do Nascimento
Luiz Gustavo de Andrade dos Santos
Prof. Dr. Mário Lemes Proença Júnior
LONDRINA - PR
2007
Sumário
1 Hypertext Transfer Protocol
p. 4
1.1
Introduçã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
Requisição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
p. 9
1.6.1
Métodos Seguros e Idempotentes . . . . . . . . . . . . . . . p. 10
1.6.2
Definição dos Métodos de Requisiçã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
Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 16
2 Metro Ethernet
p. 17
2.1
Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 17
2.2
Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 18
2.3
Serviços Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 19
2.3.1
Parâmetro de Tráfego (Bandwidth Profile) . . . . . . . . . . p. 20
2.4
Identificadores de Classes de Serviços (CoS) . . . . . . . . . . . . . p. 22
2.5
Carrier Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 22
2.6
Aspectos Bá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 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 26
Referências
p. 28
4
1
Hypertext Transfer Protocol
1.1
Introdução
A Internet é basicamente constituı́da por milhões de web pages, as conhecidas páginas de internet, que podem ser publicadas e acessadas de qualquer parte do mundo.
Essas páginas podem conter textos, imagens, filmes, sons, entre outros, que em conjunto com uma linguagem de marcação denominada HyperText Markup Language
(HTML), formam um página. As páginas são requisitadas por meio de um navegador (browser) que o usuário utiliza para solicitar e posteriormente apresentar a página
solicitada, do outro lado está o servidor que contém a página, ele é quem recebe a
solicitação envia a página que será interpretada pelo navegador, mostrando então a página ao usuário. A partir deste contexto o HyperText Transfer Protocol (HTTP) vêm
com o intuito de definir as regras de requisição/resposta e como deve ser transmitidos
esses dados.
1.2
Uniform Resource Locator
Para identificar cada página (recurso) na internet é atribuı́do a ela um nome, o
chamado URL (Uniform Resource Locators), que é utilizado com um esquema para
acessar um item, o URL é um subconjunto da URI (Uniform Resource Identifiers). Este
esquema define todos os atributos necessários para acessar aquela página na internet.
Abaixo é mostrado um exemplo de um esquema:
1.3 HTTP
5
http:
// hostname [: port] / path [:parameters][?query]
A parte em itálico denota o item a ser fornecido, e as partes entre colchetes “[...]”
denotam itens opcionais.
http: identifica o protocolo que esta utilizando;
hostname: é o nome do domı́nio ou o IP do servidor que contém o item solicitado;
port: é utilizado caso o servidor não utilize a porta padrão 80;
path: é o caminho que identifica o recurso no servidor;
parameters: são algum parametros adicionais fornecidos pelo cliente;
? query: é uma string opcional informando que o cliente está ouvindo uma questão.
Existem outras duas definições sobre a URL que são a URL Absoluta e Relativa.
URL absoluta é a especificação completa, exemplo
http://www.uol.com.br/esportes/formula1
e a URL relativa é a forma que omite o endereço do servidor, somente usado quando
o servidor é implicitamente conhecido.
1.3
HTTP
O HyperText Transfer Protocol que a partir daqui chamaremos de HTTP é um
protocolo da camada de aplicação do modelo OSI que é responsável por definir as
regras de emissão e recebimento de dados pela World Wide Web. A utilização do
protocolo é definida pela string http: na URL.
Segundo (COMER, 2006) o intuito original era de prover uma maneira de publicar
e resgatar pá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 é classificado como um protocolo orientado a conexão, pois necessita
1.4 Caracterı́sticas do protocolo
6
estabelecer uma conexã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) é geralmente utilizado e usa como padrã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 explosão da internet foi necessitando o envio não somente de
textos, mas també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 versão o protocolo passou a enviar mensagens no mesmo formato que
era utilizado para envio de e-mail e também da Multipurpose Internet Mail Extensions
(MIME). Segundo (BERNERS-LEE, 1996) o HTTP/1.0 utiliza muitas das construções
definidas pelo MIME, as poucas diferenças estavam ligadas a questão da otimização da
performance sobre as conexões binárias, para fornecer maior liberdade para os novos
tipos de mı́dias.
A versão utilizada atualmente é o HTTP/1.1 que foi apresentado em 1999 por
meio da RFC 2616 por (FIELDING, 1999). Esta versão do protocolo implementa alguns
outros recursos não suportados pela até então atual versão, segundo (FIELDING, 1999)
os procotolo HTTP1.0 não era suficiente para considerar os efeitos dos proxys, cache,
conexões persistentes e hosts virtuais. O HTTP também é utilizado como um protocolo
genérico para comunicação entre os agentes utilizadores e proxies/gateways para outros
sistemas, incluindo aqueles suportados pelo SMTP, NNTP, FTP, Gopher e WAIS,
permitindo o acesso à recursos disponı́veis em aplicações diversas (FIELDING, 1999).
As requisições são feitas a partir de métodos, que serão discutidos na secção 1.6.
Os métodos vão identificar que tipo de requisição o cliente esta realizando ao servidor.
E a resposta do servidor em relação à requisição é apresentado na seção 1.7.
1.4
Caracterı́sticas do protocolo
Algumas das principais caracterı́sticas da versão atual do HTTP (HTTP/1.1) são
apresentadas por (COMER, 2006) as quais são descritas abaixo:
1.4 Caracterı́sticas do protocolo
7
Nı́vel de Aplicação O protocolo HTTP trabalha no nı́vel de aplicação do modelo
OSI, sendo assim ele utiliza um protocolo de transporte orientado á conexão
como o TCP.
Requisição/Resposta Considerando a conexão já estabelecida, um cliente solicita
uma requisição HTTP para o um servidor que envia uma resposta a esta requisição.
Sem preservação de estado As requisições são independentes. Um servidor não
mantém as informações das requisições realizadas anteriormente.
Transferência Bi-direcional A transferência de dados é realizada de uma forma bidirecional, ou seja, tanto podem ser enviados dados do servidor para cliente,
exemplo o envio de uma página para o cliente, como do cliente para o servidor,
exemplo o envio de dados de um formulário.
Capacidade de Negociação O HTTP permite ao servidor e cliente a negociação de
detalhes como o conjunto de caracteres que serão utilizados durante a transferência. O emissor pode especificar suas capacidades oferecidas e o receptor as
suas capacidades aceitáveis.
Suporte à cache Para melhorar o tempo de resposta, o navegador armazena uma
cópia de todas as páginas recebidas. Caso o cliente solicitar uma página já
acessada anteriormente, o HTTP permite o navegador perguntar ao servidor se
a página foi alterada desde que a cópia foi armazenada.
Suporte à intermediários O HTTP permite as máquinas que estão entre o servidor
e o cliente, armazenar uma cópia das páginas que passam por ela, como se fosse
um servidor proxy e responde a uma requisição do cliente à esta cache.
1.5 Como funciona
1.5
8
Como funciona
O protocolo HTTP é definido principalmente para determinar como será o processo de requisição e resposta do cliente e servidor respectivamente. Entende-se por
requisição o ato de um cliente solicitar dados, uma página por exemplo, de um servidor
e por resposta entende-se como o retorno do servidor a esta solicitação.
A RFC 2616 (FIELDING, 1999) apresenta o processo de transmissão de dados utilizando o HTTP, inicialmente o cliente estabelece uma conexão com o servidor, após
estabelecida a conexão o cliente envia uma requisição em forma de método de requisição, o identificador do servidor (o Uniform Resource Identifier, URI), a versão do
protocolo que está sendo utilizada, seguido pela mensagem a ser enviada para o servidor. Após o recebimento desta requisição o servidor envia uma resposta que contém
uma linha de status, que inclui a versão do protocolo e o status-line que é um código
de retorno e a mensagem que contém informações sobre o servidor.
Até a versão HTTP/1.0, após este procedimento a conexão era encerrada, na
versão atual, HTTP/1.1, foi implementada o conceito de conexão persistente, que
mantém a conexão estabelecida, encerrando-a caso uma requisição incluir em seu
cabeçalho uma operação de fechamento de conexão, outra maneira é se a conexão
ficar ociosa por um determinado perı́odo de tempo.
A figura 1 apresenta o esquema de requisição/resposta definido pelo HTTP.
Figura 1: Esquema do funcionamento do procedimento requisição/resposta.
1.6 Requisição
1.6
9
Requisição
Para que um programa cliente (navegador) possa acessar uma página na internet,
ele solicita ao servidor uma cópia da mesma para apresentá-la na tela. Esta solicitação
é feita por meio de requisições, que são cabeçalhos que vão informar ao servidor qual
página ele deseja e algumas de suas caracterı́sticas.
Uma requisição é composta básicamente por 4 partes:
1. o método de definição da ação a ser realizada pelo servidor,
2. a URI que define o endereço do recurso que deve ser realizado a ação,
3. a versão do HTTP que utilizado (1.0 ou 1.1),
4. informações adicionais sobre o recurso e sobre o cliente.
Os métodos de definição da ação são discutidos na seção 1.6.2. A URI utilizada
pelo HTTP é a URL que define a localização do servidor e do caminho do recurso no
servidor, a URL foi apresentada na seção 1.2. Abaixo é apresentado um exemplo de
uma requisiçã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 é uma requisição que solicita uma cópia da página que está na
URL relativa
/internet/index.html
, a versão do HTTP utilizada é a HTTP/1.0 e abaixo
algumas informações sobre o cliente, como o browser utilizado (Mozilla), o sistema
operacional utilizado (Windows NT), além de outras informações.
1.6 Requisição
1.6.1
10
Métodos Seguros e Idempotentes
A RFC 2616 (FIELDING, 1999) apresenta a definição de métodos seguros e idempotentes. Essas definições apresentam algumas caracterı́sticas dos métodos de requisição.
Um método seguro não deve ser utilizado para realizar mudanças nos dados contidos no servidor. Alguns exemplos de métodos seguros são os métodos GET e HEAD
que serão apresentados na seção 1.6.2. Um método é dito ser idempotente se o resultado de múltiplas requisições de um mesmo recurso for o mesmo resultado de uma
única requisição a este mesmo recurso. Alguns métodos que possuem esta caracterı́stica são GET, HEAD, PUT e DELETE.
1.6.2
Definição dos Métodos de Requisição
Abaixo serão apresentados os principais métodos de requisição presentes na versão
atual do protocolo, a HTTP/1.1, segundo a RFC 2616 (FIELDING, 1999).
GET Este solicita a recuperação de um determinado recurso. É o método mais utilizado, é um método não seguro, assim não pode ser utilizado para atualizar dados
em um servidor por exemplo e também é um método idempotente.
HEAD Este método é idêntico ao método GET, a exceção é que o servidor não retorna
o recurso, ele apenas retorna as informações do recurso.
POST É utilizado para requisitar que o servidor de origem utilize as informações
presentes no corpo da mensagem para criar um novo recurso subordinado ao
recurso especificado na URI. É responsável também em realizar processamento
que não são diretamente relacionadas ao recurso.
PUT É utilizado para atualizar um recurso especificado. Caso o recurso não exista,
um novo recurso é criado e o código de retorno 201 (Created) é emitido pelo
servidor indicando a ação executada. A principal diferença entre POST e o PUT
1.7 Resposta do Servidor
11
é forma que cada um interpreta o recurso especificado na URI, no caso do POST
a URI identifica o recurso que manipulará o recurso enviado, este recurso pode
ser um validador, um gateway pra outro protocolo e o PUT apenas identifica o
recurso incluido na requisição.
DELETE Utilizado para remover um recurso especificado pela URI. Caso não exista
nenhum recurso o servidor deve retornar o código de status 204 (Not Found)
informando que este recurso não existe.
OPTIONS Este método é utilizado para retornar informações sobre as opções da
comunicação, como os requerimentos associados a um recurso, as capacidades
do servidor, sem implicar em uma ação ou recuperação do recurso.
TRACE Utilizado para ecoar a requisição recebida, para o cliente saber o que os
servidores intermediários estão adicionando e/ou alterando na requisição.
CONNECT É usado com um proxy para que possa ser realizado um túnel, exemplo
para estabelecer uma conexão segura.
1.7
Resposta do Servidor
Quando o servidor recebe uma requisição de um cliente ele a analisa e tenta
executa-lá, após esta tentativa ele retorna uma reposta para o cliente informando
qual foi o resultado da ação. A resposta é um cabeçalho basicamente divido em três
partes:
• o código do status, que indicará ao cliente o resultado da execução,
• descrição da informação sobre o recurso solicitado,
• o recurso solicitado, um exemplo o código HTML de uma página.
Abaixo é apresentado um exemplo de uma resposta enviada pelo servidor após a
execução de uma requisição, esta requisição foi exemplificada na seçã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 código 200 identifica que a requisição foi executada com sucesso
e que a informação será retornada, nas linhas seguintes algumas caracterı́sticas do
servidor e do recurso solicitado. Na segunda linha a data da resposta, na terceira há
informações sobre o servidor e sua versão, na linha quatro o tipo do recurso solicitado
(um arquivo html), na quinta linha a data da última alteração do arquivo solicitado e
por fim o tamanho do documento que está sendo retornado.
Segundo (FIELDING, 1999) o código de status é um número de 3 dı́gitos, sendo que
o primeiro dı́gito corresponde a classe de respostas que o código pertence. As classes
definem uma curta descrição textual do código, e os dois últimos dı́gitos definem o
resultado mais detalhadamente. Há 5 classes distintas que são apresentadas abaixo:
1xx Informacional, a requisição foi recebida e o processo continua;
2xx Sucesso, a ação foi recebida com sucesso, compreendida e aceita;
3xx Redirecionamento, mais uma ação dever ser recebida em ordem para completar a
requisição;
4xx Erro no cliente, a requisição contém um erro de sintaxe ou não pôde ser completada;
5xx Erro no servidor, o servidor falhou em completar uma requisição aparentemente
válida.
1.7 Resposta do Servidor
13
Os valores dos principais códigos de status definido pelo HTTP/1.1 estão definidos
abaixo, a lista completa de todos os códigos de status suportados pelo HTTP/1.1 pode
ser vista em (FIELDING, 1999).
200 OK A requisição foi executada com sucesso.
201 Created A requisição foi completada e resultado em um novo foi criado.
202 Accepted A requisição foi aceita para processamento, mas o processamento nã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 não foi alterado.
401 Unauthorized A URI especificada exige autenticação do cliente. O cliente pode
tentar fazer novas requisições.
403 Forbidden O servidor entende a requisição, mas se recusa em atendê-la. O
cliente não deve tentar fazer uma nova requisição.
404 Not Found O servidor não encontrou nenhuma URI correspondente.
405 Method Not Allowed O método especificado na requisição não permitido para
o recurso indentificado pela URI. A resposta deve incluir um cabeçalho Allow
com uma lista dos métodos aceitos para aquele recurso.
410 Gone O recurso solicitado está indisponı́vel mas seu endereço atual não é conhecido.
500 Internal Server Error O servidor não foi capaz de concluir a requisição devido
a um erro inesperado.
502 Bad Gateway O servidor, enquanto agindo como proxy ou gateway, recebeu
uma resposta inválida do servidor upstream a que fez uma requisição.
1.8 HTTPS
14
503 Service Unavailable O servidor não é capaz de processar a requisição pois está
temporariamente indisponı́vel.
1.8
HTTPS
Inicialmente o HTTP foi criado para definir um simples esquema de requisição/resposta
que era suficiente até então. Quando começaram a surgir aplicações mais complexas, como vendas pela internet, foram surgindo necessidades de atribuir segurança a
este esquema, a partir disto foi apresentado o HyperText Transfer Protocol Security
(HTTPS), que nada mais é 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 não é um protocolo separado, mas sim uma referência a uma combinação de dois protocolos, o HTTP sobre um protocolo de segurança. A string https:
no inı́cio da URL indica que se trata de um esquema de comunicação de dados segura.
Na seção 1.8.1 serão apresentados os protocolos SSL e TSL e na seção 1.8.2 como
é usado o HTTP sobre o TLS.
1.8.1
SSL e TLS
O protocolos SSL e TLS são protocolos que proveêm comunicaçã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, após
a autenticação os lados escolhem um algoritmo de encriptação de dados suportado por
ambos os lados. Finalmente o SSL permite que os dois lados estabeleçam um conexão
criptografada.
Definido inicialmente na versão 1.0 por meio da RFC 2246 por (DIERKS, 1999) em
1.8 HTTPS
15
1999, atualmente na versão o TLS/1.1 definido pela RFC 4346 por (DIERKS, 2006) o
protocolo TLS é o sucessor do SSL, que permite aplicações cliente/servidor se comunicarem de maneira que previne o eavesdropping (escuta), tampering (adulteração) e
message forgery (falsificação de mensagem).
1.8.2
HTTP sobre TLS
O HTTP sobre TLS é 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 conexão
segura, a porta padrão é 443 e é adicionada uma camada de encriptação/autenticação
entre HTTP e o TCP, já 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 conexão é inicializada quando o cliente envia um TLS ClientHello para iniciar o
processo de verificação da autenticidade handshake, após a autenticação o cliente pode
1.9 Conclusão
16
então enviar a primeira requisição HTTP. Todos os dados HTTP devem ser enviados
como se fossem dados de aplicação TLS.
Para o fechamento da conexão o TLS deve iniciar uma troca de alertas de fechamento, antes do real fechamento da conexão. O TLS também pode, depois de
enviadas alertas de fechamento, fechar a conexã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 conexão sem
receber nenhum alerta.
1.9
Conclusão
O HTTP está atendendo bem até agora as necessidades da web, mesmo com seu
rápido crescimento, mas um projeto está sendo desenvolvido paralelamente, o protocolo
chamado HTTP-NG (HTTP New Generation), que está sendo desenvolvido a partir
do zero, mas utilizando a experiência que foi obtida até 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
Introdução
O mercado de redes cada vez mais busca por soluções com custo baixo e que
garantem qualidade de serviço. Com isso aumenta-se a interconexão entre as redes
corporativas distribuı́das geograficamente e com a Internet. Com isso Metro Ethernet
tem sido bastante visada, pois tem fácil interconexão, administração, boa granularidade
e é claro baixo custo.
Com o aparecimento de novos protocolos, visando aumentar a qualidade de serviço,
seguranç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 tráfego corporativo passa por
interfaces Ethernet, isto se deve por causa da facilidade de execução e o preço. Mas
isso não ocorre nas redes MAN e WAN, que usam serviços em ATM, Frame Relay e
linhas linhas privativas, todos um razoavelmente mais complicados e mais caros.
A definição de uma rede Metro Ethernet (Metropolitan Ethrnet Network) é uma
rede que interconecta LANs separadas geograficamente, e também interconectando-se
a uma rede WAN ou backbone operados através do provedor de serviços. Ilustrando
na figura 3.
As principais vantagens da utilização de uma rede Metro Ethernet estã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;
• Transmissão baseada em pacotes que comparada com transmissão em circuitos
é significativamente melhor;
• Permite a interconexão direta com as redes LAN (Interoperabilidade), não necessitando de protocolos, pois quase todas as redes Lan são baseadas em Ethernet.
2.2
Arquitetura
É utilizado um modelo genérico para descrever os componentes de externos e
internos da rede Metro Ethenet.
O fluxo Ethernet flow mostrado na figura 4 mostra o trá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 à rede é 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 Serviços Ethernet
19
Figura 4: Arquitetura da rede Metro Ethernet
Um conceito muito importante em redes Metro Ethernet é a EVC conexão Ethernet
virtual (it Ethernet Virtual Connection), pois associa 2 ou mais UNIs, com o objetivo
de passar fluxo entre dois ou mais clientes, além de ajudar a visulaizar o conceito de
conexõ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
Serviços Ethernet
Os três principais fatores que influenciam na escolha de serviços Ethernet são:
1. Facilidade de uso através de uma interface padrão e bem conhecida;
2. Baixo custo por causa da produção dos equipamentos em larga escala;
3. Flexibilidade: modificação da banda em minutos ao contrário de dias e semanas
em outras redes.
4. Pode-se realizar diversos tipos de serviços utilizando a mesma interface.
O modelo básico para o serviços Ethernet é apresentado na 5, o equipamento do
cliente (CE = Customer Equipment) se interconecta à rede por meio da UNI através
de uma interface Ethernet padrão 10Mbps, 100Mbps, 1Gbps ou 10Gbps.
2.3 Serviços Ethernet
20
Figura 5: Modelo Básico
A figura 6 mostra os dois serviços Ethernet reconhecidos pelo Metro Ethernet
Forum MEF 1 , que consiste em uma aliança global de indústrias na área de comunicação
de dados, que possui como intuito desenvolver especificações técnicas na área de redes
Metro, e um resumo dos atributos e parâmetros.
2.3.1
Parâmetro de Tráfego (Bandwidth Profile)
O Bandwidth Profile diz o limite da taxa média de quadros de serviços Ethernet
que podem entrar na rede do provedor de serviços através de uma UNI. O MEF tem
definido três atributos de ıBandwidth Profile:
Perfil por UNI aplicados a todos os serviç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 marcação (tag).
Cada um dos atributos possui 4 parâmetros de tráfegos:
1
www.metroethernetforum.org
2.3 Serviços Ethernet
21
Figura 6: Serviços Ethernet reconhecidos pelo MEF
1. Committed Information Rate (CIR): taxa média de desempenho de acordo com
desempenhos contratados (atraso, etc.) especificados por um SLA (Service Level
Agreement).
2. Committed Burst Size (CBS): define o número máximo de bytes permitidos por
quadros de serviços e são contados pelo CIR.
3. Excess Information Rate (EIR): taxa média excedente ao CIR, no qual o quadros
são entregues sem garantia.
4. Excess Burst Size (EBS): define o número máximo de bytes permitidos por quadros de serviços, e são contados pelo EIR.
Um meio eficiente de descrever se os quadros de serviços estão na média é através
do uso de cores, verde se estiver dentro do contrato SLA, amarelo não está de acordo,
mas não serão descartados imediatamente e vermelho que não está de acordo e serão
descartados imediatamente.
2.4 Identificadores de Classes de Serviços (CoS)
2.4
22
Identificadores de Classes de Serviços (CoS)
As redes Metro Ethernet necessitam oferecer várias classes de serviço (Cos) distintas, as quais são identificados através de:
• Porta fı́sica: apenas uma classe de serviço pode ser fornecida nesse caso;
• CE-VLAN CoS (802.1p): classe de serviço identificada pelas tags de VLAN do
cliente.
• DiffServ/IP TOS: neste caso o segundo byte do cabeçalho IP pode ser usado
para definir classes de serviço e que podem ser definidas até 8 classes.
2.5
Carrier Ethernet
O termo Carrier Ethernet significa oferecer serviços atravé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 são encontrados nas
tı́picas redes LAN (FRAULOD; PIACENTINI, 2006).
O Metro Ethernet Fórum (MEF) propõem cinco atributos que distinguem uma
rede Carrier de uma rede LAN. São elas:
QoS : garantir um bom desempenho do tráfego com qualidade similar ao das redes
tradicionais;
Confiabilidade : capaz de se recuperar de falhar com tempo abaixo de 50ms; proteção
de caminho fia-a-fim;
Escalabilidade : suportar mais de 100.000 clientes;
Gerencia de serviços : monitorar, diagnosticar e centralizar a gerencia de redes,
configuração rápida e fácil da rede;
Serviços Padronizados : serviços globais com equipamentos padronizados.
2.6 Aspectos Básicos de QoS
2.6
23
Aspectos Básicos de QoS
Obtém-se qualidade se serviço através de uma combinação de técnicas que objetiva
garantir nı́veis de confiabilidade referente às necessidades dos clientes. O cliente vê a
qualidade de serviços como uma especificação técnica e operacional de nı́vel de serviço
(FRAULOD; PIACENTINI, 2006).
O protocolo Ethernet possui como uma de suas caracterı́sticas, proverem a cada
usuário um acesso compartilhado e semelhante à rede, de maneira que ocorra uma
mı́nima implementação nos equipamentos. Nas redes LAN, isto não é novidade, o
tráfego entre departamentos é separado atravé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 tráfego dentro da rede é através da utilização de VLANs. No padrão
802.1Q é encontrada a definição do funcionamento de VLAN, que resumidamente pode
ser definido como a utilização de um identificador para cada VLAN, este método de
utilização de identificador já vem sendo muito utilizado, assim está seria uma maneira
natural para as redes Metro Ethernet proverem o isolamento de tráfego entre os diversos
clientes. Mas, a utilização da norma 802.1Q em redes Metro Ethernet esbarra no
problema da quantidade e administração dos VLAN-IDs. Não há como o operador de
serviços gerenciar e assegurar que cada cliente utilize identificar de VLAN (VLAN-ID)
diferente dentro da rede metropolitana. Outro problema é a quantidade máxima de
identificadores oferecidos que é de 4096, este número é uma quantia muito limitada
em relação às dimensões da rede metropolitana, alem do fato de limitar o cliente na
criação de suas pró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 é um mecanismo
muito simples, no qual uma VLAN é encapsulada dentro de outra VLAN conforme
2.7 Provider Bridge (PB) ou Q-in-Q
24
mostrado na 7. Este tunelamento permite uma completa separação do tráfego do
cliente. Assim o cliente conta com total liberdade de gerenciar suas C-VLANs. O
provedor tem à sua disposição até 4096 S-VLANs, suportando até 4k clientes/serviços.
Figura 7: Exemplo de tunelamento VLAN 34 dentro de uma VLAN 2
Conforme observado na 8 o formato cabeçalho do 802.1ad é bem parecido com
o do 802.1Q. A implementação da S-VLAN ocorre através da adição de quatro bytes
ao cabeçalho Ethernet após os campos de MAC de origem e destino, sã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 combinação dos três bits
de prioridade mais o bit DEI formam o conceito de PCP (Priority Code Point), que é
utilizado dentro da rede como parâmetro de descarte ou não dos pacotes.
Figura 8: Formato do frame 802.1Q
Pelo motivo de inserção ou remoção destes quatro bytes do cabeç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 serviços tem apenas 4096
S-VLANs a sua disposição, este é um nú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 é um padrão que é 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 são encapsulados por um novo cabeçalho, que possui um novo
MAC (B-MAC - Backbone MAC). Assim, os switches intermediários na rede Metro
Ethernet não precisam aprender todos os MACs de uma determinada S-VLAN, mas
somente os B-MAC que pertencem à rede do provedor. Então o funcionamento deste
novo padrão seria desta forma: acrescenta-se o novo cabeçalho os pacotes oriundos
de uma S-VLAN ao entrarem no backbone e na outra ponta, assim quando deixarem
o backbone, o cabeçalho acrescido é removido.
O uso do padrão MinM traz algumas vantagens como pro exemplo: simplifica
a operação, ou seja, o provedor pode planejar sua rede sem ter a preocupação de
conflitos relacionados a identificadores de VLANs ou de endereços MAC de seus clientes
(FRAULOD; PIACENTINI, 2006).
2.9
Provider Backbone Transport (PBT)
Segundo (FRAULOD; PIACENTINI, 2006) o conceito de PBT é similar ao PBB, à
diferença é que o PBT propicia tú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 marcação de VLAN (VID - 12 bits) e o endereço MAC (48 bits).
2.10 Conclusão
26
Assim quando um endereço não é 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 informação a sua tabela de encaminhamento.
A idéia principal do PBT é justamente desabilitar a funcionalidade do Ethernet
relacionada ao broadcast, quando o destino não é conhecido. Agora no PBT se usa
o VID em conjunto com o MAC para resultar em um caminho pré-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 proteção. Assim se ocorrer
alguma falha no caminho principal o roteador começa a passar os pacotes pelo caminho
de proteção. A proposta de monitoramento do estado da conexão é utilizar o protocolo
802.1ag (FRAULOD; PIACENTINI, 2006). Uma sessão de conectividade (Connectivity
Check - CC) é estabelecida em ambos os caminhos. Ambas as pontas do enlace
enviam mensagens CC em intervalos regulares de 10ms (configurável) e ouvem as
mensagens que chegam da outra ponta. Se três mensagens CC não chegarem, o
enlace é considerado com falha e o caminho de proteção é ativado.
Assim, mecanismos de proteção com tempos inferiores a 50ms (padrão do SDH/SONET)
são possı́veis. O uso do PBT trás benefı́cios como: a rede torna-se mais robusta e
isolada de tempestades de broadcast, os roteadores do provedor não precisam aprender
endereços MAC dos clientes, permitindo assim, uma redução dos custos de equipamentos.
2.10
Conclusão
Hoje em dia os mais serviços requeridos pela área corporativa e que tem crescido
são as interconexões das redes LAN geograficamente distribuı́das e a conectividade com
a Internet. Assim, as redes Metro Ethernet tem se mostrado uma solução, devido as
grandes exigências de Qualidade de Serviço (QoS). Por este motivo novos protocolos
estão sendo desenvolvidos para suportar as redes Metro Ethernet com segurança e
2.10 Conclusão
27
muitos provedores de serviços já estão desenvolvendo ou pesquisando o seu uso, tanto
da rede Metro Ethernet quanto seus protocolos.
28
Referê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
Católica do Paraná. 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>.