Redes de Circuitos Dinâmicos na RNP

Treinamento para participantes do Serviço Experimental Cipó

Agenda

• Redes de Circuitos Dinâmicos• Motivação e adoção por outras NRENs• Modelo de arquitetura• Softwares usados no plano de controle• A rede híbrida da RNP e o SE-Cipó• Treinamento com foco no SE-Cipó

DCN e Rede Híbrida

• DCN: Dinamic Circuit Networko Comutação de circuitos com provisionamento

automático (mais uma vez...)

• Por ser circuito, pressupõe-se:o Caminho de rede único pré-determinado por

sinalizaçãoo Banda garantida ao longo do caminho

• Porém, solução (genérica) deve contemplar:o Múltiplos domínios administrativoso Independência da tecnologia de rede

DCN e Rede Híbrida

• Rede híbrida (para nós): DCN + Rede de pacoteso Garante requisitos de banda fim-a-fim através do

provisionamento dinâmico de circuitos Sobre múltiplos domínios, independente da

tecnologia de rede usada por cada domínioo Domínio: região sob uma mesma administração de

rede Pode ser um AS Pode ser uma rede de campus

Motivação para uso de DCN

• Modelo roteado não fornece tais garantias:o Não há como definir arquitetura de QoS fim-a-fim sobre

múltiplos domínios

• A quem se destina (maiores usuários)?o Aplicações que precisam transferir grandes volumes de

dados Grids, previsão climática, e-ciência etc Fluxos com fortes requisitos de QoS (perda, jitter) Tempo de transferência é crítico

o Virtualização de redeso Fazendo uso de camadas abaixo do IP, p/ex.

Tráfego de dados na ESnet

• TB/mês [Johnston 2011], destaque para Fermilab (FNAL):

Vermelho: top-1000 fluxos IPAmarelo: fluxos usando circuitos dinâmicos a partir de Jan/2010

Laranja: tráfego de circuitosAzul: tráfego IP

LHC - Large Hadron Collider

• Acelerador de partículas do CERN localizado na Suíça

LHC - Large Hadron Collider

• Dados gerados são processados ao redor do globo• Boa parte dos circuitos dinamicamente criados na ESnet

estão relacionados com o LHC

27Km de circunferência

Compact Muon Solenoid (CMS) Grid

[Jonhston 2011]

WLCG – Worls LHC Computing Grid

[Barczyk 2011]

Transferência de dados

• Bases de dados da ordem de TBytes são cada vez mais comuns

• Tempo para transferir 1TB [Dart 2010]:o 10 Mbps: 300 hrs (12,5 dias)o 100 Mbps: 30 hrso 1 Gbps: 3 hrs (discos "rápidos" o bastante?)o 10 Gbps: 20 min (discos e filesystems precisam ser

muito rápidos!)

Transferência de dados

• Tempo para mover Y Bytes num tempo X:

    Disponível em http://fasterdata.es.net/fasterdata/requirements-and-expectations/

Além da garantia de banda

• Controle de congestionamento do TCP Reno reduz o aproveitamento da banda disponívelo Implementações TCP turbinadas (disponíveis no Linux):

Cubic, HTCP, Bic, Vegas etc

• Buffers do TCP precisam ser aumentadoso Auto-tuning de buffers (transmissor e receptor)o Disponível na maioria dos SOs

• Aplicações também precisam ser "espertas":o Ex.: GridFTP

Por que ser dinâmico?

• Configuração manual de circuito muito custosao Tempo de set-up grande, principalmente para circuito

multidomínio Várias interações entre operadores, compatibilização

de tecnologias de rede etc Não escala

• Transferências ocorrem sob demandao Circuitos não devem ficar alocados todo o tempo

Uso racional de recursos

Circuitos dinâmicos

• Solução deve contemplar criação e remoção automáticas de circuitos mediante agendamentoo Por operadores, usuários e/ou aplicaçõeso Necessário definir políticas para tal

• Solução dinâmica se torna escalávelo Permite uma grande quantidade de circuitos sendo

automaticamente configuradoso Dor de cabeça para a gerência?

Boa parte dependerá da arquitetura Processos e ferramentas de gerenciamento devem

estar adaptados à nova realidade

Exemplos de NRENs usando DCN

• USA: ESnet e Internet2• Canada: CANARIE• Europa: GEANT e diversas redes europeias (SURFnet,

NORDUnet, )• Asia: Coréia (KOREN) e Japão (JGN2)• Ampath: primeiras experiências c/ rede híbrida (p/ GLIF

meeting 2011, Rio)• etc

Global Lambda Integrated Facility (GLIF)

[Tanaka 2009]

GOLE: GLIF Open Lightpath Exchange

Modelo de arquitetura para DCN

• Vários desafios:o Aspectos multidomínio, diferentes tecnologias de rede,

controle de admissão, agendamento etc• A serem destacados:

o Negociação multidomínioo Equipamentos s/ suporte a circuito virtualo Efetivação da reserva de recursos ao longo do caminho

• Arquitetura genérica contempla os desafios em destaque

Modelo de arquitetura para DCN

• Arquitetura genérica usa o conceito de plano de controle e plano de dadoso Plano de controle: Protocolos e SW que definem o

encaminhamento dos pacoteso Plano de dados: Faz o encaminamento dos pacotes

conforme definido pelo plano de controle

• Em geral, ambos os planos residem no mesmo equipamento, mas podem estar separados:o Plano de controle rodando fora dos equipamentos que

fazem o encaminhamento dos dadoso Permite um mesmo SW controlando toda a rede

Plano de controle na arquitetura DCN

• Solução para plano de controle se divide em interdomínio (IDC) e intradomínio (DC)

[DCN 2008]

Plano de controle na arquitetura DCN

• Controle intradomínio cuida da configuração e remoção dos circuitos nos equipamentos num dado domínioo Dependente da tecnologia de redeo Papel do DC (Domain Controller)

• Controle interdomínio cuida da negociação do circuito entre domínios vizinhoso Deve ser independente da tecnologia de redeo Sinaliza as ações de controle para o intradomínioo Papel do IDC (Inter-Domain Controller)

Detalhes de uma arquitetura DCN

[Tanaka 2009]

Softwares adotados

• Principais SWs para controle interdomínio:o OSCARS (Esnet, Internet2, RNP etc)o AutoBAHN (GEANT)o UCLP (CANARIE)

• Principal SW para controle intradomínioo DRAGON

• SWs para front-end de gerenciamento:o ION (Internet2)o MEICAN (RNP)o Interfaces web dos SWs de IDC

Rede híbrida da RNP

• Rede Cipó: futura rede híbrida da RNP

• SE-Cipó: Serviço Experimental com foco na rede Cipó

• Potencial de uso:o Transferências de dados para computação em grade

HepGrid (UERJ), Sprace (UNESP)o Transmissão de vídeo 4K (CineGRID, CPqD)o Espetáculos de dança interativao Telemedicina etc

Arquitetura do SE-Cipó

• Topologia descentralizada– Diversos domínios OSCARS instalados nos PoPs

• Mas com alguns elementos centralizados:– Um OSCARS instalado no backbone– Somente uma instalação do perfSONAR– Somente uma instância do sistema MEICAN

gerenciando todos os domínios

Arquitetura do SE-Cipó

• O backbone da RNP – rede Ipê – se consistirá num único domínio– Fronteiras do domínio coincidem com a fronteira

administrativa, ou seja, até as interfaces para os equipamentos de distribuição do PoPs

• Clientes dos PoPs farão parte de um domínio separado– É possível que outros domínios surjam ligados ao

domínio PoP:• Instituições ou redes metropolitanas, p/ex.

Topologia do SE-Cipó

Mais sobre o SE-Cipó

• Testes interdomínio com Internet2 foram realizados na reunião do GLIF 2011 no Rio

• Há um grupo na RNP trabalhando na seleção de potenciais usuários do serviço, além dos já conhecidos

• Esforço para criar processos de operação do backbone (Gerência de Operações) aderentes ao novo “paradigma”

Mais sobre o SE-Cipó

• Prazo alvo para efetivação do serviço no 1º semestre de 2012

• GTs estão envolvidos com o desenvolvimento do serviço nas áreas estratégicas:– Arquitetura (ligação do OSCARS aos roteadores do

backbone)– Documentação e geração de templates para

configuração de clientes– Monitoramento– Gerenciamento via MEICAN– Weathermap

Treinamento com foco no SE-Cipó

• É previsto treinamento para técnicos e gestores envolvidos com o serviço experimental– Técnicos dos PoPs, de instituições clientes e de

laboratórios usuários

• 1ª realização no SCI 2011, sendo elencado para nova oferta no SCI 2012

• Utilização de infraestrutura remota de laboratório– Hospedada na UNIRIO, em fase de ativação

Treinamento com foco no SE-Cipó

AGENDA Segunda Terça Quarta Quinta Sexta

Manhã (4h) + break

Introdução, agenda

Dragon (intro.) OSCARS (intro., instal.) MEICAN (intro.,config.) SE-Cipó

Break

Tecnologias de redes híb.

Dragon (instal., config.)

OSCARS (config. intrad., testes)

MEICAN (config., uso) Discussões

  Almoço

Tarde (2h)Testes da infra.,

lab. de QinQDragon (testes)

OSCARS (conf. interd., testes)

Monitoramento  

Lay-out do laboratório

• POD: conjunto de 2 switches e um servidoro Switches são Extreme ou Ciscoo Servidor é Dell com SO base VMware ESXi

• Cada POD representa um domínio:o Servidor abriga VMs do plano de controle e VMs de

clienteso VMs de clientes e switches representam plano de

dados

• Topologia possui 4 PODs dispostos em anel + servidor extra para abrigar serviços centrais

Topologia lógica

Topologia física

Instalação física

Atividades práticas

• Lay-out do laboratório• Plano de endereçamento• Testes de acesso a VMs e switches• Testes de conectividade• Verificação de softwares instalados• Verificação da configuração base dos switches• Acompanhamento da instalação do Dragon• Configuração do Dragon e teste intradomínio

Atividades práticas

• Acompanhamento da instalação do OSCARS• Configuração do OSCARS para intradomínio e testes• Configuração do OSCARS para interdomínio e testes• Acompanhamento da instalação do MEICAN• Configuração do MEICAN e testes intra e interdomínio• Uso de ferramentas de monitoramento

Obrigado!

sidney@uniriotec.br

Slides de BACKUP

Arquitetura do SE-Cipó• No domínio da rede Ipê não haverá uso de Dragon

– Roteadores de núcleo são capazes de fazer MPLS e rodar OSPF-TE e RSVP-TE

– Mesma abordagem atualmente usada pela ESnet e pela Internet2

• Domínio do PoP fará uso de Dragon– Configuração dos switches de distribuição, etc– Provavelmente o mesmo nos domínios clientes– Maioria dos clientes deve se ligar c/ VLAN estática

Arquitetura do SE-Cipó• O que a RNP fará que ninguém mais tentou

fazer ainda (até onde sabemos):– Usar os Logical Systems dos Junipers MX para

“virtualizar” a DCN• Logical System é como a Juniper chama sua

funcionalidade de roteador virtual (“virtual router” é uma forma mais simplificada disto)

– Ideia é garantir isolamento da rede IP de produção

Arquitetura do SE-Cipó• Uso de logical systems:

– Interligações entre logical systems através da VLAN 3200 configurada nas interfaces físicas

– Policiamento a 1 Gbps na VLAN 3200 do enlace, ambos sentidos

– Por enquanto sem reserva de banda• Tráfego IP de produção pode “invadir” banda dos

circuitos– MPLS, LDP e RSVP habilitados nas interfaces WAN

do backbone

Arquitetura do SE-Cipó• Uso de logical systems:

– Acesso para clientes previsto apenas nos PoPs RS, SC, PR, SP, RJ e PA• Padronizado usar porta ge-2/3/4, sem endereço IP

aplicado– Mais uma interface de acesso em RJ e SP:

• No RJ, a xe-3/0/0.3250 para acesso ao OSCARS da Rede Ipê

• Em SP, a ge-2/3/3 para falar com Ampath– Faixas IPv4 e IPv6 p/ interfaces da VLAN 3200

Arquitetura do SE-Cipó• OSCARS da rede Cipó:

– Servidor da aplicação instalado no escritório da RNP no Rio

– Acesso do OSCARS aos equipamentos via SSH– Configuração dos equipamentos via junoscript– Usuário “oscars” configurado nos Log.Sys.

• Permissão de configuração apenas nestas instâncias– Somente as interfaces ge-2/3/4 podem ser

configuradas (ge-2/3/3 no caso de SP)

Arquitetura do SE-Cipó• Topologia lógica:

Arquitetura do SE-Cipó• Topologia física +

lógica:

Arquitetura do SE-Cipó• Problemas identificados:

– SNMP não faz distinção dos Log. Sys., enxerga apenas a caixa (problemas foram contornados)

– OSCARS compilado para falar junoscript não fala com Dragon e vice-versa

– Problemas com “configurate private” do Juniper:• Se algum operador usar este comando, OSCARS não

consegue configurar o equipamento

– Lixo de configuração nos Log. Sys, qdo circuito não é estabelecido (remoção manual)