Mecanismos de OAM em redes MPLS-TP

Transcrição

Niudomar Siqueira de Araujo Chaves*, Tomaz de Mello Vilela, Vinícius Garcia de Oliveira
Este artigo apresenta um panorama da padronização das ferramentas de OAM para redes MPLS-TP.
São apresentados os principais requisitos e os protocolos e mecanismos desenvolvidos e em
desenvolvimento pelo IETF e pelo ITU-T, cujo objetivo é agregar, às redes orientadas a pacotes,
funcionalidades similares às existentes em redes legadas, como a SDH e, mais recentemente, a OTN. O
trabalho apresenta também uma análise crítica da padronização, especialmente das consequências da
decisão do ITU-T de especificar seu próprio padrão de solução de OAM para redes MPLS-TP.
Palavras-chave: MPLS-TP. OAM. MPLS. Rede de transporte.
Introdução
Em fevereiro de 2006, o ITU-T iniciou os
trabalhos de especificação de uma tecnologia de
rede de transporte baseada em comutação de
pacotes capaz de prover serviço similar àquele
prestado pelas redes SDH e OTN. Essa
tecnologia era inspirada na solução MPLS,
definida pelo IETF, e foi nomeada T-MPLS
(Transport MPLS). O IETF alertou o ITU-T de
que a T-MPLS apresentava incompatibilidades
com o MPLS. Em setembro de 2007, na reunião
do Study Group 15 do ITU-T, em Stuttgart,
decidiu-se criar um grupo de trabalho conjunto
com o IETF (Joint Working Team – JWT) para
analisar a questão.
Em um relatório apresentado em abril de 2008, o
JWT recomendou que o ITU-T abandonasse a
especificação da T-MPLS e iniciasse a
especificação de uma nova solução em um
trabalho conjunto com o IETF (IETF, 2009a).
O ITU-T acatou as recomendações do JWT,
suspendendo a especificação da T-MPLS e
iniciando a especificação de uma nova solução,
plenamente compatível com a MPLS, em
conjunto com o IETF – padrão MPLS Transport
Profile, ou MPLS-TP. Adicionalmente, o acordo
de relacionamento entre as duas instituições
previa que a especificação seria desenvolvida de
acordo com as regras e os procedimentos do
IETF, atendendo aos requisitos do ITU-T para
uma rede de transporte comutada por pacotes.
Um dos pontos centrais do MPLS-TP são as
ferramentas de OAM (Operação, Administração
e Manutenção). Tecnologias orientadas a
pacotes, como o Ethernet, ATM e Frame Relay,
se desenvolveram em redes locais de, no
máximo, alguns quilômetros de cobertura, sendo
que, neste caso, questões de OAM não são
críticas. Mesmo a tecnologia IP, de ampla
cobertura, contou com a camada de transporte
provida pelas operadoras, em geral utilizando a
tecnologia SDH, para a composição de uma rede
global, não sendo necessário o desenvolvimento
de tais ferramentas na camada IP, dado que a
camada de transporte se responsabiliza por
essas funcionalidades. Apesar de, em meados
dos anos 90, a MPLS ter sido introduzida como
tecnologia complementar ao IP, de forma a
solucionar as limitações existentes, ele foi
originalmente desenvolvido visando a questões
de engenharia de tráfego e qualidade de serviço,
e não OAM.
Criado com o intuito de se desenvolver uma rede
de transporte totalmente orientada a pacotes, o
MPLS-TP propõe o desenvolvimento de
ferramentas de OAM que permitam a aplicação
em redes metropolitanas e de longo alcance sem
que haja necessidade de uma camada de
transporte orientada à divisão temporal
determinística, permitindo assim o uso mais
eficiente dos recursos da rede através da
multiplexação estatística da comutação de
pacotes.
Dessa forma, este artigo tem por objetivo
apresentar as soluções e ferramentas de OAM
propostas para o MPLS-TP. Existem atualmente
duas propostas em vigência: a primeira, liderada
pelo ITU-T, visa a reaproveitar os mecanismos
desenvolvidos com base na tecnologia Ethernet;
a segunda, liderada pelo IETF, visa a adaptar e
estender a solução originalmente concebida para
a MPLS.
Este artigo divide-se da seguinte maneira: a
Seção 1 apresenta a visão geral da tecnologia
MPLS-TP; a Seção 2, os requisitos genéricos de
OAM definidos no trabalho de especificação do
MPLS-TP; a Seção 3, a solução de OAM
desenvolvida pelo ITU-T; a Seção 4, a solução
de OAM desenvolvida pelo IETF; e, por fim, a
Seção 5 realiza uma análise crítica com relação
às duas propostas apresentadas.
1
Visão geral do MPLS-TP
Com o início da especificação do MPLS-TP, as
recomendações do ITU-T que definem os
requisitos de uma rede de comutação de pacotes
para serviço de transporte baseadas no padrão
T-MPLS foram suspensas e estão sendo
substituídas, gradativamente, por novas versões
adaptadas para o MPLS-TP. O núcleo básico
*Autor a quem a correspondência deve ser dirigida: [email protected].
Cad. CPqD Tecnologia, Campinas, v. 7, n. 2, p. 87-100, jul./dez. 2011
dessas recomendações é constituído pelos
documentos descritos na Tabela 1.
Tabela 1 Recomendações do ITU-T para redes de
transporte baseadas em comutação de pacotes
G.8101/Y.1355: Terms and definitions for
MPLS transport profile
G.8110/Y.1370: MPLS layer network
architecture
G.8110.1/Y.1370.1: Architecture of transport
MPLS (T-MPLS) layer network
G.8112/Y.1371: Interfaces for the transport
MPLS (T-MPLS) hierarchy
2
Requisitos de OAM
A norma IETF RFC 5860 (2010a) define os
requisitos de OAM para a arquitetura MPLS-TP,
atendendo à especificação do ITU-T para uma
rede de comutação de pacotes para serviço de
transporte. Os requisitos apresentados se
aplicam a PWs (pseudowires), LSPs (Label
Switched Paths) e sections (trecho entre dois nós
MPLS-TP adjacentes). Alguns dos requisitos
mais relevantes são os seguintes:
a) as funções de OAM devem ser capazes de
operar e ser configuradas, mesmo na
ausência de um plano de controle;
b) as funções de OAM operam no plano de
dados; portanto, os pacotes de OAM
devem trafegar em banda para receber o
mesmo tratamento dado aos pacotes do
usuário e sofrer dos mesmos problemas
(fate sharing). No entanto, deve ser
possível distinguir esses pacotes do
tráfego do usuário;
G.8121/Y.1381: Characteristics of transport
MPLS equipment functional blocks
G.8131/Y.1382: Linear protection switching for
transport MPLS (T-MPLS) networks
G.8151/Y.1374: Management aspects of the TMPLS network element
O MPLS-TP está sendo definido como um
subconjunto da MPLS (IETF, 2009c), dessa
forma, funcionalidades que não são necessárias,
ou até mesmo que são inapropriadas, em uma
rede de transporte estão sendo excluídas do
novo padrão. Ao mesmo tempo, agrega à MPLS
novas funcionalidades necessárias a uma rede
de transporte, estendendo, particularmente,
funções de OAM e mecanismos de proteção.
O MPLS-TP não é interpretado pelo IETF como
uma tecnologia separada da MPLS, mas sim
como um padrão totalmente compatível com as
especificações legadas, de tal forma que a
arquitetura MPLS passa a atender a duas
necessidades:
a) o serviço fim a fim, com uma solução já
utilizada
amplamente
no
mercado,
chamada de IP/MPLS; e
b) o serviço de transporte, com uma solução
chamada MPLS-TP, conforme ilustrado na
Figura 1.
c) as funções de OAM não podem depender
da existência de camada IP; mas, quando
ela existir, deve ser possível optar por seu
uso;
d) deve ser aplicável a qualquer LSP,
independentemente da profundidade da
pilha de rótulos, e deve ser possível
estimar desempenho e falhas de um único
PW ou segmento LSP ou de um agregado
de segmentos LSP ou PW;
e) a solução de OAM deve apresentar
aplicação fim a fim ou por segmento de
caminho, assim como deve funcionar de
forma “intradomínio” e ao longo de vários
domínios;
f) a experiência operacional no uso dos
recursos de OAM deve ser similar à
experiência operacional de outras redes de
transporte;
g) as funções de OAM devem ser baseadas,
tanto quanto possível, em soluções
preexistentes na MPLS;
h) o protocolo deve ser independente do meio
de transmissão, bem como da tecnologia
de transporte subjacente à camada MPLSTP e do serviço que um PW esteja
emulando.
Para a descrição das funções de OAM, alguns
componentes funcionais foram definidos (IETF,
2011e):
a) MPLS-TP section: enlace entre dois nós
MPLS-TP adjacentes;
Figura 1 Arquitetura resultante da tecnologia
MPLS
88
b) ME (Maintenance Entity): representa um
trecho de um caminho de transporte,
delimitado por dois nós de rede (cumprindo
a função de MEP) e o relacionamento
entre eles;
c) MEG
(Maintenance
Entity
Group):
constituído por um conjunto de uma ou
mais MEs que pertencem a um mesmo
caminho de transporte e são mantidas e
monitoradas como um grupo em um
domínio de OAM;
d) MEP (MEG End Point): nó de rede que
determina a borda de uma ME/MEG.
Na maioria dos casos, um fluxo de OAM é
iniciado num MEP e é destinado ao seu
MEP-par. Pode ser compartilhado por mais
de uma ME em um MEG;
e) MIP (MEG Intermediate Point): representa
um nó de rede intermediário a dois MEPs,
dentro de uma ME. Um MIP pode
responder a uma mensagem de OAM, mas
não deve iniciar requisições de OAM por
conta própria (a geração de requisições de
OAM é prerrogativa dos MEPs). Pode ser
compartilhado por mais de uma ME em um
MEG;
f) Conexão Tandem: uma parte de um
caminho de transporte que pode ser
monitorada
por
OAM
de
forma
independente da monitoração fim a fim.
A Figura 2, a seguir, exemplifica uma conexão
fim a fim monitorada pelos protocolos de OAM.
É possível perceber a organização da hierarquia
de MEGs por meio da posição das linhas, que
representam diferentes níveis de fluxos de OAM.
Os triângulos representam os MEPs e os
círculos, os MIPs. No exemplo, há quatro níveis
hierárquicos de OAM. No nível mais baixo, o
fluxo de OAM acontece individualmente entre
cada par de nós adjacentes; portanto, não há
MIPs. No segundo nível, pode-se verificar fluxos
de OAM que abrangem a extensão do provedor
de rede, ou seja, há um fluxo que abrange a rede
do provedor A e outro que abrange a rede do
provedor B. O nível seguinte mostra um fluxo de
OAM no nível do provedor do serviço,
atravessando, portanto, a rede dos provedores
A e B. No último nível, há um fluxo fim a fim, em
que a monitoração acontece desde um CPE
(Customer Premises Equipment) até o outro.
Todos esses fluxos são transportados dentro do
mesmo canal de controle G-ACh (ver Seção 2.2),
sendo discriminados apenas por meio de
informações no cabeçalho das mensagens de
OAM. Entre essas informações estão, por
exemplo, o identificador do MEG e do MEG level
ao qual essa mensagem pertence.
2.1 Funções de OAM
As seguintes funções de OAM são definidas pelo
IETF (IETF, 2010a; IETF, 2011e):
a) CC (Continuity Check): sua função é
detectar uma falha de perda de
continuidade (Loss Of Continuity – LOC)
entre dois MEPs em um MEG. Dessa
forma, não há necessidade de verificar se
o MEP de origem deveria ter conectividade
com o MEP de destino, nem mesmo de
transmitir o identificador do MEP de
origem. Essa verificação é desempenhada
pela função seguinte;
b) CV (Connectivity Verification): sua utilidade
é permitir que o MEP que recebe a
mensagem de CV possa verificar qual foi o
MEP emissor e avaliar se essa
conectividade é válida, ou seja, se o MEP
emissor faz parte do mesmo MEG e da
mesma ME que o MEP que recebeu a
mensagem. Quando as funções de CC e
CV são desempenhadas usando uma
única mensagem, para reduzir o consumo
de largura de banda, essa mensagem é
chamada de CC-V;
c) RDI (Remote Defect Indication): trata-se
de um sinalizador enviado por um MEP
para avisar seu MEP-par da existência de
uma condição de falha no MEG. Essa
informação é transmitida em mensagens
CC-V;
Fonte: ITU-T, 2011
Figura 2 Exemplo de hierarquia OAM para diversas redes em uma conexão fim a fim
89
d) Alarm Reporting: função utilizada para
supressão de alarmes. Quando ocorre
uma falha em uma determinada camada
da hierarquia de conexões, os LSPs ou
PWs de níveis superiores àquele onde
ocorreu a falha também são afetados e
geram alarmes. Um elemento de rede que
é, ao mesmo tempo, um MEP no nível n
em que ocorreu a falha, ou onde ela foi
detectada, e um MIP no nível superior,
n+1, pode enviar uma mensagem AIS
(Alarm Indication Signal) na conexão de
transporte de nível n+1 direcionada ao
MEP, para avisar que uma falha ocorreu
no nível n e que o alarme de nível n+1
pode ser suprimido;
e) LI (Lock Instruct): trata-se de uma função
que permite a um MEP instruir o seu MEPpar a bloquear o caminho de transporte
MPLS-TP. Isso permite à gerência da rede
bloquear administrativamente um caminho
de transporte a partir de uma de suas
pontas apenas. O bloqueio administrativo
impede o transporte de dados do usuário e
permite apenas o tráfego de mensagens
de OAM e controle. As mensagens LI não
são interpretadas pelos MIPs do caminho.
f) Lock Reporting: permite que um MIP de
camada n+1 comunique a seu MEP-par
que há um bloqueio administrativo na
camada n, promovendo a supressão de
alarmes. O princípio de funcionamento é
idêntico ao da função Alarm Reporting,
exceto pela causa da interrupção. No caso
do Lock Reporting, a interrupção do
serviço ocorre por bloqueio administrativo,
já no caso do Alarm Reporting a
interrupção ocorre por falha;
g) Route Tracing: é iniciada sob demanda por
um MEP e tem o propósito de determinar a
rota percorrida por um caminho de
transporte, identificando todos os MIPs e o
MEP associado;
h) Diagnostic Test: o IETF definiu os testes
de vazão e de loopback do plano de dados
a serem utilizados em caminhos de
transmissão
bloqueados
administrativamente. O teste de vazão
tenta determinar a capacidade máxima de
transmissão do PW ou do LSP, sem que
haja perda de pacotes, e pode ser
realizado entre MEPs ou entre um MEP e
um MIP. Quando o loopback do plano de
dados é ativado em um nó MPLS-TP, todo
o tráfego que chega até ele é interceptado
e enviado de volta no mesmo caminho de
transporte, mesmo que, originalmente, ele
devesse seguir em frente. Ambas as
funções só devem ser executadas em
90
PWs ou LSPs bloqueados;
i) CFI (Client Failure Indication): tem a
função de transmitir, de MEP para MEP, a
informação de que há uma falha no sinal
do cliente (externo à rede MPLS-TP),
quando esse cliente do caminho de
transporte não suportar um mecanismo de
indicação de falha nativo;
j) LM (Packet Loss Measurement): tem o
propósito de mensurar a razão de perda
de pacotes de usuário no transporte entre
dois MEPs. Pode ser executada de forma
proativa ou sob demanda;
k) DM (Packet Delay Measurement): essa
função determina o atraso e a variação do
atraso entre os dois MEPs de uma ME.
A medição do atraso pode ser baseada
apenas na ida ou na ida e na volta. No
primeiro caso, faz-se necessário garantir o
sincronismo de relógio nos nós da rede.
A intenção inicial do IETF e do ITU-T era de
especificar uma única solução de OAM, assim
como um único padrão MPLS-TP. No entanto,
várias divergências entre os dois grupos
ocorreram durante o desenvolvimento do
trabalho, até que, em 25 de fevereiro de 2011, o
ITU-T decidiu especificar sua própria solução de
OAM (ITU, 2011), baseada no padrão ITU-T
Y.1731 (ITU-T, 2008), voltado para OAM em
redes Ethernet. Com a decisão do ITU-T, o
MPLS-TP deve oferecer duas soluções de OAM
totalmente distintas. As propostas de protocolos
para essas funções feitas pelo IETF e pelo ITU-T
serão apresentadas nas próximas seções.
2.2 Mensagens de OAM
No MPLS-TP, as mensagens de protocolos OAM
são transportadas por um canal de controle,
G-ACh (Generic Associated Channel), criado
dentro da conexão do cliente, sendo
considerado, portanto, um canal em banda.
A palavra generic foi utilizada em decorrência de
o mecanismo ter sido concebido primeiramente
apenas para o uso em PW; porém,
posteriormente, ele foi estendido para o uso em
LSPs
(IETF,
2009b).
As
mensagens
transportadas nesse canal recebem um
cabeçalho ACH (Associated Channel Header),
que contém informações que identificam qual
protocolo está sendo transportado, conforme
ilustra a Figura 3.
Para alertar sobre a presença de um cabeçalho
ACH na mensagem, foi definido um rótulo MPLS
específico – GAL (G-ACh Label). Esse rótulo
possui valor 13 e é localizado no nível mais
interno da pilha de rótulos, tendo por esse motivo
S bit igual a “1” (IETF, 2009b).
Porém, para atingir os MIPs é necessário o uso
de outro mecanismo, uma vez que apenas o
primeiro label da pilha é tratado. Nesse caso, o
campo de TTL do primeiro label é ajustado para
expirar no MIP desejado, indicando para esse nó
que o quadro deve ser tratado.
Quando um MEP deseja alcançar um MIP, ele
deve saber a quantos saltos de distância seu
destino está, para marcar o TTL de maneira
correta. Quando o pacote chega ao LSR,
verifica-se que o TTL expirou, ou seja, o pacote
não deve ser mais encaminhado, sendo
necessário verificar se o último label da pilha é
reservado (IETF, 2010e). Nesse momento, será
possível verificar que se trata de um pacote de
OAM, em decorrência da existência do GAL, e
que ele deve ser tratado como tal.
LSP Label
GAL
ACH
ACH TLV
Payload
Figura 3 Formato de mensagem no canal G-ACh
para um LSP
3
Solução ITU-T G.8113.1
A proposta do ITU-T descrita no draft G.tpoam
(ITU-T, 2011) visa a atender às necessidades de
OAM das redes de transporte MPLS-TP (IETF,
2010a). Quando o ITU-T aprovar o draft
G.tpoam, ele se tornará a recomendação
ITU-T G.8113.1.
A grande maioria dos recursos de OAM que
serão apresentados compartilham o mesmo
formato definido pelo protocolo Y.1731,
desenvolvido para redes Ethernet. Obviamente, a
utilização em redes MPLS-TP modifica o modo
como as mensagens são enviadas e
reconhecidas.
O foco desse trabalho desenvolvido pelo ITU-T
são as conexões MPLS-TP ponto a ponto
corroteadas e bidirecionais, não contemplando
em sua primeira versão outros tipos de
conexões, como, por exemplo, ponto-multiponto.
3.1 Continuity Check – CC
Continuity Check é o mecanismo que opera de
forma proativa para verificar a conexão entre dois
MEPs. Também é capaz de verificar uma
conexão indesejada e erros de configuração.
Mais adiante neste artigo, serão abordadas as
formas de se utilizar essa mensagem para
indicação de falha e monitoramento de
desempenho.
Em uma conexão entre dois MEPs, cada um fica
encarregado de enviar mensagens de CCM
(Continuity Check Message) periodicamente para
o outro MEP e, ao mesmo tempo, de monitorar
as mensagens recebidas.
Com o recebimento de uma mensagem de CCM,
é possível verificar a continuidade do caminho
percorrido pelos pacotes dentro do MEG entre os
dois extremos, uma vez que o não recebimento
indica falha na conexão. Essa situação deverá
ser reportada quando o quadro CCM não for
recebido por 3,5 períodos.
A solução do G.tpoam prevê três períodos
possíveis para o envio dessa mensagem:
3,33 ms, período necessário para que o
chaveamento do caminho de transporte principal
para o caminho de transporte de proteção, em
caso de falha, ocorra em até 50 ms, conforme
requisito estabelecido para a tecnologia
MPLS-TP; 100 ms, período indicado para as
medições de desempenho; e 1 s, período
indicado para gerenciamento de falha.
Uma mensagem enviada por um MEP possui
várias informações, entre as quais destacam-se:
MEG level, MEG ID, MEP ID da fonte e o período
em que a mensagem está sendo gerada.
Analisando-se esses parâmetros, podem ser
inferidas diversas falhas. A primeira verificação é
o MEG level: se esse valor for maior do que o
valor configurado no MEP, o quadro é
encaminhado normalmente. Porém, se o valor for
menor, pode-se inferir um erro na configuração
da hierarquia da rede ou o vazamento de
quadros de um MEP de um nível inferior.
Em caso de igualdade, os demais parâmetros
serão verificados.
Em seguida, o MEG ID deve ser verificado: se o
valor for diferente do valor atribuído para o MEP,
conclui-se que há uma conexão indevida entre os
dois MEGs. O próximo passo é a verificação do
MEP ID da fonte; nesse caso, se o valor
apresentado no pacote é diferente do esperado,
trata-se de um MEP não cadastrado. Por último,
é verificado o período em que a mensagem é
gerada, que deve ser o mesmo em ambos os
lados.
Em caso de falha em qualquer um desses
parâmetros, o MEP deve se reportar ao
gerenciamento da rede.
3.2 Loopback
Loopback é o mecanismo utilizado para verificar
a continuidade entre um MEP e um MIP ou entre
dois MEPs. Também pode ser usado para testes
de conexão entre dois MEPs. Trata-se de um
serviço realizado sob demanda, e pode ser
realizado com tráfego habilitado, in-service, ou
com o tráfego interrompido, out-of-service.
No último caso, deve-se utilizar as mensagens de
Lock, apresentadas mais adiante, para
interromper o tráfego no MEG level superior,
evitando, assim, alarmes desnecessários.
A mensagem que inicia a transação é a LBM
(Loopback Message), e a resposta é a LBR
(Loopback
Reply).
Para
identificar
a
91
comunicação, a mensagem deve conter o ID da
transação e o número de sequência, além do
MEG level.
A LBM deve sempre possuir ID do MIP/MEP de
destino e, opcionalmente, o ID do MEP-origem.
Esses dois campos, em conjunto com o MEG
level, devem ser validados antes do envio da
resposta. Portanto, o ID de destino deve ser o
mesmo do MIP/MEP que recebeu a mensagem,
o ID da origem deve ser conhecido e o MEG
level deve ser o mesmo.
A LBR sempre deve conter o ID do MIP/MEP que
está respondendo à requisição e, caso o ID do
MEP-origem tenha sido adicionado, ele deve ser
mantido na resposta. Esses campos, em
conjunto com o ID da transação e com o número
de sequência, serão verificados na recepção da
LBR.
No caso dos testes de conexão, o quadro
enviado para o MEP adjacente informa o tipo do
teste a ser realizado. Para os testes de largura
de banda, são acrescentados dados ao pacote.
Para outros tipos, é acrescentada uma série de
bytes de teste que definirão os padrões a serem
seguidos.
3.3 Remote Defect Indication (RDI)
Remote Defect Indication é o mecanismo
utilizado para indicar ao MEP vizinho que uma
condição de falha foi encontrada.
A RDI, uma flag que está contida no quadro de
CCM, deve ser ativada sempre que uma falha for
encontrada e desativada imediatamente após a
resolução do problema.
3.4 Alarm Indication Signal (AIS)
O objetivo do sinal AIS é suprimir alarmes de
falhas
de
níveis
superiores
que
são
consequência de uma falha de um nível inferior.
Assim, quando uma falha é detectada por um
MEP de um dado nível, se esse MEP exercer o
papel de MIP no nível adjacente superior, ele
transmitirá uma indicação AIS no nível superior,
endereçada ao MEP associado, para informá-lo
sobre a existência de uma falha no nível inferior,
suprimindo os alarmes no nível superior.
A recomendação G.tpoam define que essas
mensagens devem ser transmitidas com
periodicidade de 1 segundo.
A condição de falha pode ser suspensa por um
MEP quando as mensagens de AIS não forem
recebidas por 3,5 períodos.
3.5 Locked Signal – LCK
Locked Signal é a mensagem utilizada por um
MEP para comunicar aos MEPs de um MEG de
nível superior sobre o bloqueio do tráfego no
nível inferior. Portanto, é possível diferenciar a
interrupção do tráfego causada por uma falha da
interrupção de tráfego causada por uma
92
determinação administrativa. Esse recurso deve
ser usado, por exemplo, na realização de testes
out-of-service.
A mensagem de LCK será gerada imediatamente
após o MEG ter o tráfego interrompido, e será
continuamente enviada até que essa condição
seja alterada. Segundo o G.tpoam, as
mensagens devem ter período igual a 1 segundo.
O MEP adjacente fica aguardando 3,5 períodos
sem o recebimento da mensagem para alterar a
condição de tráfego interrompido.
3.6 Test Signal (TST)
O TST é o sinal utilizado para a realização de
testes e verificações no caminho entre dois
MEPs. É utilizado em um único sentido, realizado
sob demanda, de forma in-service ou
out-of-service.
No caso de testes out-of-service, deve-se
previamente enviar a mensagem de LCK para a
interrupção do tráfego do usuário.
Um MEP enviará mensagens periodicamente ao
seu par com as informações necessárias para
que o teste desejado seja realizado.
Os testes mais comuns são as medições de
largura de banda, de perda de pacotes
(realizadas por meio do envio de uma grande
quantidade de bytes) e de erros de bits,
utilizando-se
uma
sequência
de
dados
pseudoaleatórios (Pseudo Random Binary
Sequence – PRBS) para verificar a quantidade
de erros.
3.7 Loss Measurement
Loss Measurement é um mecanismo, realizado
de maneira autônoma ou sob demanda, utilizado
para medir a perda de pacotes na rede. O cálculo
utiliza os contadores locais de egresso e
ingresso, chamados de TxFCl e RxFCI,
respectivamente.
Há duas definições para perda: near-end, que se
refere à perda associada aos contadores de
ingresso; e far-end, associada às perdas nos
contadores de egresso.
Cada MEP mantém esses dois contadores para
cada conexão ponto a ponto e para cada classe
de prioridade. Em caso de falta de continuidade,
assume-se 100% de perda.
Para o cálculo proativo, os contadores TxFCl e
RxFCI locais são adicionados às mensagens de
Continuity Check. Além disso, o último valor
TxFCl recebido é devolvido ao MEP-par, sendo
enviado na mesma mensagem que os
contadores locais. Nessa configuração, o período
do CCM deve ser igual a 100 ms.
Quando um MEP recebe um quadro CCM
contendo os três contadores do MEP adjacente,
são realizados cálculos de perda de near-end e
far-end. Para isso, também são necessários os
valores dos mesmos contadores recebidos no
momento imediatamente anterior.
O cálculo da perda near-end é realizado com
base na diferença entre os bytes transmitidos
pelo MEP adjacente (TxFCl recebido), nos
momentos atual e anterior, menos a diferença
entre os bytes recebidos (RxFCl local), nos
momentos atual e anterior.
A perda far-end é calculada com base na
diferença entre os bytes transmitidos pelo MEP;
porém, utiliza-se o valor de TxFCl que foi enviado
ao MEP adjacente e foi devolvido, nos momentos
atual e anterior, menos a diferença entre os bytes
recebidos pelo MEP adjacente (RxFCl recebido),
nos momentos atual e anterior.
Quando o cálculo da perda de pacote é feita sob
demanda, é necessário que um MEP envie uma
mensagem
de
requisição,
LMM
(Loss
Measurement Message), e o MEP vizinho
responda com uma mensagem LMR (Loss
Measurement Reply). Essas mensagens, quando
habilitadas, são trocadas periodicamente.
A mensagem LMM possui o contador de egresso
do MEP que deseja realizar a verificação. O MEP
vizinho valida a mensagem por meio da
verificação do MEG level e responde com LMR,
copiando o contador recebido e os contadores
locais de egresso e ingresso.
Após a recepção da LMR, são calculados os
valores de perda near-end e far-end. Esses
cálculos são realizados da mesma forma: o
primeiro, utilizando os valores RxFCl locais e
TxFCl remotos e o segundo, utilizando os valores
TxFCl locais e RxFCl remotos, respectivamente.
DMM (Delay Measurement Message) e
DMR (Delay Measurement Reply). A DMM
carrega o time stamp com valor correspondente
ao momento de seu envio; a DMR copia esse
time stamp e adiciona dois outros time stamps: o
instante de tempo da recepção do DMM e o
instante de tempo da transmissão do DMR.
O MEP que iniciou o processo pode então
calcular o atraso total com base no tempo para
ida e volta das mensagens e no tempo gasto pelo
MEP adjacente.
3.9 Client Signal Fail (CSF)
A mensagem CSF é gerada por um MEP para
indicar ao seu par que o cliente externo ao MEG
possui uma falha. Esse recurso é utilizado
quando a rede-cliente não implementa recursos
para reportar a ocorrência de uma falha. Essas
mensagens são enviadas periodicamente, até
que o problema seja resolvido.
4
Solução IETF
A composição da solução do IETF para OAM
obedece integralmente ao requisito, expresso na
RFC 5860 (IETF, 2010a), de aproveitar tanto
quanto possível as soluções de OAM já definidas
para a MPLS. Dessa forma, foram aproveitados
os protocolos BFD (Bidirectional Forwarding
Detection) e LSP Ping, já utilizados na MPLS,
conforme ilustra a Tabela 2.
Tabela 2 Funções de OAM para gerenciamento de
falhas do IETF
3.8 Delay measurement
É o mecanismo utilizado para medir o atraso dos
pacotes dentro de um MEG. Por meio desse
cálculo é possível estimar a variação do atraso,
ou jitter.
O atraso pode ser medido de duas maneiras:
a) utilizando-se apenas uma mensagem;
neste caso, os dois MEPs trocam
mensagens periodicamente; e
b) utilizando-se
uma
mensagem
de
requisição e outra de resposta.
No primeiro caso, as mensagens 1DM (One-way
Delay Measurement) são enviadas carregando o
valor do instante de tempo, ou time stamp, no
momento da transmissão. Quando o outro MEP
recebe essa mensagem, verifica-se o tempo.
De posse desses valores, o cálculo de latência é
obtido com base no valor do time stamp do
instante de tempo da recepção menos o time
stamp do instante de tempo da transmissão.
Esse método exige que os equipamentos
mantenham
seus
relógios
sincronizados.
Omecanismo utilizado para sincronização não é
escopo desta especificação.
A outra forma de se obter o atraso da
transmissão é através do uso de mensagens
Função de OAM
Proativa
Sob demanda
Continuity Check
(CC)
BFD estendido
Não se aplica
Connectivity
Verification (CV)
BFD estendido
LSP Ping
estendido
Remote Defect
Indication (RDI)
Flag em
mensagem BFD
Não se aplica
Route Tracing
Não se aplica
LSP Ping
estendido
Alarm Indication
Signal (AIS)
Mensagem AIS
baseada em GACh (Generic
Associated
Channel)
Não se aplica
Link Down
Indication (LDI)
Flag em
mensagem AIS
Não se aplica
Lock Reporting
(LKR)
Mensagem LKR
baseada em GACh
Não se aplica
Client Signal Fail
(CSF)
Mensagem CSF
baseada em GACh
Não se aplica
93
Função de OAM
Diagnostic:
Loopback e Lock
Instruct
Proativa
Não se aplica
entre os MEPs é válida; e
Sob demanda
a. Lock Instruct e
Loopback
baseados em
G-ACh
b. LSP Ping
As funções para gerenciamento de desempenho
do IETF são estruturadas conforme ilustra a
Tabela 3.
Tabela 3 Funções de OAM para gerenciamento de
desempenho do IETF
Função de OAM
Protocolos
Medição de perda de pacote
(Loss Measurement – LM)
Requisições LM e DM
baseadas em G-ACh – novo
protocolo
Medição de latência de
pacote (Delay Measurement
– DM)
Requisições LM e DM
baseadas em G-ACh – novo
protocolo
Medição de vazão
Derivada da medição de
perda de pacote – novo
protocolo
Medição de variação da
latência
Derivada da medição de
latência – novo protocolo
A seguir, os mecanismos definidos pelo IETF são
descritos em maiores detalhes.
4.1 Funções Continuity Check e Connectivity
Verification
O IETF propôs extensões ao protocolo BFD para
implementar as funções de CC, CV e RDI no
modo proativo. Para o modo sob demanda, o
IETF propõe extensões ao protocolo LSP Ping
para executar as funções de CV e Route Tracing.
O estado atual do trabalho de especificação
dessas funções no IETF suporta apenas LSPs
bidirecionais dos tipos corroteado, quando os
dois sentidos de transmissão percorrem o
mesmo caminho de rede, e associado, quando
os dois sentidos de transmissão podem percorrer
caminhos diferentes. O suporte a conexões
unidirecionais e ponto-multiponto será abordado
pelo IETF em trabalhos futuros.
Tanto o protocolo LSP Ping (também chamado
de LSPing) como o BFD já existiam na MPLS.
Após o desenvolvimento do protocolo LSP Ping,
o IETF o considerou computacionalmente
pesado e julgou necessário especificar um
protocolo mais leve e com melhor escalabilidade,
trabalho que resultou no protocolo BFD. Contudo,
o BFD não possui todos os recursos disponíveis
no LSP Ping. As principais limitações do BFD na
sua forma original se concentram no fato de que
ele:
a) não oferece recursos para realizar CV, ou
seja, não é possível testar o plano de
dados em comparação com o plano de
controle para verificar se a conectividade
94
b) o BFD depende do LSP Ping para iniciar
uma sessão BFD.
4.1.1
Funções CC e CV proativas
As funções CC e CV são desempenhadas pelo
protocolo BFD com algumas extensões para
adaptá-lo ao uso no MPLS-TP, conforme a RFC
6428 (IETF, 2011j). O MPLS-TP aproveita o BFD
como especificado nas normas IETF RFC 5880
(IETF, 2010b), 5884 (IETF, 2010c) e 5885 (IETF,
2010d).
No
BFD,
cada
MEP
envia
periodicamente mensagens do tipo hello ou
heartbeat para todos os outros MEPs com os
quais ele deve ter conectividade, permitindo que
cada MEP detecte quando houver perda de
continuidade, falha de conectividade ou
conectividade indevida. As mensagens CC e CV
trafegam sobre o mesmo canal de controle do
MPLS-TP, o G-ACh. Mensagens CC são
intercaladas
com
mensagens
CV.
A especificação determina que o intervalo de
transmissão das mensagens CV deve ser de
1 segundo, enquanto as mensagens CC podem
ter uma frequência maior. As mensagens CC e
CV são constituídas basicamente por um pacote
de controle BFD, acrescido do cabeçalho relativo
ao G-ACh. A mensagem CV também recebe um
campo após o pacote de controle BFD, dado que,
como o BFD originalmente é capaz de prover
apenas o serviço CC, é necessário incluir o
identificador do MEP de origem nas mensagens
CV, capacitando o plano de controle do MEP de
destino a identificar o originador da mensagem e
a verificar se a conectividade entre os MEPs é
correta. O protocolo BFD no MPLS-TP trabalha
no modo assíncrono, conforme definido na
norma IETF RFC 5880 (IETF, 2010b), segundo a
qual uma sessão BFD é estabelecida entre dois
MEPs e ambos enviam periodicamente pacotes
de controle BFD de um para o outro. Se um
determinado número de pacotes de controle
sequenciais não é recebido, a sessão é
considerada inoperante (down). No MPLS-TP, o
estabelecimento de uma sessão BFD é
disparada por um LSP Ping. Os pacotes de
controle BFD são transportados usando o
protocolo UDP. O endereço IP de destino é
sorteado entre os IPs da faixa 127/8, reservada
para endereços de loopback. O uso desses
endereços tem o objetivo de evitar que um
pacote de controle BFD seja indevidamente
encaminhado como um pacote IP qualquer até o
MEP da conexão MPLS-TP caso, por uma falha
na rede, esse pacote saia prematuramente da
conexão de transporte (LSP ou PW) em um
ponto intermediário. Como os endereços da faixa
127/8 não podem trafegar em um enlace, uma
vez que são de uso interno a um nó de rede, se
ocorrer um vazamento, há a garantia de que o
pacote será descartado, em vez de ser
encaminhado indevidamente até o destino. Só é
possível utilizar um endereço de destino
“inválido” no cabeçalho IP da mensagem BFD
porque o encaminhamento no MPLS-TP é feito
pelo rótulo no nível mais alto da pilha e não
depende do endereço IP.
4.1.2 Funções CV sob demanda e Route
Tracing
Essas funções são implementadas utilizando-se
o protocolo LSP Ping com algumas extensões
para adaptá-lo ao uso no MPLS-TP, conforme a
RFC 6426 (IETF, 2011h). O LSP Ping, definido
na norma IETF RFC 4379 (IETF, 2006), utiliza
mensagens chamadas MPLS echo request e
MPLS echo reply para verificar a conectividade
com um dado LSR (Label Switched Router),
usando o mesmo conceito do protocolo ICMP,
com suas mensagens echo request e echo reply.
Como o LSP Ping envia nas suas mensagens a
informação da FEC (Forwarding Equivalence
Class) associada ao LSP sob teste, é possível
testar tanto a continuidade do caminho no plano
de dados quanto a conectividade dos LSRs de
origem e destino. Quando o LSR de destino
recebe a mensagem MPLS echo request, a
informação que identifica a FEC é analisada pelo
seu plano de controle, que pode determinar se
esse LSR deveria ou não ter conectividade com o
LSR de origem.
No MPLS-TP, por ser executado sob demanda,
para realizar a localização de falha por meio de
ping e route tracing, o protocolo LSP Ping é
utilizado entre MEPs (no caso de LSPs, PWs ou
sections) ou entre um MEP e um MIP (no caso
de LSPs e PWs). Para que um MIP processe
uma mensagem MPLS echo request, em vez de
encaminhá-lo de acordo com o rótulo, é
necessário configurar o valor do campo TTL
(Time To Live) do cabeçalho MPLS com um valor
tal para que ele expire ao chegar ao MIP
desejado.
Um TTL expira quando chega a um LSR com
valor 1, dado que internamente ele será
decrementado e chegará ao valor zero. A
expiração do campo TTL é um mecanismo de
exceção que obriga o LSR (seja MIP ou MEP) a
entregar o pacote ao plano de controle para ser
analisado. Esse recurso é usado no LSP Ping
para testar a conectividade com um MIP e
também é usado para implementar a função de
levantamento de rota (route tracing), de forma
similar ao recurso traceroute utilizado em redes
IP. Assim como o BFD na função CC-V proativa,
o LSP Ping na função CV sob demanda também
utiliza a faixa de endereços IP 127/8, pela
mesma motivação apontada na Seção 4.1.1.
4.1.3
Comparação entre o LSP Ping e o BFD
Por demandar um processamento intenso no
plano de controle do LSR, o protocolo LSP Ping
tem um custo computacional considerado
elevado, o que limita a quantidade de LSPs que
podem ser monitorados e a frequência dessa
monitoração. Como a tecnologia MPLS tem sido
utilizada para atender a serviços cada vez mais
exigentes, frequentemente subordinados a SLAs
(Service Level Agreements) rigorosos, a
necessidade de detecção de falhas em tempos
menores tem sido constante. O BFD foi
desenvolvido pelo IETF como um protocolo mais
leve e capaz de testar apenas a continuidade do
caminho de transmissão, ou seja, não permite
verificar no plano de controle se o LSR que
recebe uma mensagem MPLS echo request
deveria ter, de fato, conectividade com o LSR
que enviou essa mensagem, ou se se trata de
uma conexão indevida. Além de testar apenas o
plano de dados, as mensagens BFD possuem
tamanho fixo, o que facilita a sua implementação
em hardware ou firmware. Em decorrência de
sua leveza, o BFD possui maior escalabilidade
que o LSP Ping e consegue realizar detecção
rápida de falhas, de tal forma que as primeiras
implementações já conseguiam detectar falhas
em intervalos da ordem de 100 milissegundos,
enquanto
implementações
mais
recentes
conseguem tempos ainda menores (MINEI;
LUCEK, 2008).
4.2 Indicação RDI
A indicação RDI é gerada por um MEP para
avisar seu MEP-par da existência de falha no
MEG, conforme detalhado na Seção 2.1.
A função RDI ocorre de forma proativa e é
realizada simplesmente utilizando-se flags já
existentes no campo Diagnostic nas mensagens
CC, protocolo apresentado na Seção 4.1.1.
O mesmo campo nas mensagens CV deve ser
ignorado. Essas flags permitem indicar três
condições de falha: estouro do temporizador de
chegada de mensagens CC (normalmente, três
vezes o período de transmissão), perda de
continuidade (Loss Of Continuity – LOC) ou
conectividade indevida.
4.3 Indicação AIS, LDI e Lock Report
A RFC 6427 (IETF, 2011i) especifica um canal
chamado “MPLS-OAM Fault Management (FM)
channel”.
Ela
também
especifica
duas
mensagens para informar sobre a ocorrência de
falha na camada subjacente: a mensagem Alarm
Indication Signal (AIS) e a mensagem Lock
Report (LKR). A indicação LDI (Link Down
Indication) é apenas uma flag dentro da
mensagem AIS. A indicação AIS implementa a
função Alarm Reporting, enquanto a mensagem
LKR implementa a função Lock Reporting,
ambas apresentadas na Seção 2.1. Os dois tipos
de mensagens trafegam no canal FM, que em
95
essência é o próprio canal G-ACh, definido pela
IETF RFC 5586 (IETF, 2009b). A particularidade
do canal FM é que ele não usa os TLVs (TypeLength-Values) definidos para o G-ACh, e sim
define seus próprios TLVs, aproveitando apenas
o canal criado pelo G-ACh. Tanto a mensagem
AIS quanto a indicação LDI informam o MEP da
camada n+1 de que ocorreu uma falha na
camada n. Entretanto, enquanto o propósito da
mensagem AIS é promover a supressão de
alarmes, a indicação LDI tem o propósito de
promover a comutação de proteção. A ativação
da flag de LDI por um nó deve aguardar o tempo
suficiente para haver a garantia de que há uma
falha não recuperada na camada inferior. Por
exemplo, se ocorrer comutação de proteção na
camada inferior, a flag de LDI não deve ser
ativada. Outro ponto relevante é que o uso de
LDI deve considerar o uso de CC. Por exemplo,
em uma rede de transporte, normalmente se
deseja obter detecção rápida de falha e, nesse
caso, o protocolo CC deve estar ativado com
uma alta taxa de geração de mensagens CC.
Nesse cenário, a indicação LDI pode ser
ignorada pelos elementos de rede. Já em uma
rede com requisitos menos rigorosos, o protocolo
CC pode ser ativado com uma baixa taxa de
geração de mensagens CC. Nesse caso, a
indicação LDI pode promover a recuperação
rápida de falhas. O protocolo define uma
segunda flag para indicar que uma falha cessou.
Se essa flag não for ativada, o MEP também
assumirá que a falha cessou caso não receba
mensagens FM com a indicação de falha por um
intervalo de 3,5 vezes o tempo de renovação, um
parâmetro configurável entre 1 e 20 segundos.
4.4 Indicação CSF
O IETF definiu o protocolo CSF (Client Signal
Fail) para implementar a função Client Failure
Indication, conforme exposto na Seção 2.1 (IETF,
2011c). A função desse protocolo é propagar, de
um lado a outro de uma rede MPLS-TP, uma
indicação de falha ocorrida fora dessa rede e
detectada por um MEP, para ser utilizada quando
a camada-cliente do serviço de transporte não
possuir um mecanismo próprio para transportar
essa indicação de falha. Uma mensagem CSF é
gerada por um MEP e destinada a outro MEP. Os
MIPs não geram ou interpretam essas
mensagens. A forma como um MEP de ingresso
é informado de uma falha externa à rede MPLSTP é específica à camada-cliente.
Quando a falha é do tipo perda de sinal, o MEP
de ingresso pode detectar diretamente essa
ocorrência, sem depender de algum tipo de
comunicação da camada-cliente. Uma vez
detectada a falha, o MEP de ingresso inicia a
transmissão periódica de mensagens CSF para o
seu MEP-par. O período de transmissão varia de
acordo com o propósito almejado, podendo ser,
96
por exemplo, de 3,33 milissegundos para
aplicações de comutação de proteção e de
1 segundo para aplicações de gerenciamento de
falhas. A recuperação da falha pode ser
detectada pelo MEP de egresso de uma das
seguintes formas:
a) o MEP não recebe mensagens CSF
durante um intervalo maior que um timeout
pré-configurado (usualmente, 3,5 períodos
de transmissão);
b) o MEP recebe um quadro de dados válido
do cliente;
c) o MEP recebe uma mensagem CSF
contendo informação explícita de ausência
de falha.
A transmissão de mensagens CSF é feita através
do canal G-ACh, e uma mensagem CSF pode
carregar as seguintes indicações de falha:
a) CSF-LOS (Loss of Signal);
b) CSF-FDI (Forward Defect Indication);
c) CSF-RDI (Reverse Defect Indication); e
d) CSF-Clear (Clearance of Client Signal
Fail).
4.5 Lock Instruct e Loopback
As funções Lock Instruct e Loopback estão
associadas às funcionalidades de OAM Lock
Instruct e Diagnostic Test, definidas pelo IETF
para o MPLS-TP e apresentadas na Seção 2.1.
A função Lock Instruct consiste em um bloqueio
administrativo de um LSP, PW ou section, de tal
forma que nenhum tráfego de usuário seja
transportado, permitindo-se apenas tráfego de
teste e de OAM. A ação de bloqueio é realizada
por uma ação do sistema de gerência, que pode
controlar individualmente a execução do bloqueio
em todos os MEPs do caminho de transporte.
Como o MPLS-TP define conexões ponto a
ponto e ponto-multiponto, a coordenação do
bloqueio em todos os MEPs necessários pode
ser complexa. A função Lock simplifica esse
processo, uma vez que, ao iniciar o bloqueio no
primeiro MEP, este envia mensagens de OAM LI
(Lock Instruct) para os demais MEPs a ele
associados, garantindo o bloqueio automático
nas outras pontas do caminho de transporte.
A função de Loopback faz com que um LSR (MIP
ou MEP) encaminhe de volta todo o tráfego que
chegar até ele por um caminho de transporte
para o MEP de origem nesse mesmo caminho.
De outra forma, pode-se dizer que é feito um
loopback no plano de dados. O sistema de
gerência deve assegurar que uma operação de
loopback não seja executada sem que antes seja
feito o bloqueio de todas as pontas do caminho
de transporte.
A transmissão de mensagens LI é feita através
do canal de controle em banda G-ACh e seu
formato é definido na RFC 6435 (IETF, 2011k).
A mensagem LI contém apenas o identificador do
MEP de origem e um valor que representa o
tempo máximo de renovação, representado em
segundos, sendo o valor-padrão igual a
1 segundo. Esse tempo é utilizado para o MEP
de destino desbloquear o caminho de transporte
se não receber uma nova mensagem LI após
3,5 vezes o tempo máximo de renovação. Não é
definida uma mensagem de loopback, dado que
essa ação é comandada diretamente no
equipamento pelo sistema de gerência.
4.6 Medição de latência, variação da latência,
perda de pacotes e vazão
O gerenciamento de desempenho para o
MPLS-TP é especificado nas normas IETF RFC
6374 (IETF, 2011f) e 6375 (IETF, 2011g). A RFC
6374 especifica um conjunto de ferramentas para
a medição de perda de pacotes, latência,
variação da latência (jitter) e vazão em redes
MPLS. A RFC 6375 sugere um subconjunto de
procedimentos definidos na RFC 6374 a serem
utilizados em redes MPLS-TP. Essas sugestões
podem
ou
não
ser
adotadas
pelos
implementadores.
A RFC 6374 especifica um protocolo para a
medição de perda de pacotes
(Loss
Measurement – LM) e um protocolo para a
medição de latência (Delay Measurement – DM),
ambos
projetados
para
redes
MPLS.
Os protocolos foram desenvolvidos com o
objetivo de serem simples e eficientes, de
possuírem elevada precisão (no caso da
medição de latência) e foram projetados de
forma a permitir sua implementação em
hardware de maneira eficiente. Esses protocolos
são aplicáveis a PWs, LSPs e sections, operam
sobre o canal de controle G-ACh e podem
funcionar de forma proativa ou sob demanda.
O mecanismo básico consiste no uso de
mensagens de requisição e resposta, o que
permite que se façam medidas unidirecionais ou
bidirecionais. O princípio de funcionamento é
simples e o mesmo para os dois tipos de
medição. Um nó de origem R1 envia uma
requisição adicionando uma marca de tempo T1.
Quando a requisição chega ao destino R2, é
adicionada a essa mensagem a marca de tempo
T2. Ao enviar a resposta, o nó de destino R2
copia as marcas de tempo T1 e T2 e acrescenta
a marca de tempo T3, relativa ao momento da
transmissão da resposta. Quando a resposta
chega ao nó R1, este acrescenta a marca de
tempo T4. O registro dos quatro instantes de
tempo permite a medição da latência tanto na ida
quanto na volta, de tal forma que um nó pode
medir a latência no caminho de ida, no caminho
de volta ou na ida e na volta. No último caso,
uma
particularidade
interessante
é
a
possibilidade de medir a latência total (incluindo o
tempo de processamento em R2) ou apenas a
latência total de transmissão (desconsiderando o
tempo de processamento em R2).
No caso da medição de perda de pacotes, em
vez das marcas de tempo, cada nó deve
adicionar à mensagem um contador com o valor
da quantidade de pacotes que já foram
transmitidos ou recebidos em cada um desses
quatro instantes. O nó R1 transmite a mensagem
incluindo a quantidade de pacotes transmitidos
até esse instante, R1_Tx. Quando R2 recebe a
resposta, acrescenta a quantidade recebida de
R1 até esse instante, R2_Rx. A resposta de R2
para R1 contém R1_Tx, R2_Rx e R2_Tx, com a
quantidade de pacotes transmitidos por R2 para
R1 até o momento. Quando R1 recebe a
resposta de R2, acrescenta R1_Rx, contendo a
quantidade de pacotes recebidos de R2 até o
momento. A contagem dos pacotes pode ser
baseada no tráfego do usuário – chamado de
modo de medição direta (aplicável apenas a
alguns tipos de LSP) – ou no tráfego injetado
para esse fim – chamado de modo de medição
inferida (aplicável a qualquer tipo de conexão
MPLS-TP). Como não há garantia de que a
contagem dos pacotes esteja sincronizada
adequadamente entre os nós, a medição de
perda de pacotes se baseia na diferença entre
mensagens sucessivas. A sincronização de
relógio entre os nós de rede é necessária para
medição de latência unidirecional e deve ser
garantida por outra solução, mas, para garantir
elevada precisão, as RFCs 6374 e 6375 sugerem
o uso de marca de tempo no formato IEEE
1588v2 (IEEE, 2008) truncado, que corresponde
aos 64 bits menos significativos do formato
completo, divididos em 32 bits para segundos e
32 bits para nanossegundos. O padrão 1588v2
foi adotado por representar a tendência de
mercado nesse momento em alternativa à
solução NTP (Network Time Protocol), de baixa
precisão.
A RFC 6374 também prevê o uso de marcas de
tempo no formato NTP, mas apenas para
permitir interoperabilidade com redes legadas.
O intervalo de transmissão das requisições para
medição de perda no modo direto pode ser de
100 milissegundos, 1 segundo, 10 segundos,
1 minuto ou 10 minutos. No modo inferido, além
dos intervalos anteriores, deve-se suportar
também o intervalo de 10 milissegundos.
O intervalo de transmissão das requisições para
medição de latência pode ser de 1 segundo,
10 segundos, 1 minuto ou 10 minutos.
Uma característica muito importante dessa
solução é que ela prevê o suporte à qualidade de
serviço existente nas redes MPLS. A medição de
latência é realizada na mesma classe de serviço
da conexão MPLS-TP em monitoração e a
medição de perda pode ser feita em uma classe
de serviço específica ou no caminho de
transporte como um todo. A medição de vazão
aproveita os dados da medição de perda, que
são as quantidades de dados transmitidos e
recebidos e os intervalos de tempo. Como as
97
quantidades são contabilizadas tanto em número
de pacotes como em número de octetos, é
possível calcular a quantidade de octetos
transmitidos e recebidos num dado intervalo de
tempo. Assim, pode-se calcular a vazão
oferecida (transmitida) e a vazão obtida
(recebida). O cálculo da variação da latência
também é feito a partir do cálculo da latência.
5
Análise crítica
Conforme apresentado nas seções anteriores,
pode-se constatar que o conjunto de
mecanismos de OAM para o MPLS-TP reproduz
os recursos tipicamente disponíveis em redes de
transporte determinísticas, como SDH e OTN.
Adicionalmente aos mecanismos de OAM, estão
sendo padronizadas também soluções para
comutação de proteção, tema não abordado
neste artigo. A experiência adquirida com as
redes legadas mostra que esses recursos
asseguram
uma
alta
disponibilidade
e
confiabilidade às redes de transporte. Dessa
forma, espera-se que o MPLS-TP seja capaz de
oferecer um serviço de transporte, de fato,
similar ao dessas redes, agregado à flexibilidade
típica de redes de comutação de pacotes.
Como as duas propostas pretendem atender aos
requisitos de OAM para o MPLS-TP, expressos
na RFC 5860 (2010a), elas são muito similares
do ponto de vista das funcionalidades oferecidas.
Nesse contexto, um ponto comum é que as
duas, de forma geral, definem soluções de OAM
apenas para conexões ponto a ponto
bidirecionais (em alguns casos, apenas para o
tipo corroteado) – há algumas poucas exceções,
como, por exemplo, a medição unidirecional de
latência.
Conexões
unidirecionais
e
ponto-multiponto
serão
consideradas
em
trabalhos futuros. As diferenças entre as duas
propostas estão nos detalhes de definição dos
protocolos. Entre as diferenças, podem-se citar:
a) a proposta do ITU-T prevê apenas um
intervalo de tempo padrão (100 ms) para
transmissão de mensagens de LM, para
medição de perda de pacotes. A proposta
do IETF prevê mais opções, conforme
apresentado na Seção 4.6;
b) o ITU-T propõe o uso da solução de
medição de latência apenas no modo sob
demanda, entretanto, a solução do IETF
pode ser utilizada nos modos proativo e
sob demanda;
c) o draft G.tpoam adota o formato IEC
61588, de 2004, como padrão para a
marca de tempo. Por sua vez, esse padrão
corresponde ao 1588, versão 1. O IETF
adota um formato truncado do padrão
1588, versão 2;
d) o G.tpoam não especifica um protocolo
98
para a função Lock Instruct, requisitada na
RFC 5860.
A decisão do ITU-T de adotar uma adaptação da
recomendação Y.1731 (OAM em redes Ethernet)
para redes MPLS-TP como sua solução de OAM
gerou um cenário de conflito entre os dois órgãos
e de incerteza para a indústria. Ambos os grupos
publicaram drafts no IETF apresentando seus
argumentos em favor de suas escolhas (IETF,
2011b; IETF, 2011d).
De forma geral, a solução baseada em Y.1731
consiste em inserir as mensagens do
padrão Y.1731
em
pacotes
MPLS-TP
transportados dentro do canal G-ACh. O padrão
Y.1731 foi desenvolvido pelo ITU-T em parceria
com o IEEE (Institute of Electrical and Electronics
Engineers). Essa proposta é defendida pelo
ITU-T e por um conjunto de fabricantes que já
possuem equipamentos suportando o padrão
Y.1731 (ou sua adaptação para o MPLS-TP) e
operadoras que já implementaram ou estão
testando esses produtos. Segundo o draft em
que é defendida a adoção de uma solução de
OAM baseada no padrão Y.1731 (IETF, 2011b),
três operadoras chinesas já implementaram
milhares de nós PTN (Packet Transport
Network), suportando essa solução. Além disso,
segundo o documento, essa solução está sendo
avaliada por uma operadora italiana e uma
espanhola.
Além da grande quantidade de equipamentos já
implantados, outros argumentos empregados
nessa discussão são: a demora do IETF em
concluir a especificação da sua solução; a
necessidade emergente de várias operadoras e
fabricantes de terem um padrão concluído para
adoção; e a realização de testes abertos de
interoperabilidade
que
atestaram
o
funcionamento da solução baseada em Y.1731.
No entanto, no início de dezembro de 2011, a
maior parte dos documentos do IETF que
constituem sua solução de OAM para MPLS-TP
estavam aprovados (IETF, 2011e, 2011f, 2011g,
2011h, 2011i, 2011j e 2011k), enquanto a
proposta do ITU-T, concentrada em um único
documento, ainda estava como draft tanto no
IETF (IETF, 2011a) quanto no próprio ITU-T
(ITU-T, 2011).
Apesar da iniciativa do ITU-T de definir seu
próprio padrão, ainda é necessário que o IETF
aceite a proposta e que se convença o órgão a
incluir essa solução no conjunto de ferramentas
de OAM do MPLS-TP, de tal forma que se
ofereçam duas opções de solução de OAM aos
fabricantes e às operadoras. O ITU-T depende
dessa aceitação pelo IETF, porque vários valores
de parâmetros do protocolo devem ser definidos
e reservados pela IANA (Internet Assigned
Numbers Authority) e apenas o IETF pode fazer
solicitações a essa instituição.
A intenção do ITU-T é convencer o IETF a
aceitar que o MPLS-TP tenha duas opções de
OAM, uma de cada órgão. No entanto, o IETF
tem se posicionado contrário a essa proposta.
Em uma tentativa de conciliação, o ITU-T
determina em sua proposta que, em um
ambiente heterogêneo, no qual as duas soluções
estejam disponíveis, a solução do IETF deve ter
precedência sobre a sua própria solução.
Por sua vez, o IETF se opõe à proposta com
base no requisito do MPLS-TP, aceito por ambos
os órgãos, de reaproveitar tanto quanto possível
as ferramentas preexistentes na MPLS e de
garantir que qualquer solução adotada para o
MPLS-TP seja compatível com a MPLS. De fato,
os vários drafts que constituem a proposta do
IETF são baseados em duas ferramentas de
OAM já existentes na MPLS – LSP Ping e BFD –,
enquanto a proposta do ITU-T é uma adaptação
de uma solução para redes Ethernet. Isso
levanta outra objeção do IETF, pelos próprios
requisitos definidos: o MPLS-TP é uma
tecnologia MPLS e, portanto, deve ser
especificado seguindo os mesmos conceitos e
princípios.
Se os fabricantes decidirem pela implementação
das duas soluções, a despeito do custo adicional,
que seria repassado no custo dos produtos, as
operadoras terão liberdade de escolha. Contudo,
se os fabricantes optarem por apostar em um
padrão ou outro, as operadoras também
precisarão fazer suas escolhas de fornecedor,
limitando a concorrência e, potencialmente,
encarecendo os produtos. Até o momento da
conclusão deste artigo, não havia uma definição
final para esse impasse entre as instituições.
Conclusão
A evolução das redes de comunicação tem
avançado num processo de migração de redes
baseadas em divisão temporal para redes
baseadas em multiplexação estatística através
da comutação de pacotes. Dois dos principais
organismos internacionais de padronização
decidiram trabalhar em parceria para especificar
uma solução de rede de transporte utilizando
uma tecnologia de comutação de pacotes
madura, a MPLS. A nova tecnologia, chamada de
MPLS-TP, absorve das redes de transporte
legadas os conceitos e as funcionalidades de
OAM que apresentam eficiência e robustez
comprovadas em anos de uso.
Este trabalho apresentou uma descrição
sistêmica das soluções de OAM, que ainda estão
em processo de especificação pelo IETF e pelo
ITU-T. As ferramentas de OAM das duas
instituições são muito similares em uma análise
de alto nível, o que é esperado, uma vez que
ambas atendem aos mesmos requisitos. Dado
que os padrões ainda não estão completos, é
prematuro avaliar o desempenho das duas
propostas.
No nível funcional, como as funcionalidades têm
eficácia comprovada nas redes legadas, pode-se
presumir que a tecnologia MPLS-TP oferecerá
um serviço robusto, confiável, de alta
disponibilidade e que permitirá ao provedor do
serviço fazer a operação, manutenção e
administração de forma eficiente. O provedor
será capaz de identificar e localizar falhas
rapidamente.
O trabalho também discute sobre a decisão do
ITU-T de romper com o acordo de
relacionamento ao decidir desenvolver sua
própria solução de OAM, os principais
argumentos de ambas as instituições e algumas
possíveis consequências dessa decisão. Por fim,
deve-se destacar que, até a conclusão deste
artigo, a proposta do ITU-T, concentrada num
único documento, ainda está no estado de draft,
tanto dentro do próprio ITU-T quanto no IETF.
No caso da proposta do IETF, como a solução é
composta por protocolos definidos em muitos
documentos separados, a maior parte do núcleo
da solução já está concluída.
Referências
INSTITUTE
OF
ELECTRICAL
AND
ELECTRONICS ENGINEERS (IEEE). IEEE
1588-2008: IEEE Standard for a Precision Clock
Synchronization
Protocol
for
Networked
Measurement and Control Systems. New York,
2008.
ITU
TELECOMMUNICATION
STANDARDIZATION SECTOR (ITU-T). Y.1731:
OAM functions and mechanisms for Ethernet
based networks. Geneve, 2008.
______.
Draft
Recommendation
G.tpoam. Geneve, 2011.
ITU-T
INTERNATIONAL
TELECOMMUNICATION
UNION (ITU). ITU satisfies market demand for
carrier class MPLS standard. 2011. Disponível
em:
<http://www.itu.int/net/pressoffice/press_releases/
2011/03.aspx>. Acesso em: 29 set. 2011.
INTERNET ENGINEERING TASK FORCE
(IETF). RFC 4379: Detecting Multi-Protocol Label
Switched (MPLS) Data Plane Failures. Fremont,
2006.
______. RFC 5317: Joint Working Team (JWT)
Report on MPLS Architectural Considerations for
a Transport Profile. Fremont, 2009a.
______. RFC 5586: MPLS Generic Associated
Channel. Fremont, 2009b.
99
______. RFC 5654: Requirements of an MPLS
Transport Profile. Fremont, 2009c.
______.
RFC
5860:
Requirements
for
Operations, Administration and Maintenance
(OAM) in MPLS Transport Networks. Fremont,
2010a.
______. RFC 5880: Bidirectional Forwarding
Detection (BFD). Fremont, 2010b.
Detection (BFD) for MPLS Label Switched Paths
(LSPs). Fremont, 2010c.
oam-considerations-01.txt: The Reasons for
Selecting a Single Solution for MPLS-TP OAM.
Fremont, 2011d.
______. RFC 6371: Operations, Administration
and Maintenance Framework for MPLS-based
Transport Networks. Fremont, 2011e.
______. RFC 6374: Packet Loss and Delay
Measurement for MPLS Networks. Fremont,
2011f.
______. RFC 6375: A Packet Loss and Delay
Measurement Profile for MPLS-Based Transport
Networks. Fremont, 2011g.
Detection (BFD) for the Pseudowire Virtual Circuit
Connectivity Verification (VCCV). Fremont,
2010d.
______. RFC 6426: MPLS On-demand
Connectivity Verification and Route Tracing.
Fremont, 2011h.
______. RFC 5960: MPLS Transport Profile Data
Plane Architecture. Fremont, 2010e.
______. RFC 6427: MPLS Fault Management
OAM. Fremont, 2011i.
______.Internet Draft draft-bhh-mpls-tp-oamy1731-07.txt: MPLS-TP OAM based on Y.1731.
Fremont, 2011a.
______. RFC 6428: Proactive Connectivity
Verification, Continuity Check and Remote Defect
Indication for MPLS Transport Profile. Fremont,
2011j.
______. Internet Draft draft-fang-mpls-tp-oamconsiderations-02.txt: Operator Considerations
on MPLS-TP OAM Mechanisms. Fremont,
2011b.
______. RFC 6435: MPLS Transport Profile Lock
Instruct and Loopback Functions. Fremont,
2011k.
______. Internet Draft draft-ietf-mpls-tp-csf02.txt: Indication of Client Failure in MPLS-TP.
Fremont, 2011c.
MINEI,
I.;
LUCEK,
J.
MPLS-Enabled
Applications: Emerging Developments and New
Technologies. 2nd ed. Chichester: Wiley, 2008.
497 p.
______. Internet Draft draft-sprecher-mpls-tpAbstract
This paper presents an overview of the standardization status of OAM tools for MPLS-TP. It introduces
the main requirements and the protocols already developed and under development by IETF and ITU-T.
They constitute an MPLS-TP OAM toolset similar to the legacy transport networks, e.g. SDH and OTN. It
also includes an analysis of the standardization status, mainly the consequences of ITU-T decision to
specify its own OAM standard for MPLS-TP networks.
Key words: MPLS-TP. OAM. MPLS. Transport Network.
100

Mecanismos de OAM em redes MPLS-TP

Transcrição

Documentos relacionados

NEM - Acta Reumatológica Portuguesa

Gabarito

ESTRATGIAS PARA O AUMENTO DA VARIABILIDADE

Estudo Teórico de Propriedades Geométricas e - SBQT-2015

01 - Linio

LEVEL 3 ETHERNET SOLUTIONS MATRIX

Texto QoS_IP_Itelcon - Universidade Santa Cecília

310816 O Mensageiro

TG580 v2 - Speed Touch

Livro do IETF

fundação arquivo e memória de santos atos da comissão de