protocolos multimídia na internetadriano/aulas/...unesp - ibilce - são josé do rio preto...

UNESP - IBILCE - São José do Rio Preto Protocolos Multimídia na Internet

Prof. Dr. Adriano Mauro Cansian 1

unesp - IBILCE - SJRP

Protocolos Multimídia na Internet

Parte 3 – QoS em Redes IP V4

Tópicos em Sistemas de Computação

Prof. Dr. Adriano Mauro Cansian [email protected]


Oferecendo QoS em Redes IP

q  Os grupos do IETF desenvolveram propostas para fornecer melhor controle de QoS em redes IP. •  Buscando superar o serviço de melhor esforço, e prover alguma

garantia de QoS com a tecnologia atual.

q  Desenvolvimentos incluem Serviços Diferenciados, e Serviços Integrados.

Enlace de 1,5 Mbps

Fila de interface de saída de R1




Serviços integrados X diferenciados

q Serviços Integrados •  Baseado em um protocolo de sinalização: RSVP

•  Permite efetuar reserva de recursos fim-a-fim para garantir a QoS de um dado fluxo, no momento em que o fluxo é criado.

q Serviços Diferenciados •  Não utiliza protocolo de sinalização.

•  Utiliza um esquema de priorização de recursos baseado em SLA (Service Level Agreement) previamente configurados.


Níveis de QoS

Melhor Esforço

Serviços Diferenciados

Serviços Integrados

Reserva de Recursos Fim-a-Fim Protocolo de Sinalização

Priorização de Recursos de Acordo com SLAs pré-

estabelecidos

O primeiro pacote a chegar é o primeiro a

ser atendido.




Serviços Integrados sobre IP Comparação com outras tecnologias

q  Frame Relay •  Opera apenas com priorização. •  Não tem protocolo de sinalização.

q  ATM •  Opera com priorização e reserva de recursos. •  Possui protocolo de sinalização próprio.

q  IP •  Opera com priorização ou reserva de recursos. •  Utiliza o protocolo de sinalização RSVP. •  Serviços integrados em IP podem utilizar recursos de QoS

disponíveis na camada de enlace. •  Integrated Services over Specific Lower Layers


Os 4 princípios

Existem 4 princípios para garantias de QoS q 1. Marcação de pacotes.

•  Permite o roteador distinguir entre diferentes classes.

q 2. Isolamento (ou proteção). •  Fornecer proteção (isolamento) para uma classe em relação às demais.

q 3. Eficiência no uso dos recursos. •  Ainda que se forneça isolamento, é necessário usar os recursos

da forma mais eficiente possível.

q 4. Admissão de chamada. •  Se não puder atender a exigência, não desperdiça banda

fornecendo algo insuficiente.




Garantias de QoS – 1. Marcação q  Considere uma aplicação de telefonia a 1 Mbps e uma

aplicação FTP, ambos compartilhando um enlace de 1.5 Mbps. •  Rajadas de tráfego FTP podem congestionar o roteador, e fazer

com que pacotes de áudio sejam perdidos. •  Deseja-se dar prioridade ao áudio sobre o FTP.

q  PRINCÍPIO 1: Marcação dos pacotes é necessária para o roteador distinguir entre diferentes classes. •  Assim como novas regras de roteamento para tratar os pacotes

de forma diferenciada.


Garantias de QoS – 2. Isolamento q  Aplicações “mal-comportadas” – exemplo: áudio envia pacotes

numa taxa superior a 1 Mbps anteriormente assumida.

q  PRINCÍPIO 2: Fornecer proteção (isolamento) para uma classe em relação às demais.

q  Exige mecanismos de policiamento para assegurar que as fontes aderem aos seus requisitos de banda passante.

q  Marcação e policiamento precisam ser feitos nas bordas da rede.




q  Alternativa à marcação e isolamento: alocar uma porção da taxa de transmissão a cada fluxo de aplicação. •  Pode produzir um uso ineficiente da banda se um dos fluxos

não usa toda a sua alocação.

q  PRINCÍPIO 3: Ainda que se forneça isolamento, é necessário usar os recursos da forma mais eficiente possível.

Garantias de QoS – 3. Eficiência

marcação de pacotes

enlace lógico de 1 Mbps

enlace lógico de 0,5 Mbps


q  Não deve ser aceito tráfego além da capacidade do enlace.

q PRINCÍPIO 4: É necessário um processo de admissão de chamada.

q  A aplicação declara a necessidade do seu fluxo, e a rede pode bloquear a chamada se a necessidade não pode ser satisfeita.

q  Se não puder atender a exigência, não desperdiça banda fornecendo algo insuficiente.

Garantias de QoS – 4. Chamada




Resumo:

QoS para aplicações em redes C

lass

ifica

ção

de p

acot

es

Isol

amen

to: p

rogr

amaç

ão

e po

licia

men

to

Alta

efic

iênc

ia

de u

tiliz

ação

Adm

issã

o de

cha

mad

as


IETF - Internet Engineering Task Force

q  Grupos de Trabalho (relacionados a QoS) •  Serviços Integrados (IntServ)

–  http://www.ietf.org/html.charters/intserv-charter.html

•  Serviços Diferenciados (DiffServ) –  http://www.ietf.org/html.charters/diffserv-charter.html

•  MPLS (Multiprotocol Label Switching) –  http://www.ietf.org/html.charters/mpls-charter.html

•  Engenharia de Tráfego –  http://www.ietf.org/html.charters/tewg-charter.html

•  Roteamento baseado em QoS (encerrado) –  http://www.ietf.org/html.charters/qosr-charter.html




Serviços Integrados


Serviços Integrados (IntServ) q  IntServ = RFC 1633 q Cada nó entre fonte e destino mantém

informações de estado e encaminhamento para garantir QoS.




Serviços integrados

q Roteadores necessitam manter informação de estado, com um registro dos recursos alocados, e respondendo a novos pedidos de conexões de acordo com o estado da rede.


Arquitetura IntServ

q Duas características-chave: •  Recursos reservados.

•  Os roteadores necessitam saber qual quantidade de seus recursos já está reservada para as sessões em andamento.

•  Estabelecimento de chamada. •  Reservar recursos em cada roteador em seu

trajeto fonte-destino, para garantir que suas exigências fim-a-fim sejam atendidas.




Admissão de chamadas (1)

q  A sessão deve primeiramente declarar seus requisitos, e caracterizar o tráfego que ela enviará através da rede.

q  Usa 2 parâmetros:

q  R-spec → define a QoS sendo solicitada para uma sessão [“R” de Reserve].

q  T-spec → define as características de tráfego que o remetente enviará à rede, ou que o destinatário irá receber da rede [“T” de Traffic].

q  Definidas parcialmente no RFC-2210 e RFC-2215


Admissão de chamadas (2)

q  Roteadores podem ou não aceitar as chamadas com base nas suas R-spec e T-spec, e com base nos recursos correntemente alocados nos roteadores para outras sessões.

1. Pedido: especifica - Tráfego (T-spec) - Garantia (R-spec)

2. Elemento considera - recursos não reservados - recursos solicitados

3. Resposta: o pedido pode ou não ser atendido




Sinalização para admissão de chamadas

q É necessário um protocolo de sinalização. •  Para transportar parâmetros R-spec e T-spec

aos roteadores.

q Protocolo RSVP é o melhor candidato para este papel de protocolo de sinalização.

q RSVP é definido no RFC-2210. •  Será visto adiante…


O Modelo de Referência

q Escalonador de pacotes. •  Gerencia o encaminhamento dos fluxos •  Usa políticas de filas

q Classificador. •  Mapeia pacotes para classes (fluxos)

q Controle de admissão. •  Decide se existem recursos suficientes para

permitir novas reservas

q Protocolo de reserva de recursos (RSVP).




Classes de serviços integrados (1)

q Foram definidas 2 classes de serviços integrados:

•  Classe 1 - QoS Garantido.

•  Classe 2 - Carga Controlada.


Classes de serviços integrados (2)

q QoS Garantido: classe fornece controles estritos dos atrasos de filas nos roteadores. •  Projetada para aplicações de tempo real críticas,

as quais são muito sensíveis ao jitter.

q Carga Controlada: classe fornece um QoS que se aproxima do comportamento de um roteador não sobrecarregado. •  Projetada para as aplicações IP que se

comportam bem quando a rede não está sobrecarregada.




1. O servico de QoS garantido q  RFC 2212 q  O serviço oferece:

•  Nível de largura de banda assegurado. •  Limite rígido (provado) de atraso fim-a-fim. •  Proteção contra perda de pacotes.

q  Destinado a aplicações com requisitos rígidos de tempo real, como aplicações intolerantes. •  Todos os roteadores no caminho devem suportar o serviço

para que ele seja possível fim a fim.

q  Usa balde de fichas para controlar taxa máxima. •  Exercício: Estudar protocolo de Token Bucket.


2. O serviço de carga controlada q  RFC 2211 q  Semelhante ao serviço de melhor esforço em uma

rede levemente carregada. q  Não oferece garantias rígidas

•  Alto percentual dos pacotes chegarão ao receptor. •  Atraso da grande maioria dos pacotes não deve exceder o

atraso mínimo.

q  Maior parte das aplicações multimídia se enquadram nessa categoria

q  Também usa balde de fichas para controlar taxa. •  Exercício: Estudar protocolo de Token Bucket.




RSVP - Resource reSerVation Protocol

q Primeiro padrão para garantir QoS em redes heterogêneas.

q O RSVP é um protocolo de sinalização que têm a capacidade de requisitar um determinado nível de QoS através da rede. •  O RSVP carrega o pedido, passando por cada

nó que a rede usa para transportar o fluxo de mídia.


RSVP

q Padronizado pela RFC2205,Setembro de 1997. •  Complementada pelas RFCs 2206, 2207, 2210,

2380, 2745, 2747, 2961.

q Protocolo de controle, similar ao ICMP ou IGMP. •  Permite que os nós da rede recebem

informações para caracterizar fluxos de dados, definir caminhos e características de QoS para esses fluxos ao longo desses caminhos.




RSVP - Resource reSerVation Protocol (2)

q O RSVP opera em conjunção com os protocolos de roteamento. •  NÃO é um protocolo de roteamento!

q Também pressupõe algum tipo de política de escalonamento. •  Tipo WFQ - Weighted Fair Queing ou RED -

Random Early Detection. •  Política de escalonamento deve ser

implementada nos nós intermediários para permitir a reserva de recursos.



q  Resource Reservation Protocol - RFC 2205 q  Características:

•  Unicast e multicast •  Reservas simplex - unidirecionais •  Receptor solicita a reserva (receiver-initiated) •  “Estado leve” (tem que fazer refresh periodicamente)

q  Mensagens PATH e RESV •  RESV cria e mantém o estado da reserva em cada nó do

caminho até o remetente. •  PATH instala informações de roteamento reverso.

q  Tornou-se um protocolo “pesado”. q  Disponível em vários produtos comerciais.




Arquitetura do RSVP q As funções de implementação do QoS pelos

nós NÃO são de responsabilidade do RSVP. q Outros módulos são especificados na

arquitetura: •  Módulos de Decisão:

•  Controle de Admissão: verifica se existem recursos para o pedido.

•  Controle de Política: verifica se o usuário pode pedir os recursos.

•  Módulos de Controle de Tráfego: •  Classificador: determina a classe do pacote •  Escalonador: implementa o QoS


Arquitetura do RSVP

Host

Controle de Política

Controle de Admissão

Classificador Escalonador

dados

Roteador

dados

Dados

RSVP aplicação Processo

RSVP Processo

RSVP

Classificador Escalonador

Processo roteamento

RSVP

Controle de Política

RSVP





q  Processo RSVP comunica-se com os módulos locais de controle de admissão e controle de política. •  Para efetuar a reserva de recursos num roteador,

q  Controle de admissão → determina se o nó tem capacidade para fornecer a QoS requisitada.

q  Controle de política → determina se o usuário tem permissão administrativa para efetuar tal requisição.

q  O RSVP deve ser implementado nó a nó, portanto, enfrenta problemas de escalabilidade.


RSVP é Unidirecional

q  As reservas em RSVP são sempre unidirecionais. q  As reservas podem ser em unicast ou multicast. q  No RSVP o pedido de uma reserva sempre é

iniciado pelo receptor. •  Os direitos da reserva são debitados na conta do cliente.

Servidor

Cliente

REDE

1. Solicita serviço

2. Especifica os requisitos

3. Faz reserva




Mensagens RSVP

3. Fluxo de dados RSVP

2. Mensagem RESV

Receptor Transmissor

1. Mensagem PATH


Sessões RSVP

q Em RSVP, a política de QoS não é aplicada individualmente sobre cada pacote, mas sim em sessões.

q Uma sessão é definida como um fluxo de dados para um mesmo destino, utilizando um mesmo protocolo de transporte.

q Uma sessão é definida por três parâmetros: •  Endereço de destino •  Identificador de Protocolo (TCP ou UDP) •  Porta de destino (Opcional).




Sessões RSVP

q Podem ser de dois tipos:

Multicast (239.0.64.240),TCP,[dstport])

Unicast (168.100.64.5,TCP,5000)

IGMP Endereço Classe D

Os receptores precisam formar

um grupo multicast para poder receber

as mensagens.

Transmissor

Receptor

Receptor Transmissor


RSVP na Internet

q  Para que o RSVP possa ser implementado na Internet, utiliza-se técnicas de tunelamento para saltar os roteadores que não suportam RSVP.

Nuvem não RSVP

servidor cliente

O endereço de destino das mensagens PATH é do próximo roteador que suporta RSVP.




Problemas do RSVP

q No IPv4, o RSVP classifica os pacotes utilizando informações do protocolo de transporte (portas)

q  Isso causa problemas quando: •  Houver fragmentação.

•  Solução: As aplicações devem transmitir as informações com o mínimo MTU do caminho.

•  IPsec ou outras técnicas de tunelamento podem criptografar os pacotes:

•  Uma extensão do IPsec foi proposta para suportar RSVP.


Problemas IntServ e RSVP

q Problema: escalabilidade . q A quantidade de informação de estado

cresce proporcionalmente ao número de fluxos que um roteador tem que tratar. •  Há sinalização a cada nó (seja sistema final ou

roteador) para cada fluxo. •  Demandas enormes para os roteadores,

principalmente para aqueles de núcleo.




IntServ - problema de escalabilidade:

Muitos

fluxos


Desenvolvimento de Aplicações RSVP

q  Serviços integrados necessitam que as aplicações sejam escritas de maneira a usar o protocolo RSVP.

q  Já estão disponíveis API para desenvolver aplicações RSVP em várias plataformas:

q  Em Windows •  Winsock 2 QoS API

q  Em Java •  Várias implementações em universidades •  JQoSAPI: http://www-vs.informatik.uni-ulm.de/soft/

JavaQoS/ q  Em Linux

•  Suporta RSVP, mas API estão disponíveis para serviços diferenciados.




Serviços Integrados na Internet

q A abordagem de serviços integrados não é vista como apropriada para Internet.

q O RSVP é pouco escalável pois: •  Muitas mensagens trocadas para estabelecimento da

reserva. •  Os roteadores necessitam de manter informações de

caminho (operação em statefull)

q Serviços diferenciados são uma proposta alternativa do IETF para implementação de QoS em provedores e Backbones na Internet.


Differentiated Services - Diffserv Serviços diferenciados




Differentiated Services - Diffserv q  DiffServ: Planejado para resolver as dificuldades

apresentadas pela arquitetura com Intserv. •  Escalabilidade: manter informações de estado nos

roteadores em redes de alta velocidade é difícil, devido ao grande número de fluxos simultâneos.

•  Modelos de Serviços Flexíveis: Intserv tem apenas duas classes.

•  Deseja-se prover mais classes de serviços, com diferentes méritos qualitativos.

•  Deseja-se manter uma distinção “relativa” entre as classes (Platina, Ouro, Prata, …)

•  Sinalização mais Simples (que o RSVP): muitas aplicações e usuários podem desejar apenas especificar um serviço de forma mais qualitativa.


Serviços diferenciados

Abordagem: q Apenas funções simples no interior da rede,

e funções relativamente complexas nos roteadores de borda (ou nos hosts).

q Não define classes de serviço. •  Ao invés disso, fornece componentes

funcionais com os quais as classes de serviço podem ser construídas.




Funções de borda q  Executados num computador com funções de DS (serviços

diferenciados), ou no primeiro roteador com funções de DS. q  Classificação: o nó de borda marca os pacotes de acordo

com regras de classificação a serem especificadas (manualmente pelo administrador ou por algum protocolo de sinalização).

q  Condicionamento de Tráfego: o nó de borda pode atrasar e então enviar, ou pode descartar.

roteador de borda: classificação condicionamento roteador central:

envio


Funções do Núcleo Central

q  Envio ocorre de acordo com PHB - Per-Hop-Behavior (comportamento por salto) especificado para aquela classe em particular •  Este PHB baseia-se estritamente na marcação de classe. •  Nenhum outro campo do cabeçalho pode ser usado para

influenciar o PHB.

q  GRANDE VANTAGEM: Não há necessidade de manter informação de estado nos roteadores.




Serviços diferenciados (DiffServ)

q  QoS na Internet para agregações de fluxos. q  Resumindo:

•  Sem estado para cada fluxo de dados. •  Sem sinalização para cada nó.

q  DS-Field •  Pacotes são marcados para receber serviços diferenciados

nos “Domínios DS” •  Campo TOS do IPv4 ou Traffic Class do IPv6. •  Identifica o PHB (Per-Hop Behavior) •  Valores do DS-Field são chamados de

DSCP - DiffServ Code Point. (Como veremos em seguida…)


Classificação e condicionamento (1) q  Pacote é marcado no campo TOS (Type of Service

- TOS) no IPv4, e no campo Classe de Tráfego no IPv6.

q  6 bits usados para o Código de Serviços Diferenciados ou DSCP - Differentiated Service Code Point: •  DSCP determina qual o PHB que o pacote receberá.

q  2 bits são atualmente reservados para uso futuro.




Version IHL Type of service Total length

Identification

Time to live Protocol

Fragment offset

Header checksum

Source address

Destination address

Options (0 or more words)

D F

M F

32 Bits

TOS no IP


q  Pode ser desejável limitar a taxa de injeção de tráfego em alguma classe. •  Usuário declara o perfil de tráfego (por exemplo taxa e

tamanho das rajadas).

q  Tráfego é medido e ajustado se não estiver de acordo com o seu perfil.

Classificação e condicionamento (2)

pacotes classificador marcador ajuste

corte

enviar

descartar

medidor




Contratos e serviços

q SLA: Service Level Agreement •  Contrato comercial bilateral. •  Identifica perfil de tráfego

q Nível de Serviço: •  “tratamento global de um determinado

subconjunto do tráfego de um usuário dentro de um Domínio DS, ou fim a fim”.

q PHBs + regras de policiamento = vários serviços.


Domínios proporcionam serviços especificados no SLA aos seus clientes

SLA: Service Level Agreement

SLA SLA

SLA

SLA

SLA Domínio

Domínio Domínio

Fonte

Destino

Arquitetura de Serviços Diferenciados (Lógica)




Policiamento de tráfego nos roteadores de borda

Roteadores internos dão tratamento aos pacotes de acordo com o

PHB indicado no DSCP

Arquitetura de Serviços Diferenciados (Física)


Condicionamento de tráfego (1)

q Classificador: seleciona os pacotes dentro de um fluxo através do cabeçalho (BA e MF).

q Medidor: mede o fluxo para verificar se está de acordo com o perfil de tráfego contratado (SLA).

q Marcador: grava determinado padrão de bits no codepoint (DSCP).

q Suavizador (shapping): atrasa tráfego fora do perfil, para torná-lo dentro do perfil.




q Nem todos os quatro elementos precisam estar presentes em todos os nós de borda

Condicionamento de tráfego (2)

Pacotes

Classificador Marcador

Medidor

Suavizador/ Descartador

Condicionador


Envio PHB

q  PHB resulta num comportamento diferente (mensurável) para o desempenho do envio de pacotes.

q  PHB não especifica quais mecanismos usar para assegurar um comportamento do desempenho.

q  Exemplos: •  Classe A obtém x % da taxa de transmissão do enlace de

saída considerando intervalos de tempo de uma certa extensão.

•  Pacotes de classe A partem primeiro, antes dos pacotes de classe B.




Envio PHB PHBs que estão sendo estudados: q  Envio Acelerado / Expedited Forwarding - EF:

•  RFC 2598 •  Especifica que uma taxa de partida dos pacotes de uma

dada classe deve ser igual ou maior que uma taxa especificada (garante um enlace lógico com uma taxa mínima).

q  Envio Assegurado / Assured Forwarding - AF: •  RFC 2597 •  4 classes, cada uma garantida com um mínimo de taxa de

transmissão e armazenamento. •  Cada uma delas com três particionamentos para

preferência de descarte dos pacotes.


Problemas com os Serviços Diferenciados...

q AF e EF ainda não estão padronizados. •  Pesquisas em andamento.

q “Linhas dedicadas virtuais” e serviços “Olímpicos” (classificação em ouro-prata-bronze) estão sendo discutidos.

q Estuda-se o impacto de atravessar múltiplos sistemas autônomos e roteadores, os quais não estão preparados para operar com as funções de serviços diferenciados.




Exemplos de Serviços

q  Serviço Premium (PHB EF) •  emulação de linha dedicada a uma taxa de pico especificada

q  Serviço Olímpico (PHB AF) •  serviço “melhor” relativo a quem paga menos •  semelhante ao serviço assegurado, mas com três classes de

serviços: ouro, prata e bronze


Considerações finais sobre QoS




Comparação Intserv e Diffserv (1)

q  Existe sobreposição, mas muitos aspectos são ortogonais entre as abordagens

q  Resolvem problemas diferentes. q  Podem ser combinadas em um arquitetura

integrada para QoS na Internet. q  DiffServ e IntServ: oferecimento de garantias a

fluxos através da priorização de tráfego q  MPLS - Multiprotocol Label Switching: técnica de

encaminhamento, que possibilita a fixação de caminhos. •  Não será estudado neste curso. •  Consulte: http://www.mplsrc.com/mplsfaq.shtml


Comparação Intserv e Diffserv (2)

q QoSR - QoS Routing: •  Técnica de roteamento com QoS. •  Procura caminhos com as características de QoS

que os fluxos necessitam.

q Engenharia de Tráfego: não é uma técnica específica, mas um processo de gerenciar o tráfego na Internet.

q É possível utilizar uma combinação de técnicas DiffServ, RSVP, QoSR e MPLS para efetuar a engenharia de tráfego.




Propostas de Integração

q Drafts da IETF (ou resultados de pesquisas).

q QoSR em redes IntServ.

q Engenharia de tráfego com MPLS.

q QoSR para Engenharia de Tráfego.

q  Integração entre DiffServ e MPLS.

q Mapeamento entre DiffServ e IntServ.

q RSVP para distribuir rótulos em MPLS.

q RSVP para configurar rede DiffServ.


Resumo da arquitetura de QoS na Internet

Aplicação

Transporte

Rede

Interface de Rede

Aplicação

Transporte

Rede

Interface de Rede

API QoS

IEEE 802.1p, ATM Frame Relay

QoS fim a fim

IntServ/RSVP, DiffServ, MPLS, QoSR, TE

Aplicações com QoS

Rede sem fio




Fornecedores


Cisco - www.cisco.com

q  Líder no mercado de roteadores q  Conceito de Tag Switching

•  Comutação de rótulos, influenciou padrão MPLS

q  Cisco IOS QoS •  Gerenciamento de congestionamento: PB, CQ, WFQ •  Prevenção de congestionamento: WRED •  Condicionamento de tráfego: CAR •  IP Precedence (3 bits do campo TOS): DiffServ

q  Implementa DiffServ e RSVP




Outras empresas

q  3Com •  www.3com.com •  Voltada principalmente para switches •  Implementação de RSVP.

q  Extreme Networks •  www.extremenetworks.com •  Assumiu linha Core Builder 9000 da 3Com


Outras empresas

q  IBM •  www.ibm.com •  Implementa DiffServ •  Desfez-se da área de redes

q Juniper Networks •  www.juniper.net •  Implementa DiffServ/MPLS




Perguntas em aberto:

q Como/quando/se o QoS irá funcionar em uma Internet completamente heterogênea ?

q Como se obtém QoS quando múltiplos domínios administrativos de trânsito (backbones distintos) ?

protocolos multimídia na internetadriano/aulas/...unesp - ibilce - são josé do rio preto...

Documents