Seção: Tutoriais Operação
|
|
||
Vimos na seção Plano de Controle com Rede Independente do tutorial parte I, que em redes modo pacote controladas pelo GMPLS, como redes MPLS por exemplo, o plano de controle opera in-band com o plano de dados, utilizando-se usualmente um único canal para os tráfegos desses dois planos.
Na aplicação do GMPLS para redes ópticas de transporte, no entanto, o plano de controle opera out-of-band com relação ao plano de dados, com redes independentes de diferentes formas.
Para qualquer uma das duas hipóteses, foi definido, na RFC 4204 (Link Management Protocol (LMP)), o protocolo LMP.
O LMP é um protocolo de aplicação ponto a ponto entre dois LSRs GMPLS que são adjacentes no plano de dados, mas que podem ser não adjacentes no plano de controle (podem existir múltiplos roteadores IP entre eles, por exemplo). Os dois LSRs GMPLS entre os quais se aplica o LMP são referidos como vizinhos LMP ou simplesmente nós vizinhos. O LMP tem como suporte o protocolo UDP, utilizando a porta 701. Pelo fato de que se utiliza o UDP, o próprio LMP é responsável pela recuperação de erros no plano de controle.
O LMP requer que os endereços dos canais de controle sejam configurados nos LSRs em seus extremos. Para o funcionamento do LMP, é necessário que exista pelo menos um canal de controle bidirecional ativo entre os dois LSRs. Cada sentido de um canal de controle é identificado por um CC_Id (control channel identifier), cujos valores devem ser únicos em qualquer um dos LSRs.
Os objetos MESSAGE_ID e MESSAGE_ID_ACK são incluídos nas mensagens LMP para permitir a transmissão confiável dessas mensagens.
De acordo com a RFC 4204, um link de dados pode ser considerado, por cada um dos LSRs onde termina, como uma porta ou como um link componente. Links componentes são capacitados para multiplexação, enquanto portas não o são.
A RFC 4204 define dois procedimentos fundamentais para o LMP:
Foram também definidos dois procedimentos adicionais para o LMP:
Gerenciamento de Canal de Controle
Para que o plano de controle no GMPLS entre em operação, é necessário que pelo menos um canal de controle esteja ativado. Como é do conhecimento dos leitores, os canais de controle no GMPLS são utilizados para a transmissão das mensagens de roteamento, de sinalização e do protocolo LMP.
O gerenciamento de um canal de controle consiste em duas etapas, que são a ativação do canal e a posterior manutenção da conectividade do canal. As mensagens utilizadas nessas duas etapas devem ser transmitidas especificamente no canal de controle a que se referem. As 44demais mensagens do LMP podem ser transmitidas em qualquer canal de controle que se encontre ativado.
Ativação de Canais de Controle
Para a ativação de um canal de controle no GMPLS, são utilizados três tipos de mensagem:
Previamente à ativação de um canal de controle, é necessário que esse canal esteja estabelecido. Para sinalização in-band, um canal de controle pode ser configurado explicitamente no link de dados.
Como foi visto anteriormente neste texto, existem diferentes formas de estabelecimento de canais de controle em redes ópticas de transporte.
A ativação de um canal de controle inicia-se pela troca de parâmetros de negociação entre o par de LSRs que terminam esse canal, utilizando-se para isso as mensagens Config, ConfigAck e ConfigNack. Os conteúdos dessas mensagens consistem em objetos LMP, que são negociáveis ou não negociáveis
A Figura 5 ilustra a ativação de canais de controle, que será vista nesta seção, assim como o processo de manutenção da conectividade do canal, o que será abordado na próxima seção.
Figura 5: Etapas do gerenciamento de canais de controle Fonte: livro GMPLS – Architecture and Applications, editora Morgan Kaufmann)
Vamos considerar, nesta seção, apenas a parte superior da figura, relativa à ativação de dois canais de controle, um identificado pelo CC_Id 1 e o outro pelo CC_Id 2.
O LSR A enviou inicialmente uma mensagem Config para o LSR B, propondo a ativação do primeiro canal (CC_Id 1), mas esse LSR rejeitou a proposta, respondendo com uma mensagem ConfigNack. O LSR A repetiu a proposta, que foi agora aceita, tendo o LSR B respondido com uma mensagem ConfigAck.
Foi então iniciado um novo processo para a ativação de um outro canal de controle (CC_Id 2), tendo ocorrido uma coincidência, tendo o LSR A e o LSR B enviado mensagens Config ao mesmo tempo. Por convenção, sendo o valor do node ID do LSR B superior ao do LSR A, prevaleceu a proposta do LSR B. Assim, apenas o LSR A respondeu com uma mensagem ConfigAck.
Dessa forma, ficam ativados os dois canais de controle pretendidos. O canal de controle solicitado pelo LSR A (CC_Id 1) foi configurado como canal primário, que se encontra destacado pelas linhas verticais mais grossas. O outro canal de controle (CC_Id 2) foi configurado como canal backup, destacado pelas linhas verticais mais finas.
Manutenção da Conectividade de Canais de Controle
Assim que um canal de controle é ativado entre dois LSRs adjacentes no plano de dados, o protocolo LMP Hello pode ser utilizado para manter a conectividade do canal e para detectar falhas no canal. O protocolo LMP Hello consiste em um mecanismo keep-alive que deve reagir rapidamente a falhas no canal de controle.
Cada canal de controle é mantido em operação pela troca de mensagens Hello entre os LSRs pares, em um intervalo de tempo regular. Esse intervalo é denominado Hello Interval, sendo aplicado em ambos os sentidos do canal de controle.
Caso pelo menos um dos LSRs pares de um canal de controle fique sem receber mensagens Hello por um outro intervalo de tempo referido como Hello Dead Interval, esse LSR declara a interrupção do canal e encerra a transmissão de mensagens Hello. O Hello Dead Interval é tipicamente configurado com um valor no mínimo superior a três vezes o valor do Hello Interval.
Caso a interrupção tenha ocorrido apenas no canal de controle primário, os LSRs comutam a transmissão para o canal de controle backup, designando-o como canal primário.
Observem que a situação descrita nos parágrafos anteriores ocorreu no exemplo da Figura 5 anterior, como ilustra a parte inferior da figura.
Nessa situação, é de se supor que os dois LSRs serão comandados para aplicar um novo processo de configuração, para restaurar a proteção operacional por meio de um novo canal de controle backup.
Para fins de controle, as mensagens Hello são numeradas sequencialmente (parâmetro TxSeqNum), e contêm também o número sequencial da última mensagem Hello recebida do LSR adjacente par nesse canal de controle (parâmetro RxSeqNum).
Verificação de Conectividade de Link
A RFC 4204 descreve um procedimento opcional que pode ser utilizado para verificar a conectividade física de links de dados e para dinamicamente determinar os estados dos LSRs que os delimitam. Esse procedimento deveria ser aplicado quando se estabelece um link TE, ou periodicamente para todos os links de dados não alocados de um link TE.
O processo de verificação de conectividade de links de dados se efetiva mediante o intercâmbio de mensagens BeginVerify, BeginVerifyAck e BeginVerifyNack. O LSR que deseja verificar um link de dados envia uma mensagem BeginVerify, e o outro LSR responde com uma mensagem BeginVerifyAck ou uma mensagem BeginVerifyNack, dependendo de sua possibilidade ou de deu desejo de atender à solicitação.
Uma vez constatada a conectividade entre dois LSRs, essa conectividade pode passar a ser testada para cada link de dados especificado no link TE, por meio do intercâmbio de mensagens de teste (Test messages) através do próprio canal de dados que está sendo testado., no que se denomina processo de verificação de links de dados.
Observamos que as mensagens de teste são as únicas mensagens do LMP que podem transitar pela rede do plano de dados. As mensagens Hello continuam a ser intercambiadas por cada canal de controle durante o processo de verificação de links de dados.
Correlação de Propriedades de Link
Como parte do LMP, foi definido um na RFC 4204 um mecanismo para o estabelecimento da correlação das propriedades de um link TE e dos links de dados que constituem esse link TE, entre os LSRs que os delimitam.
Essa correlação é estabelecida pelo intercâmbio de mensagens LinkSummary, LinkSummaryAck e LinkSummaryNack entre esses LSRs. Uma mensagem LinkSummary pode envolver múltiplos canais de dados que pertençam a um único link TE.
Como no caso da configuração de canais de controle, as mensagens de correlação de links contêm objetos LMP negociáveis ou não negociáveis. Objetos negociáveis podem ser utilizados para permitir que ambos os LSRs acordem quanto ao uso de certos parâmetros enquanto os objetos não negociáveis apenas comunicam valores de parâmetros não sujeitos a negociações.
Identificadores de links TE (Link_Id) e de links de dados (Interface_Id) devem ser de um mesmo tipo, o que deve ser conferido no processo de correlação. Esse processo é também utilizado com outros propósitos, tais como a agregação de links de dados em um link TE, determinação de outras inconsistências e comunicação de informações.
Gerenciamento de Falhas
A RFC 4204 define um procedimento LMP opcional, que é utilizado para gerenciar falhas pela rápida notificação do estado de um ou mais canais de dados de um link TE. Esse procedimento pode ser utilizado para isolar rapidamente falhas de links de dados e de links TE, sendo capacitado para operar tanto com LSPs unidirecionais quanto com LSPs bidirecionais.
A detecção de uma falha deve ser tratada na camada mais próxima à falha. Para redes ópticas, por exemplo, a falha deve ser tratada na camada óptica física.
O processo é iniciado pelo LSR downstream que detecta uma falha em um canal de dados. Esse LSR envia então uma mensagem ChannelStatus para o LSR upstream utilizando a rede decontrole, que respondeimediatamente com uma mensagem ChannelStatusACK, acusando o recebimento. O upstream LSRpode então examinar destrutivamente os sinais de dados recebidos no sentido upstream sem qualquer consequência.
O LSR upstream verifica então se o sinal recebido de seu LSR upstream está corrompido ou não.
Se não está corrompido, a falha está localizada em um canal de dados, em múltiplos canais de dados ou em todo o link TE, no sentido downstream, o que é notificado ao LSR downstream por meio de uma mensagem ChannelStatus.
Se o sinal recebido pelo LSR upstream de seu LSR upstream está corrompido, a falha não está localizada, sendo necessário continuar a pesquisa. Para isso, o LSR upstream repete os procedimentos realizados pelo LSR downstream, agora com relação a seu LSR upstream.
|
|||
