Quem sou eu
- J. R. Smolka
- Salvador, BA, Brazil
- Analista de sistemas, expert em telecom, formado em Eng. Elétrica e nerd assumido
sábado, 29 de outubro de 2011
quinta-feira, 27 de outubro de 2011
Network capacity planning - um algoritmo
Vamos primeiro definir: o que é fazer planejamento de capacidade? É garantir que os recursos da sua rede (enlaces de comunicação e nós de comutação de pacotes) sejam capazes de cursar o tráfego previsto sem entrar em congestionamento.
Neste artigo vou apresentar um algoritmo simples para, conhecido o interesse de tráfego (em K/M/Gbps e K/M/Gpps) bidirecional entre todos os pontos de ingresso e egresso de tráfego na rede, calcular o volume de tráfego na HMM (Hora de Maior Movimento) em cada enlace e em cada nó da rede.
Os nós de comutação de pacotes da rede (roteadores e switches) são descritos como um vetor (array unidimensional) de estruturas de dados. Cada estrutura S(i) contém um acumulador do volume de tráfego cursado em K/M/Gbps (bits/s) e um acumulador do volume de tráfego cursado em K/M/Gpps (packets/s), para cada hora do dia, conforme o modelo abaixo.
Como regra geral vou usar sempre a seguinte convenção para os itens de hora: cada rótulo hh:00 acumula o tráfego desde a hora hh:00:00 até a hora hh:59:59. Exemplo: o rótulo 13:00 representa os valores desde 13:00:00 até 13:59:59.
Outra dúvida comum é: porque os volumes de tráfego em K/M/Gbps e em K/M/Gpps? Aplicações diferentes geram tamanhos médios de pacote diferentes. Aplicações tipo VoIP geram um K/M/Gpps alto, porém com um K/M/Gbps modesto. O contrário acontece com aplicações como, por exemplo, transferência de arquivos. Como a capacidade dos elementos de comutação não depende somente dos K/M/Gbps trafegados, mas tem um limite muito mais sensível para o K/M/Gpps máximo, ambos os números são importantes.
Para representar a topologia da rede vamos usar uma matriz (array bidimensional) de estruturas de dados. A numeração dos elementos nas dimensões i e j da matriz de topologia replicam a numeração da dimensão i do vetor de nós de comutação. Desta forma cada estrutura T(i,j) representa a existência (ou não) de um enlace de comunicação entre os elementos i e j do vetor de nós de comutação e o volume de tráfego esperado, em K/M/Gbps e K/M/Gpps, a cada hora, na direção de i para j. Obviamente, se existe o enlace T(i,j) então também tem que existir o enlace T(j,i), que representa o tráfego na direção reversa (de j para i) do enlace.
Abaixo temos um modelo para o elemento T(i,j)
Matriz de interesse de tráfego:
Cada estrutura I(i,j) desta matriz (array bidimensional) indica o particionamento do tráfego, em K/M/Gbps e K/M/Gpps, por hora do dia, originado no nó de comutação i e direcionado ao nó de comutação j, conforme o modelo abaixo.
Uma situação comum é a existência concomitante do tráfego dos serviços A, B, C, ... cursando pela rede. Neste caso é necessário montar uma matriz de interesse de tráfego para cada serviço individual, e depois executar o algoritmo com a matriz de interesse de tráfego total, ou seja, se IA(i,j), IB(i,j), IC(i,j), ... são as matrizes de interesse de tráfego, respectivamente, para os serviços A, B, C, ..., então o algoritmo deve ser executado sobre a matriz de interesse de tráfego obtida pela operação
Matriz de rotas:
A matriz de rotas é um array tridimensional que descreve a sequência dos nós de comutação que deve ser percorrida pelo tráfego. Visualmente podemos imaginar esta matriz como um cubo.
As dimensões i e j definem, respectivamente, os nós de comutação de início e fim da rota. cada instância da dimensão k declara a identificação (numérica, correspondente à numeração dos nós de comutação) de um dos nós de comutação na rota que vai do nó de comutação i até o nó de comutação j. Consequentemente o primeiro nó de comutação em cada rota é dado, implicitamente, pelo valor da dimensão i. E rota encerra´se quando localizamos um elemento na dimensão k cujo valor seja igual a j.
A forma mais simples de executar este algoritmo é considerar o conteúdo das estruturas de dados que representem a situação normal de operação. Caso queira-se analisar também o comportamento da rede em situações de contingência é necessário criar novas versões das estruturas de dados, uma para cada situação de contingência que se deseje testar.
Neste caso os valores de tráfego em HMM em cada enlace e em cada nó de comutação será o pior caso obtido em cada ponto da rede, considerados todos os cenários testados.
Esta é, talvez, a parte mais complexa da utilização prática deste algoritmo, porque exige o conhecimento prévio da estrtura de rotas negociada entre os nós de comutação, geralmente pelo uso de algum protocolo de roteamento dinâmico (OSPF, IS-IS, etc.). Mesmo nos casos onde seja usada alguma forma de "circuitização de pacotes" (ex.: MPLS-TE) nem sempre é fácil saber com antecedência as rotas correspondentes ao cenário considerado (normal ou contingência).
Em termos práticos é necessário observar o comportamento real da rede em cada situação desejada, ou simular o comportamento dos algoritmos de roteamento dinâmico para definir quais rotas devem ser inseridas na matriz.
Uma vez que buscamos o dimensionamento dos elementos da rede de tal forma que, mesmo em HMM, eles não apresentem congestionamento (e, talvez, para que não entrem em congestionamento mesmo em certas situações de contingência), temos que pensar um pouco sobre que valores de tráfego devemos considerar para cada hora do dia (por serviço, se for o caso).
O comportamento do tráfego medido em uma determinada hora não é constante. Existem diferenças, para a mesma hora, entre os diferentes dias da semana, feriados, etc. Quando tabhulamos estas variações obtemos (muito provavelmente) uma distribuição de frequência normal, para a qual calculamos o valor médio e o desvio padrão.
Minha sugestão, já que estamos projetando para o pico de tráfego em HMM, em cada hora considere como valor do tráfego (em bps e pps) o valor médio mais quatro desvios-padrão. Desta forma a probabilidade que qualquer tráfego observado seja menor ou igual a este valor é de, aproximadamente 99,69%
O algoritmo:
Pois bem... agora podemos iniciar o processamento dos dados.
Tudo começa pelo percurso sistematicamente da matriz de interesse de tráfego e, para cada par (i,j) de origem e destino de tráfego, Acumular (para todas as horas do dia) o tráfego nos nóe e links ao longo da rota que une o nó de comutação i ao nó de comutação j.
Vou representar os trechos do algoritmo usando a linguagem REXX. A sintaxe é muito simples e intuitiva. Não creio que isso venha a dificultar a compreensão pelos interessados. Não está mostrada a parte inicial de leitura dos dados nas respectivas estruturas.
Um detalhe da implementação mostrada: a linguagem REXX permite que o contexto das variáveis de um procedimento seja ou não visível para os procedimentos que ele invoca. A forma sintática que estou apresentando expõe todo o espaço de variáveis do procedimento invocador para os procedimentos invocados.
Como o primeiro nó de comutação na rota de i para j é o próprio nó i, a primeira coisa a fazer é acumular o tráfego (de todas as horas) no nó de comutação i. A seguir fazemos o percurso da rota até encontrar o elemento que contém o valor j, que marca o final da rota. Para cada elemento ao longo da rota (nós de comutação e enlaces) acumulamos o tráfego de i para j indicado na matriz de interesse de tráfego.
Uma observação sintática: a construção "DO WHILE" na linguagem REXX executa o teste da condição de controle no final do loop, o que resulta em pelo menos uma execução das instruções contidas no loop. O loop será executado enquanto o resultado da condição de controle for o valor lógico "VERDADEIRO"
Resta agora detalhar cada um do procedientos de acumulação do tráfego. Vejamos primeiro a acumulação por nó.
O nó alvo da acumulação é passado para o procedimento como um parâmetro, que é recuperado pela instrução "PARSE ARG". A variável índice da variação das horas começa do valor 1 (indicando o período das 00:00:00 às 00:59:59), somente porque a linguagem REXX não aceita valores de índice iguais a zero.
Aliás, o uso da hora como índice transforma, na prática, o vetor de nós de comutação em um array bidimensional, e a matriz de interesse de tráfego em um array tridimensional.
O procedimento de acumulação por enlace é logicamente semelhante ao procedimento de acumulação de tráfego por no, com a diferença que os parâmetros de entrada são dois: ponta A e ponta B do enlace. Da mesma forma que no procedimento anterior, a matriz de topologia transforma-se, na prática, em um array tridimensional, com o acréscimo do indice de hora.
Não estão mostrados os procedimentos para exibição/impressão dos resultados.
Após a execução do algoritmo o vetor dos nós de comutação e a matriz de topologia contém o tráfego acumulado sobre cada elemento, conforme indicado pela matriz de interesse de tráfego.
Para cada elemento representado nestas estruturaas de dados a sequência temporal dos valores indicará qual hora representa a HMM daquele elemento (que não é, necessariamente, a mesma sobre toda a rede).
O valor a ser considerado para dimensionamento dos nós de comutação é o valor de K/M/Gbps e K/M/Gpps na HMM daquele elemento. A especificação do roteador ou switch para este ponto da rede deve atender, no mínimo, a esta demanda de tráfego.
Para o dimensionamento dos enlaces é necessário comparar os valores de K/M/Gbps em HMM de cada enlace nas duas direções (porque o volume de tráfego sobre o enlace pode ser assimétrico). O valor para dimensionamento do enlace (i,j) deve ser o maior valor de HMM entre esta direção e a direção reversa (j,i).
No próximo artigo vou apresentar um caso-exemplo de utilização deste algoritmo. Inté...
Neste artigo vou apresentar um algoritmo simples para, conhecido o interesse de tráfego (em K/M/Gbps e K/M/Gpps) bidirecional entre todos os pontos de ingresso e egresso de tráfego na rede, calcular o volume de tráfego na HMM (Hora de Maior Movimento) em cada enlace e em cada nó da rede.
Vetor dos nós de comutação:
Os nós de comutação de pacotes da rede (roteadores e switches) são descritos como um vetor (array unidimensional) de estruturas de dados. Cada estrutura S(i) contém um acumulador do volume de tráfego cursado em K/M/Gbps (bits/s) e um acumulador do volume de tráfego cursado em K/M/Gpps (packets/s), para cada hora do dia, conforme o modelo abaixo.
Como regra geral vou usar sempre a seguinte convenção para os itens de hora: cada rótulo hh:00 acumula o tráfego desde a hora hh:00:00 até a hora hh:59:59. Exemplo: o rótulo 13:00 representa os valores desde 13:00:00 até 13:59:59.
Outra dúvida comum é: porque os volumes de tráfego em K/M/Gbps e em K/M/Gpps? Aplicações diferentes geram tamanhos médios de pacote diferentes. Aplicações tipo VoIP geram um K/M/Gpps alto, porém com um K/M/Gbps modesto. O contrário acontece com aplicações como, por exemplo, transferência de arquivos. Como a capacidade dos elementos de comutação não depende somente dos K/M/Gbps trafegados, mas tem um limite muito mais sensível para o K/M/Gpps máximo, ambos os números são importantes.
Matriz de topologia da rede:
Para representar a topologia da rede vamos usar uma matriz (array bidimensional) de estruturas de dados. A numeração dos elementos nas dimensões i e j da matriz de topologia replicam a numeração da dimensão i do vetor de nós de comutação. Desta forma cada estrutura T(i,j) representa a existência (ou não) de um enlace de comunicação entre os elementos i e j do vetor de nós de comutação e o volume de tráfego esperado, em K/M/Gbps e K/M/Gpps, a cada hora, na direção de i para j. Obviamente, se existe o enlace T(i,j) então também tem que existir o enlace T(j,i), que representa o tráfego na direção reversa (de j para i) do enlace.
Abaixo temos um modelo para o elemento T(i,j)
Matriz de interesse de tráfego:
Cada estrutura I(i,j) desta matriz (array bidimensional) indica o particionamento do tráfego, em K/M/Gbps e K/M/Gpps, por hora do dia, originado no nó de comutação i e direcionado ao nó de comutação j, conforme o modelo abaixo.
Uma situação comum é a existência concomitante do tráfego dos serviços A, B, C, ... cursando pela rede. Neste caso é necessário montar uma matriz de interesse de tráfego para cada serviço individual, e depois executar o algoritmo com a matriz de interesse de tráfego total, ou seja, se IA(i,j), IB(i,j), IC(i,j), ... são as matrizes de interesse de tráfego, respectivamente, para os serviços A, B, C, ..., então o algoritmo deve ser executado sobre a matriz de interesse de tráfego obtida pela operação
A matriz de rotas é um array tridimensional que descreve a sequência dos nós de comutação que deve ser percorrida pelo tráfego. Visualmente podemos imaginar esta matriz como um cubo.
As dimensões i e j definem, respectivamente, os nós de comutação de início e fim da rota. cada instância da dimensão k declara a identificação (numérica, correspondente à numeração dos nós de comutação) de um dos nós de comutação na rota que vai do nó de comutação i até o nó de comutação j. Consequentemente o primeiro nó de comutação em cada rota é dado, implicitamente, pelo valor da dimensão i. E rota encerra´se quando localizamos um elemento na dimensão k cujo valor seja igual a j.
Condições normais de tráfego x condições de contingência:
A forma mais simples de executar este algoritmo é considerar o conteúdo das estruturas de dados que representem a situação normal de operação. Caso queira-se analisar também o comportamento da rede em situações de contingência é necessário criar novas versões das estruturas de dados, uma para cada situação de contingência que se deseje testar.
Neste caso os valores de tráfego em HMM em cada enlace e em cada nó de comutação será o pior caso obtido em cada ponto da rede, considerados todos os cenários testados.
Como definir o conteúdo da matriz de rotas?
Esta é, talvez, a parte mais complexa da utilização prática deste algoritmo, porque exige o conhecimento prévio da estrtura de rotas negociada entre os nós de comutação, geralmente pelo uso de algum protocolo de roteamento dinâmico (OSPF, IS-IS, etc.). Mesmo nos casos onde seja usada alguma forma de "circuitização de pacotes" (ex.: MPLS-TE) nem sempre é fácil saber com antecedência as rotas correspondentes ao cenário considerado (normal ou contingência).
Em termos práticos é necessário observar o comportamento real da rede em cada situação desejada, ou simular o comportamento dos algoritmos de roteamento dinâmico para definir quais rotas devem ser inseridas na matriz.
Que valores usar na(s) matriz(es) de interesse de tráfego?
Uma vez que buscamos o dimensionamento dos elementos da rede de tal forma que, mesmo em HMM, eles não apresentem congestionamento (e, talvez, para que não entrem em congestionamento mesmo em certas situações de contingência), temos que pensar um pouco sobre que valores de tráfego devemos considerar para cada hora do dia (por serviço, se for o caso).
O comportamento do tráfego medido em uma determinada hora não é constante. Existem diferenças, para a mesma hora, entre os diferentes dias da semana, feriados, etc. Quando tabhulamos estas variações obtemos (muito provavelmente) uma distribuição de frequência normal, para a qual calculamos o valor médio e o desvio padrão.
Minha sugestão, já que estamos projetando para o pico de tráfego em HMM, em cada hora considere como valor do tráfego (em bps e pps) o valor médio mais quatro desvios-padrão. Desta forma a probabilidade que qualquer tráfego observado seja menor ou igual a este valor é de, aproximadamente 99,69%
O algoritmo:
Tudo começa pelo percurso sistematicamente da matriz de interesse de tráfego e, para cada par (i,j) de origem e destino de tráfego, Acumular (para todas as horas do dia) o tráfego nos nóe e links ao longo da rota que une o nó de comutação i ao nó de comutação j.
Vou representar os trechos do algoritmo usando a linguagem REXX. A sintaxe é muito simples e intuitiva. Não creio que isso venha a dificultar a compreensão pelos interessados. Não está mostrada a parte inicial de leitura dos dados nas respectivas estruturas.
Um detalhe da implementação mostrada: a linguagem REXX permite que o contexto das variáveis de um procedimento seja ou não visível para os procedimentos que ele invoca. A forma sintática que estou apresentando expõe todo o espaço de variáveis do procedimento invocador para os procedimentos invocados.
Como o primeiro nó de comutação na rota de i para j é o próprio nó i, a primeira coisa a fazer é acumular o tráfego (de todas as horas) no nó de comutação i. A seguir fazemos o percurso da rota até encontrar o elemento que contém o valor j, que marca o final da rota. Para cada elemento ao longo da rota (nós de comutação e enlaces) acumulamos o tráfego de i para j indicado na matriz de interesse de tráfego.
Uma observação sintática: a construção "DO WHILE" na linguagem REXX executa o teste da condição de controle no final do loop, o que resulta em pelo menos uma execução das instruções contidas no loop. O loop será executado enquanto o resultado da condição de controle for o valor lógico "VERDADEIRO"
Resta agora detalhar cada um do procedientos de acumulação do tráfego. Vejamos primeiro a acumulação por nó.
O nó alvo da acumulação é passado para o procedimento como um parâmetro, que é recuperado pela instrução "PARSE ARG". A variável índice da variação das horas começa do valor 1 (indicando o período das 00:00:00 às 00:59:59), somente porque a linguagem REXX não aceita valores de índice iguais a zero.
Aliás, o uso da hora como índice transforma, na prática, o vetor de nós de comutação em um array bidimensional, e a matriz de interesse de tráfego em um array tridimensional.
O procedimento de acumulação por enlace é logicamente semelhante ao procedimento de acumulação de tráfego por no, com a diferença que os parâmetros de entrada são dois: ponta A e ponta B do enlace. Da mesma forma que no procedimento anterior, a matriz de topologia transforma-se, na prática, em um array tridimensional, com o acréscimo do indice de hora.
Não estão mostrados os procedimentos para exibição/impressão dos resultados.
Como avaliar os resultados?
Após a execução do algoritmo o vetor dos nós de comutação e a matriz de topologia contém o tráfego acumulado sobre cada elemento, conforme indicado pela matriz de interesse de tráfego.
Para cada elemento representado nestas estruturaas de dados a sequência temporal dos valores indicará qual hora representa a HMM daquele elemento (que não é, necessariamente, a mesma sobre toda a rede).
O valor a ser considerado para dimensionamento dos nós de comutação é o valor de K/M/Gbps e K/M/Gpps na HMM daquele elemento. A especificação do roteador ou switch para este ponto da rede deve atender, no mínimo, a esta demanda de tráfego.
Para o dimensionamento dos enlaces é necessário comparar os valores de K/M/Gbps em HMM de cada enlace nas duas direções (porque o volume de tráfego sobre o enlace pode ser assimétrico). O valor para dimensionamento do enlace (i,j) deve ser o maior valor de HMM entre esta direção e a direção reversa (j,i).
No próximo artigo vou apresentar um caso-exemplo de utilização deste algoritmo. Inté...
sexta-feira, 21 de outubro de 2011
Redes de telecomunicação (13) - Going all-IP (parte 3)
Estive pensando sobre os assuntos que prometi, no final da parte anterior deste artigo, abordar aqui. Cheguei à concusão que preciso, antes, contextualizar melhor as mudanças de paradigma (ô terminologia batida, sô) envolvidas na prestação de serviços de nova geração. Sem isso não dá para arquitetar uma repartição racional de responsabilidades entre os três grupos atuantes no ecossistema NGN:
E isto é uma das principais dificuldades para analisar com isenção o cenário de evolução das redes de telecom em direção à NGN. É difícil separar o que é uma genuína inovação técnica, ou uma verdadeira tendência, do "ruído de fundo" criado pelo intenso bombardeio de propaganda dos fornecedores de equipamentos e serviços. Principalmente aqueles que tem seu próprio destino umbilicalmente ligado ao destino das próprias operadoras (como, por exemplo, os fornecedores de equipamentos SDH e DWDM).
Se a migração das redes para o modelo NGN ocorrer muito rápido eles ficarão "na chuva". Basicamente eles ouvirão dos seus atuais clientes algo parecido com: "segura aí no pincel, que eu tô levando a escada embora". E a consciência disso (por parte deles) aliada a uma postura leniente (em minha opinião) das operadoras de telecom, que, em vez de traçarem seus próprios roadmaps de evolução tecnológica e de serviços (e, depois disso, selecionarem os vendors capazes de satisfazer suas necessidades), meio que "terceirizam" isso para seus fornecedores. Na maioria dos casos o planejamento das operadoras depende demais daquilo que os fornecedores dizem que dá pra fazer, ou não, e quando. No meu conceito, isso é um caso do rabo abanando o cachorro.
Enfim... isso justifica o ambiente de FUD (fear, uncertainty and disinformation) com relação a redes e serviços all-IP que vemos na maioria das operadoras de telecom. Em grande parte ele é criado e disseminado pelos fornecedores, que tem muito a perder. Mas vou tentar não me deixar levar por isso na minha argumentação.
O ponto principal que temos que reconhecer é que, mais do que uma mudança na filosofia e tecnologia de transporte dos dados (e tudo é dados, inclusive a voz), o que caracteriza uma NGN é a capacidade de prover serviços realmente inovadores aos seus usuários. O que vai caracterizar quais modelos de negócio serão vencedores, ou não, neste contexto será sua real capacidade em suportar estes novos tipos de interação dos usuários.
Falamos muito de novos serviços, de serviços avançados, mas quase ninguém entende direito o que isto significa. Vou tentar dar dois exemplos:
As diversas tecnologias de rede que devem ser integradas e harmonizadas para este cenário estão resumidas no diagrama abaixo (retirado da Recomendação ITU-T Y-110):
O desenho é meio velho (1998), daí ainda mencionar N-ISDN e B-ISDN (respectivamente Narrowband e Broadband Integrated Services Digital Network) como alternativas para o segmento core da NGN. Isto, como vimos em artigo anterior, já foi superado. Mas a ideia geral da variedade de redes de acesso a convergir sobre um core NGN comum (agora all-IP) ainda é válida.
Para o problema de construção de plataformas de redes e serviços de telecom usando componentes COTS a ITU-T produziu um framework chamado CGOE (Carrier-Grade Open Environment), descrito na Recomendação ITU-T Y-2901. O diagrama abaixo (retirado da Recomendação Y-2901) mostra os elementos gerais deste framework.
Arquiteturalmente as NGNs devem separar claramente o estrato de serviço (service stratum) e o estrato da rede de transporte (transport stratum), sendo que cada estrato possui um user plane (onde trafegam os dados de aplicação), um control plane (onde trafegam os dados de sinalização) e um management plane (onde trafegam os dados das aplicações de gerência). Este é o NGN BRM (Basic Reference Model), descrito na Recomendação ITU-T Y.2011, de onde foi retirada a figura abaixo:
Observem que a divisão entre os planos de usuário, controle e gerenciamento dentro de cada estrato é puramente lógica, servindo mais para propósitos administrativos (ex.: determinação dos critérios de QoS aplicáveis a cada caso) do que indicando segregação rígida dos diversos tipos de tráfego dentro de cada estrato.
E assim chegamos, finalmente, no ponto principal para o sucesso da idéia das NGNs: conseguir criar um ecossistema de aplicações que reconheçam um mesmo padrão para a troca de sinalização de controle entre elas. O 3GPP (3rd Generation Partnership Program) fez a primeira proposta abrangente para suportar um ecossistema de aplicações IP que utilizam o protocolo de sinalização SIP (Session Initiation Protocol - veja RFC 3261): o IMS (IP Multimedia Subsystem).
Embora o IMS tenha surgido no contexto das redes móveis, ele mostrou-se bastante adequado para o cenário convergente da NGN, então a ITU-T, na Recomendação Y.2021, adotou o IMS como solução padrão de sinalização SIP para serviços convergentes e all-IP para NGNs.
Vou apresentar a seguir o modelo de referência básico para o IMS, tal como aparece na Recomendação Y.2012, mas aviso logo: tanto a recomendação ITU quanto as especificações do 3GPP que se referm ao IMS causam em mim a impressão que elas foram escritas por computadores, com a intenção de que fossem lidas por máquinas de calcular. Vou (na medida do possível) tentar abrandar isso.
Muito bem... Sem pânico. O primeiro elemento importante a observar é aquela caixinha despretensiosa na parte inferior esquerda do diagrama, marcada UE (User Equipment). Ela representa qualquer tipo de dispositivo que o usuário possa estar utilizando para concetar-se à NGN. A linha do UE para a direita apenas indica que ele tem conectividade IP à NGN, através do estrato de transporte (que, claro, incorpora os segmentos de acesso, backhaul e core).
Os outros relacionamentos importantes do UE são com o AS-FE (Application Server Functional Entity), que é o elemento de tratamento de sinalização no servidor de aplicação que o usuário está tentando acessar (esta comunicação é regida conforme o protocolo de interface Ut - não vou nem tentar detalhar estes protocolos de interface); e com o elemento principal da estrutura do IMS, o CSCF (Call Session Control Function).
O CSCF executa todas as funções que, tradicionalmente, são chamadas de call control: o estabelecimento da sessão (call initiation), os eventos durante a sessão - inclusive aqueles ligados a tarifação (o call control propriamente dito), e o término da sessão (call termination).
O UE entra em contato, usando o protocolo de interface Gm, com o proxy CSCF (P-CSCF). Este elemento pode ser um dos CSCFs nativos da NGN de registro do usuário (nada impede que o CSCF seja implementado de forma distribuída), ou um dos CSCFs da NGN visitada pelo usuário (se ele estiver em roaming em outra NGN). O P-CSCF vai selecionar um serving CSCF (S-CSCF) para executar de fato as funções de call-control. Não vi nenhuma restrição (e acho lógico) que, no caso de um UE dentro da sua própria NGN de registro, as funções de P-CSCF e S-CSCF não possam ser acumuladas por uma única instância do CSCF.
Se a sessão de serviço demandada pelo UE implique em troca de sinalização com servidores que utilizem perfis de sinalização SIP diferentes do IMS, ou outros protocolos de sinalização utilizados em ambiente IP (ex.: H.323), o P-CSCF e o S-CSCF utilizam o serviço de intermediação de um IBC-FE (Interconnection Border gateway Controller Functional Entity), usando o protocolo de interface Mx.
Para os casos de UEs em roaming, ou de tráfego de sinalização que esteja apenas em trânsito através de uma NGN, aparece uma nova variedade de para o CSCF: o interrogating CSCF (I-CSCF), que faz o meio de campo da comunicação entre o P-CSCF e o S-CSCF. A comunicação entre todas estas variantes funcionais do CSCF são regidas pelo protocolo de interface Mw.
O S-CSCF interage com o AS-FE no servidor de aplicação demandado pelo UE através do protocolo ISC (IMS Service Control) e pelo protocolo de interface Ma. Para a correta designação e acesso do S-CSCF ao AS-FE existe a intermediação de elementos de localização (SL-FE - Subscription Locator Functional Entity) e autorização/autenticação (SAA-FE - Service Authentication and Authorization Functional Entity; e SUP-FE - Service User Profile Functional Entity).
Se a sessão de serviço demandada pelo usuário necessita utilizar recursos específicos do estrato de transporte da NGN (ex.: classe de QoS, registro/retirada em grupos de multicast, etc.) o CSCF usa um outro elemento do IMS, o MRFC (Multimedia Resources Control Function), que aciona o elemento MRP-FE (Multimedia Resources Processor Functional Entity) para a implementação das ações específicas de suporte à sessão do serviço no estrato de transporte da NGN.
Para a interoperação de serviços NGN com redes de telecomunicação legadas (PSTN/ISDN) o S-CSCF interage com o MGCF (Media Gateway Control Function). No caso de haver necessidade de trânsito do tráfego entre a NGN e a PSTN/ISDN o S-CSCF utiliza o BGCF (Breakout Gateway Control Function) para determinar qual TMG-FE (Trunking Media Gateway Functional Entity) no estrato de transporte deve ser usado para efetuar o "salto" do tráfego entre as redes. A troca de sinalização fim a fim (SIP/SS7) é mediada por um SG-FE (Signalling Gateway Functional Entity).
Só para terminar, caso vocês ainda não tenham percebido, elementos responsáveis pelo processo de sinalização IMS são chamados Control Functions. Elementos que interagem com o IMS para determinar como executar suas funções corretamente são chamados Functional Entities.
E chega! Acho até que, para um texto introdutório, fui até complexo demais. Isto encerra a série de artigos sobre a evolução das redes (e serviços) de telecom. Espero que tenham gostado da viagem, e até breve.
Auf wiedersehen...
- Operadoras de telecom e seus fornecedores de equipamentos e serviços carrier-class tradicionais;
- Provedores de serviço na Internet (Internet Service Providers - ISPs) e seus fornecedores de equipamentos e serviços Internet-class (que podem ou não ser, também, participantes do grupo anterior de fornecedores);
- Os usuários dos serviços prestados pelos outros grupos.
E isto é uma das principais dificuldades para analisar com isenção o cenário de evolução das redes de telecom em direção à NGN. É difícil separar o que é uma genuína inovação técnica, ou uma verdadeira tendência, do "ruído de fundo" criado pelo intenso bombardeio de propaganda dos fornecedores de equipamentos e serviços. Principalmente aqueles que tem seu próprio destino umbilicalmente ligado ao destino das próprias operadoras (como, por exemplo, os fornecedores de equipamentos SDH e DWDM).
Se a migração das redes para o modelo NGN ocorrer muito rápido eles ficarão "na chuva". Basicamente eles ouvirão dos seus atuais clientes algo parecido com: "segura aí no pincel, que eu tô levando a escada embora". E a consciência disso (por parte deles) aliada a uma postura leniente (em minha opinião) das operadoras de telecom, que, em vez de traçarem seus próprios roadmaps de evolução tecnológica e de serviços (e, depois disso, selecionarem os vendors capazes de satisfazer suas necessidades), meio que "terceirizam" isso para seus fornecedores. Na maioria dos casos o planejamento das operadoras depende demais daquilo que os fornecedores dizem que dá pra fazer, ou não, e quando. No meu conceito, isso é um caso do rabo abanando o cachorro.
Enfim... isso justifica o ambiente de FUD (fear, uncertainty and disinformation) com relação a redes e serviços all-IP que vemos na maioria das operadoras de telecom. Em grande parte ele é criado e disseminado pelos fornecedores, que tem muito a perder. Mas vou tentar não me deixar levar por isso na minha argumentação.
O ponto principal que temos que reconhecer é que, mais do que uma mudança na filosofia e tecnologia de transporte dos dados (e tudo é dados, inclusive a voz), o que caracteriza uma NGN é a capacidade de prover serviços realmente inovadores aos seus usuários. O que vai caracterizar quais modelos de negócio serão vencedores, ou não, neste contexto será sua real capacidade em suportar estes novos tipos de interação dos usuários.
Falamos muito de novos serviços, de serviços avançados, mas quase ninguém entende direito o que isto significa. Vou tentar dar dois exemplos:
- Você está no seu escritório usando um equipamento desktop, em videoconferência com alguns colegas, e a reunião se alonga a ponto de você correr o risco de perder o vôo marcado para o fim da tarde. Então você transfere a sessão de videoconferência do seu desktop (que está usando a rede LAN e o acesso Internet compartilhado do escritório) para o seu laptop/tablet usando acesso wireless 3G/4G e segue para o aeroporto mantendo a videoconferência ativa. Ao chegar no aeroporto você continua com a sessão de videoconferência ativa, porém utilizando a cobertura WiFi do aeroporto como meio de acesso.
- Você usa uma aplicação (no desktop, laptop, tablet ou smartphone - normalmente teremos versões das aplicações adequadas a todos os tipos de plataforma) para programar a sua smart house - ligar o ar condicionado, ativar o microondas onde você deixou o jantar congelado, ligar o aquecedor de água, fechar as cortinas, etc. Mas, em vez de usar um horário específico para cada evento você especifica que todos eles devem ser iniciados após intervalos determinados, contados a partir do recebimento de um sinal disparador. E programa o sistema multimídia do seu carro (que também está conectado) a controlar seu posicionamento em relação à sua casa, e disparar o sinal de acionamento se o tempo estimado de chegada (considerando a rota adotada e as informações de tráfego recebidas) for menor ou igual a, por exemplo, meia hora.
As diversas tecnologias de rede que devem ser integradas e harmonizadas para este cenário estão resumidas no diagrama abaixo (retirado da Recomendação ITU-T Y-110):
O desenho é meio velho (1998), daí ainda mencionar N-ISDN e B-ISDN (respectivamente Narrowband e Broadband Integrated Services Digital Network) como alternativas para o segmento core da NGN. Isto, como vimos em artigo anterior, já foi superado. Mas a ideia geral da variedade de redes de acesso a convergir sobre um core NGN comum (agora all-IP) ainda é válida.
Para o problema de construção de plataformas de redes e serviços de telecom usando componentes COTS a ITU-T produziu um framework chamado CGOE (Carrier-Grade Open Environment), descrito na Recomendação ITU-T Y-2901. O diagrama abaixo (retirado da Recomendação Y-2901) mostra os elementos gerais deste framework.
Arquiteturalmente as NGNs devem separar claramente o estrato de serviço (service stratum) e o estrato da rede de transporte (transport stratum), sendo que cada estrato possui um user plane (onde trafegam os dados de aplicação), um control plane (onde trafegam os dados de sinalização) e um management plane (onde trafegam os dados das aplicações de gerência). Este é o NGN BRM (Basic Reference Model), descrito na Recomendação ITU-T Y.2011, de onde foi retirada a figura abaixo:
Observem que a divisão entre os planos de usuário, controle e gerenciamento dentro de cada estrato é puramente lógica, servindo mais para propósitos administrativos (ex.: determinação dos critérios de QoS aplicáveis a cada caso) do que indicando segregação rígida dos diversos tipos de tráfego dentro de cada estrato.
E assim chegamos, finalmente, no ponto principal para o sucesso da idéia das NGNs: conseguir criar um ecossistema de aplicações que reconheçam um mesmo padrão para a troca de sinalização de controle entre elas. O 3GPP (3rd Generation Partnership Program) fez a primeira proposta abrangente para suportar um ecossistema de aplicações IP que utilizam o protocolo de sinalização SIP (Session Initiation Protocol - veja RFC 3261): o IMS (IP Multimedia Subsystem).
Embora o IMS tenha surgido no contexto das redes móveis, ele mostrou-se bastante adequado para o cenário convergente da NGN, então a ITU-T, na Recomendação Y.2021, adotou o IMS como solução padrão de sinalização SIP para serviços convergentes e all-IP para NGNs.
Vou apresentar a seguir o modelo de referência básico para o IMS, tal como aparece na Recomendação Y.2012, mas aviso logo: tanto a recomendação ITU quanto as especificações do 3GPP que se referm ao IMS causam em mim a impressão que elas foram escritas por computadores, com a intenção de que fossem lidas por máquinas de calcular. Vou (na medida do possível) tentar abrandar isso.
Muito bem... Sem pânico. O primeiro elemento importante a observar é aquela caixinha despretensiosa na parte inferior esquerda do diagrama, marcada UE (User Equipment). Ela representa qualquer tipo de dispositivo que o usuário possa estar utilizando para concetar-se à NGN. A linha do UE para a direita apenas indica que ele tem conectividade IP à NGN, através do estrato de transporte (que, claro, incorpora os segmentos de acesso, backhaul e core).
Os outros relacionamentos importantes do UE são com o AS-FE (Application Server Functional Entity), que é o elemento de tratamento de sinalização no servidor de aplicação que o usuário está tentando acessar (esta comunicação é regida conforme o protocolo de interface Ut - não vou nem tentar detalhar estes protocolos de interface); e com o elemento principal da estrutura do IMS, o CSCF (Call Session Control Function).
O CSCF executa todas as funções que, tradicionalmente, são chamadas de call control: o estabelecimento da sessão (call initiation), os eventos durante a sessão - inclusive aqueles ligados a tarifação (o call control propriamente dito), e o término da sessão (call termination).
O UE entra em contato, usando o protocolo de interface Gm, com o proxy CSCF (P-CSCF). Este elemento pode ser um dos CSCFs nativos da NGN de registro do usuário (nada impede que o CSCF seja implementado de forma distribuída), ou um dos CSCFs da NGN visitada pelo usuário (se ele estiver em roaming em outra NGN). O P-CSCF vai selecionar um serving CSCF (S-CSCF) para executar de fato as funções de call-control. Não vi nenhuma restrição (e acho lógico) que, no caso de um UE dentro da sua própria NGN de registro, as funções de P-CSCF e S-CSCF não possam ser acumuladas por uma única instância do CSCF.
Se a sessão de serviço demandada pelo UE implique em troca de sinalização com servidores que utilizem perfis de sinalização SIP diferentes do IMS, ou outros protocolos de sinalização utilizados em ambiente IP (ex.: H.323), o P-CSCF e o S-CSCF utilizam o serviço de intermediação de um IBC-FE (Interconnection Border gateway Controller Functional Entity), usando o protocolo de interface Mx.
Para os casos de UEs em roaming, ou de tráfego de sinalização que esteja apenas em trânsito através de uma NGN, aparece uma nova variedade de para o CSCF: o interrogating CSCF (I-CSCF), que faz o meio de campo da comunicação entre o P-CSCF e o S-CSCF. A comunicação entre todas estas variantes funcionais do CSCF são regidas pelo protocolo de interface Mw.
O S-CSCF interage com o AS-FE no servidor de aplicação demandado pelo UE através do protocolo ISC (IMS Service Control) e pelo protocolo de interface Ma. Para a correta designação e acesso do S-CSCF ao AS-FE existe a intermediação de elementos de localização (SL-FE - Subscription Locator Functional Entity) e autorização/autenticação (SAA-FE - Service Authentication and Authorization Functional Entity; e SUP-FE - Service User Profile Functional Entity).
Se a sessão de serviço demandada pelo usuário necessita utilizar recursos específicos do estrato de transporte da NGN (ex.: classe de QoS, registro/retirada em grupos de multicast, etc.) o CSCF usa um outro elemento do IMS, o MRFC (Multimedia Resources Control Function), que aciona o elemento MRP-FE (Multimedia Resources Processor Functional Entity) para a implementação das ações específicas de suporte à sessão do serviço no estrato de transporte da NGN.
Para a interoperação de serviços NGN com redes de telecomunicação legadas (PSTN/ISDN) o S-CSCF interage com o MGCF (Media Gateway Control Function). No caso de haver necessidade de trânsito do tráfego entre a NGN e a PSTN/ISDN o S-CSCF utiliza o BGCF (Breakout Gateway Control Function) para determinar qual TMG-FE (Trunking Media Gateway Functional Entity) no estrato de transporte deve ser usado para efetuar o "salto" do tráfego entre as redes. A troca de sinalização fim a fim (SIP/SS7) é mediada por um SG-FE (Signalling Gateway Functional Entity).
Só para terminar, caso vocês ainda não tenham percebido, elementos responsáveis pelo processo de sinalização IMS são chamados Control Functions. Elementos que interagem com o IMS para determinar como executar suas funções corretamente são chamados Functional Entities.
E chega! Acho até que, para um texto introdutório, fui até complexo demais. Isto encerra a série de artigos sobre a evolução das redes (e serviços) de telecom. Espero que tenham gostado da viagem, e até breve.
Auf wiedersehen...
sábado, 1 de outubro de 2011
Teste de afinidade com programação Assembly - entendendo o exemplo
Se você estiver na lamentável situação de nem sequer iniciar o teste porque não conseguiu entender o funcionamento do programa apresentado no exemplo, e porque ele é uma solução válida para o problema, não desespere.
Sua situação, na verdade, corresponde à maioria das pessoas que fazem o teste sem nenhum conhecimento prévio de linguagens de programação de baixo nível e/ou toria da computação e/ou arquitetura de computadores.
Para facilitar a sua vida vou fazer algo bem fora de moda hoje em dia: um teste de mesa. Vamos simular (por escrito) a execução passo a passo do programa e verificar se o efeito produzido corresponde ao que se pede.
Cada passo do programa será representado da seginte forma:
Vamos começar. Esta é a situação inicial (válida para todos os casos): cabeçotes de leitura e gravação posicionados no início da mídia e primeira instrução a executar no endereço de memória 0.
Após a execução da instrução T, como o caracter lido na mídia foi um *, a próxima instução a executar estará no endereço de memória 0 + 2 = 2. Observe a nova posição do cabeçote de leitura.
Agora a instrução executada é H, que grava um - na mídia e reposiciona o cabeçote de gravação. Próxima instrução a executar está no endereço de memória 3.
Desvio incondicional para a instrução no endereço de memória 0.
Voltamos à instrução T. Após execução o cabeçote de leitura é reposicionado e, como o caraccter lido foi um -, a próxima instrução a executar está no endereço de memória 0 + 1 = 1.
Desvio incondicional para a instução no endereço de memória 4.
Executa a instrução A, que grava um * na mídia e reposiciona o cabeçote de gravação. Próxima instrução a executar está no endereço 5.
O desvio para a instrução na posição de memória 0 voltará a executar a instrução T. A esta altura já dá para perceber toda a mecânica de execução do programa, que vai percorrer toda a mídia (supostamente de comprimento infinito) substituindo os caracteres * por -, e vice versa, como pedido.
Se ainda assim você não consegue entender como escrever os programas para solucionar os problemas propostos, então realmente é melhor você se dedicar a linguagens com sintaxe mais abstrata.
Sua situação, na verdade, corresponde à maioria das pessoas que fazem o teste sem nenhum conhecimento prévio de linguagens de programação de baixo nível e/ou toria da computação e/ou arquitetura de computadores.
Para facilitar a sua vida vou fazer algo bem fora de moda hoje em dia: um teste de mesa. Vamos simular (por escrito) a execução passo a passo do programa e verificar se o efeito produzido corresponde ao que se pede.
Cada passo do programa será representado da seginte forma:
Vamos começar. Esta é a situação inicial (válida para todos os casos): cabeçotes de leitura e gravação posicionados no início da mídia e primeira instrução a executar no endereço de memória 0.
Após a execução da instrução T, como o caracter lido na mídia foi um *, a próxima instução a executar estará no endereço de memória 0 + 2 = 2. Observe a nova posição do cabeçote de leitura.
Agora a instrução executada é H, que grava um - na mídia e reposiciona o cabeçote de gravação. Próxima instrução a executar está no endereço de memória 3.
Voltamos à instrução T. Após execução o cabeçote de leitura é reposicionado e, como o caraccter lido foi um -, a próxima instrução a executar está no endereço de memória 0 + 1 = 1.
Desvio incondicional para a instução no endereço de memória 4.
Executa a instrução A, que grava um * na mídia e reposiciona o cabeçote de gravação. Próxima instrução a executar está no endereço 5.
O desvio para a instrução na posição de memória 0 voltará a executar a instrução T. A esta altura já dá para perceber toda a mecânica de execução do programa, que vai percorrer toda a mídia (supostamente de comprimento infinito) substituindo os caracteres * por -, e vice versa, como pedido.
Se ainda assim você não consegue entender como escrever os programas para solucionar os problemas propostos, então realmente é melhor você se dedicar a linguagens com sintaxe mais abstrata.
Assinar:
Postagens (Atom)