Mecanismos de OAM em redes MPLS-TP

Tamanho: px
Começar a partir da página:

Download "Mecanismos de OAM em redes MPLS-TP"

Transcrição

1 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: Cad. CPqD Tecnologia, Campinas, v. 7, n. 2, p , jul./dez. 2011

2 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 /Y : Architecture of transport MPLS (T-MPLS) layer network G.8112/Y.1371: Interfaces for the transport MPLS (T-MPLS) hierarchy 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 T- MPLS 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. Figura 1 Arquitetura resultante da tecnologia MPLS 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; 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 MPLS- TP 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; b) ME (Maintenance Entity): representa um trecho de um caminho de transporte, delimitado por dois nós de rede (cumprindo 88 Cad. CPqD Tecnologia, Campinas, v. 7, n. 2, p , jul./dez. 2011

3 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 Cad. CPqD Tecnologia, Campinas, v. 7, n. 2, p , jul./dez

4 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 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 90 Cad. CPqD Tecnologia, Campinas, v. 7, n. 2, p , jul./dez. 2011

5 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 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 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 Cad. CPqD Tecnologia, Campinas, v. 7, n. 2, p , jul./dez

6 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 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 92 Cad. CPqD Tecnologia, Campinas, v. 7, n. 2, p , jul./dez. 2011

7 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. 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 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 Função de OAM Proativa Sob demanda Continuity Check (CC) Connectivity Verification (CV) Remote Defect Indication (RDI) Route Tracing Alarm Indication Signal (AIS) Link Down Indication (LDI) Lock Reporting (LKR) Client Signal Fail (CSF) BFD estendido BFD estendido Flag em mensagem BFD Mensagem AIS baseada em G- ACh (Generic Associated Channel) Flag em mensagem AIS Mensagem LKR baseada em G- ACh Mensagem CSF baseada em G- ACh LSP Ping estendido LSP Ping estendido Cad. CPqD Tecnologia, Campinas, v. 7, n. 2, p , jul./dez

8 Função de OAM Proativa Sob demanda Diagnostic: Loopback e Lock Instruct 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 Medição de perda de pacote (Loss Measurement LM) Medição de latência de pacote (Delay Measurement DM) Medição de vazão Medição de variação da latência Protocolos Requisições LM e DM baseadas em G-ACh novo protocolo Requisições LM e DM baseadas em G-ACh novo protocolo Derivada da medição de perda de pacote novo protocolo 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 entre os MEPs é válida; e b) o BFD depende do LSP Ping para iniciar uma sessão BFD 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 94 Cad. CPqD Tecnologia, Campinas, v. 7, n. 2, p , jul./dez. 2011

9 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 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 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 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 Cad. CPqD Tecnologia, Campinas, v. 7, n. 2, p , jul./dez

10 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 (Type- Length-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 MPLS- TP é 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, 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 96 Cad. CPqD Tecnologia, Campinas, v. 7, n. 2, p , jul./dez. 2011

11 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 Cad. CPqD Tecnologia, Campinas, v. 7, n. 2, p , jul./dez

12 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 para a função Lock Instruct, requisitada na RFC 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 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 98 Cad. CPqD Tecnologia, Campinas, v. 7, n. 2, p , jul./dez. 2011

13 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 : IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems. New York, ITU TELECOMMUNICATION STANDARDIZATION SECTOR (ITU-T). Y.1731: OAM functions and mechanisms for Ethernet based networks. Geneve, Draft Recommendation ITU-T G.tpoam. Geneve, INTERNATIONAL TELECOMMUNICATION UNION (ITU). ITU satisfies market demand for carrier class MPLS standard Disponível em: <http://www.itu.int/net/pressoffice/press_releases/ 2011/03.aspx>. Acesso em: 29 set INTERNET ENGINEERING TASK FORCE (IETF). RFC 4379: Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures. Fremont, 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. Cad. CPqD Tecnologia, Campinas, v. 7, n. 2, p , jul./dez

14 . 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.. RFC 5884: Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs). Fremont, 2010c.. RFC 5885: Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV). Fremont, 2010d.. RFC 5960: MPLS Transport Profile Data Plane Architecture. Fremont, 2010e..Internet Draft draft-bhh-mpls-tp-oamy txt: MPLS-TP OAM based on Y Fremont, 2011a.. Internet Draft draft-fang-mpls-tp-oamconsiderations-02.txt: Operator Considerations on MPLS-TP OAM Mechanisms. Fremont, 2011b.. Internet Draft draft-ietf-mpls-tp-csf- 02.txt: Indication of Client Failure in MPLS-TP. Fremont, 2011c.. Internet Draft draft-sprecher-mpls-tpoam-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.. RFC 6426: MPLS On-demand Connectivity Verification and Route Tracing. Fremont, 2011h.. RFC 6427: MPLS Fault Management OAM. Fremont, 2011i.. RFC 6428: Proactive Connectivity Verification, Continuity Check and Remote Defect Indication for MPLS Transport Profile. Fremont, 2011j.. RFC 6435: MPLS Transport Profile Lock Instruct and Loopback Functions. Fremont, 2011k. MINEI, I.; LUCEK, J. MPLS-Enabled Applications: Emerging Developments and New Technologies. 2nd ed. Chichester: Wiley, p. Abstract 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 Cad. CPqD Tecnologia, Campinas, v. 7, n. 2, p , jul./dez. 2011

MPLS MultiProtocol Label Switching

MPLS MultiProtocol Label Switching MPLS MultiProtocol Label Switching Cenário Atual As novas aplicações que necessitam de recurso da rede são cada vez mais comuns Transmissão de TV na Internet Videoconferências Jogos on-line A popularização

Leia mais

Visão geral da arquitetura do roteador

Visão geral da arquitetura do roteador Visão geral da arquitetura do roteador Duas funções-chave do roteador: Executar algoritmos/protocolos (RIP, OSPF, BGP) Comutar os datagramas do link de entrada para o link de saída 1 Funções da porta de

Leia mais

MPLS. Redes de Longa Distância Prof. Walter Cunha

MPLS. Redes de Longa Distância Prof. Walter Cunha Redes de Longa Distância Prof. Walter Cunha Vantagens do Multiprotocol Label Switching (MPLS) em relação às redes IP puras: Possibilitar a utilização de switches no roteamento principalmente em backbones

Leia mais

Redes WAN MPLS. Redes de Longa Distância Prof. Walter Cunha

Redes WAN MPLS. Redes de Longa Distância Prof. Walter Cunha Redes WAN MPLS Redes de Longa Distância Prof. Walter Cunha Vantagens do Multiprotocol Label Switching (MPLS) em relação às redes IP puras: Possibilitar a utilização de switches no roteamento Principalmente

Leia mais

Redes de Computadores

Redes de Computadores s de Computadores s de Computadores s de Computadores 2 1 Roteamento como visto cada gateway / host roteia mensagens não há coordenação com outras máquinas Funciona bem para sistemas estáveis e sem erros

Leia mais

UNIDADE II. Fonte: SGC Estácio e João Bosco M. Sobral

UNIDADE II. Fonte: SGC Estácio e João Bosco M. Sobral UNIDADE II Aula 6 LPCD, Redes IP/MPLS, VPN e Frame Relay Fonte: SGC Estácio e João Bosco M. Sobral MPLS significa Multi Protocol Label Switching. OMPLSé um mecanismo eficiente i de encapsulamento em hardware

Leia mais

PROJETO DE REDES www.projetoderedes.com.br

PROJETO DE REDES www.projetoderedes.com.br PROJETO DE REDES www.projetoderedes.com.br CENTRO UNIVERSITÁRIO DE VOLTA REDONDA UniFOA Curso Tecnológico de Redes de Computadores Disciplina: Redes Convergentes II Professor: José Maurício S. Pinheiro

Leia mais

MPLS Multi-Protocol Label Switching

MPLS Multi-Protocol Label Switching MPLS Multi-Protocol Label Switching Adilson Eduardo Guelfi Volnys Borges Bernal Luis Gustavo G. Kiatake Agenda Introdução Arquitetura de Rede Conceitos MPLS Conclusões Introdução MPLS is the enabling technology

Leia mais

Funcionamento de ARP entre redes (sub-redes) distintas. Mecanismos de entrega. Funcionamento entre redes (sub-redes): default gateway

Funcionamento de ARP entre redes (sub-redes) distintas. Mecanismos de entrega. Funcionamento entre redes (sub-redes): default gateway Introdução Inst tituto de Info ormátic ca - UF FRGS Redes de Computadores Protocolos ARP e ICMP Aula 18 A camada de rede fornece um endereço lógico Uniforme, independente da tecnologia empregada pelo enlace

Leia mais

Redes de Computadores

Redes de Computadores 1 Elmano R. Cavalcanti Redes de Computadores Camada de Rede elmano@gmail.com facisa-redes@googlegroups.com http://sites.google.com/site/elmano Esta apresentação contém slides fornecidos pela Editora Pearson

Leia mais

Faculdade Integrada do Ceará FIC Graduação em Redes de Computadores

Faculdade Integrada do Ceará FIC Graduação em Redes de Computadores Faculdade Integrada do Ceará FIC Graduação em Redes de Computadores Disciplina Redes de Banda Larga Prof. Andrey Halysson Lima Barbosa Aula 5 Multiprotocol Label Switching (MPLS) Sumário Definição; Histórico;

Leia mais

REDES MPLS. Roteiro. Protocolos anteriores ao MPLS. Demanda crescente por largura de banda.

REDES MPLS. Roteiro. Protocolos anteriores ao MPLS. Demanda crescente por largura de banda. REDES MPLS PARTE 1 PROFESSOR: MARCOS A. A. GONDIM Roteiro Protocolos anteriores ao MPLS. Motivações para o uso de Redes MPLS. O Cabeçalho MPLS. Label Switch Router (LSR). Switched Path (LSP). Forwarding

Leia mais

CA Nimsoft Monitor. Guia do Probe Monitoramento de conectividade de rede. net_connect série 3.0

CA Nimsoft Monitor. Guia do Probe Monitoramento de conectividade de rede. net_connect série 3.0 CA Nimsoft Monitor Guia do Probe Monitoramento de conectividade de rede net_connect série 3.0 Aviso de copyright do CA Nimsoft Monitor Este sistema de ajuda online (o Sistema ) destina-se somente para

Leia mais

Walter Cunha Tecnologia da Informação Redes WAN

Walter Cunha Tecnologia da Informação Redes WAN Walter Cunha Tecnologia da Informação Redes WAN Frame-Relay 1. (FCC/Pref. Santos 2005) O frame-relay é uma tecnologia de transmissão de dados que (A) opera no nível 3 do modelo OSI. (B) tem velocidade

Leia mais

Redes de Computadores I ENLACE: PPP ATM

Redes de Computadores I ENLACE: PPP ATM Redes de Computadores I ENLACE: PPP ATM Enlace Ponto-a-Ponto Um emissor, um receptor, um enlace: Sem controle de acesso ao meio; Sem necessidade de uso de endereços MAC; X.25, dialup link, ISDN. Protocolos

Leia mais

Endereço IP Privado. Endereçamento IP. IP Protocolo da Internet. Protocolos da. Camada de Inter-Rede (Internet)

Endereço IP Privado. Endereçamento IP. IP Protocolo da Internet. Protocolos da. Camada de Inter-Rede (Internet) Protocolos da Camada de Inter- (Internet) IP Protocolo da Internet. Não Confiável; Não Orientado à conexão; Trabalha com Datagramas; Roteável; IPv 4 32 bits; IPv 6 128 bits; Divisão por Classes (A,B,C,D,E);

Leia mais

CA Nimsoft Monitor Snap

CA Nimsoft Monitor Snap CA Nimsoft Monitor Snap Guia de Configuração do Monitoramento de conectividade de rede net_connect série 2.9 Aviso de copyright do CA Nimsoft Monitor Snap Este sistema de ajuda online (o Sistema ) destina-se

Leia mais

Modulo 4. Professor: Leandro Engler Boçon E-mail: leandro@facear.edu.br Disciplina: Comunicação de dados

Modulo 4. Professor: Leandro Engler Boçon E-mail: leandro@facear.edu.br Disciplina: Comunicação de dados Modulo 4 Professor: Leandro Engler Boçon E-mail: leandro@facear.edu.br Disciplina: Comunicação de dados 1 Protocolo ICMP Internet Control Message Protocol 2 ICMP Internet Control Message Protocol IP funciona

Leia mais

Gerencia de Rede (Desempenho) Professor: Guerra (Aloivo B. Guerra Jr.)

Gerencia de Rede (Desempenho) Professor: Guerra (Aloivo B. Guerra Jr.) Gerencia de Rede (Desempenho) Professor: Guerra (Aloivo B. Guerra Jr.) Tópicos Gerencia de Rede Motivação da Gerência Desafios Principais Organismos Padronizadores Modelo Amplamente Adotado As Gerências

Leia mais

QoS em Redes IP: Arquitetura e Aplicações

QoS em Redes IP: Arquitetura e Aplicações QoS em Redes IP: Arquitetura e Aplicações Mário Meireles Teixeira mario@deinf.ufma.br Motivação Atualmente, funcionam sobre as redes IP aplicações cujos requisitos elas não foram projetadas para atender

Leia mais

Estrutura da Internet

Estrutura da Internet Estrutura da Internet Redes de redes Estrutura da Internet: rede de redes Grosseiramente hierárquica No centro: s de zona-1 (ex.: UUNet, BBN/Genuity, Sprint, AT&T), cobertura nacional/internacional Os

Leia mais

Arquitetura e Protocolos de Rede TCP/IP. Modelo Arquitetural

Arquitetura e Protocolos de Rede TCP/IP. Modelo Arquitetural Arquitetura e Protocolos de Rede TCP/IP Modelo Arquitetural Motivação Realidade Atual Ampla adoção das diversas tecnologias de redes de computadores Evolução das tecnologias de comunicação Redução dos

Leia mais

MPLS. Multi Protocol Label Switching

MPLS. Multi Protocol Label Switching MPLS Multi Protocol Label Switching Nome: Edson X. Veloso Júnior Engenheiro em Eletrônica Provedor de Internet desde 2002 Integrante da equipe de instrutores da MikrotikBrasil desde 2007 Certificado Mikrotik:

Leia mais

Redes de Computadores I - Protocolos de Controle: ICMP. por Helcio Wagner da Silva

Redes de Computadores I - Protocolos de Controle: ICMP. por Helcio Wagner da Silva Redes de Computadores I - Protocolos de Controle: ICMP por Helcio Wagner da Silva Introdução Na Internet, cada roteador opera de maneira autônoma X X X X 2 Introdução Infelizmente, nada funciona corretamente

Leia mais

Gerencia de Rede (Desempenho) Professor: Guerra (Aloivo B. Guerra Jr.)

Gerencia de Rede (Desempenho) Professor: Guerra (Aloivo B. Guerra Jr.) Gerencia de Rede (Desempenho) Professor: Guerra (Aloivo B. Guerra Jr.) Unidade 3 3.1 Introdução 3.2. Definições 3.3. Motivações 3.4. Problemas 3.5. Desafios 3.6. Padronização e Arquitetura 3.7. Gerência

Leia mais

Este tutorial apresenta os conceitos básicos do Multi Protocol Label Switching (MPLS) utilizado em redes IP.

Este tutorial apresenta os conceitos básicos do Multi Protocol Label Switching (MPLS) utilizado em redes IP. MPLS Este tutorial apresenta os conceitos básicos do Multi Protocol Label Switching (MPLS) utilizado em redes IP. Eduardo Tude Engenheiro de Teleco (IME 78) e Mestre em Teleco (INPE 81) tendo atuado nas

Leia mais

REDES DE COMPUTADORES II. Ricardo José Cabeça de Souza www.ricardojcsouza.com.br

REDES DE COMPUTADORES II. Ricardo José Cabeça de Souza www.ricardojcsouza.com.br REDES DE COMPUTADORES II Ricardo José Cabeça de Souza www.ricardojcsouza.com.br REDE PÚBLICA x REDE PRIVADA Rede Pública Circuitos compartilhados Rede Privada Circuitos dedicados Interligação entre Dispositivos

Leia mais

Arquitetura e Protocolos de Rede TCP/IP. Modelo Arquitetural

Arquitetura e Protocolos de Rede TCP/IP. Modelo Arquitetural Arquitetura e Protocolos de Rede TCP/IP Modelo Arquitetural Agenda Motivação Objetivos Histórico Família de protocolos TCP/IP Modelo de Interconexão Arquitetura em camadas Arquitetura TCP/IP Encapsulamento

Leia mais

A topologia em estrela é caracterizada por um determinado número de nós, conectados em uma controladora especializada em comunicações.

A topologia em estrela é caracterizada por um determinado número de nós, conectados em uma controladora especializada em comunicações. Topologia em estrela A topologia em estrela é caracterizada por um determinado número de nós, conectados em uma controladora especializada em comunicações. Como esta estação tem a responsabilidade de controlar

Leia mais

Roteamento e Comutação

Roteamento e Comutação Roteamento e Comutação Uma estação é considerada parte de uma LAN se pertencer fisicamente a ela. O critério de participação é geográfico. Quando precisamos de uma conexão virtual entre duas estações que

Leia mais

Arquitetura TCP/IP. Parte VI Entrega de pacotes sem conexão (IP) Fabrízzio Alphonsus A. M. N. Soares

Arquitetura TCP/IP. Parte VI Entrega de pacotes sem conexão (IP) Fabrízzio Alphonsus A. M. N. Soares Arquitetura TCP/IP Parte VI Entrega de pacotes sem conexão (IP) Fabrízzio Alphonsus A. M. N. Soares Tópicos Conceitos Pacote (ou datagrama) IP Formato Campos do cabeçalho Encapsulamento Fragmentação e

Leia mais

Redes TCP/IP. Prof. M.Sc. Alexandre Fraga de Araújo. alexandref@ifes.edu.br. INSTITUTO FEDERAL DO ESPÍRITO SANTO Campus Cachoeiro de Itapemirim

Redes TCP/IP. Prof. M.Sc. Alexandre Fraga de Araújo. alexandref@ifes.edu.br. INSTITUTO FEDERAL DO ESPÍRITO SANTO Campus Cachoeiro de Itapemirim Redes TCP/IP alexandref@ifes.edu.br Camada de Redes (Continuação) 2 Camada de Rede 3 NAT: Network Address Translation restante da Internet 138.76.29.7 10.0.0.4 rede local (ex.: rede doméstica) 10.0.0/24

Leia mais

Protocolos, DNS, DHCP, Ethereal e comandos em Linux

Protocolos, DNS, DHCP, Ethereal e comandos em Linux Redes de Computadores Protocolos, DNS, DHCP, Ethereal e comandos em Linux Escola Superior de Tecnologia e Gestão Instituto Politécnico de Bragança Março de 2006 Endereços e nomes Quaisquer duas estações

Leia mais

1. PRINCIPAIS PROTOCOLOS TCP/IP

1. PRINCIPAIS PROTOCOLOS TCP/IP 1. PRINCIPAIS PROTOCOLOS TCP/IP 1.1 IP - Internet Protocol RFC 791 Esse protocolo foi introduzido na ARPANET no início dos anos 80, e tem sido utilizado juntamente com o TCP desde então. A principal característica

Leia mais

Redes de Computadores

Redes de Computadores Introdução Instituto de Informátic ca - UFRGS Redes de Computadores Circuitos virtuais, frame relay,tm e MPLS (redes WN) ula 4! Comunicação entre dois dispositivos exige um meio Enlaces ponto-a-ponto ou

Leia mais

Introdução ao MPLS. Tiago Carrijo Setti Algar Telecom

Introdução ao MPLS. Tiago Carrijo Setti Algar Telecom Introdução ao MPLS Tiago Carrijo Setti Algar Telecom Algar Telecom 60 anos de atuação Mais de 1,5 mil associados Mais de 1 milhão de clientes Companhia de capital aberto* Backbone 13 mil km de rede óptica

Leia mais

Redes de Computadores II. Módulo 1 Introdução e a camada de enlace

Redes de Computadores II. Módulo 1 Introdução e a camada de enlace Redes de Computadores II Módulo 1 Introdução e a camada de enlace 1 A Camada de Enlace Principal objetivo da camada: Comunicar dados entre dois equipamentos de rede conectados ao mesmo meio de transmissão

Leia mais

PROTOCOLO PPP. Luciano de Oliveira Mendes 1 Ricardo dos Santos 2

PROTOCOLO PPP. Luciano de Oliveira Mendes 1 Ricardo dos Santos 2 PROTOCOLO PPP Luciano de Oliveira Mendes 1 Ricardo dos Santos 2 RESUMO Neste trabalho é apresentado o Protocolo PPP, Suas principais características e seu funcionamento. Suas variações também são enfocadas

Leia mais

REDES DE COMPUTADORES Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br

REDES DE COMPUTADORES Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br - Aula 1- MODELO DE CAMADAS 1. INTRODUÇÃO A compreensão da arquitetura de redes de computadores envolve a compreensão do modelo de camadas. O desenvolvimento de uma arquitetura de redes é uma tarefa complexa,

Leia mais

Professor: Macêdo Firmino Configuração TCP/IP no Windows 7

Professor: Macêdo Firmino Configuração TCP/IP no Windows 7 Professor: Macêdo Firmino Configuração TCP/IP no Windows 7 Se você tem mais que um computador ou outros dispositivos de hardware, como impressoras, scanners ou câmeras, pode usar uma rede para compartilhar

Leia mais

A Camada de Rede. A Camada de Rede

A Camada de Rede. A Camada de Rede Revisão Parte 5 2011 Modelo de Referência TCP/IP Camada de Aplicação Camada de Transporte Camada de Rede Camada de Enlace de Dados Camada de Física Funções Principais 1. Prestar serviços à Camada de Transporte.

Leia mais

V3PN Voice, Video and Integrated Data IP. Palestra V3PN

V3PN Voice, Video and Integrated Data IP. Palestra V3PN V3PN Voice, Video and Integrated Data IP V3PN Voice, Video and Integrated Data Palestrante André Gustavo Lomônaco Diretor de Tecnologia da IPPLUS Tecnologia Mestre em Engenharia Elétrica Certificado Cisco

Leia mais

Packet Tracer 4.0: Overview Session. Conceitos e práticas

Packet Tracer 4.0: Overview Session. Conceitos e práticas Packet Tracer 4.0: Overview Session Conceitos e práticas Processo de Flooding ou Inundação envia informações por todas as portas, exceto aquela em que as informações foram recebidas; Cada roteador link-state

Leia mais

Engenharia de Tráfego em Redes IP sobre Tecnologia MPLS: Otimização Baseada em Heurísticas.

Engenharia de Tráfego em Redes IP sobre Tecnologia MPLS: Otimização Baseada em Heurísticas. Engenharia de Tráfego em Redes IP sobre Tecnologia MPLS: Otimização Baseada em Heurísticas. Tese submetida à Universidade Federal de Sanat Catarina como parte dos requisitos para a obtenção do grau de

Leia mais

Prof. Manuel A Rendón M

Prof. Manuel A Rendón M Prof. Manuel A Rendón M Tanenbaum Redes de Computadores Cap. 1 e 2 5ª. Edição Pearson Padronização de sistemas abertos à comunicação Modelo de Referência para Interconexão de Sistemas Abertos RM OSI Uma

Leia mais

1 Redes de comunicação de dados

1 Redes de comunicação de dados 1 Redes de comunicação de dados Nos anos 70 e 80 ocorreu uma fusão dos campos de ciência da computação e comunicação de dados. Isto produziu vários fatos relevantes: Não há diferenças fundamentais entre

Leia mais

Redes de Computadores. Mauro Henrique Mulati

Redes de Computadores. Mauro Henrique Mulati Redes de Computadores Mauro Henrique Mulati Roteiro Roteamento na Internet OSPF BGP IPv6 Revisão MPLS Roteamento na Internet IGP: Interior Gateway Protocol (Protocolo de Gateway Interior) Algoritmo de

Leia mais

Alternativas de aplicação do serviço GPRS da rede celular GSM em telemetria pela Internet

Alternativas de aplicação do serviço GPRS da rede celular GSM em telemetria pela Internet Alternativas de aplicação do serviço GPRS da rede celular GSM em telemetria pela Internet Marcos R. Dillenburg Gerente de P&D da Novus Produtos Eletrônicos Ltda. (dillen@novus.com.br) As aplicações de

Leia mais

CAMADA DE REDE. UD 2 Aula 3 Professor João Carneiro Arquitetura de Redes 1º e 2º Semestres UNIPLAN

CAMADA DE REDE. UD 2 Aula 3 Professor João Carneiro Arquitetura de Redes 1º e 2º Semestres UNIPLAN CAMADA DE REDE UD 2 Aula 3 Professor João Carneiro Arquitetura de Redes 1º e 2º Semestres UNIPLAN Modelo de Referência Híbrido Adoção didática de um modelo de referência híbrido Modelo OSI modificado Protocolos

Leia mais

Márcio Leandro Moraes Rodrigues. Frame Relay

Márcio Leandro Moraes Rodrigues. Frame Relay Márcio Leandro Moraes Rodrigues Frame Relay Introdução O frame relay é uma tecnologia de chaveamento baseada em pacotes que foi desenvolvida visando exclusivamente a velocidade. Embora não confiável, principalmente

Leia mais

Aula 4. Pilha de Protocolos TCP/IP:

Aula 4. Pilha de Protocolos TCP/IP: Aula 4 Pilha de Protocolos TCP/IP: Comutação: por circuito / por pacotes Pilha de Protocolos TCP/IP; Endereçamento lógico; Encapsulamento; Camada Internet; Roteamento; Protocolo IP; Classes de endereços

Leia mais

MÓDULO 7 Modelo OSI. 7.1 Serviços Versus Protocolos

MÓDULO 7 Modelo OSI. 7.1 Serviços Versus Protocolos MÓDULO 7 Modelo OSI A maioria das redes são organizadas como pilhas ou níveis de camadas, umas sobre as outras, sendo feito com o intuito de reduzir a complexidade do projeto da rede. O objetivo de cada

Leia mais

REDES DE COMPUTADORES Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com

REDES DE COMPUTADORES Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com - Aula Complementar - MODELO DE REFERÊNCIA OSI Este modelo se baseia em uma proposta desenvolvida pela ISO (International Standards Organization) como um primeiro passo em direção a padronização dos protocolos

Leia mais

MPLS MultiProtocol Label Switching. Trabalho de Redes de Computadores I Autor: Fabricio Couto Inácio Período: 01/2002

MPLS MultiProtocol Label Switching. Trabalho de Redes de Computadores I Autor: Fabricio Couto Inácio Período: 01/2002 MPLS MultiProtocol Label Switching Trabalho de Redes de Computadores I Autor: Fabricio Couto Inácio Período: 0/2002 Por que MPLS? Fatores Motivadores O crescimento rápido da Internet e a difusão de redes

Leia mais

Aula 6 Modelo de Divisão em Camadas TCP/IP

Aula 6 Modelo de Divisão em Camadas TCP/IP Aula 6 Modelo de Divisão em Camadas TCP/IP Camada Conceitual APLICATIVO TRANSPORTE INTER-REDE INTERFACE DE REDE FÍSICA Unidade de Dados do Protocolo - PDU Mensagem Segmento Datagrama /Pacote Quadro 01010101010100000011110

Leia mais

MultiProtocol Label Switching - MPLS

MultiProtocol Label Switching - MPLS MultiProtocol Label Switching - MPLS Prof. S. Motoyama Rede IP Tradicional ROT - roteador ROT ROT ROT ROT ROT ROT ROT ROT ROT uvem IP ROT ROT 2 Encaminhamento de pacote na rede tradicional Prefixo Enderereço

Leia mais

REDES DE COMPUTADORES II. Ricardo José Cabeça de Souza www.ricardojcsouza.com.br

REDES DE COMPUTADORES II. Ricardo José Cabeça de Souza www.ricardojcsouza.com.br REDES DE COMPUTADORES II Ricardo José Cabeça de Souza www.ricardojcsouza.com.br Surgiu final década de 1980 Tecnologia de comutação em infraestrutura redes RDSI-FL(B-ISDN) Recomendação I.121 da ITU-T(1988)

Leia mais

PROJETO DE REDES www.projetoderedes.com.br

PROJETO DE REDES www.projetoderedes.com.br PROJETO DE REDES www.projetoderedes.com.br Curso de Tecnologia em Redes de Computadores Disciplina: Redes I Fundamentos - 1º Período Professor: José Maurício S. Pinheiro Material de Apoio VI PROTOCOLOS

Leia mais

Redes TCP/IP. Prof. M.Sc. Alexandre Fraga de Araújo. alexandref@ifes.edu.br. INSTITUTO FEDERAL DO ESPÍRITO SANTO Campus Cachoeiro de Itapemirim

Redes TCP/IP. Prof. M.Sc. Alexandre Fraga de Araújo. alexandref@ifes.edu.br. INSTITUTO FEDERAL DO ESPÍRITO SANTO Campus Cachoeiro de Itapemirim Redes TCP/IP alexandref@ifes.edu.br Camada de Redes 2 O que acontece na camada de rede Transporta segmentos do hospedeiro transmissor para o receptor Roteador examina campos de cabeçalho em todos os datagramas

Leia mais

O QUE É O ENDEREÇO IP

O QUE É O ENDEREÇO IP O QUE É O ENDEREÇO IP O uso de computadores em rede, tal como a internet, requer que cada máquina possua um identificador que a diferencie das demais. É necessário que cada computador tenha um endereço,

Leia mais

Redes de Computadores

Redes de Computadores Redes de Computadores CAMADA DE REDE DHCP NAT IPv6 Slide 1 Protocolo DHCP Protocolo de Configuração Dinâmica de Hospedeiros (Dynamic Host Configuration Protocol DHCP), RFC 2131; Obtenção de endereço de

Leia mais

ESCOLA SUPERIOR DE TECNOLOGIA E GESTÃO

ESCOLA SUPERIOR DE TECNOLOGIA E GESTÃO ESCOLA SUPERIOR DE TECNOLOGIA E GESTÃO PROJECTO E INSTALAÇÃO DE REDES LOCAIS DE COMPUTADORES O Modelo TCP/IP: Camada Internet Discentes: Ricardo Alexandre Revez Costa, nº5963 Manuel José Terlica Revés,

Leia mais

Curso: Sistemas de Informação Disciplina: Redes de Computadores Prof. Sergio Estrela Martins

Curso: Sistemas de Informação Disciplina: Redes de Computadores Prof. Sergio Estrela Martins Curso: Sistemas de Informação Disciplina: Redes de Computadores Prof. Sergio Estrela Martins Material de apoio 2 Esclarecimentos Esse material é de apoio para as aulas da disciplina e não substitui a leitura

Leia mais

Prof. Samuel Henrique Bucke Brito

Prof. Samuel Henrique Bucke Brito - Switch na Camada 2: Comutação www.labcisco.com.br ::: shbbrito@labcisco.com.br Prof. Samuel Henrique Bucke Brito Introdução A conexão entre duas portas de entrada e saída, bem como a transferência de

Leia mais

Redes de Computadores

Redes de Computadores Redes de Computadores Capítulo 5.6 e 5.7 Interconexões e PPP Prof. Jó Ueyama Maio/2011 SSC0641-2011 1 Elementos de Interconexão SSC0641-2011 2 Interconexão com Hubs Dispositivo de camada física. Backbone:

Leia mais

Parte 2 Usando o CLI do Roteador

Parte 2 Usando o CLI do Roteador Parte 2 Usando o CLI do Roteador O acesso à CLI Comand Line Interface, é feita pelo usuário no roteador com um terminal ou remotamente. Quando acessamos um roteador, devemos efetuar login nele antes de

Leia mais

PROJETO DE REDES www.projetoderedes.com.br

PROJETO DE REDES www.projetoderedes.com.br PROJETO DE REDES www.projetoderedes.com.br Curso de Tecnologia em Redes de Computadores Disciplina: Redes I Fundamentos - 1º Período Professor: José Maurício S. Pinheiro AULA 6: Switching Uma rede corporativa

Leia mais

Universidade do Sul de Santa Catarina. Tecnologia e Comutação Ethernet. Ana Lúcia Rodrigues Wiggers

Universidade do Sul de Santa Catarina. Tecnologia e Comutação Ethernet. Ana Lúcia Rodrigues Wiggers Universidade do Sul de Santa Catarina Tecnologia e Comutação Ethernet Conceitos de Ethernet Nos anos 80 foi publicado o primeiro padrão Ethernet por um consórcio entre a Digital Equipment Company, a Intel,

Leia mais

Redes de Computadores

Redes de Computadores Redes de Computadores Prof. Marcelo Gonçalves Rubinstein Programa de Pós-Graduação em Engenharia Eletrônica Faculdade de Engenharia Universidade do Estado do Rio de Janeiro Ementa Introdução a Redes de

Leia mais

Fundamentos de Redes de Computadores. Arquitetura TCP/IP Endereçamento das Redes Classes de redes Principais protocolos

Fundamentos de Redes de Computadores. Arquitetura TCP/IP Endereçamento das Redes Classes de redes Principais protocolos Fundamentos de Redes de Computadores Arquitetura TCP/IP Endereçamento das Redes Classes de redes Principais protocolos Histórico O TCP/IP é um padrão de comunicação entre diferentes computadores e diferentes

Leia mais

Capítulo 10 - Conceitos Básicos de Roteamento e de Sub-redes. Associação dos Instrutores NetAcademy - Julho de 2007 - Página

Capítulo 10 - Conceitos Básicos de Roteamento e de Sub-redes. Associação dos Instrutores NetAcademy - Julho de 2007 - Página Capítulo 10 - Conceitos Básicos de Roteamento e de Sub-redes 1 Protocolos Roteáveis e Roteados Protocolo roteado: permite que o roteador encaminhe dados entre nós de diferentes redes. Endereço de rede:

Leia mais

1. INTRODUÇÃO AO ATM. O nome ATM vem de ASYNCHRONOUS TRANSFER MODE.

1. INTRODUÇÃO AO ATM. O nome ATM vem de ASYNCHRONOUS TRANSFER MODE. 1. INTRODUÇÃO AO ATM O nome ATM vem de ASYNCHRONOUS TRANSFER MODE. O Protocolo ATM vem se tornando a cada dia que passa o mas importante no meio das Telecomunicações Mundiais. Tudo leva a crer que desempenhará

Leia mais

Introdução as Redes de Computadores Transparências baseadas no livro Computer Networking: A Top-Down Approach Featuring the Internet James Kurose e Keith Ross Redes de Computadores A. Tanenbaum e Prof.

Leia mais

Redes WAN. Redes de Longa Distância Prof. Walter Cunha

Redes WAN. Redes de Longa Distância Prof. Walter Cunha Redes WAN Frame-Relay Redes de Longa Distância Prof. Walter Cunha Desdobramento da ISDN Alta Velocidade Taxas entre 64 Kbps e 2 Mbps Roteamento na Camada de Enlace Usada p/ interligar: WAN, SNA, Internet

Leia mais

2 Avaliação de desempenho de uma rede de telecomunicações

2 Avaliação de desempenho de uma rede de telecomunicações 2 Avaliação de desempenho de uma rede de telecomunicações Ao longo do presente capítulo são introduzidos os principais elementos qualitativos e quantitativos capazes de permitir a avaliação do desempenho

Leia mais

Assumiu em 2002 um novo desafio profissional como empreendedor e Presidente do Teleco.

Assumiu em 2002 um novo desafio profissional como empreendedor e Presidente do Teleco. VPN: Redes Privadas Virtuais O objetivo deste tutorial é apresentar os tipos básicos de Redes Privadas Virtuais (VPN's) esclarecendo os significados variados que tem sido atribuído a este termo. Eduardo

Leia mais

Modelo em Camadas Arquitetura TCP/IP/Ethernet. Edgard Jamhour

Modelo em Camadas Arquitetura TCP/IP/Ethernet. Edgard Jamhour Modelo em Camadas Arquitetura TCP/IP/Ethernet Edgard Jamhour Ethernet não-comutada (CSMA-CD) A Ethernet não-comutada baseia-se no princípio de comunicação com broadcast físico. a b TIPO DADOS (até 1500

Leia mais

Protocolos. Prof. Wladimir da Costa

Protocolos. Prof. Wladimir da Costa Prof. Wladimir da Costa Introdução Até o presente momento discutimos sobre a infraestrutura de redes (hardware, sistema operacional e cabeamento). Agora vamos ver como realmente é feito a troca de informação

Leia mais

Arquitetura TCP/IP. Parte IX Multicast (IGMP e roteamento) Fabrízzio Alphonsus A. M. N. Soares

Arquitetura TCP/IP. Parte IX Multicast (IGMP e roteamento) Fabrízzio Alphonsus A. M. N. Soares Arquitetura TCP/IP Parte IX Multicast (IGMP e roteamento) Fabrízzio Alphonsus A. M. N. Soares Tópicos Hardware multicast Ethernet multicast IP multicast Endereçamento e mapeamento para Ethernet multicast

Leia mais

CONTROLADOR CENTRAL P25 FASE 1 CAPACIDADE MÍNIMA PARA CONTROLAR 5 SITES

CONTROLADOR CENTRAL P25 FASE 1 CAPACIDADE MÍNIMA PARA CONTROLAR 5 SITES CONTROLADOR CENTRAL P25 FASE 1 CAPACIDADE MÍNIMA PARA CONTROLAR 5 SITES O sistema digital de radiocomunicação será constituído pelo Sítio Central, Centro de Despacho (COPOM) e Sítios de Repetição interligados

Leia mais

Modelo de Referência OSI

Modelo de Referência OSI Modelo de Referência OSI Hermes Senger Pós-Graduação Lato Sensu em Redes de Computadores - DC - UFSCar Modelo OSI- 1 A necessidade de padronização Década de 70 : Sucesso das primeiras redes de dados (ARPANET,

Leia mais

Introdução ao Frame Relay. Prof. José Marcos Câmara Brito Inatel - 05/99

Introdução ao Frame Relay. Prof. José Marcos Câmara Brito Inatel - 05/99 Introdução ao Frame Relay Prof. José Marcos Câmara Brito Inatel - 05/99 Objetivo Prover o usuário com uma rede privativa virtual (VPN) capaz de suportar aplicações que requeiram altas taxas de transmissão

Leia mais

Endereçamento IP, Sub-redes e Roteamento

Endereçamento IP, Sub-redes e Roteamento Segurança em Redes Prof. Rafael R. Obelheiro Semestre: 2009.1 Endereçamento IP, Sub-redes e Roteamento Endereçamento IP Endereços IP possuem 32 bits, o que possibilita 2 32 = 4.294.967.296 endereços Na

Leia mais

Há dois tipos de configurações bidirecionais usados na comunicação em uma rede Ethernet:

Há dois tipos de configurações bidirecionais usados na comunicação em uma rede Ethernet: Comunicação em uma rede Ethernet A comunicação em uma rede local comutada ocorre de três formas: unicast, broadcast e multicast: -Unicast: Comunicação na qual um quadro é enviado de um host e endereçado

Leia mais

William Stallings Arquitetura e Organização de Computadores 8 a Edição

William Stallings Arquitetura e Organização de Computadores 8 a Edição William Stallings Arquitetura e Organização de Computadores 8 a Edição Capítulo 7 Entrada/saída Os textos nestas caixas foram adicionados pelo Prof. Joubert slide 1 Problemas de entrada/saída Grande variedade

Leia mais

Contribuição acadêmica

Contribuição acadêmica Contribuição acadêmica Origem deste trabalho em cadeiras do curso de mestrado na COPPE/UFRJ; Continuidade da contribuição acadêmica através do laboratório RAVEL: desenvolvimento de sw para apoio; intercâmbio

Leia mais

Módulo 8 Ethernet Switching

Módulo 8 Ethernet Switching CCNA 1 Conceitos Básicos de Redes Módulo 8 Ethernet Switching Comutação Ethernet 2 Segmentação de Redes Numa Ethernet o meio de transmissão é compartilhado Só um nó pode transmitir de cada vez. O aumento

Leia mais

1.1 Transmissão multimídia em redes

1.1 Transmissão multimídia em redes 1.1 Transmissão multimídia em redes Pode-se dividir a parte de transmissão multimídia em redes de computadores como mostra a figura 1, ou seja, a parte de conferência (que requer interatividade) e a parte

Leia mais

Sistemas Distribuídos Capítulos 3 e 4 - Aula 4

Sistemas Distribuídos Capítulos 3 e 4 - Aula 4 Sistemas Distribuídos Capítulos 3 e 4 - Aula 4 Aula passada Threads Threads em SDs Processos Clientes Processos Servidores Aula de hoje Clusters de Servidores Migração de Código Comunicação (Cap. 4) Fundamentos

Leia mais

TRANSMISSÃO DE DADOS Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com

TRANSMISSÃO DE DADOS Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com - Aula 4 - A CAMADA DE REDE (Parte 2) 1. Flooding (Inundação) Outro algoritmo estático é o algoritmo de inundação, no qual cada pacote de entrada é enviado para todas as linhas de saída, exceto para aquela

Leia mais

Sistemas Distribuídos Comunicação. Edeyson Andrade Gomes www.edeyson.com.br

Sistemas Distribuídos Comunicação. Edeyson Andrade Gomes www.edeyson.com.br Sistemas Distribuídos Comunicação Edeyson Andrade Gomes www.edeyson.com.br Roteiro da Aula Roteiro da Aula Comunicação entre Processos Protocolos Modelo OSI Modelo Cliente Servidor 3 Comunicação entre

Leia mais

Capítulo IV - QoS em redes IP. Prof. José Marcos C. Brito

Capítulo IV - QoS em redes IP. Prof. José Marcos C. Brito Capítulo IV - QoS em redes IP Prof. José Marcos C. Brito Mecanismos básicos Classificação Priorização Policiamento e conformação Gerenciamento de congestionamento Fragmentação Dejjiter buffer Reserva de

Leia mais

Redes de computadores e a Internet. A camada de rede

Redes de computadores e a Internet. A camada de rede Redes de computadores e a Internet Capitulo Capítulo 4 A camada de rede A camada de rede Objetivos do capítulo: Entender os princípios dos serviços da camada de rede: Roteamento (seleção de caminho) Escalabilidade

Leia mais

ANEXO II PROJETO BÁSICO - INTERNET

ANEXO II PROJETO BÁSICO - INTERNET 1. Objetivo 1.1. Contratação de serviços para fornecimento de uma solução de conexão IP Internet Protocol que suporte aplicações TCP/IP e disponibilize a PRODEB acesso a rede mundial de computadores Internet,

Leia mais

Redes de Computadores

Redes de Computadores Redes de Computadores Prof. Marcelo Gonçalves Rubinstein Programa de Pós-Graduação em Engenharia Eletrônica Faculdade de Engenharia Universidade do Estado do Rio de Janeiro Ementa Introdução a Redes de

Leia mais

Aula-19 NAT, IP Móvel e MPLS. Prof. Dr. S. Motoyama

Aula-19 NAT, IP Móvel e MPLS. Prof. Dr. S. Motoyama Aula-19 NAT, IP Móvel e MPLS Prof. Dr. S. Motoyama 1 NAT Network address translation Resto da Internet 138.76.29.7 10.0.0.4 Rede local (ex.: rede doméstica) 10.0.0/24 10.0.0.1 10.0.0.2 10.0.0.3 Todos os

Leia mais

Redes WAN Conceitos Iniciais. Prof. Walter Cunha

Redes WAN Conceitos Iniciais. Prof. Walter Cunha Redes WAN Conceitos Iniciais Prof. Walter Cunha Comutação por Circuito Todos os recursos necessários em todos os subsistemas de telecomunicação que conectam origem e destino, são reservados durante todo

Leia mais

Rede de Computadores II

Rede de Computadores II Slide 1 Técnicas para se alcançar boa qualidade de serviço Reserva de recursos A capacidade de regular a forma do tráfego oferecido é um bom início para garantir a qualidade de serviço. Mas Dispersar os

Leia mais

Fundamentos de Rede. Aula 01 - Introdução e Redes

Fundamentos de Rede. Aula 01 - Introdução e Redes Fundamentos de Rede Aula 01 - Introdução e Redes Contextualização Séculos XVIII e XIX - Revolução Industrial máquinas mecânicas, taylorismo, fábricas hierarquia, centralização da decisão, mainframes Séculos

Leia mais

Prof. Roberto Franciscatto 4º Semestre - TSI - CAFW. Free Powerpoint Templates Page 1

Prof. Roberto Franciscatto 4º Semestre - TSI - CAFW. Free Powerpoint Templates Page 1 Segurança na Web Capítulo 6: Firewall Prof. Roberto Franciscatto 4º Semestre - TSI - CAFW Page 1 Introdução Qual a função básica de um firewall? Page 2 Introdução Qual a função básica de um firewall? Bloquear

Leia mais