Fundamentação Teórica
2.4 Qualidade de Serviço(QoS)
Alguns esforços do Internet Engineering Task Force (IETF) para prover a QoS são descritos na Seção 2.4.1 (EL-GENDY; BOSE; SHIN, 2003)(SHARAFAT et al., 2011). A Seção 2.4.2 fará uma breve análise dos aspectos negativos dos mecanismos propos- tos pelo IETF, e as vantagens oferecidas pelas SDNs caso sejam usadas em conjunto ou como alternativa aos protocolos descritos na Seção 2.4.1 (EL-GENDY; BOSE; SHIN, 2003)(REID; KATCHABAW, 2004)(DAS; PARULKAR; MCKEOWN, 2012) (SHARA- FAT et al., 2011).
2.4.1 Propostas tradicionais de QoS apresentadas pelo IETF
❏ IntServ: A Arquitetura de Serviços Integrados (IntServ), deĄnida pelo IETF em (BRADEN; CLARK; SHENKER, 1994), foi desenvolvida devido à necessidade de garantir a QoS de aplicações em tempo real, tais como uma conferência multimedia e realidade virtual. Como o IntServ foi desenvolvido para prover QoS por Ćuxo, seria possível ter um controle maior sobre cada tráfego da rede, e esta alta granularidade é fundamental para prover QoS às aplicações em tempo real. Quando uma aplicação requisita uma determinada QoS, o IntServ usa o protocolo Resource ReSerVation
Protocol (RSVP) (BRADEN; ZHANG, 1997) para reservar os recursos requisitados
pela aplicação em todos os roteadores do caminho. O RSVP utiliza a mensagem PATH, que é enviada pelo cliente e passa pelos roteadores do caminho até chegar ao servidor, para deĄnir a característica do tráfego enviado (T-spec), como também, a QoS requisitada (R-spec). Quando a mensagem PATH chega ao servidor, este irá enviar uma mensagem RESV ao cliente, e caso todos os roteadores do caminho aceitem o RESV, a QoS requisitada será alocada e o estado do Ćuxo armazenados nos roteadores. As reservas feitas pelo RSVP para um Ćuxo devem ser atualizadas a cada 30 segundos, através do envio de novas mensagens PATH e RESV, caso contrário, a reserva é desfeita;
2.4. Qualidade de Serviço(QoS) 45
❏ DiffServ: A Arquitetura de Serviços Diferenciados (DiffServ), proposta pelo IETF em (BLAKE et al., 1998), surgiu propondo uma abordagem mais simples e eĄciente que o IntServ, onde não haveria a necessidade de sinalizar e reservar os recursos, e nem manter os estados dos Ćuxos da rede, fazendo com que o DiffServ fosse uma solução ideal para a Internet, já que o IntServ não seria escalável em backbones de milhares ou milhões de Ćuxos. A idéia do DiffServ é classiĄcar os Ćuxos em classes através de uma marca DSCP, de 6 bits, feita no campo Type of Service (TOS) do datagrama IPv4 ou no campo Classe de Tráfego do datagrama IPv6. A partir dessa marca DSCP feita no pacote, seria possível atribuir este pacote a um comportamento de encaminhamento, também chamado de Per-Hop Behavior (PHB). A PHB deĄniria como escalonar o pacote, por exemplo, enviá-lo para uma Ąla de menor atraso, jitter e poucas perdas; de melhor esforço; de maior prioridade; e a Ąla, posteriormente, encaminharia o pacote para uma interface;
❏ MPLS: O MPLS, proposto pelo IETF em (ROSEN; VISWANATHAN; CALLON, 2001), é um esquema de encaminhamento avançado, ele estende o roteamento em relação ao encaminhamento de pacote e controle de caminho. Ele trabalha em uma camada intermediária entre as camadas 2 (Enlace) e 3 (Rede) do modelo Open
Systems Interconnection (OSI). O pacote MPLS possui um cabeçalho de 32 bits
usado para encapsular um pacote IP, sendo que o campo principal do cabeçalho MPLS é o de 20 bits, chamado de rótulo. Em uma rede MPLS é comum usarmos os seguintes termos: Label Switch Router (LSR), Label Edge Router (LER) e Label
Switch Path (LSP). Os LSRs são os roteadores que estão em uma rede MPLS e
são responsáveis por executar algoritmos de encaminhamento e manter a tabela de encaminhamento, e têm como função principal a substituição dos rótulos dos pa- cotes recebidos por outros rótulos e encaminhar os pacotes para a interface correta do dispositivo. Os LERs têm as mesmas funções dos LSRs, entretanto, eles se lo- calizam na entrada do domínio MPLS, e possuem, como funcão adicional, deĄnir uma Forwarding Equivalency Class (FEC) para um conjunto de pacotes, ou seja, os pacotes com características semelhantes, por exemplo, mesmo IP de destino, serão associados a uma FEC e encaminhados por um determinado LSP. O LSP é o ca- minho por onde pacotes, com as mesmas características, irão passar. O MPLS usa protocolos de sinalização para construir LSPs, tais como, o RSVP e o Label Distri-
bution Protocol (LDP). Por Ąm, vale destacar que o MPLS é semelhante ao DiffServ
devido à classiĄcação de Ćuxos em classes, como também ao ATM(KESHAV, 1997) e ao Frame Relay(BRADLEY; BROWN; MALIS, 1992), devido ao uso de rótulos para comutação de pacotes;
❏ GMPLS: O Generalized Multi-Protocol Label Switching (GMPLS), proposto pelo IETF em (MANNIE, 2004), é uma extensão do MPLS para prover novos tipos de
46 Capítulo 2. Fundamentação Teórica
comutações, tais como, por Ąbra, por tempo (TDM) e por comprimento de onda (lambda). Para que o GMPLS suportasse esses novos tipos de comutações foi ne- cessário estender algumas funcionalidades presentes no MPLS, e em alguns casos, adicionar novas funcionalidades. Exemplos de tais funcionalidades são: propaga- ção de erros, propagação de informações de sincronização entre os comutadores de ingresso e de egresso e requisição e distribuição de rótulos. Outras características do GMPLS é que não há uma restrição do modelo de interconexão utilizado entre as redes, há a separação entre o Plano de Controle (sinalização e roteamento) e o Plano de Dados, existe a possibilidade de estabelecer caminhos bidirecionais, entre outros.
2.4.2 SDN e Protocolos Tradicionais
Os protocolos tradicionais, citados na Seção 2.4.1, são bastante utilizados para a oferta de QoS dos usuários Ąnais. Entretanto, eles possuem algumas desvantagens, e também podem ser usados em conjunto com a Arquitetura SDN para a oferta de QoS especiĄcada pelo SLA do usuário.
Algumas desvantagens do IntServ são, todos os roteadores precisam ter noção do pro- tocolo RSVP e serem capazes de sinalizar a QoS requerida; as reservas em cada dispositivo devem ser atualizadas periodicamente, ocasionando aumento do tráfego na rede e aumen- tando a chance de que as reservas possam expirar se os pacotes de atualização forem perdidos; manter os estados em cada roteador, combinando com controle de admissão em cada salto e aumento dos requisitos de memória para permitir um número maior de reservas, fazendo com que seja necessário roteadores mais robustos. Com o uso do pro- tocolo OpenFlow, a QoS pode ser aplicada diretamento nos Ćuxos dos comutadores pelo controlador sem o uso do protocolo RSVP, sem a necessidade de atualização constante, sem envio de tráfego na rede e usando apenas dispositivos comoditizados.
Algumas desvantagens do DiffServ incluem, o gerenciamento e o monitoramento com- plexos, há a perda da granularidade, pois o QoS é aplicado na classe e há a necessidade de classiĄcar o tráfego da rede em classes. Com o uso do protocolo OpenFlow é possível ge- renciar e monitorar a rede com mensagens já pré-deĄnidas ou desenvolvendo ferramentas de acordo com a vontade do usuário, não existe perda de granularidade, pois é possí- vel trabalhar com Ćuxos individualmente e com seus campos de match, e não existe a necessidade de classiĄcação de tráfego em classes.
Um dos maiores problemas do MPLS/GMPLS é que eles Ącam limitados aos protocolos de Engenharia de Tráfego existentes, tais como o OSPF, LDP, RSVP-TE e I-BGP. Além disso, muitos desses protocolos foram estendidos para funcionar no MPLS/GMPLS. O RSVP, por exemplo, foi desenvolvido como um protocolo para sinalização de recursos em uma rede na Arquitetura IntServ, depois estendido para o uso no MPLS e depois para o GMPLS, gerando um protocolo mais complexo e de codiĄcação maior, ocasionando
2.4. Qualidade de Serviço(QoS) 47
desperdício de recursos. O uso de protocolos distribuídos eleva o tráfego da rede quando há mudanças constantes na mesma, acarretando desperdício de banda e aumento do atraso do enlace, além do gasto adicional para recálculo de rotas e processamento de informações nos dispositivos de rede. A partir da versão 1.1 do OpenFlow, foram inseridas algumas funcionalidades do MPLS/GMPLS, como o push, pop e swap de rótulos. Com a Arquitetura SDN, o MPLS não Ącará mais limitado a protocolos já existentes, pois um novo protocolo pode ser criado e modiĄcado de acordo com o desejo de cada administrador de rede.
Portanto, é possível perceber que a SDN, e o OpenFlow, não vieram para exterminar os protocolos tradicionais de oferta de QoS, mas sim, como uma arquitetura que pode usá-los de uma forma mais eĄciente, e que possa, também, propor futuras extensões aos mesmos. Essa idéia é reforçada no momento em que o próprio protocolo OpenFlow deĄne mensagens que permitem a inserção de cabeçalho MPLS nos pacotes, como mencionado anteriormente; e também através das meters, é possível implementar operações simples de QoS, podendo ser combinado com as Ąlas das portas para desenvolver frameworks mais complexos, tais como o DiffServ.
Vale ressaltar que, o OpenFlow é um protocolo aberto, e portanto, é possível adicionar novas funcionalidades aos dispositivos, já que não Ącaríamos mais limitados aos protoco- los proprietários, e qualquer grupo de pesquisa poderia, por exemplo, adicionar uma nova funcionalidade ao MPLS ou DiffServ. Esta funcionalidade poderia ser, no futuro, imple- mentada em larga escala, e consequentemente, beneĄciaria toda a indústria, empresas e o usuário Ąnal.
49