4. METODE OG DATAINNSAMLING
4.7 E VALUERING AV DATA OG FORSKNINGSDESIGN
A RFC 791 (POSTELS, 1981), publicada em 1981, apresenta um modelo de tratamento de pacotes através da definição de indicadores em cada unidade de pacotes. Em cada pacote existe um octeto designado de Type of Service (ToS), onde a relevância do pacote (campo precedence) e as necessidades do serviço (campo ToS) são marcadas. O campo ToS fornece uma indicação dos valores teóricos da qualidade de serviço esperada.
No começo da década de 90, foi proposto o modelo chamado de Serviços Integrados, posteriormente chamado Integrated Services (IntServ), RFC 1633 (BRADEN; CLARK; SHENKER, 1994). Esta arquitetura descreveu o conceito de qualidade de serviço relativa ao fluxo, mecanismos de controle de admissão e reserva de recursos. E propôs que recursos, como largura de banda tivesse explicitamente gerenciado de modo a corresponder com os objetivos das aplicações.
Figura 10 - Fluxo dos tokens através dos buckets.
O processo de reserva de recursos e controle de admissão é praticado pelo protocolo de sinalização Resource Reservation Protocol (RSVP) (BRADEN et al., 1999), através do encaminhamento de mensagens de sinalização em cada roteador, envolvidos no transporte do fluxo fim a fim. Este protocolo tem como objetivo observar a disponibilidade de recursos em cada equipamento e, caso haja recurso, processar a reserva de recursos de acordo com a necessidade do fluxo. Não havendo disponibilidade de recursos em quaisquer uns dos roteadores, a reserva não é criada.
Contudo, as características deste protocolo geram consigo sérias dificuldades de escalabilidade, pelo fato que os roteadores precisarem manter o estado, mesmo sem o uso da reserva por uma aplicação, causando desperdício de recursos. Na Figura 11 é mostrado o protocolo RSVP, que prove a reserva de caminho entre dois computadores, encaminhando mensagem de solicitação de reserva e recebendo na origem a resposta para efetivamente processar a reserva de recurso.
Em 1998 a RFC 2474 tornou público a arquitetura DiffServ (NICHOLS et al., 1998) como um padrão escalável, possível de ser instalado em fases, acompanhando a evolução e dentro de domínios de redes administrativas. Na arquitetura DiffServ a unidade essencial é o tráfego agregado, que baseia em fluxos individuais com requisitos semelhantes de QoS, portanto cada tráfego agregado é vinculado a uma classe de serviço, Class of Service (CoS). Deste modo, fluxos individuais que fazem parte do mesmo tráfego agregado obterão tratamentos iguais pela rede, sendo que este tratamento é denominado de comportamento agregado, Behavior Aggregated (BA).
A identificação de cada CoS é executada de forma explícita através de marcação de bits no cabeçalho do pacote IP no campo Differentiated Service Code Point (DSCP). Este campo é uma redefinição do campo ToS, só que agora apenas 6 bits do conjunto de 8 são precisos. Deste modo a marcação do campo DSCP define o tratamento que será executado no
Figura 11- Síntese de operação do RSVP.
transporte dos pacotes em cada roteador. Esta marcação caracteriza o que chamamos de comportamento por salto Per Hop Behavior (PHB).
Enquanto que na arquitetura IntServ os processos de reserva de recursos e controle de admissão são processados localmente pelos roteadores, na arquitetura DiffServ estas tarefas são movidas para o nível do domínio da rede. Deste modo, são as regras do domínio que designam quais pacotes serão aceitos junto à rede. Essas políticas são armazenadas geralmente em uma entidade central e são processadas nas bordas da rede.
O Service Level Agrement (SLA) descreve o comportamento que o tráfego do cliente deve receber dentro do domínio. Utilizam variáveis, tais como: taxa de pico de informação Peak Information Rate (PIR), taxa de informação comprometida Committed Information Rate (CIR), tamanho da rajada comprometida Committed Burst Size (CBS), atraso fim a fim, jitter, entre outros.
Na arquitetura DiffServ a complexidade da rede é atribuída às bordas, possibilitando o tratamento e a transmissão de pacotes no núcleo da rede de modo fácil e eficiente. Os roteadores de borda, denominado de edge router, executa as seguintes funções:
• classificação: vincula o tráfego ao seu correspondente SLA; • medição: calcula as taxas de geração do tráfego (PIR, CIR, CBS);
• marcação: atribui o valor de DSCP relacionado ao PHB aguardado pelos pacotes junto à rede; e
• policiamento: executa ações para os pacotes que apresentam fora de um perfil SLA, tomando decisão sobre o descarte os pacotes, ou designação um valor de DSCP com qualidade de serviço inferior, ou retardar a transmissão dos pacotes.
Na Figura 12 ilustram-se as funções dos roteadores de borda e de núcleo. Os roteadores de núcleo ou interior da rede introduz o PHB conforme a marcação no campo DSCP, apoiando-se em métodos de gerenciamento de filas, escalonamento e descarte de pacotes.
Figura 12 - Funções dos roteadores de borda e de núcleo.
O tratamento uniforme atribuído a uma determinada classe de serviço, durante todo o domínio, chamado de comportamento por domínio Per Domain Behavior (PDB). A exclusão do processo de reserva de recurso e controle de admissão, do nível dos roteadores para o nível do domínio da rede, é vista como o desmembramento entre o plano de dados e o plano de controle.
• plano de controle: suporta o roteamento e muda informações de rótulos entre os dispositivos adjacentes; e
• plano de dados: também denominado como plano de encaminhamento, encaminha as informações com base nos endereços ou rótulos de destino.
Na Figura 13 demonstra-se o processo de controle de admissão na arquitetura DiffServ. O Fluxo de dados é admitido junto ao tráfego agregado, logo após corresponder à condição definida por políticas/regras do domínio no roteador de borda. Este comportamento é válido em todo domínio, pois a política é conhecida por todos os roteadores. A fila é escolhida de acordo com o DSCP especificado.
No processo de controle de admissão um fluxo é admitido junto a um tráfego agregado, e vinculado a um definido PDB. Esse processo pode ser executado de modo estático ou dinâmico, sendo que para a forma dinâmica é exigido sinalização por fluxo proporcionado pela arquitetura DiffServ. Sua escalabilidade é provida pelas características informadas abaixo e são de suma importância:
Figura 13- Controle de admissão na arquitetura DiffServ.
• alteração no controle de admissão, como por exemplo, nas regras do domínio, ocasionam reconfigurações na borda da rede, contudo, não altera as configurações do interior da rede; e
• a decisão em relação à aceitação ou não do fluxo, é armazenada em uma base de dados, definindo as políticas do domínio, e a mesma é encaminhada aos roteadores de borda. Apesar de a arquitetura DiffServ ter demonstrado como uma solução escalável desde a sua concepção, existem ainda alguns desafios a serem alcançados.