Solução de QoS para Serviços Triple-Play

Carlos Eduardo Terra Barroso

Departamento de Telecomunicações – Universidade Federal Fluminense (UFF) Rua Passo da Pátria, 156 – São Domingos – CEP 24.210-240 – Rio de Janeiro – RJ –

Brasil carlos_terra@midiacom.uff.br

Resumo. Este artigo apresenta uma solução de QoS para serviços triple-play, sendo descrito o modelo de rede de acesso e na seqüência apresentados os requisitos de Qualidade de Serviço para as aplicações que compõem o serviço Triple-Play (vídeo, voz e dados), os requisitos das operadoras para operação e manutenção da rede, a visão do usuário sobre a prestação do serviço e a solução de QoS para a prestação do serviço.

1. Introdução A demanda por serviços de telefonia, TV por assinatura e acesso a Internet exige, atualmente, dos provedores de serviços de telecomunicações a busca por soluções de rede que permitam a prestação de serviços Triple-Play. Redes de acesso específicas para cada um dos serviços (telefonia. TV e Internet) permitem o tratamento individual dos requisitos de Qualidade de Serviço (QoS – Quality of Service) das aplicações (voz, vídeo e dados) aumentando, todavia, a quantidade de redes em operação e a complexidade para prestação de serviços com alto valor agregado. Este trabalho apresenta uma solução que permite a oferta de serviços multimídia convergentes [1]. A solução é baseada na arquitetura NGN (Next Generation Networks), com uma única rede de acesso para todos os serviços. A infra-estrutura da rede utiliza um backbone IP/MPLS, com tratamento individual dos requisitos de QoS por aplicação em toda a estrutura, compondo o serviço Triple-Play em rede convergente, ou Triple-Play convergente, conforme mostrado na Figura 1.

Figura 1 – Arquitetura NGN

Inicialmente será descrito o modelo de rede de acesso, sendo na seqüência apresentados os requisitos de Qualidade de Serviço para as aplicações que compõem o serviço Triple-Play (vídeo, voz e dados), os requisitos das operadoras para operação e manutenção da rede, a visão do usuário sobre a prestação do serviço e, finalmente, a solução de QoS para a prestação do serviço.

2 . Modelagem da Rede de Acesso

As redes de acesso compõem a estrutura responsável pelo transporte e entrega dos serviços, do ponto de concentração da prestadora até o usuário final.

A estrutura de rede escolhida neste trabalho para a abordagem direta ou

agregação de acessos é a de Redes Ethernet Metropolitanas (MEN – Metro Ethernet Networks), proposta pelo MEF (Metro Ethernet Forum)1 com a complementação de uma rede de serviços NGN baseada e núcleo IP/MPLS. As MENs possibilitam a prestação de serviços com alta velocidade e ganularidade de acesso (10, 100, 1000, 10000 Mbps), alto grau de compartilhamento de recursos físicos e lógicos, aderência a diversos modelos de QoS, ferramentas de Operação e Manutenção (OAM) de fácil integração com as redes de camadas superiores e, principalmente, possuem o framework ideal para operação com tecnologias de acesso complementares. A Figura 2 descreve o framework (estrutura) genérico, proposto pelo MEF para as Redes Ethernet Metropolitanas. 1 Consórcio internacional responsável pela consolidação de normas técnicas e certificação de redes e serviços baseados em Ethernet

TV

Figura 2 – Arquitetura MEN: Framework Genérico

O MEF define [2] que o único requisito para a abordagem ao usuário final, a partir de um elemento da MEN é a capacidade de transporte transparente de quadros ethernet.

Tecnologias de acesso como WIMAX, G-PON e DSL são aderentes ao modelo,

desde que atendam ao requisito de transporte transparente de quadros Ethernet. Os estudos detalhados dos mecanismos utilizados por outras tecnologias de acesso para transporte dos quadros Ethernet são temas para outros trabalhos.

A MEN tem o comprometimento de isolamento, multiplexação e manutenção da

Qualidade de Serviço dos diversos fluxos de aplicações que são transportados por sua estrutura.

Os serviços fornecidos pela MEN podem variar de acordo com a aplicação e a

característica da aplicação utilizada. Para aplicações com característica de transmissão unicast, como aplicações de

telefonia e a maior parte das aplicações na Internet são utilizados serviços do tipo ponto-a-ponto, ilustrados na Figura 3, definidos pelo MEF como E-LINE [3], [4], com multiplexação de interface.

Service Interworking

NNI

Network Interworking

NNI

Network Interworking

NNI

Subscriber

UNI

Other L1 Transport Networks

(e.g., SONET, SDH, OTN)

MEN Service Provider Z1

Other L2/L2+ Services Networks (e.g., ATM, FR, IP)

External NNI

Ethernet Wide Area Network

(E-WAN ) Service Provider Y

MEN Service Provider Z2

MEN Service Provider X

Metro Ethernet Network

(MEN) Service Provider X

External NNI

Subscriber

Subscriber

UNI

UNI

Figura 3 – Serviço E-LINE com multiplexação na interface central

As aplicações com características de difusão irrestrita (broadcast), como

aplicações de TV, ou com características de difusão restrita para grupos (multicast), como aplicações de jogos e Vídeo sob Demanda (VoD), são serviços que usam de transmissão ponto-multiponto (TV e VoD) ou multiponto-multiponto (jogos), ilustrados na Figura 4 e definidos pelo MEF como E-LANs [3], [4].

Figura 4 – Serviço E-LAN

3. Caracterização do tráfego e requisitos de QoS As aplicações do serviço Triple-Play podem ser entendidas a partir da análise de suas características e de seus requisitos (de forma absoluta ou relativa) considerando as seguintes métricas [5], [6]:

? Throughput (banda/vazão): Consumo de banda da aplicação (médio e valor de pico). Pode variar em função dos codificadores de camadas superiores utilizados ou em função da ação do usuário. Para cálculos de QoS é utilizado o valor de pico.

? Delay (retardo): Tempo máximo de entrega (origem => destino)

suportado por uma determinada aplicação sem comprometimento do seu funcionamento. Devem ser levados em consideração o retardo de enfileiramento na origem e no destino, o retardo de codificação/decodificação (se houver) e o retardo de propagação pela rede, conforme ilustrado na Figura 5.

Figura 5 – Cálculo do retardo

? Jitter (variação de retardo): Variação no retardo, normalmente causada pela concorrência entre tráfegos em um mesmo canal de saída, e que pode comprometer o retardo máximo.

? Perda de Pacotes: Perda de pacotes é tolerável até comprometer a

aplicação.

Um bom entendimento do comportamento das aplicações quando variamos uma ou mais métricas é essencial para a modelagem de QoS da rede.

A percepção do usuário em relação ao serviço prestado (QoE – Quality of

Experience) deve ser no mínimo igual à de um serviço prestado em uma rede de acesso dedicada.

3.1 Voz (Telefonia)

Os requisitos para a prestação do serviço de telefonia são:

Vazão: Varia em função do codificador utilizado. Com G.711 e a pilha TCP/IP (RTP, UDP, IP, Ethernet), a vazão é de aproximadamente 90Kbps por canal.

Retardo: Fim-a-Fim (Origem => Destino) não deve ser superior a 150ms para a mídia voz (ITU-T G.114). A sinalização da chamada telefônica pode variar acima desse valor. Jitter: É tolerado desde que, somado ao calculo do Delay, não ultrapasse o valor máximo de 150ms. Perda de Pacotes: Valor máximo para implementações práticas de 0,25% (utilizando G.711) A Figura 6 [5] traz um exemplo do impacto do retardo em uma aplicação de Voz sobre IP (VoIP) com diferentes codificadores de voz. A parametrização para definição do nível de satisfação do usuário é dada pela norma G.107 (R-value) do ITU-T. Um dos motivos para o maior impacto do retardo nos codificadores de menor consumo de banda, como o G.729A e o G.723.1 é a complexidade da decodificação em comparação com codificadores mais simples, porém com maior consumo de banda, como o G.711.

Figura 6 – Impacto do retardo na qualidade da chamada

3.2 Vídeo (IPTV) Vazão: Varia em função do codificador utilizado. Com MPEG-2 aproximadamente 4Mbps por canal SDTV e com MPEG-4 2Mbps por canal SDTV. Retardo: Fim-a-Fim (Origem => Destino) entre 3 e 5 segundos, não deve comprometer a interação do usuário com a aplicação. Variação do retardo: Até 30 ms em função do sincronismo entre o vídeo e áudio apresentados (TV). Perda de Pacotes: Deve ser abaixo de 0,5%.

3.3 Vídeoconferência Vazão: Varia em função do codificador utilizado. Aplicações utilizando H.264 variam de 64kbps até 8Mbps. Retardo: Fim-a-Fim (Origem => Destino) não deve ser superior a 150ms, para manutenção da interação entre usuários. Variação do retardo: Até 30 ms em função do sincronismo entre o vídeo e áudio apresentados (TV). Perda de Pacotes: Deve ser abaixo de 0,5%.

3.4 Video Streaming (VoD) Vazão: Varia em função do codificador utilizado na origem. Aplicações típicas variam entre 384Kbps até 1,5Mbps. Retardo: Fim-a-Fim (Origem => Destino) entre 4 e 5 segundos. Variação do retardo: Sem requisitos significativos (tolerante). Perda de Pacotes: Sem requisitos significativos (tolerante). A aplicação de streaming de vídeo, por não ser uma aplicação de tempo real, é mais tolerante a atrasos e perdas que as demais aplicações de vídeo.

3.5 Aplicações de Internet e Jogos Vazão: Aplicações de transferência e compartilhamento de arquivos (FTP e P2P) tendem a ocupar toda a banda disponível, com valor médio próximo ao valor de pico. Jogos tendem a limitar a banda em perfis pré-definidos. Navegação na web, com uso do protocolo HTTP e chats tendem a ocupar a banda disponíve l pontualmente (durante a interação do usuário), tendo alto valor de pico e baixo valor médio. Retardo: Com exceção da aplicação de jogos, não tende a ser crítico. Variação do retardo: Sem requisitos significativos (tolerante). Perda de Pacotes: Sem requisitos significativos (tolerante).

Não existem valores exatos para variação de retardo e perda de pacotes para aplicações de jogos.

4. Visão da Operadora e do Cliente Podemos analisar os serviços Triple-Play sob duas perspectivas, visão da operadora e visão do cliente. As seções a seguir tratam de cada uma dessas vertentes.

4.1 Visão da Operadora A visão da operadora em relação aos serviços Triple-Play deve ser analisada sob o ponto de vista do framework de operação e a operação da camada de rede. Aspectos de operação como segurança e disponibilidade envolvendo a camada de rede não são detalhados neste trabalho. Da mesma forma, tomamos as redes IP/MPLS e NGN como estruturas elementares para a prestação do serviço Triple-Play convergente. A seguir é proposto um framework para a operação da rede e são apresentadas algumas funcionalidades de operação da MEN.

4.1.1 Framework de Operação A prestação de serviços Triple-Play convergentes exige a unificação das camadas de acesso, rede e serviços nas operadoras de telecomunicações. Para possibilitar essa unificação/convergência entre as camadas, é necessária uma camada intermediária de mediação, que seja capaz de coletar informações específicas de cada rede, atuando diretamente em cada elemento, ou interagindo com o EMS (Element Management System ) respectivo de cada rede, consolidando a visão integrada do serviço. A interação entre a camada de mediação (CIL – Camada de Inventário Lógico) e os EMS é feita através de APIs (Aplication Programming Interfaces) usando linguagem XML, por exemplo, onde a CIL é capaz de tratar as informações coletadas antes de repassá- las ao Sistema de OAM (Operation and Maintenence) da Camada de Operação. No modelo onde cada serviço corresponde a uma rede de acesso/serviço, mesmo com o núcleo de rede compartilhado, a visão consolidada do serviço Triple-Play exigiria ainda um segundo passo de integração, tornando bastante complexa, mas não inviável, a sua implementação. A unificação dessas três camadas permite o aprovisionamento e configuração do serviço Triple-Play de forma centralizada, evitando que a ativação de um único usuário exija ação individual em três diferentes plataformas de acesso, rede e serviço, em comparação com o modelo de prestação de serviços em redes especializadas.

A camada de provisionamento é capaz de interagir com a CIL permitindo a visualização dos recursos disponíveis e a geração das rotinas de configuração dos serviços nas camadas inferiores.

Em escala similar estão os ganhos na operação do serviço, uma vez que através da camada de operação, é possível a visualização do serviço como um todo. As funções de cada EMS, muitas vezes proprietárias, são mantidas nesse modelo, uma vez que a CIL não altera a sua estrutura, apenas estabelece uma interação padronizada no contexto da prestação do serviço, dessa forma a gerência de rede/elemento é mantida. O faturamento dos serviços é feito através da consolidação das informações do sistema de provisionamento. Como o sistema de provisionamento tem a visão orientada para o serviço e não para a rede, através das facilidades da camada de mediação, além do faturamento automático após a ativação, qualquer interrupção ou falha no serviço pode ser automaticamente relatada pelo sistema de OAM ao sistema de faturamento, o que implica na possibilidade de relatório, também automático, do nível de prestação do serviço ao usuário final. A Figura 7 apresenta um diagrama em blocos do modelo com a camada de mediação.

Figura 7 – Modelo de operação convergente

4.1.2 Operação da MEN Originalmente os protocolos Ethernet/IEEE 802.3 não ofereciam maiores funcionalidades para gerenciamento de status, verificação de conectividade e medição de níveis de Qualidade de Serviço, conhecidas como funcionalidades de OAM (Operation and Maintenence). Com a sua crescente utilização em redes de acesso metropolitanas (MEN), algumas funções de OAM foram adicionadas protocolo através de extensões padronizadas, como a 802.3ah [7] (Ethernet in First Mile - Physical Link Layer OAM) e 802.1ag [8] (Connectivity Fault Management - Per Service OAM). A principal preocupação das novas extensões é prover a MEN com, no mínimo, as mesmas funcionalidades de OAM encontradas em outras redes de acesso, como as redes SDH e Frame-Relay, por exemplo.

Cabe ao EFM (padrão IEEE 802.3ah) o gerenciamento de cada enlace Ethernet componente da solução (não necessariamente restrito a MEN ou ao last-mile).

É necessária a definição de um elemento lógico ativo em umas das interfaces Ethernet que compõe o enlace, que será responsável pelo envio das PDUs de controle (OAMPDU – com endereço MAC de destino padronizado), para a outra interface do enlace (passiva), que será responsável pela resposta das informações solicitadas no campo de dados da OAMPDU. O formato da OAMPDU é mostrado na Figura 8. Essas interfaces não precisam estar diretamente conectadas, sendo permitida a passagem das OAMPDUs por elementos (switchs e bridges) que não implementam a facilidade.

Figura 8 – 802.3ah, formato da OAMPDU

Diversas informações são controladas, permitindo uma enorme variedade de informações sobre o estado do enlace que podem ser usadas pelo EMS para ações de manutenção na rede, como por exemplo, desabilitar determinada interface caso o número de erros encontrados seja superior a um determinado patamar. Cabe ao CFM (padrão IEEE 802.1ag) a função mais importante do gerenciamento nas MENs, visto que ele é o responsável pela gerência do serviço ethernet (E-LINE ou E-LAN) fim-a-fim. Essa funcionalidade traz a possibilidade do conhecimento do caminho lógico percorrido na MEN, sendo possível a medição dos níveis de QoS do serviço globais e

por aplicação, a definição de caminhos alternativos (backup) e a vizualição dos pontos de falha para entrega adequada do serviço. Diferentemente de outros protocolos as funcionalidades de OAM trazidas pelo CFM são específicas da camada de enlace (ethernet). Dessa forma é possível a realização, por exemplo, de testes de conectividade (como o Echo Reply / Request), sem a necessidade de conhecimento do endereço IP, sendo o pacote de controle endereçado a um endereço MAC.

Além de conectividade, verificações e medições de níveis de QoS nas diferentes aplicações/serviços são realizadas através do envio de mensagens de controle nas respectivas classes de serviço.

A Figura 9 ilustra de forma geral a aplicação do EFM e do CFM em uma rede de

acesso de maneira integrada.

Figura 9 – Uso em conjunto dos padrões 802.3ah e 802.1ag

Uma abordagem mais detalhada sobre o IEEE 802.3ah e o IEEE 802.1ag compõe tema para um trabalho específico, dada a variedade de informações tratadas.

4.2 Visão do cliente A visão do cliente em relação ao serviço prestado é em geral bastante subjetiva, sendo fator determinante para a satisfação com o serviço prestado às experiências anteriores do usuário com as aplicações (QoE). Usuários tradicionais dos serviços de TV atuais (aberta e paga) e telefonia tradicional (TDM) costumam possuir certa resistência às aplicações de streaming de vídeo e comunicação de voz via Internet, pois estão adaptados a um nível de serviço mais elevado. O entendimento das prioridades dos usuários para cada tipo de serviço e aplicação é certamente um campo de estudo de total interesse das operadoras e dos provedores de conteúdo e serviço.

A agregação de valor e funcionalidades aos serviços prestados tem sido um dos grandes objetivos das operadoras de telecomunicações. Uma funcionalidade, ligada às camadas de rede e provisionamento, que se propõe a atender uma das maiores necessidades dos usuários, o aumento da banda disponível para uma determinada aplicação, é o auto-provisionamento. Com o auto-provisionamento o usuário é capaz de solicitar a operadora o aumento ou diminuição da largura de banda disponibilizada para o serviço ou até mesmo uma aplicação de acordo com a sua necessidade momentânea. Como exemplo, o usuário pode solicitar o aumento do seu circuito de acesso à rede, enquanto utiliza serviços de um portal de vídeo sob demanda através de streaming de vídeo ou transferência de arquivos. Como terá maior banda disponibilizada, pode solicitar que o streaming ou o arquivo para transferência tenha qualidade HDTV ao invés de SDTV. Em outro exemplo, para a mesma situação, o usuário pode solicitar que a banda até então alocada para o seu serviço de TV seja integralmente repassada para a aplicação de VoD enquanto essa estiver ativa. A solicitação pode ser feita em portal de auto-atendimento acessado utilizando-se recursos da própria rede. O modelo apresentado na Figura 7 permite a interação do usuário com o sistema de provisionamento. Cabe ao sistema de provisionamento verificar com as camadas inferiores a disponibilidade de recursos, adicionais ou não, para o atendimento da solicitação, realizando as alterações necessárias nos elementos da camada de rede caso os recursos estejam disponíveis, e informar ao sistema de faturamento as alterações efetuadas no serviço prestado ao usuário.

5. Solução de Qos para diferentes tecnologias de acesso Conforme descrito na Seção 2, o único requisito para a abordagem ao usuário final, a partir de um elemento da MEN é a capacidade de transporte transparente de quadros Ethernet. Dessa forma, a definição de um modelo a partir da entrega direta em Ethernet é aderente a qualquer outra tecnologia de acesso complementar que atenda a esse requisito.

5.1 Classificação do tráfego na origem A partir da classificação do tráfego (pacote a pacote) conforme a aplicação é possível o tratamento individualizado da aplicação e a utilização de métodos que permitam a manutenção ou garantia dos seus requisitos, conforme apresentado na Seção 3. A classificação do tráfego na origem pode ser realizada baseando-se nos SAPs de origem e destino (mais comum) de camada 3 (endereço IP) ou camada 4 (endereço IP + Porta TCP ou UDP). Implementações mais recentes permitem também a classificação baseada em endereços de camada 2 (MAC, por exemplo). Por exemplo, podemos classificar todo o tráfego TCP nas portas 20, 21 e 80 (FTP, Controle FTP e HTTP), para o endereço IP de destino 200.255.67.132 (Locadora Virtual - Servidor de transferência de arquivos) como tráfego de aplicação de Vídeo sob Demanda e todo tráfego HTTP (TCP porta 80) para a URL http://www.bb.com.br como tráfego de aplicação crítica. Demais pacotes com portas TCP (portas 20, 21 e 80) e endereços IP de destino diferentes podem ser classificados como aplicação default. O tráfego de controle, como as OAMPDUs do IEEE 802.3ah, pode ser classificado como de controle/gerência, baseando-se no endereço MAC de destino (padronizado). A classificação do tráfego deve ser realizada nos dois sentidos da comunicação. Para aplicações controladas pela operadora (telefonia, TV e VoD) a classificação bidirecional é facilitada em função da centralização da operação. Aplicações com pontos remotos fora de sua administração (servidores de compartilhamento de arquivo P2P e servidores de jogos distribuídos, por exemplo) e que não utilizam portas padronizadas ou previamente informadas dificultam a classificação do tráfego. Uma alternativa para a resolução dessa questão pode ser a utilização do portal de auto-provisionamento para que o usuário informe, pelo menos em um dos sentidos da comunicação, qual classificação que esse tráfego deve receber. Nada impede, também, acordo entre diferentes operadoras para padronização da classificação do tráfego entre suas redes, o que pode ser bastante útil nas aplicações de jogos distribuídos e videoconferência. A classificação do tráfego é extremamente relacionada à expectativa individual do usuário em relação a uma determinada aplicação. Aplicações com maior tempo de mercado, como telefonia (TDM x VoIP) e TV (IPTV e TV aberta), têm melhor definidos os seus requisitos e as respectivas metodologias de verificação do nível de satisfação do usuário (como ilustrado na Figura 6). Aplicações oriundas do ambiente web ou amplamente utilizadas após a popularização da Internet, como serviços de e-mail, chat e transferências de arquivos, não possuem metodologias de auditoria da satisfação dos usuários tão bem definidas como as aplicações de telefonia e TV. A classificação empregada pelas prestadoras de serviços, para essas aplicações, é normalmente genérica e essencialmente técnica, podendo causar insatisfação em usuários mais exigentes. A adaptação da classificação em função do critério do usuário é extremamente comum nas implementações práticas.

Uma das opções da operadora é flexibilizar totalmente a classificação pelo usuário, o que pode causar um colapso nos sistemas de provisionamento, ou definir alguns perfis/pacotes que o usuário possa optar de acordo com os seus próprios critérios. Do escopo da flexibilização e dos perfis/pacotes, devem ser retirados o tráfego de controle e operação.

5.2 Utilizando a arquitetura Diffserv como base para a garantia de QoS

No modelo Diffserv [9], [10] cada nó realiza a classificação do tráfego para que

ele receba o tratamento diferenciado. O Diffserv não necessita controle de admissão, sinalização de QoS e nem

reserva de banda fim-a-fim.

A arquitetura Diffserv contém 6 mecanismos básicos de QoS:

• Classificação: Detalhada na Seção 5.1 • Marcação: Após a primeira classificação o tráfego é marcado de forma

padronizada facilitando a identificação das classes nos demais elementos. • Policiamento (Policing): Responsável pela definição do throughput reservado

para cada classe de serviço. • Mecanismo de Filas (Queuing): Responsável pelo isolamento do tráfego de

cada classe de serviço em filas, priorização e manutenção do throughput entre as filas. Pacotes de maior prioridade são alocados em filas expressas.

• Descarte (Dropping): Responsável pela política de descarte. Tráfego excedente

de maior prioridade pode ser reclassificado como não prioritário antes de ser descartado.

• Moldagem (Shaping): Aplicado ao final de todo o processo, tem

comprometimento com a eficiência de uso do enlace. Tráfego de pico, acima do valor permitido pode ser conforme no tempo, aproveitando-se de intervalos de baixa utilização. A Figura 10 traz uma ilustração em blocos funcionais da implementação da

arquitetura Diffserv.

Figura 10 – Diffserv apresentado em blocos funcionais

Os protocolos de camada 2 e 3 têm campos definidos para as marcações. Estas

têm formatos definidos nas seguintes recomendações ou padrões:

? Camada 3 (ToS – IP): IP Precedence (RFC 791) DSCP (RFC 2474)

? Camada 2 (CoS – Ethernet): IEEE 802.1p ? Camada 2 (EXP Bits – MPLS): MPLS EXP (RFC 2547)

Na arquitetura Diffserv não importa se a marcação é feita no cabeçalho de

camada 2 (CoS - Ethernet ou EXP Bits - MPLS) ou no cabeçalho de camada 3 (ToS – IP), pois é possível o mapeamento no protocolo de camada superior ou inferior baseada na marcação original.

A Tabela 1 traz um exemplo do mapeamento de classes entre os protocolos de

camada 2 e 3.

Camada 3 Camada 2

IP Precedence PHB DSCP Decimal

802.1p ou MPLS EXP

0 0 0 0

1 CS1 8 1

1 AF11 10 1

2 CS2 16 2

2 AF21 18 2

3 CS3 24 3

3 AF31 26 3

4 CS4 32 4

4 AF41 34 4

5 EF 46 5

6 CS6 48 6

Tabela 1 – Mapeamento de marcações

A escolha da arquitetura de QoS Diffserv [11] como base para o modelo de QoS

para prestação de serviços Triple-Play convergentes se dá pela sua simplicidade de implementação e pela sua transparência em relação aos protocolos implementados na camada de rede apresentada na Figura 7.

A camada de mediação, apresentada na seção 4.1.1, é capaz de coletar todo o

mapeamento de QoS aplicado na camada de rede (inventário lógico) e as estatísticas de utilização das classes de serviços internas às estruturas de rede.

A disponibilização das estatísticas de utilização do serviço como um todo, de

cada rede ou segmento, para o sistema de OAM provê para a operadora as informações necessárias para o planejamento de capacidade do sistema.

5.3 Mapeamento genérico de ToS (DSCP) para MPLS EXP Bits e 802.1p

A Tabela 2 traz um exemplo do mapeamento entre marcações, dadas as respectivas classes de serviço.

Camada 3 Camada 2

Classe de Serviço PHB / DSCP

802.1q ou MPLS EXP

Sem Prioridade / Sem Classificação 0 0 0

Baixa Prioridade CS1 8 1

Trafego Volume AF11 10 1

Gerência de Enlace CS7 16 7

Cliente-Servidor AF21 18 2

Sinalização CS3 24 3

Missão Critica AF31 26 3

Vídeo Streaming/VoD

CS4 32 4

IPTV AF41 34 4

Telefonia EF 46 5

Gerência de Rede CS6 48 6

Tabela 2 – Mapeamento classes de serviço

Das 7 classes de serviço possíveis nos protocolos de camada 2, além da classe Sem Prioridade / Sem Classificação, devem ser reservadas ao menos 2 níveis para o tráfego de gerenciamento. Caso o protocolo de gerenciamento do enlace seja classificado como sem prioridade ocorre que, nos momentos de sobrecarga de informações no enlace, a taxa de perda dos pacotes de controle pode chegar a um nível acima do tolerado provocando a interpretação nos receptores de falha no enlace e conseqüente interrupção dos transmissores.

De maneira semelhante, tabelas de roteamento não recebidas dentro do tempo limite esperado, podem provocar no receptor a interpretação de retirada de elementos da tabela de encaminhamento, alterando a topologia conhecida da rede.

Dessa forma, torna-se recomendável que o tráfego de gerenciamento do enlace e

o tráfego de gerência de rede recebam classificações e conseqüentemente ocupem filas específicas. Aplicações de rede como videoconferência sobre IP normalmente realizam a transmissão das mídias de tempo real (vídeo e áudio) utilizando pacotes UDP com o tráfego de controle da conexão lógica utilizando TCP.

Se os protocolos TCP e UDP utilizarem uma mesma classe de serviço, nos momentos de congestionamento da classe por alto interesse de tráfego, por exemplo, a ação do TCP ao longo do tempo será a diminuição da taxa de transmissão, enquanto o UDP manterá a sua taxa de transmissão original. Assim, cada vez que o TCP diminui sua taxa de transmissão a banda disponibilizada é automaticamente ocupada pela aplicação baseada em UDP, provocando um colapso na aplicação de controle baseada no transporte via TCP, que tem seu tempo de vida ultrapassado. A utilização de uma classe de serviço específica ou compartilhada com aplicações baseadas em TCP, para o transporte dos tráfegos de sinalização das aplicações que tenham essa característica torna-se recomendável.

5.4 Solução de QoS para serviços Triple-Play convergentes A solução de QoS para serviços Triple-Play convergentes pode ser resumido através da Tabela 3, levando-se em consideração uma banda disponível para cada

usuário de 10Mbps, dois canais de telefonia, com codificador G.711 e dois canais de TV SDTV com MPEG-4.

Tabela 3 – Solução de QoS para serviços Triple-Play convergentes

A arquitetura Diffserv, usada como base para esse modelo, trabalha com os conceitos de compartilhamento de banda, permitindo que fatias de banda não utilizadas por uma determinada classe de serviço sejam realocadas para outras classes, otimizando o uso da banda total disponível. Para viabilizar a realocação dinâmica de banda é necessário que cada classe de serviço possua, além do seu valor de banda reservada, um valor de banda de pico. Aplicações cujas características e requisitos, conforme apresentados na Seção 3, são restritos, como para Voz sobre IP e IPTV, além do tráfego das classes de gerenciamento de rede e enlace, os valores de banda reservada serão sempre iguais aos valores de banda de pico. Para as demais aplicações, como nem sempre as características e requisitos são conhecidos, é permitido que a banda de pico seja correspondente a banda total do enlace. A classe de serviço reservada para a tráfego com o portal de Auto-Provisionamento não necessita de banda de pico com valor acima da banda reservada, uma vez que a taxa proposta é suficiente para a interação do usuário com o portal. A Tabela 4 traz os valores de banda reservada e de pico tendo como base as classes de serviços da Tabela 3.

Camada 3 Camada 2

Classe de Serviço PHB

Banda Reservada

(Mbps) 802.1q ou

MPLS EXP

Banda Reservada

(Mbps)

Internet 0 2,5 0 2,5

Jogos AF11 1,5 1 1,5

Gerência de Enlace CS2 0,11 2

Portal de Auto-Provisionamento

AF21 0,1 2 0,21

Sinalização (Telefonia e IPTV) CS3 0,1 3 0,1

Vídeo Streaming / VoD CS4 1,4 4

TV (IPTV) AF41 4 4 5,4

Telefonia EF 0,18 5 0,18

Gerência de Rede CS6 0,11 6 0,11

Banda Total (Mbps) 10 10

Classe de Serviço Banda

Reservada (Mbps)

Banda de Pico

(Mbps)

Internet 2,5 10

Jogos 1,5 10

Gerência de Enlace 0,11 0,11

Portal de Auto-Provisionamento 0,1 0,1

Sinalização (Telefonia e IPTV) 0,1 0,1

Vídeo Streaming / VoD

1,4 10

TV (IPTV) 4 4

Telefonia 0,18 0,18

Gerência de Rede 0,11 0,11

Banda Total (Mbps) 10

Tabela 4 – Bandas reservada e de pico, por classe de serviço

Além dos valores de reserva de banda os requisitos delay, jitter e perda de pacotes por pacotes devem ser permanentemente auditados pelo sistema de OAM (seção 4.1.1), sempre do ponto de origem da aplicação ao ponto de destino, tendo como base a Tabela 5.

Requisito Delay (ms)

Jitter (ms)

Perda de Pacotes

(%)

Internet 5000 500 1

Jogos 4000 até 400 1

Gerência de Enlace 150 150 0,5

Portal de Auto-Provisionamento 500 500 1

Sinalização (Telefonia e IPTV) 150 30 0,25

Vídeo Streaming / VoD

3000 até 300 1

TV (IPTV) 3000 30 0,5

Telefonia 150 até 150 0,25

Gerencia de Rede 150 150 0,5

Tabela 5 – Requisitos de Delay, Jitter e Perda de Pacotes

6. Conclusão Uma proposta de solução de QoS para serviços Triple-Play exige o entendimento primário das suas aplicações, de suas formas de prestação e as arquiteturas de rede possíveis. A busca pela solução de rede convergente remete a tentativa de diminuição do número de redes em operação, o que provoca a diminuição de custos pela operadora e principalmente a capacidade de operação unificada do sistema. A operação unificada, por sua vez, traz o desafio da integração entre diferentes EMS e do compartilhamento de um único meio de acesso para entrega dos serviços exigindo o entendimento dos requisitos específicos de cada aplicação e consumindo recursos financeiros para desenvolvimento de sistemas. Uma vez desenvolvidos os sistemas, entretanto, a operadora prestadora do serviço Triple-Play passa a possuir uma plataforma que lhe permitirá a operação simplificada do sistema, a auditoria on-line de todos os recursos físicos e lógicos disponíveis ou em uso, a rápida adequação às necessidades do usuário, a introdução simplificada de outras tecnologias de acesso e a implementação de modelos de QoS específicos para cada segmento da sua rede.

7. Referências [1] Triple Play - The future of media convergence. Disponível em: < http://www.praxis-profiline.de/bestellung-e.htm>. Acesso em 14 de nov. 2007. [2] Metro Ethernet Network Architecture Framework Part 1 (MEF4): Generic Framework. Disponível em: < http://metroethernetforum.org/techspec.htm>. Acesso em 12 de nov. 2007 [3] Metro Ethernet Services Definitions Phase I (MEF6). Disponível em: < http://metroethernetforum.org/techspec.htm>. Acesso em 12 de nov. 2007 [4] Ethernet Services Attributes Phase 2 (MEF 10.1). Disponível em: < http://metroethernetforum.org/techspec.htm>. Acesso em 12 de nov. 2007 [5] BUILDING the carrier - class IP next-generation network. Disponível em: <http://www.cisco.com/en/US/partner/netsol/ns548/networking_solutions_white_paper0900aecd802e2a52.shtml>. Acesso em 17 de ago. 2006. [6] Service Provider Quality of Service Design Guide. Disponível em http://www.cisco.com/en/US/partner/netsol/ns590/networking_solutions_white_paper09186a00801b1c5a.shtml>. Acesso em 10 de out. 2007 [7] IEEE 802.3ah-2004, “Ethernet in the First Mile Task Force” [8] IEEE 802.1ag Draft8, “Connectivity Fault Management” [9] [DiffServ_2474] K.Nichols, S. Blake, F. Baker, D. Black, Definition of the Differentiated Services Field (DS Fiel) in the IPv4 and IPv6 Headers, RFC 2474, dez. 1998. [10] [DiffServ_2475] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss, An Architetcture for Differentiated Services, RFC 2475, dez. 1998. [11] SRIVINAS, Vegesna. IP Quality of Service. S.l: Macmillan Technical Pub, 2001, 343 p.