Soluções em redes IP:

(1)

(2)

Soluções em redes IP:

Integração Intserv / Diffserv Controle de Admissão

Vítor Costa

(3)

3 3 3

CRSC’ 2002

Integração Intserv / Diffserv para controle de

admissão em redes IP:

• Onde estamos com o Diffserv?

• As opções para controle de admissão

• Como estamos com o Intserv / RSVP?

• Integração Intserv / Diffserv

• Case study: Controle de Admissão para uma

(4)

(5)

5 5 5

CRSC’ 2002

Onde estamos com o Diffserv?

• O Diffserv WG completou efectivamente todos os

pontos que se propôs

Essencialmente terminou o serviço que se propôs no inicio de 1998:

“ … métodos relativamente simples e grosseiros de

providenciar classes de serviço diferenciadas para tráfego Internet, para suportar vários tipos de aplicações, …”

• O Diffserv é claramente a tecnologia preferida para

suportar QoS em larga escala no momento presente

(ex. SPs)

(6)

Domínio Diffserv

VoIP Bus Best-Effort Classificação e condicionamento (medida, marcação e policiamento) na extremidade

Arquitectura Diffserv: RFC2475

“Colorização” de pacotes com DSCP VoIP Bus Best-Effort PHBs agregados no núcleo (EF, AF, DF, CSn)

(7)

7 7 7

CRSC’ 2002

• Serviços providenciados por uma combinação de

comportamento na extremidade (classificação

complexa, policiamento / “shaping”, marcação, etc.)

+ comportamento no núcleo (PHBs)

• Complexidade mínima

Sem estado, sem sinalização

Exemplo: pode-se instalar DS com apenas 1 bit de header bit e 2 “per-hop behaviors” (PHBs)

Serviços variados com o único PHB

(8)

Diffserv – o que (não) nos dá?

• “QoS por planeamento de capacidade por classe”

Fornece a capacidade de fazer sobre/sub aproveitamento numa base por classe

O serviço (delay, jitter, loss) que o tráfego recebe é

dependente do racional da carga oferecida e da capacidade disponível

Assim permite que se definam SLAs numa base de classe de serviço

(9)

9 9 9

CRSC’ 2002

O controle de admissão é necessário?

• Sem controle de admissão:

Para aplicações cuja performance não se degrada graciosamente com a congestão ...

ex. VoIP, vídeo

… se existe uma hipótese de congestionamento da

capacidade disponível numa ligação para estas classes,

então poderemos degradar o serviço para todas as ligações existentes nesse momento

• Só viável se os recursos para estas classes forem

sobre-dimensionados de tal forma que nunca possa

existir congestão

O sobre-dimensionamento nem sempre é prático ou economicamente viável

(10)

Opções para controle de admissão

• É preferível recusar uma chamada / fluxo do que

degradar todas as que se encontram já em progresso

• Possíveis aproximações ao controle de admissão em

redes IP:

Controle de admissão local estático

Controle de admissão estático centralizado (servidor)

System Resource Check (SRC) CAC Service Assurance Agent (SAA) CAC

(11)

11 11 11

CRSC’ 2002

Opções para controle de admissão (cont.)

• Controle de admissão local estático

Cada gateway mantém uma tabela estática com por exemplo o nº máximo de chamadas para cada destino ou máximo nº de fluxos por cliente.

Nota: efectivo para topologias simples, com problemas em escalar, não se adapta a mudança de recursos/topologia (ex. estados de backup)

• Controle de admissão estático centralizado

Servidor centralizado (ex. gatekeeper) mantém tabelas de nº máximo de chamadas para cada destino ou nº máximo de fluxos por cliente

(12)

Opções para controle de admissão (cont.)

• System Resource Check (SRC) CAC

Controle de admissão por medida dos recursos locais: mede coisas como memória e recursos DSP disponíveis no

gateway local para tomada de decisão

Nota: Não há entendimento dos recursos de rede disponíveis

• Service Assurance Agent (SAA) CAC

Controle de admissão por medidas realizadas na rede:

basedo na resposta a sondas enviadas para o gateway de destino

Nota: usa dados circunstanciais – não fornece garantias

• Controle de admissão dinâmico baseado na rede

(13)

13

CRSC’ 2002

Como estamos com o Intserv /

RSVP?

(14)

• O RFC 1633 estabeleceu a filosofia dos serviços

integrados

ou seja “Intserv” ou “IS”

• O Intserv usa um protocolo de sinalização para

explicitamente requerer e reservar os recursos

necessários, extremo-a-extremo, para o fluxo de uma

aplicação

Serviço garantido (Guaranteed Service/GS) – RFC 2212

Serviço de carga-controlada (Controlled-Load Service/CL) – RFC 2211

• Características chaves do Intserv:

Controle de admissão com dependência topológica Reservas firmes para fluxos individuais

(15)

15 15 15

CRSC’ 2002

• O RFC2210 define o uso do RSVP com Intserv

Em teoria o Intserv é independente do RSVP – na prática são sinónimos

• O RSVP é usado para instigar três funções chave de

controle de tráfego por micro-fluxo em cada “salto”

numa interligação

Controle de admissão Classificadores

Reserva de recursos interna

• Preocupações que têm limitado o uso do RSVP:

Escalabilidade

Suporte nos pontos terminais

(16)

Referências Intserv / RSVP

• RFC1633 – Integrated Services in the Internet Architecture: an Overview

• RFC2205 – Resource ReSerVation Protocol (RSVP) – Version 1 Functional Specification

• RFC2210 – The Use of RSVP with IETF Integrated Service

• RFC2211 – Specification of the Controlled-Load Network Element Service

• RFC2212 – Specification of Guaranteed Quality of Service

• RFC2214 – Integrated Services Management Information Base Guaranteed Service Extensions using SMIv2

• RFC2215 – General Characterization Parameters for Integrated Service Network Elements

(17)

17 17 17

CRSC’ 2002

Recapitulação Intserv / RSVP (1)

• A aplicação emissora passa SENDER_TSPEC e ADSPEC para o RSVP via a API RSVP

SENDER_TSPEC

Traffic specifier – descreve o tráfego que a aplicação espera gerar

ADSPEC

Gerado no ponto de envio e modificado dentro da rede

Anuncia para os receptores (e emissor) as características de QoS do caminho da comunicação

Pode incluir parâmetros requeridos para o bom funcionamento de serviços de QoS

Emissor Receptor

Aplic. RSVP

(18)

Recapitulação Intserv / RSVP (2)

• Mensagem PATH gerada pelo emissor com:

SENDER_TSPEC ADSPEC Emissor Receptor Aplic. RSVP PATH

(19)

19 19 19

CRSC’ 2002

Recapitulação Intserv / RSVP (3)

• Instala o "path state" em cada nó ao longo do caminho

Inclui pelo menos um endereço IP unicast do nó anterior – usado para encaminhar as mensagens RESV salto-a-salto na direcção da reserva

• O ADSPEC é passado do RSVP para o módulo de controle de tráfego em cada salto

O TCon actualiza o ADSPEC com informação sobre as capacidades de controle do QoS

Pode incluir serviços disponíveis e estimativas de atraso e de largura de banda

Emissor TCon Receptor

(20)

Recapitulação Intserv / RSVP (4)

• O ADSPEC actualizado é devolvido ao RSVP para

entrega ao nó seguinte ao longo do caminho

(21)

21 21 21

CRSC’ 2002

Recapitulação Intserv / RSVP (5)

• O processo é repetido para cada salto ao longo do

caminho

RSVP

TCon RSVP

(22)

Recapitulação Intserv / RSVP (6)

• O SENDER_TSPEC e ADSPEC são entregues à

aplicação receptora via a API do RSVP

Aplic. RSVP

(23)

23 23 23

CRSC’ 2002

Recapitulação Intserv / RSVP (7)

• A aplicação receptora fornece parâmetros de reserva ao RSVP via a API do RSVP:

Pedido de nível de serviço: Serviço Garantido (Guaranteed Service/GS) ou Carga Controlada (Controlled Load/CL)

O RECEIVER_TSPEC descrevendo o nível de tráfego para o qual os recursos devem ser reservados

Opcionalmente o RECEIVER_RSPEC pode conter quaisquer parâmetros requeridos para invocar o serviço

Aplic. RSVP

(24)

Recapitulação Intserv / RSVP (8)

• A mensagem RESV é enviada “upstream”

FILTERSPEC – informação de classificação que define o conjunto de pacotes de dados – o “fluxo” – que receberá o QoS definido pelo FLOWSPEC

FLOWSPEC – contem a informação gerada pela aplicação receptora descrevendo o serviço Intserv desejado:

RECEIVER_TSPEC, RECEIVER RSPEC

Aplic. RSVP RESV

(25)

25 25 25

CRSC’ 2002

Recapitulação Intserv / RSVP (9)

• A mensagem RESV é processada em cada salto

O FLOWSPEC é usado para controle de admissão e para configurar os recursos por fluxo

O FILTERSPEC recebido é usado para instanciar os classificadores de fluxos

• Fusão de estados, encaminhamento de mensagens e gestão de erros procede de acordo com as regras do protocolo RSVP

Emissor Receptor Aplic. RSVP TCon RSVP TCon RSVP TCon RSVP

(26)

Recapitulação Intserv / RSVP (10)

• O objecto FLOWSPEC resultante da fusão chega a cada um dos extremos da sessão RSVP e é entregue à aplicação

• Informa cada um dos extremos do resultado global do pedido de reserva e das propriedades do caminho estabelecido

Aplic. RSVP

(27)

27 27 27

CRSC’ 2002

Escalabilidade do RSVP

• Cada nó mantém informação por fluxo aplicacional

ou por estado de cliente

Plano de controle

Controle de admissão: estado da reserva por fluxo – garante a disponibilidade de largura de banda

Plano dos dados

Classificadores por fluxo, condicionadores e

escalonadores – garantem o isolamento entre fluxos

• O requisito da manutenção do fluxo por aplicação ou

do estado por cliente tem limitado a percepção da

(28)

Estado por fluxo Estado

agregado Sem estado

O espectro do QoS

• O Diffserv foi criado, em grande parte, como resposta

às preocupações de escalabilidade do RSVP

Best Effort RSVP v1/

Intserv Diff-Serv

(29)

29

(30)

Integração Inserv / Diffserv

• A maioria dos problemas de escalabilidade do Intserv situam-se no plano dos dados

• A integração Intserv / Diffserv fornece o melhor dos dois mundos

• No plano de controle é usado RSVP enquanto no plano dos dados é usado Diffserv

Sem estado

Best Effort

Estado por fluxo

RSVP v1/ Intserv Estado agregado Diffserv O estado agregado garante o controle de admissão RSVP + Diffserv

(31)

31 31 31

CRSC’ 2002

Intserv sobre Diffserv: RFC2998

• Estrutura que descreve

como se consegue atingir o Intserv na presença de

“nuvens” Diffserv (“regiões”)

• As regiões Diffserv vistas como elementos de uma rede Intserv maior

• Mapeamento de fluxos RSVP para PHBs

• Fundamental para o

escalamento do RSVP tanto a nível empresarial como de SPs • Como é conseguido o controle de admissão ? Telefone PBX Servidor Servidor Intserv Diffserv

(32)

Múltiplas alternativas para controle de admissão sobre a nuvem DS:

1. Sem controle de admissão sobre os

recursos DS

Os routers de núcleo não são “RSVP

aware”

Os fluxos RSVP são mapeados para PHBs

A região DS tem de ser aprovisionada por forma a garantir não existência de congestão para cada PHB

Telefone PBX Servidor Servidor Intserv

?

Diffserv

(33)

33 33 33

CRSC’ 2002

1. Sem controle de admissão sobre os recursos DS

2. Controle de admissão apenas nas extremidades baseado na largura de banda contratada por PHB à entrada da nuvem DS

Os routers de núcleo não são “RSVP aware”

Os routers nas extremidades

compreendem pedidos RSVP por fluxo Os fluxos RSVP são mapeados para PHBs Executa controle de admissão estático baseado em tabelas de recursos de largura de banda contratada por PHB

Não faz um uso eficiente dos recursos na rede DS Telefone PBX Servidor Servidor Intserv

?

Diffserv

(34)

2. Controle de admissão apenas nas extremidades baseado na largura de banda contratada por PHB à entrada da nuvem DS

3. Controle de admissão em cada salto da nuvem DS

Todos os routers “RSVP aware”

Controle de admissão dinâmico por fluxo Classificação agregada e “scheduling” baseado em DSCP

Melhor escalabilidade que o “tradicional” RSVP porque não existe classificação e estado por fluxo

Telefone PBX Servidor Servidor Intserv ? ? ? Diffserv

(35)

35 35 35

CRSC’ 2002

Escalabilidade do RSVP:

Integração Intserv / Diffserv

• A sinalização RSVP é usada apenas para controle de

admissão

A classificação e o “scheduling” por fluxo estão desabilitados

• O Diffserv é usado para classificação e “scheduling”

agregado baseado em DSCP

• Combina os benefícios da sinalização RSVP para o

controle de admissão e a simplicidade do Diffserv no

tratamento do tráfego

O plano dos dados escala independentemente do número de fluxos

• Ainda é preciso manter a informação de estado de

cada fluxo no plano de controle

(36)

Intserv sobre Diffserv: RFC2998

Múltiplas alternativas para

controle de admissão sobre a nuvem DS:

2. Controle de admissão apenas nas extremidades baseado na largura de banda contratada por PHB à entrada da nuvem DS

3. Controle de admissão em cada salto da nuvem DS

4. Controle de admissão em cada salto da rede DS, mas via

reservas agregadas: Agregação RSVP Telefone PBX Servidor Servidor ? ? ? Diffserv E2E Intserv Agregação RSVP

(37)

37 37 37

CRSC’ 2002

Agregação RSVP: RFC3175

• Múltiplas reservas

agregadas em apenas uma grande (fat pipe) reserva agregada

• Reduz a carga em termos de manutenção de estados e sinalização, no núcleo

• Tráfego pertencente à

reserva agregada é mapeado para um DSCP da rede DS

• Controle dinâmico de

admissão – uso eficiente dos recursos do DS

• Cisco = Static pipes, MPLS-TE Telefone PBX Servidor Servidor ? ? ? Agregação RSVP Diffserv E2E Intserv

(38)

Detalhes da agregação de RSVP (1)

• As mensagens RSVP extremo-a-extremo (E2E –

end-to-end) representam micro-fluxos

• Mensagens RSVP agregadas representam “fat pipes”

de muitos fluxos

• Uma região de agregação é criada configurando os

routers para agregar e desagregar

Tais routers têm uma interface “interior” e outra “exterior” A agregação ocorre quando um caminho E2E passa do interior para o exterior

(39)

39 39 39

CRSC’ 2002

Detalhes da agregação de RSVP (2)

• É criado um “hiper-espaço” para as mensagens

RSVP dos micro-fluxos sobre a nuvem Diffserv

O router de agregação muda o número do protocolo IP de “RSVP” para “RSVP-E2E-IGNORE”

É ignorado pelos routers de núcleo

É interceptado e restaurado para “RSVP” pelo router de desagregação (egress)

• O router de saída envia PathErr de volta para o de

entrada

Desta forma novos pontos de término para reservas agregadas são auto-descobertos

(40)

Detalhes da agregação de RSVP (3)

• Os routers de entrada e de saída constróem uma

reserva agregada

Tal como uma reserva normal, mas um novo tipo de sessão identifica o DSCP

Todos os fluxos que partilhem o mesmo ponto de entrada, de saída e DSCP pertencem a uma sessão agregada

A dimensão do agregado pode ser configurada estaticamente ou estabelecida dinamicamente

Determinada pela sumarização dos caminhos E2E e RESVs

Heurísticas podem ser usadas para reduzir o desperdício – ajustáveis lentamente com hysteresis

(41)

41

Case study: Controle de

Admissão para uma Rede

(42)

STB Telef. TV PC IP CPE PoP de agregação Núcleo da Rede RSVP COPS COPS Radius Billing IP MEDIA SERVER RSVP 1. Pedido de “stream” 2. RSVP PATH 3. Rx proxy + Verificação de politica COPS/RSVP 4. Decisão da politica 5. Adm ctrl + RSVP RESV 6. “streaming” RTP 7. RSVP TEAR 1 2 3 4 RTP 6 RTCP 7 5 GATEWAY GATE KEEPER

Case study: Controle de Admissão para uma Rede

(43)

43 43 43

CRSC’ 2002 STB Phone TV PC ATM CPE PoP de agregação Núcleo da Rede RSVP COPS COPS Radius Billing IP GATE KEEPER MEDIA SERVER RSVP GATEWAY 1 1. Offhook + digitos 2. Call continue 3. H.225 Setup 4. H.225 Call proceeding 5. RSVP PATH 6. RSVP RESV 7. Alerting 8. Disconnect 9. RESV TEAR 10. Accounting/ Billing 2 3 4 5 6 8 9 7 10

Case study: Controle de Admissão para uma

(44)