Soluções em redes IPDomínio Diffserv VoIP Bus Best-Effort Classificação e condicionamento (medida, marcação e policiamento) na extremidade Arquitectura Diffserv: RFC2475 “Colorização”

2© 2002, Cisco Systems, Inc. All rights reserved.CRSC’ 2002

Soluções em redes IP:Integração Intserv / Diffserv Controle de Admissão

Vítor Costa

Consulting Systems Engineer


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 Rede Multi-Serviços


Onde estamos com o Diffserv?


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)


Domínio Diffserv

VoIP Bus Best-Effort

Classificação e condicionamento(medida, marcação e policiamento) na extremidade

Arquitectura Diffserv: RFC2475

“Colorização” depacotes com DSCP

VoIP

Bus

Best-Effort

PHBs agregados no núcleo(EF, AF, DF, CSn)


• 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ínimaSem estado, sem sinalização

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

Serviços variados com o único PHB

Recapitulação Diffserv


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

• Sem conceito de controle de admissão!


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


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

Controle de admissão dinâmico baseado na rede


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

• Controle de admissão local estáticoCada 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 centralizadoServidor centralizado (ex. gatekeeper) mantém tabelas de nº máximo de chamadas para cada destino ou nº máximo de fluxos por cliente

Nota: como no caso precedente (acima)


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

• System Resource Check (SRC) CACControle 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) CACControle 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 redeUsa RSVP / Intserv


Como estamos com o Intserv / RSVP?


• 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

Integrated Services


• O RFC2210 define o uso do RSVP com IntservEm 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

Intserv / RSVP


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

• RFC2216 – Network Element Service Specification Template


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



• Mensagem PATH gerada pelo emissor com:SENDER_TSPEC

ADSPEC

Emissor Receptor

Aplic.RSVP

PATH



• Instala o "path state" em cada nó ao longo do caminhoInclui 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 ReceptorTConRSVP



• O ADSPEC actualizado é devolvido ao RSVP para entrega ao nó seguinte ao longo do caminho




• O processo é repetido para cada salto ao longo do caminho


TConRSVP

PATH PATH PATH



• O SENDER_TSPEC e ADSPEC são entregues à aplicação receptora via a API do RSVP

Emissor Receptor

Aplic.RSVP



• 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

Emissor Receptor

Aplic.RSVP



• 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

Emissor Receptor

Aplic.RSVP

RESV



• A mensagem RESV é processada em cada saltoO 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

TConRSVP

TConRSVP

TConRSVP

RESV RESV RESV



• 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

Emissor Receptor

Aplic.RSVP


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 escalabilidade


Estado por fluxoEstado

agregadoSem 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© 2002, Cisco Systems, Inc. All rights reserved.CRSC’ 2002 29© 2001, Cisco Systems, Inc.

Integração Intserv / Diffserv


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

Estadoagregado

DiffservO estado agregadogarante o controle

de admissão

RSVP + Diffserv


Intserv sobre Diffserv: RFC2998• Estrutura que descreve

como se consegue atingir oIntserv 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 oescalamento do RSVP tanto a nível empresarial como deSPs

• Como é conseguido o controle de admissão ?

Telefone

PBX

Servidor

Servidor

Intserv

Diffserv


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 “RSVPaware”Os fluxos RSVP são mapeados paraPHBsA 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

Intserv sobre Diffserv: RFC2998




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 “RSVPaware”Os routers nas extremidades compreendem pedidos RSVP por fluxoOs fluxos RSVP são mapeados para PHBsExecuta controle de admissão estático baseado em tabelas de recursos de largura de banda contratada por PHBNão faz um uso eficiente dos recursos na rede DS

Telefone

PBX

Servidor

Servidor

Intserv

?Diffserv






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

Todos os routers “RSVP aware”Controle de admissão dinâmico por fluxoClassificação agregada e “scheduling” baseado em DSCPMelhor escalabilidade que o “tradicional” RSVP porque não existe classificação e estado por fluxo

Telefone

PBX

Servidor

Servidor

Intserv

?

?

?

Diffserv



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






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


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 é mapeadopara 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 RSVPDiffserv

E2E Intserv


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



• É 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



• 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 eRESVs

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

41© 2002, Cisco Systems, Inc. All rights reserved.CRSC’ 2002 41© 2001, Cisco Systems, Inc.

Case study: Controle de Admissão para uma Rede

Multi-Serviços


STB

Telef. TV PC

IP

CPEPoP deagregação

Núcleo da Rede

RSVP

COPSCOPS

Radius

Billing

IP

MEDIASERVER

RSVP

1. Pedido de “stream”2. RSVP PATH3. Rx proxy + Verificação de

politica COPS/RSVP4. Decisão da politica5. Adm ctrl + RSVP RESV6. “streaming” RTP7. RSVP TEAR

1

2

34

RTP

6RTCP

7

5

GATEWAY

GATEKEEPER

Case study: Controle de Admissão para uma RedeMulti-Serviços (Sessão de Vídeo Unicast)


STB

Phone TV PC

ATM

CPEPoP deagregação

Núcleo da Rede

RSVP

COPSCOPS

Radius

Billing

IP

GATEKEEPER

MEDIASERVER

RSVP

GATEWAY1

1. Offhook + digitos2. Call continue3. H.225 Setup4. H.225 Call proceeding5. RSVP PATH6. RSVP RESV7. Alerting8. Disconnect9. RESV TEAR10. Accounting/

Billing

234

5

68

97

10

Case study: Controle de Admissão para uma Rede Multi-Serviços (VoIP)


Documents

Soluções em redes IPDomínio Diffserv VoIP Bus Best-Effort Classificação e condicionamento (medida, marcação e policiamento) na extremidade Arquitectura Diffserv: RFC2475 “Colorização”