TERMO DE REFERÊNCIA
TERMO DE REFERÊNCIA
1. DESCRIÇÃO CONTRATAÇÃO SOLUÇÃO DE CONEXÃO DA PRODAM MUNICIPAL DE SÃO PAULO – PMSP – À INTERNET COM LINKS REDUNDANTES.
A FIM DE GARANTIR A DISPONIBILIDADE DE CONEXÃO DA PMSP À INTERNET E DOS MUNÍCIPES AOS SERVIÇOS PRESTADOS POR ELA, ESSES ACESSOS SERÃO CONTRATADOS EM 02 LOTES PARA OS SERVIÇOS DE LINK INTERNET, CONTEMPLANDO, ASSIM, O CONTINGENCIAMENTO DE OPERADORAS DE TELECOMUNICAÇÕES.
E UM LOTE ESPECíFICO DE AQUISIÇÃO DE EQUIPAMENTOS PARA O FUNCIONALMENTO DESTA SOLUÇÃO.
1. CONDIÇÕES GERAIS DE PARTICIPAÇÃO
1.1. A licitante entende, e concorda que as quantidades especificadas para cada item do objeto foram baseadas em aproximações e previsões de futuros projetos com o objetivo de não reduzir a flexibilidade na possível execução destes futuros projetos, e que podem não se concretizar em efetiva encomenda do equipamento por parte da CONTRATANTE em quaisquer quantidades, não caracterizando, portanto, promessa de consumo futuro.
1.2. Com referencia ao lote 3 deverá estar presente no envelope de habilitação da licitante, documentação comprovando:
1.2.1. Que a licitante é o fabricante, ou distribuidor autorizado no Brasil do fabricante dos equipamentos ofertados.
1.2.2. Que a licitante está autorizada pelo fabricante a prestar serviços de manutenção nos equipamentos, sem prejuízo para a garantia destes.
1.2.3. Declaração de que possui aparelhamento técnico adequado para a execução do objeto, discriminando as suas instalações, apresentando a relação do pessoal técnico especializado incumbido da execução dos serviços, com a indicação da qualificação profissional dos principais membros da sua equipe técnica.
1.2.4. Apresentar atestado de capacidade técnica (A.C.T) expedido por pessoa jurídica de direito público ou privado que comprove que a LICITANTE tenha fornecido produtos compatíveis em características e quantidades com os objetos de maior relevância deste Termo de Referência
1.3. Com referencia ao lote 3 deverá estar presente no envelope com a proposta técnica da licitante, documentação comprovando:
1.3.1. Catálogos dos equipamentos ofertados, inclusive acessórios.
1.3.2. Certificados de Homologação emitidos pela ANATEL, referentes aos equipamentos de comunicação de dados ofertados, conforme determina a Resolução nº. 242 da ANATEL, de 30 de novembro de 2000.
1.3.3. Catálogos e certificados de homologação ANATEL faltantes serão objeto de pedido de diligência, e deverão ser fornecidos em no máximo 2 dias úteis.
1.3.4. Deverão ser ofertados todos os softwares requisitados em CD/DVD originais, com suas respectivas licenças de uso originais ou poderão estar disponiveis na internet com a descrição URL de download dos softwares.
2. DEFINIÇÕES E ABREVIATURAS
2.1. 10G ou 10GbE: 10-gigabit ethernet, sem distinção entre meios de transmissão ópticos ou metálicos.
2.2. 1GBE, 1GbE, GBE, GbE: gigabit ethernet, sem distinção entre meios de transmissão ópticos ou metálicos.
2.3. 24/7/356: dito do serviço disponível a todas as horas do dia, todos os dias da semana, todos os dias do ano, inclusive feriados.
2.4. bps: bits por segundo.
2.5. combo (porta): porta com função dupla, podendo assumir personalidade modular SFP ou personalidade fixa 1000BASE-T, que não podem ser utilizadas simultaneamente. Mecanicamente é composta por uma porta com uma entrada fixa para conector RJ45, e uma entrada para módulo SFP.
2.6. FE (porta): porta fast-ethernet. No caso de porta modular, utiliza módulo SFP apropriado para fast-ethernet 100Mbps, que não deve ser confundido com os módulos SFP apropriados para gigabit-ethernet.
2.7. FEC (G.709): Forward Error Correction, algoritmo de correção de erros de transmissão, conforme definido no padrão ITU-T G.709.
2.8. FIB: Forwarding Information Base: tabela de busca rápida de baixíssima latência, utilizada pelo plano de dados para encaminhar pacotes.
2.9. Gbps: gigabits por segundo (bilhões de bits por segundo), também denotado Gbit/s.
2.10. GiB: gibibytes: Unidade IEC utilizada para expressar quantidade de memória em sistemas computacionais baseados em arquitetura binária. Equivale a exatamente 1.073.741.824 bytes ou 230 bytes. Muitas vezes confundido com "gigabyte".
2.11. IPv4, IPv6: Protocolo Internet (IP) versão 4 ou versão 6, conforme definido pela IETF
2.12. L2: equipamento de comutação de pacotes IPv4 e IPv6, sem capacidade de roteamento IPv4 e IPv6.
2.13. L3: equipamento de comutação de pacotes IPv4 e IPv6, com capacidade de roteamento IPv4 e IPv6.
2.14. line-rate: mesmo que wire-speed.
2.15. Metro-ethernet: equipamento com suporte a funções estendidas de ethernet OAM (EFM e CFM), roteamento e transporte de pacotes próprio para operar como camada de transporte ou borda em rede metropolitana de serviços convergidos.
2.16. Mbps: milhões de bits por segundo, também denotado Mbit/s.
2.17. Mpps: milhões de pacotes por segundo.
2.18. non-blocking: é dito do equipamento ou módulo cuja arquitetura interna e capacidade de comutação, roteamento, e encaminhamento de pacotes garante que não haverá contenção
de recursos internos mesmo com todas as portas operando em sua capacidade máxima efetiva. Neste edital, esta definição é estendida para aplicar-se a todas as operações do plano de dados, inclusive mas não limitado a: roteamento, classificação, modificação, e encaminhamento de pacotes.
2.19. OAM: funcionalidades específicas para apoio das atividades de Operação, Administração e Gerenciamento.
2.20. oversubscription: e dito do componente (módulo, cartão de interface, chassis, matriz de comutação, etc) que não é capaz de operar com todas as suas portas funcionando em máxima capacidade ao mesmo tempo em determinadas situações, por limitações de largura de banda dos canais de comunicação. Por exemplo um módulo com 2 interfaces 100-gigabit-ethernet cuja conexão com o resto do chassis seja menor que 200Gbit/s em cada direção (total: 400Gbit/s), ou cujas conexões internas entre as portas sejam menores que 100Gbit/s em cada direção (total: 200Gbit/s), opera em modo de oversubscrition.
2.21. pps: pacotes por segundo.
2.22. RIB: Routing Information Base: Tabela de roteamento, contendo rotas ativas e inativas, utilizada pelo plano de controle (routing engine).
2.23. wire-speed: é dito do equipamento onde a velocidade máxima efetiva de todas as portas é igual à máxima velocidade teórica das mesmas.
3. DA ENTREGA DO OBJETO
3.1. A entrega do objeto deverá ser realizada em até 75 dias corridos para os LOTE 1 e 2, em até 60 dias corridos para LOTE 3, sempre contados a partir da assinatura de cada Instrumento Contratual.
3.2. No caso do lote 3:
3.2.1. A documentação de entrega de equipamentos, inclusive notas fiscais, deve fazer referência ao nome do modelo do equipamento utilizado pelo fabricante, nome do fabricante e modelo (part number) do equipamento em questão.
3.2.2. Não serão aceitas descrições genéricas em notas fiscais.
3.2.3. Acessórios ou opcionais que sejam adicionados ao equipamento base para adequá- lo ao exigido por esse edital devem ser referenciados separadamente, no mesmo formato. Em particular, todos os módulos componentes de um sistema tipo chassi ou modular devem ser referenciados separadamente.
3.2.4. A CONTRATADA deverá fornecer à CONTRATANTE tabela de referência que permita facilmente identificar todos os componentes/módulos/equipamentos/acessórios e seus números de modelo (part- numbers) referenciado nas notas fiscais, para cada item do objeto.
4. Instalação
4.1. A instalação dos lotes deverá ser realizada em até 75 dias corridos para o LOTE 1 e em até 75 dias para LOTE 2, contados a partir da assinatura de cada Instrumento Contratual.
4.2. A instalação e configuração do lote 3 deverá ser realizada em até 30 dias após o recebimento dos equipamentos.
4.3. A CONTRATADA deverá prover a mão de obra necessária para toda configuração dos equipamentos ofertados no lote 3 para atender as necessidades da CONTRATANTE.
4.4. A CONTRATADA deverá fornecer todo o suporte técnico, mão de obra, software e hardware necessários para configuração dos equipamentos ofertados no lote 3 para atender as necessidades da CONTRATANTE.
4.5. O acesso a informações de gestão dos equipamentos será de responsabilidade da Prodam-SP, a CONTRATADA para o lote 3 será responsável por:
4.5.1. Configuração dos equipamentos ofertados no lote 3 atendendo a solicitação dos núcleos de engenharia de telecomunicações, suporte a telecomunicações e segurança da informação da PRODAM.
4.5.2. Substituição de componentes de hardware que apresentarem defeito, desde que fornecidos pela CONTRATADA, e que comprovadamente não seja devido ao uso indevido ou dano de responsabilidade imputável à Prodam-SP, tais como falhas de proteção elétrica no ambiente, falhas mecânicas (quedas, impactos, etc.), de controle de umidade e temperatura.
4.5.3. Correção de falhas de software ou sistema operacional dos elementos fornecidos, uma vez comprovado não ser devido a erros de configuração de responsabilidade da Prodam-SP ou ainda, caso seja comprovado formalmente pelo fabricante que são devidos a problemas intrínsecos do software (bug) ou versão disponibilizada.
4.5.4. Atualizações de softwares ou correções (patches) dos elementos componentes da solução, mediante requisição da contratante, ou desde que comprovadamente documentado pelo fabricante tratar-se de correções indispensáveis para a manutenção do nível de serviço prestado ou correção de bug.
4.6. O Acordo Operacional poderá ser revisado entre a PRODAM-SP e a CONTRATADA quando houver comum acordo sobre tal necessidade.
5. DA GARANTIA
5.1. Os equipamentos do lote 3 deverão ser ofertados com as referentes garantias conforme quadro abaixo:
ITENS | Quantidade | Lote | Garantia |
Roteador de borda IP 5Gbps (escalável para >36Gbps), 20Mpps, 10 portas 1GbE modulares, 1 porta 10GbE modular | 3 | 3 | 60 meses |
Módulo 10GbE óptico 10GBASE-SR, 850nm | 3 | 3 | 60 meses |
Módulo SFP 1000BASE-T 10/100/1000, RJ45 | 30 | 3 | 60 meses |
QOS 10 Gbps | 2 | 3 | 60 meses |
SWITCH DATA CORE | 2 | 3 | 60 meses |
Mini Gbic – Transceiver SR do tipo SFP+ | 8 | 3 | 60 meses |
Cordão óptico tipo LC/SC 10m, | 8 | 3 | 12 meses |
FIREWALL 10 Gbps | 2 | 3 | 60 meses |
IDS/IPS 5 Gbps | 2 | 3 | 60 meses |
Firewall de Gerenciamento | 1 | 3 | 60 meses |
6. Suporte técnico
6.1. A CONTRATADA deverá fornecer, durante a vigência do contrato, atendimento, suporte técnico, garantia para os serviços contratados.
6.2. O prazo para a resolução dos chamados técnicos é de 4 (quatro) horas.
6.3. O início do atendimento não poderá ultrapassar o prazo de 02 (duas) horas corridas, após a abertura do chamado.
6.4. A CONTRATA também deverá fornecer uma lista de recorrência (scalation list), da qual constará todos os níveis hierárquicos da empresa para a resolução do chamado.
6.5. Através do serviço de suporte técnico deverá ser possível realizar a abertura, acompanhamento e fechamento de chamados técnicos, relacionados com indisponibilidade e desempenho dos serviços de conectividade IP-Dedicado, configuração dos equipamentos, gerência e segurança.
6.6. Os serviços de registro de chamadas e de suporte técnico deverão estar disponível 24 (vinte e quatro) horas por dia, 07 (sete) dias por semana, todos os dias do ano.
6.7. A solução dos problemas dos serviços e o restabelecimento dos serviços deverão obedecer a taxa mensal de nível de serviço (SLA) de 99,5%.
6.8. Dever ser disponibilizada à PRODAM ferramenta para visualização on-line, via WEB, do tráfego de entrada e saída, 24 horas por dia, 7 dias por semana.
6.9. Em caso de falha/inoperância de qualquer componente instalado, detectado pela CONTRATADA, é obrigação da mesma abrir chamado técnico imediatamente após a constatação do problema, e informar à PRODAM sobre a abertura do chamado e prazo para normalização.
6.10. A CONTRATADA deverá designar profissionais plenamente capacitados para prestar suporte técnico à PRODAM.
6.11. A CONTRATADA deverá disponibilizar uma Central de Atendimento com número 0800 e um endereço eletrônico Internet (e-mail), pelo qual os técnicos da CONTRATANTE farão solicitações durante a vigência do contrato, para atendimento, suporte técnico, garantia, registros de ocorrências e as solicitações de reparo, bem como para acompanhamento da solução dos problemas.
6.12. Durante o atendimento, o Service Desk (ou central de atendimento equivalente) da CONTRATADA deverá informar o número de protocolo, por meio do qual serão gerenciados os SLAs de cada tipo de solicitação.
7. TREINAMENTO (LOTE 3)
7.1. A CONTRATADA deverá prever treinamento no mínimo para 10 (dez) empregados da PRODAM-SP (divididos em até 2 (duas) turmas de 5 (cinco) empregados, agendadas em datas distintas, a critério da Prodam). Este deverá ser ministrado dentro do município de São Paulo com acesso adequado por meios de transporte público e/ou privado. Caso contrário, a CONTRATADA será responsável pelo transporte, refeições e hospedagem pelo tempo que durar o treinamento.
7.2. Os treinamentos não serão realizados em qualquer dependência da CONTRATANTE.
7.3. Os treinamentos deverão ser reconhecidos como oficiais pelos fabricantes dos equipamentos (constando em listas de cursos), com emissão de certificado de participação e possuir no mínimo 16 horas por módulo, incluindo teoria e prática em laboratório aprovado pelo fabricante, em datas e horários definidos em conjunto. Entende-se por módulo, cada equipamento ofertado no lote 3, ou seja, , firewall, IPS, filtro de conteúdo, QoS, Switch, Roteador, etc.
7.4. Após a assinatura do instrumento contratual será elaborado um cronograma para a realização dos treinamentos, de comum acordo entre as partes.
8. DOS LOTES
A fim de garantir a disponibilidade de conexão da PMSP e PRODAM-SP à internet e portanto o acesso dos munícipes aos serviços eletrônicos via Internet prestados por elas, o serviço de conexão à Internet será contratado em 2 (dois) lotes distintos (lote 1 e lote 2), fornecidos por empresas diversas com estrutura de conexão à Internet independentes entre si, contemplando assim o contingenciamento de operadoras de Telecomunicações.
As licitante poderão ofertar propostas para os dois lotes, sendo que a vencedora do lote 1 não poderá ser a vencedora do lote 2. Caso isso ocorra, a proposta para o lote 2 será recusada.
8.1. Lote 1
8.1.1. Contratação de Empresa para Prestação de Serviços de Telecomunicações,
Comunicação de Dados, por meio de conexão IP dedicado a internet para a PRODAM-SP, por 36 meses, prorrogáveis conforme legislação vigente, através de sistemas completos e integrados que atenda plenamente aos requisitos.
8.1.2. O lote prevê a instalação de um link com capacidade de 1 (um) Gbps (Gigabit por segundo), na unidade Barra Funda.
ITENS | Quantidade | Lote |
LINK Internet 1 Gbps IP DEDICADO | 1 | 1 |
8.2. A solução prevê a instalação de um link com capacidade de 1 (um) Gbps (Gigabit por segundo) simétrica, através de enlace de comunicações gigabit ethernet simétrico, com redundância.
8.3. A banda nominal será de 1 Gbps (um gigabit por segundo).
8.4. A CONTRATADA deverá possuir Termo de Autorização da ANATEL para a prestação do serviço objeto deste edital.
8.5. Deverão as licitantes, anexar cópia autenticada do Termo de Autorização da ANATEL para a prestação do serviço objeto deste edital, à documentação da proposta técnica.
8.6. Lote 2
8.6.1. O lote prevê a instalação de um link com capacidade de 1 (um) Gbps (Gigabit por segundo), na unidade Barra Funda.
ITENS | Quantidade | Lote |
LINK Internet 1 Gbps IP DEDICADO | 1 | 2 |
8.6.2. A vencedora do lote 1 não poderá ser a vencedora do lote 2, caso isso ocorra sua proposta será recusada.
8.6.3. Contratação de Empresa para Prestação de Serviços de Telecomunicações, Comunicação de Dados, por meio de conexão IP dedicado a internet para a PRODAM-SP, por 36 meses, prorrogáveis conforme legislação vigente, através de sistemas completos e integrados que atenda plenamente aos requisitos.
8.6.4. DAS RESTRIÇÕES TÉCNICAS
8.6.4.1. No interesse de garantir a completa independência da conexão da CONTRATANTE à Internet em âmbito nacional e internacional, serão desclassificadas do objeto, e tão somente para este lote:
8.6.4.1.1. Quaisquer empresas que pertençam ao mesmo grupo econômico que a empresa licitante vencedora do lote 1 e 2 do objeto, ou que desta sejam
controladoras ou que por esta sejam controladas, conforme definido pela resolução nº 101 de 04/02/1999 da ANATEL.
8.6.4.1.2. Que possuam estrutura de rede em comum com a vencedora dos lotes 1 e 2 do objeto.
8.6.4.1.3. É considerada estrutura de rede em comum inclusive aquela disponibilizada através de EILD, aluguel, subcontratação, ou quaisquer outros dispositivos similares.
8.6.4.1.4. No caso específico de estrutura de rede restrita a enlaces de conexão internacional, será admitida estrutura de rede em comum com a da empresa licitante vencedora dos lotes 1 e 2 do objeto, desde que esta estrutura em comum não compreenda mais que metade da capacidade de conexão internacional de qualquer uma das duas empresas.
8.6.4.1.5. As CONTRATADAS deverão possuir Termo de Autorização da ANATEL para a prestação do serviço objeto deste edital.
8.6.4.1.6. Deverão as licitantes, anexar cópia autenticada do Termo de Autorização da ANATEL para a prestação do serviço objeto deste edital, à documentação da proposta técnica.
8.7. Lote 3
8.7.1. Contratação de Empresa para a aquisição de equipamentos com serviço de configuração e instalação na unidade PRODAM-SP.
8.7.2. A CONTRATADA deverá instalar e configurar os seguintes equipamentos na unidade PRODAM da Barra Funda:
ITENS | Quantidade | Lote |
Roteador de borda IP 5Gbps (escalável para >36Gbps), 20Mpps, 10 portas 1GbE modulares, 1 porta 10GbE modular | 3 | 3 |
Módulo 10GbE óptico 10GBASE-SR, 850nm | 3 | 3 |
Módulo SFP 1000BASE-T 10/100/1000, RJ45 | 30 | 3 |
QOS 10 Gbps | 2 | 3 |
SWITCH DATA CORE | 2 | 3 |
Mini Gbic – Transceiver SR do tipo SFP+ | 8 | 3 |
Cordão óptico tipo LC/SC 10 Mts, | 8 | 3 |
FIREWALL 10 Gbps | 2 | 3 |
IDS/IPS 5 Gbps | 2 | 3 |
Firewall de Gerenciamento | 1 | 3 |
8.7.3. A solução deverá ser fornecida conforme ilustra a topologia conceitual da figura 1, de forma a atender as necessidades da CONTRATANTE.
LOTE 1 E 2
9. LINK 1 Gbps.
FIGURA 1 –Topologia Logica
Anexo I
9.1. As CONTRATADAS vencedora do LOTE 1 e 2, respectivamente, deverá instalar, manter e configurar o LINK 1 Gbps IP DEDICADO no seguinte endereço:
9.2. Unidade PRODAM localizada no edifício Los Angeles, condomínio Agua Branca, Av. Xxxxxxxxx Xxxxxxxxx, xx 0000, Xxxxx Xxxxx, Xxx Xxxxx/XX.
9.3. A CONTRATADAS deverão fornecer um (1) acesso dedicado (ativo), conectando o site na unidade Prodam diretamente à Internet.
9.4. AS CONTRATADAS deverão ser diretamente autorizada pela ANATEL (Agência Nacional de Telecomunicações) a prover este tipo de serviço.
9.5. A Prodam usará sua licença de AS (Autonomous System) durante o contrato vigente. Assim, a CONTRATADA fornecerá todo o suporte técnico e mão de obra para configurar os equipamentos de sua propriedade para atender as necessidades da CONTRATANTE
na configuração do AS.
9.6. O acesso deverá prever a utilização de IPs pertencentes à PRODAM e de Autonomous System (AS). Para tanto, todos os serviços de suporte e configuração dos equipamentos de sua propriedade deverão estar inclusos neste fornecimento.
9.7. A solução prevê a instalação de um enlace de telecomunicações com capacidade de 1 (um) Gbps (Gigabit por segundo), simétrico. O enlace de comunicações entre contratante e contratada deverá ser óptico, e utilizar caminhos redundantes de fibra óptica até a abordagem da edificação.
9.8. O equipamento de terminação da contratada deverá disponibilizar o serviço de acesso à Internet à contratante através de duas portas gigabit ethernet, padrão 1000BASE-T, sendo um para o roteador principal da contratante, e o outro para o roteador secundário da contratante. Também é possível a utilização pela contratada de dois equipamentos de terminação independentes, cada um deles com uma porta gigabit ethernet padrão 1000BASE-T, para conexão dos equipamentos da contratante.
9.9. A CONTRATADA deverá fornecer link de acesso à internet, com banda garantida (sem compartilhamento de banda) de 1 Gbps através da conectividade IP, sem limites na quantidade de transferência de dados, simétrico (1 gigabit por segundo upstream e 1 gigabit por segundo downstream).
9.10. A CONTRATADA deverá possuir estrutura de rede e ASN próprios.
9.11. A CONTRATADA deverá possuir pelo menos duas saídas internacionais próprias, ou contrato de trânsito diretamente com pelo menos dois provedores de backbone internacional.
9.12. A capacidade agregada das saídas internacionais próprias, ou dos contratos de trânsito com provedores de backbone internacional, não pode ser inferior à 20Gbit/s (20x109 bits por segundo).
9.13. A CONTRATADA deverá possuir conectividade nacional com servidores DNS Raiz localizados no Brasil (x.xxxx-xxxxxxx.xxx, x.xxxx-xxxxxxx.xxx, x.xxxx-xxxxxxx.xxx, l.root- xxxxxxx.xxx, etc), e servidores DNS raiz da hierarquia brasileira localizados no Brasil (x.xxx.xx, x.xxx.xx, x.xxx.xx), preferencialmente através de conexão direta ou através de ponto de troca de tráfego nacional com os datacenters/redes que hospedam estes servidores.
9.14. A CONTRATADA deverá possuir conexões diretas em território nacional com as PMS (Poder de Mercado Significativo), através de ponto de troca de tráfego (PTT) em território nacional ou interconexão em território nacional.
9.15. A rede interna da CONTRATADA deverá prever redundância de rotas e equipamentos, de modo que eventuais falhas em equipamentos e linhas de dados não afetem a disponibilidade do serviço.
9.16. Todos os equipamentos instalados deverão ser capazes de suportar a velocidade máxima solicitada de 1 (um) Gbps sem a necessidade de qualquer tipo de adição ou substituição de hardware, software ou licenças.
9.17. A CONTRATADA (lote 1 e 2) fornecerá em comodato todos os equipamentos, acessórios e serviços necessários à instalação e manutenção dos serviços.
9.18. A CONTRATADA deverá fornecer todo o suporte técnico, mão de obra, software e hardware que se fizerem necessários para configurar os equipamentos de sua propriedade para atender as necessidades da CONTRATANTE.
9.19. A CONTRATADA deverá ser diretamente autorizada pela ANATEL (Agência Nacional de Telecomunicações) a prover serviços de telecomunicações. A proposta comercial deverá descrever a tecnologia a ser utilizada para provimento do serviço e como tecnicamente será assegurada e garantida a taxa de nível de serviço (SLA) solicitada.
9.20. Os links a serem contratados deverão ter 100% da velocidade e garantia de banda.
9.21. O link devera contemplar o fornecimento de roteador, com manutenção e gerenciamento de falhas tanto do roteador quanto do link.
9.22. A empresa poderá efetuar vistoria técnica no local onde será instalado o link.
9.23. O agendamento da vistoria técnica poderá ser efetuado junto ao Departamento de XXXXXXXXX, pelo telefone (11) xxxxxxxx.
9.24. A licitante deverá realizar vistoria na localidade de instalação do enlace de telecomunicações.
9.25. Para fins de julgamento o valor total do serviço será composto do valor mensal da prestação de serviços multiplicado por 12 meses somado custo de instalação.
9.26. Os serviços deverão ser prestados com total segurança, sigilo e inviolabilidade dos dados, não podendo ser sujeito a inspeção, analise de qualquer espécie do trafego destinado a equipamentos no Brasil exceto em caso de solicitação judicial.
9.26.1. Da Instalação LINK 1Gbps.
9.26.1.1. Os custos de instalação deverão ser detalhados, se houverem, e compor o valor da primeira medição da prestação dos serviços.
9.26.1.2. O canal de comunicação deverá ter como meio físico de transmissão: cabos de fibra-óptica em configuração redundante (caminho de proteção ou anel), utilizando rotas alternativas geograficamente distintas, do ponto de instalação na CONTRATANTE até ponto de presença da CONTRATADA (“dupla abordagem”).
9.26.1.3. Será exigida a comprovação por parte da CONTRATADA da utilização de dupla abordagem
9.26.1.4. O serviço deverá ser disponibilizado na CONTRATANTE através de duas interfaces gigabit-ethernet 1000BASE-T, através conector 8P8C (também conhecido como RJ45), segundo os padrões IEEE 802.3.
9.26.1.5. O enlace de comunicação deverá ser simétrico, isto é, a largura de banda de rede efetivamente disponível para uso pela CONTRATANTE deve ser igual em ambas as direções.
9.26.1.6. A CONTRATADA será responsável por fornecer, instalar, e manter em
todo o meio físico e equipamentos necessários para o perfeito funcionamento dos serviços objeto deste edital.
9.26.1.7. Todos os equipamentos instalados pela CONTRATADA nas dependências da CONTRATANTE deverão:
9.26.1.7.1. Devem ser adequados para a instalação em rack padrão de datacenter, 19” com furação universal.
9.26.1.7.2. À CONTRATADA será disponibilizada duas linhas de alimentação independentes (possivelmente de fases diferentes) de 115V a 127V em corrente alternada para conexão de seus equipamentos.
9.26.1.8. O prazo para instalação, disponibilização do serviço e funcionamento por parte da CONTRATADA será de 60 dias.
9.26.1.9. O prazo de instalação deverá ser declarado na proposta técnica.
9.26.1.10. Em 5 (cinco) dias úteis após a assinatura do contrato, a empresa deverá agendar com a Gerencia de Telecomunicações reunião de início de implantação. Nesta reunião deverão ser apresentados:
9.26.1.11. Gerente de conta da CONTRATADA.
9.26.1.12. Responsável por parte da CONTRATANTE.
9.26.1.13. Breve descritivo da tecnologia a ser utilizada, observando as exigências do edital para os serviços de IP dedicado.
9.26.1.14. Número de telefone 0800 e site da Internet para abertura dos chamados técnicos.
9.26.1.15. Endereços de e-mail da CONTRATANTE para onde a CONTRATADA deverá encaminhar os relatórios e demais informes previstos.
9.26.1.16. A empresa deverá instalar os equipamentos nos locais indicados, conforme a necessidade, fazendo as devidas adequações físicas, atendendo ao endereço contratado.
9.26.1.17. Será utilizado como protocolo roteável o IP nas suas versões IPv4 e IPv6, e protocolo de comunicação TCP/IP, UDP/IP, SCTP/IP, bem como quaisquer outros protocolos baseados em IPv4 e IPv6.
9.26.1.18. Os equipamentos deverão ser disponibilizados configurados e as configurações deverão ser acompanhadas pelos técnicos do núcleo de suporte da PRODAM, sendo fornecido pela CONTRATADA um relatório final com a configuração.
9.26.1.19. A CONTRATADA deverá prover mecanismos de visualização on-line das configurações e de monitoração de tráfego dos roteadores (entrante e saínte) ou equipamentos de terminação da rede WAN instalados na rede proposta atendendo estas funções.
9.26.1.20. O serviço ofertado devera estar disponível, 24 horas por dia, 07 dias da semana, por ano (24x7x365) com taxa mensal de nível de serviço (SLA) de 99,5%.
9.26.1.21. Todas as janelas para manutenção programada deverão ser acordados
entre as partes com antecedência mínima de 7 dias , exceto em eventos extraordinários será acordado com prioridade entre a CONTRATADA e CONTRATANTE.
9.26.1.22. Todos os equipamentos deverão ser acomodados em racks de 19’’ (de fornecimento da CONTRATADA).
9.26.1.23. A CONTRATADA deverá prover meios para comprovação da banda máxima CONTRATADA.
9.26.1.24. O acesso deverá utilizar meio físico totalmente independente.
9.26.1.25. Ao receber uma ordem de serviço a CONTRATADA deverá executá-Ia e informar à PRODAM no prazo máximo de 12 horas a sua conclusão e efetivação
9.26.1.26. A cada visita técnica realizada, a CONTRATADA deverá emitir um relatório de execução das atividades, relacionando os serviços executados e a lista de equipamentos que eventualmente sejam instalados, substituídos ou retirados.
9.26.1.27. O ingresso de pessoas não pertencentes ao corpo técnico da CONTRATADA nas dependências da PRODAM deverá ser comunicado via e-mail ou fax, com antecedência.
9.26.1.28. Pessoas pertencentes ou não ao corpo técnico da CONTRATADA que ingressarem nas dependências da PRODAM para a realização de serviços de manutenção, configuração, instalação ou reuniões de acompanhamento, deverão portar crachá de identificação e se anunciarem previamente na Recepção.
9.26.1.29. As interrupções programadas para manutenção preventivas, deverão ser efetuadas nos fins de semana e feriados, entre 00:00 e 06:00 horas, devendo ser programadas e comunicadas com antecedência mínima de 02 dias úteis a PRODAM, para que a interrupção não incida na apuração da taxa de nível de serviço mensal.
9.26.1.30. Eventuais trocas ou substituição de equipamentos serão de responsabilidade da CONTRATADA, sem ônus para a PRODAM.
9.26.1.31. Todo equipamento da CONTRATADA deverá ser acompanhado de Nota Fiscal de Remessa tanto para ingresso como para retirada das dependências da PRODAM.
9.26.2. DAS CARACTERÍSTICAS TÉCNICAS GERAIS SOBRE O SERVIÇO
9.26.2.1. O serviço deve suportar a comunicação de dados IP versão 4 (IPv4) e IP versão 6 (IPv6), dedicado, com suporte a todas as aplicações IP (incluindo TCP/IP, UDP/IP, dentre outras), em conformidade com todos os padrões e recomendações relevantes da IETF (Internet Engineering Task Force).
9.26.2.2. O serviço deverá ser fornecido com largura de banda de rede mínima de 1Gbit/s (um bilhão de bits por segundo) em cada direção.
9.26.2.2.1. A largura de banda de rede deverá ser simétrica e independente entre as duas direções.
9.26.2.3. O serviço deverá transportar, em toda a rede da contratada, pacotes IPv4 e IPv6 com 1500 bytes sem exigir a fragmentação dos mesmos na camada IPv4 ou IPv6.
9.26.2.3.1. A este tamanho de 1500 bytes, deverão ser acrescidos o tamanho necessário para frame ethernet em modo IEEE 802.1Q (VLAN) e transmissão do mesmo, portanto o tamanho máximo de quadro imposto pelos equipamentos da contratada deverá ser maior que 1542 bytes.
9.26.2.3.2. Em hipótese alguma o serviço prestado pela contratada deverá impor restrições à contratante que impliquem na necessidade da mesma reduzir o MTU para menos de 1500 bytes, portanto o tamanho máximo de quadro real imposto pelos equipamentos da contratada deverá ser maior que 1542 bytes acrescido do espaço em bytes necessários para outros encapsulamentos que a mesma utilize em sua rede (por exemplo, MPLS, IEEE 802.1ad Q-in-Q).
9.26.2.4. O serviço deverá ser fornecido inicialmente com suporte a BGP4 full- routing ativado.
9.26.2.5. O serviço deve incluir a capacidade técnica de, mediante solicitação da CONTRATANTE, realizar a negação de tráfego de dados IPv4 e IPv6 não desejado, destinado a endereços IP e redes da CONTRATANTE, implementado através de “firewall” com o objetivo de evitar os danos causados por ataques DoS e DDoS (denial of service, e distributed denial of service).
9.26.2.5.1. O tráfego descartado não será tarifado pela CONTRATADA, e o descarte deverá ser efetuado de forma que o mesmo não prejudique a banda de rede disponível para a CONTRATANTE.
9.26.2.5.2. O filtro deverá possuir, no mínimo, a capacidade de classificação de tráfego de uma “ACL estendida”, ou seja, endereços fonte e destino, protocolo e portas.
9.26.2.5.3. É desejável que o filtro seja capaz de prevenir ataques específicos em nível de aplicação, para aplicações Web e VoIP.
9.26.2.5.4. É de responsabilidade da CONTRATADA apenas a negação de tráfego de dados na direção de “entrada” do ponto de vista da CONTRATANTE (ou seja, tráfego fluindo da CONTRATADA para a CONTRATANTE).
9.26.2.5.5. A CONTRATADA deverá ativar ou desativar o filtro mediante solicitação da CONTRATANTE, em período não superior a 2 horas da abertura de chamado, ou se for o caso, de requisição de colocação do filtro pela CONTRATANTE através de sistema da CONTRATADA específico para este fim.
9.26.2.6. A CONTRATADA deverá disponibilizar à CONTRATANTE também a possibilidade de “negação de tráfego” DESTINADO À CONTRATANTE
através de uso de uma community BGP de “blackhole/sinkhole” (buraco negro/vertedouro) em anúncio BGP da CONTRATANTE, ou através de conexão com servidor específico de rotas blackhole no backbone.
9.26.2.6.1. Prefixos BGP da CONTRATANTE que sejam anunciados com a community de “blackhole/sinkhole” (ou, se for este o caso, que sejam anunciados pela CONTRATANTE ao servidor de rotas de blackhole/sinkhole da CONTRATADA) deverão ter todo o tráfego a eles destinado, descartado pela CONTRATADA.
9.26.2.6.2. O tráfego descartado através de blackhole não será tarifado pela CONTRATADA, e o descarte deverá ser efetuado de forma que o mesmo não prejudique a banda de rede disponível para a CONTRATANTE.
9.26.2.6.3. Deverão ser aceitos para o efeito de “blackhole”, em IPv4: prefixos com tamanho /24 e /32, sendo desejado que também sejam aceitos prefixos com tamanhos entre /24 e /32 (por exemplo: /25, /28).
9.26.2.6.4. Deverão ser aceitos para o efeito de “blackhole”, em IPv6: prefixos com tamanhos entre /32 (inclusive) e /64 (inclusive), bem como prefixo com tamanho /128 (por exemplo: /32, /48, /56, /64, /128).
9.26.2.6.5. A contratada deverá permitir, para efeitos de engenharia de tráfego, que a contratante controle como a contratada irá anunciar os prefixos BGP enviados pela contratante, admitindo no mínimo as seguintes possibilidades:
9.26.2.6.5.1. O prefixo será anunciado pela contratada apenas para outros AS nacionais.
9.26.2.6.5.2. O prefixo será anunciado pela contratada apenas para outros AS internacionais.
9.26.2.6.5.3. O prefixo será anunciado pela contratada para outros AS, independente de nacionalidade (padrão).
9.26.2.6.5.4. O prefixo será anunciado pela contratada apenas para seus clientes.
9.26.2.6.5.5. Deve obrigatoriamente implementar e disponibilizar para a contratada as communities NO_EXPORT, NO_ADVERTISE, NO_EXPORT_SUBCONFED, definidas no RFC 1997.
9.26.2.6.5.6. Este controle deverá ser realizado através de communities BGP nos anúncios da contratante.
9.26.2.6.6. A contratada deverá permitir à contratante, através de community BGP específica ou de abertura de chamado técnico urgente, restringir o anúncio de determinados prefixos da contratante para peers ou provedores de trânsito específicos da contratada. Para diminuição dos custos operacionais de ambas as partes, é desejado que seja utilizado o mecanismo de communities BGP.
9.26.2.6.7. A contratada deverá prover facilidade de marcação de communities nas rotas que anunciar à contratante, para efeitos de engenharia de tráfego,
que evidencie:
9.26.2.6.7.1. Se a rota é de um cliente de trânsito da contratada. 9.26.2.6.7.2. Se a rota é internacional.
9.26.2.6.7.3. Se a rota é nacional.
9.26.2.6.8. Não será aceito, em hipótese alguma, que a contratada ou provedor de trânsito da mesma anuncie rotas que causem o direcionamento de tráfego com origem nacional destinado à contratada, ou com origem da contratada com destino nacional, para enlaces internacionais. Neste caso, a contratada deverá corrigir imediatamente a situação, e tempestivamente interagir com seus provedores de trânsito caso não seja a originadora do problema de roteamento. Recomenda-se que a contratada disponibilize à contratante mecanismo para supressão de anúncios seletivamente para cada provedor de trânsito da contratada através de communities BGP, pois assim atenderá automaticamente de forma imediata e tempestiva esta exigência, contanto que a supressão de anúncios seletiva funcione.
9.26.2.7. TOPOLOGIA LOGICA DO SERVIÇO
9.26.2.7.1. A CONTRATADA deverá entregar o serviço utilizando um ou dois roteadores BGP full-route, para dois roteadores da CONTRATANTE, através de no mínimo duas portas gigabit-ethernet (uma porta gigabit- ethernet para cada roteador da CONTRATANTE).
9.26.2.7.2. Cada um dos dois roteadores da CONTRATANTE possuirá uma sessão eBGP IPv4 e uma sessão eBGP IPv6 com cada um (máximo dois) dos roteadores da CONTRATADA.
9.26.2.7.3. Todos os roteadores devem estar diretamente conectados do ponto de vista da rede IPv4 e IPv6, não sendo admitido o uso de BGP multihop.
9.26.2.7.4. Os roteadores da CONTRATANTE operarão em modo VRRP, portanto, existirá um terceiro roteador: o "roteador virtual" da CONTRATANTE, que será utilizado apenas como NEXT_HOP para o tráfego.
9.26.2.7.5. As sessões eBGP serão mantidas entre os IPs fixos dos roteadores da CONTRATANTE. A CONTRATANTE anunciará como NEXT_HOP o IP do roteador virtual. No caso de falha do roteador ativo da CONTRATANTE, o(s) roteador(es) da CONTRATADA observarão a mudança de MAC do IP do roteador virtual, e a eventual queda de uma das sessões eBGP.
9.26.2.7.6. As faixas de IP "WAN" a serem fornecidas pela CONTRATADA deverão comportar no mínimo 6 roteadores, uma vez que serão necessários três endereços IP para a CONTRATANTE, e pelo menos um endereço IP para o roteador da CONTRATADA.
9.26.2.8. PROTEÇÃO CONTRA NEGAÇÃO DE SERVIÇO CAUSADA POR ROUTE-FLAP DAMPING
9.26.2.8.1. A CONTRATADA está devidamente informada que observará de forma
altamente amplificada quaisquer eventos BGP de prefixos originados pela CONTRATANTE, devido a existência de múltiplas sessões BGP entre a CONTRATANTE e a CONTRATADA bem como entre a CONTRATANTE e outros provedores de trânsito e peers, inclusive em PTTs. Esta amplificação pode causar a ativação indevida do mecanismo de proteção conhecido como "ROUTE-FLAP DAMPING", descrito pelo RFC2439, caso a CONTRATADA utilize este mecanismo em sua rede.
9.26.2.8.2. A CONTRATADA deve considerar os parâmetros recomendados pelo documento RIPE-580 publicado pela RIPE/NCC (xxxx://xxx.xxxx.xxx/xxxx/xxxx/xxxx-000/) para evitar prejudicar o serviço prestado a seus clientes por ativação indevida do mecanismo de route-flap damping.
9.26.2.8.3. O serviço prestado pela CONTRATADA será CONSIDERADO INDISPONÍVEL DURANTE TODO O PERÍODO DE TEMPO EM QUE ROTAS DA CONTRATANTE ESTIVEREM SOB EFEITO DE ROUTE
DAMPING NA REDE DA CONTRATADA, e será contabilizado desta forma para o aferimento de SLA/acordo de nível de serviço, faturamento, e possível aplicações de multas.
9.26.3. DISPONIBILIDADE e DESEMPENHO
9.26.3.1. A disponibilidade mensal do serviço deverá ser de no mínimo 99,5%
9.26.3.2. Os LINKs, hardware, software e serviços fornecidos pela CONTRATADA deverão estar disponíveis 24 horas por dia, 7 dias por semana, todos os dias do ano, inclusive feriados e datas comemorativas de qualquer espécie.
9.26.3.3. As interrupções programadas para manutenções preventivas ou por necessidades da CONTRATADA, deverão ser efetuadas aos domingos, segundas-feiras, ou dias úteis que seguem a feriados nacionais, entre 00:00 e 06:00 horas, desde que comunicadas a PRODAM-SP com antecedência de 5 (cinco) dias úteis.
9.27. DOS ACORDOS DE NÍVEL DE SERVIÇO
9.27.1. Os acordos de nível de serviço são os mesmos para os protocolos IPv4 e IPv6.
9.27.2. O serviço deverá ter disponibilidade de no mínimo 99,5% no mês, ou seja, poderá estar indisponível apenas 0,5% no mês.
9.27.2.1. O serviço será considerado indisponível enquanto houver a violação de quaisquer das exigências de níveis mínimos de serviço previstas neste edital.
9.27.2.2. Não será tarifado pela CONTRATADA, o serviço indisponível que exceder o limite de 0,5% no mês.
9.27.2.3. Não incorrerá a CONTRATADA em multas por indisponibilidade de serviço se a mesma não exceder o limite de indisponibilidade de 0,5% no mês.
9.27.2.4. Será utilizado o mês corrido do calendário oficial brasileiro.
9.27.3. Poderá a CONTRATADA requisitar à CONTRATANTE período justificado de indisponibilidade do serviço (“indisponibilidade programada”), que não será considerado para o cálculo de disponibilidade do serviço no mês.
9.27.3.1. O pedido de indisponibilidade programada deverá ser feito por escrito, através de correspondência protocolada à CONTRATANTE, com antecedência.
9.27.3.2. Deverá constar no pedido os motivos técnicos para a indisponibilidade do serviço, bem como informações precisas sobre a indisponibilidade.
9.27.3.3. Será permitido pela CONTRATANTE apenas um período de indisponibilidade programada a cada três meses.
9.27.3.4. A CONTRATANTE poderá recusar a indisponibilidade programada em determinada data, e neste caso a CONTRATADA deverá propor uma data diferente para a indisponibilidade programada.
9.27.4. Largura de Banda
9.27.4.1. Será considerada a largura de banda do enlace, a taxa efetiva de transmissão de dados, medida em bits por segundo (bit/s), e especificada em milhões de bits por segundo (Mbit/s).
9.27.4.2. A largura de banda CONTRATADA deverá estar disponível integralmente no enlace de comunicação, em ambas as direções (upload/download).
9.27.4.2.1. Para medição da largura de banda efetivamente disponível no enlace, será considerado o tráfego observado nas interfaces ethernet, o que inclui o frame ethernet.
9.27.4.2.2. 95% da largura de banda CONTRATADA deverá estar disponível, de forma agregada, na rede interna da CONTRATADA.
9.27.4.3. Para medição da largura de banda disponível na rede, será considerado apenas o tamanho do pacote IPv4 e/ou IPv6, não estando incluído nenhuma espécie de overhead, como por exemplo o causado por encapsulamentos ethernet, SDH, MPLS, etc.
9.27.5. Perda de pacotes
9.27.5.1. A perda de pacotes não poderá ser superior a:
9.27.5.1.1. 0,5% (meio por cento) no enlace entre a CONTRATANTE e CONTRATADA.
9.27.5.1.2. 1 % (um por cento) entre a CONTRATANTE, e quaisquer pontos da rede interna da CONTRATADA (este limite já inclui a perda no enlace entre a CONTRATANTE e CONTRATADA).
9.27.5.1.3. 1,5% (um e meio por cento) entre a CONTRATANTE, e o roteador imediatamente após enlaces de conexão internacional e com outros provedores (este limite já inclui a perda no enlace entre a CONTRATANTE e CONTRATADA, e a perda na rede interna da CONTRATADA).
9.27.5.2. A perda de pacotes será medida a fim-a-fim, incluindo o caminho de retorno do pacote ICMP/ICMPv6 (round-trip) utilizando pacotes pequenos.
9.27.5.3. Serão utilizadas janelas de 5 minutos para medir a perda de pacotes, com no mínimo 60 amostras por janela.
9.27.5.4. Não será considerado perda de pacotes, a causada por volume de tráfego que exceda a largura de banda de rede CONTRATADA, no enlace de comunicação de dados entre a CONTRATANTE e a CONTRATADA.
9.27.5.5. Não será considerado perda de pacotes, o pacote explicitamente descartado para evitar um ataque DoS ou DDoS.
9.27.6. Latência
9.27.6.1. As latências oferecidas pelo serviço não poderão exceder:
9.27.6.1.1. Nos enlaces de comunicação entre a CONTRATANTE e CONTRATADA: máximo 10ms, média 5ms.
9.27.6.1.2. Dentro da rede da CONTRATADA, e até as bordas nacionais da rede da CONTRADATA: máximo 25ms, média 15ms.
9.27.6.1.3. Até servidor DNS raiz global, DNS raiz brasileira (x.xxxx-xxxxxxx.xxx/x.xxxx- xxxxxxx.xxx/x.xxxx-xxxxxxx.xxx/x.xxxx-xxxxxxx.xxx, *.xxx.xx) e NTP (*.xxx.xx) do XXX.xx: máximo 50ms, média 25ms.
9.27.6.1.4. Para provedores nacionais com os quais a CONTRATADA possua conexão direta ou através de ponto de troca de tráfego, para a rede RNP e para a rede ANSP: máximo 100ms, média 50ms.
9.27.6.1.5. Para a PRODESP (AS 28637), máximo 100ms, média 50ms.
9.27.6.1.6. Até a extremidade remota (internacional) dos enlaces internacionais: máximo 300ms, média 200ms (Américas). máximo 350ms, média 250ms (Europa). máximo 400ms, média 350ms (Asia e Oceania).
9.27.6.1.7. As latências médias serão calculadas utilizando no mínimo 60 amostras por xxxxxx, e janelas de 5 minutos.
9.27.6.1.8. A latência máxima é aquela observada em qualquer uma das amostras.
9.27.6.1.9. Será assumida uma distribuição normal para a latência, em todos os casos.
9.27.6.1.10. As latências são medidas fim-a-fim, incluindo o caminho de retorno do pacote ICMP/ICMPv6 (round-trip), utilizando pacotes pequenos.
9.27.6.1.11. A CONTRATANTE irá utilizar, para efeitos de validação do cumprimento ou não dos acordos de nível de serviço para latência, apenas amostras realizadas em períodos onde o enlace de comunicação entre a CONTRATANTE e a CONTRATADA estiver com ocupação inferior a 90% em ambas as direções.
9.27.6.1.12. Não será considerada violação de acordo de nível de serviço para a latência, aquela que exceder os valores permitidos devido a problema específico e exclusivo em rede de parte terceira (por exemplo: problemas internos nas redes ANSP, RNP, ou XXX.xx), desde que devidamente comprovado e comunicado à CONTRATANTE (por exemplo, pela CONTRATADA).
9.27.6.1.13. Será passível de multa leve a violação dos níveis de acordo de serviço para latência, se a soma dos períodos de violação superarem 48h no mês. Neste caso, a multa será aplicada sobre todo o período de violação, agregado no mês.
9.27.7. Tempo máximo para atendimento
9.27.7.1. Em consideração à possibilidade de rompimento catastrófico de múltiplas rotas de fibras ópticas ou outro problema catastrófico no backbone, o nível de acordo de serviço para tempo de reparo é de 4 horas corridas.
9.27.7.2. Os períodos para atendimento e reparo serão contados a partir da abertura do chamado pela CONTRATANTE (que poderá, caso acordado com a CONTRATADA, ser imediatamente seguido por tentativa de contato da CONTRATANTE diretamente com a área técnica da CONTRATADA através de e-mail, fax, ou telefone), e encerrado quando da efetiva resolução do problema.
9.27.7.3. Só caracterizará o reparo efetuado com sucesso, a anuência da CONTRATANTE de que o problema foi satisfatoriamente sanado.
9.27.7.4. A violação do acordo de nível de serviço do tempo máximo de reparo incorrerá em multa grave.
9.27.8. PROTEÇÃO CONTRA NEGAÇÃO DE SERVIÇO CAUSADA POR ROUTE-FLAP DAMPING
9.27.8.1. A contratada está devidamente informada que observará de forma altamente amplificada quaisquer eventos BGP de prefixos originados pela contratante, devido a existência de múltiplas sessões BGP entre a contratante e a contratada bem como entre a contratante e outros provedores de trânsito e peers, inclusive em PTTs. Esta amplificação pode causar a ativação indevida do mecanismo de proteção conhecido como "ROUTE-FLAP DAMPING", descrito pelo RFC2439, caso a contratada utilize este mecanismo em sua rede.
9.27.8.2. A contratada deve considerar os parâmetros recomendados pelo documento RIPE-580 publicado pela RIPE/NCC (xxxx://xxx.xxxx.xxx/xxxx/xxxx/xxxx-000/) para evitar prejudicar o serviço prestado a seus clientes por ativação indevida do mecanismo de route-flap damping.
9.27.8.3. O serviço prestado pela contratada será CONSIDERADO INDISPONÍVEL DURANTE TODO O PERÍODO DE TEMPO EM QUE ROTAS DA CONTRATANTE ESTIVEREM SOB EFEITO DE ROUTE DAMPING NA REDE DA CONTRATADA, e será contabilizado desta forma para o aferimento de SLA/acordo de nível de serviço, faturamento, e possível aplicações de multas ou glosas.
9.27.9. NEUTRALIDADE DE REDE
9.27.9.1. A contatada só poderá filtrar tráfego originado ou destinado à contratante em caso de pedido explícito da contratante, ou com permissão por escrito da contratante.
9.27.9.2. A contratada não poderá aplicar, em nenhum ponto de sua rede, a tráfego originado ou destinado à contrate, políticas de descarte ou shaping (alteração de prioridade, latência ou probabilidade de descarte) que ofereça vantagem à contratada ou a terceiro em específico, sob pena de multa grave.
9.27.9.3. A contratada deverá excluir, se requisitado pela contratante através de chamado técnico, os prefixos originados pela contratante do serviço de quaisquer caches ou CDNs (por exemplo: Google cache, etc) que possua em sua rede em até 48 horas úteis sob pena de multa grave. A requisição da contratante poderá ser global (todos os caches), ou específica (apenas cache de uma empresa/serviço específico).
9.27.10. MUDANÇA DE LOCALIZAÇÃO DA INSTALAÇÃO
9.27.10.1. A CONTRATANTE poderá solicitar a CONTRATADA mudança na localização da instalação do link durante o período de execução do contrato mediante aviso prévio de no mínimo 90 dias de antecedência.
9.27.10.2. As CONTRATADAS terão prazo máximo de 30 dias para efetivar a mudança na localização da instalação.
9.27.10.3. As CONTRATADAS deverão arcar com os custos desta mudança.
9.27.11. CONDIÇÕES GERAIS DE CONTRATAÇÃO
9.27.11.1. A contratada deverá comunicar imediatamente à contratante toda e qualquer anormalidade verificada ou acontecimento irregular que atente contra a integridade do patrimônio, de funcionários e visitantes desta.
9.27.11.2. A contratada deverá adotar as medidas de segurança orientadas pela contratante enquanto realizando trabalhos nas dependências desta.
9.27.11.3. A contratada será responsável por todos os atos de seus funcionários e de terceiros por ela contratada, a serviço nas instalações da contratante, respondendo, inclusive, pelo ressarcimento de prejuízos que estes comprovadamente vierem a causar, tanto à contratante, quanto a terceiros que estiverem frequentando suas dependências.
9.27.11.4. As exigências técnicas presentes neste edital são exigências mínimas de qualidade e capacidade, e serão aceitos como equivalentes, serviços ou equipamentos que excedam estas exigências para melhor segundo o entendimento da contratante.
9.27.12. DAS MULTAS
9.27.12.1. O valor cumulativo das multas aplicadas em um mesmo mês, será limitado a 10% do valor mensal do serviço.
9.27.12.1.1. Deverá ser utilizado para cálculo do limite de 10%, o valor mensal do serviço antes de qualquer redução por multas ou indisponibilidade.
9.27.12.2. Multa leve: equivale a 5% do valor mensal do serviço.
9.27.12.3. Multa grave: equivale a 10% do valor mensal do serviço.
9.27.12.4. Períodos em que o serviço esteve indisponível não serão tarifados pela contratada, e não são, portanto, considerados parte de nenhuma multa, e não contam para o limite de 10%.
9.27.12.5. Todas as multas serão encaminhadas à parte para o fornecedor, e os descontos devido a períodos de indisponibilidade do serviço serão descontados em conta futura.
ANEXO II
LOTE 3
10. Roteadores
10.1. Todos os itens deverão ser ofertados obrigatoriamente.
10.2. DA GARANTIA E MANUTENÇÃO DO ROTEADOR
10.2.1. Os equipamentos deverão ser fornecidos com garantia do fabricante e com contrato de manutenção, para que sejam atendidas todas as disposições desta seção.
10.2.2. O custo de garantia, extensões de garantia e/ou contratos de manutenção que forem necessários para atender as exigências deste edital, deverão ser incorporados ao custo do item do edital referente ao equipamento à qual a garantia se aplica.
10.2.3. Garantia válida no Brasil.
10.2.4. Garantia e manutenção modalidade on-site, limitado à região metropolitana de São Paulo, Brasil.
10.2.5. Durante a vigência da garantia e/ou do contrato de manutenção, o reparo e/ou substituição do equipamento defeituoso e de peças, não incorrerá em nenhum custo extra para a CONTRATANTE, inclusive custos de transporte de equipamentos, módulos e peças.
10.2.6. Vigência por no mínimo 5 anos para todos os equipamentos, módulos, acessórios e software.
10.2.7. Deve incluir todas as atualizações de versão de software, bem como do firmware e sistema operacional dos equipamentos, inclusive atualizações para novas versões com ampliação de funcionalidade, sem nenhum tipo de ônus para a CONTRATANTE.
10.2.8. Inclui serviços de suporte técnico, descritos em outra seção deste edital.
10.2.9. A garantia deve ser fornecida em solidariedade com o fabricante dos equipamentos e/ou software.
10.2.10. Os prazos de vigência da garantia e de contratos de manutenção iniciam apenas na efetiva data de recebimento do equipamento pela CONTRATANTE.
10.2.11. Módulos SFP 1000BASE-T devem possuir trava robusta, particularmente se a mesma for uma trava móvel. A quebra desta trava durante o uso normal do módulo caracterizará defeito de projeto ou de fabricação do módulo, e o módulo deverá ser substituído por um módulo novo e em perfeito estado de funcionamento, sem ônus para a CONTRATANTE.
10.2.12. Níveis de acordo de serviço para manutenção e reparos (inclusive em garantia):
10.2.12.1. Para todos os modelos de roteador e cartões de interface: 10.2.12.1.1. Primeiro atendimento em no máximo 1h.
10.2.12.1.2. Reparo em no máximo 4h.
10.2.12.1.3. Reparo definitivo em no máximo 20 dias úteis.
10.2.12.1.4. Serviço disponível em regime 24/7/365 (inclusive feriados nacionais e fins de semana).
10.2.12.2. Para módulos SFP, SFP+ ou XFP:
10.2.12.2.1. Primeiro atendimento em no máximo 24h. 10.2.12.2.2. Reparo definitivo em no máximo 20 dias úteis.
10.2.12.2.3. Serviço disponível em horário comercial estendido (07:00 - 22:00, dias úteis de segunda a sábado).
10.2.13. Será aceito o reparo através da substituição temporária do componente, equipamento ou módulo com defeito por outro de propriedade da CONTRATADA em bom estado e perfeitamente funcional, que será devolvido pela CONTRATANTE em no máximo 5 dias úteis após o reparo definitivo.
10.2.13.1. Será considerada a data de postagem como data de devolução.
10.2.13.2. Em casos de motivos de força maior (por exemplo: greve das transportadoras ou dos Correios) o prazo para devolução será estendido para 5 dias úteis após o fim do impedimento de força maior.
10.2.13.3. Todas as despesas de envio por conta da CONTRATADA.
10.2.14. Será aceito o reparo definitivo:
10.2.14.1. Através da substituição definitiva do componente, equipamento ou módulo por um outro novo de mesmo modelo, sem uso prévio, em perfeitas condições de funcionamento, dentro dos prazos estabelecidos por este termo.
10.2.14.2. Através do reparo em fábrica ou por assistência técnica autorizada pela fábrica do componente, equipamento ou módulo, que retorne o mesmo à CONTRATANTE em perfeitas condições de funcionamento dentro dos prazos estabelecidos por este termo.
10.2.15. O reparo definitivo deverá restaurar inclusive as condições estéticas/cosméticas (aparência externa) do componente, equipamento ou módulo.
10.3. DO ESTADO DOS EQUIPAMENTOS
10.3.1. Todos os equipamentos devem ser novos, sem uso prévio e em perfeito estado de funcionamento. Não devem ser remanufaturados, recondicionados, ou possuir reparos de quaisquer espécie.
10.3.2. Todos os equipamentos devem ser de fabricação recente (máximo 6 meses).
10.3.3. Todos os equipamentos devem ser acompanhados de todos os manuais e acessórios normalmente fornecidos pelo fabricante com aquele modelo de equipamento.
10.3.4. Equipamentos, módulos, componentes, ou qualquer outra parte do OBJETO do presente edital que a CONTRATANTE constate terem sido entregues já com defeito ou danificados devem ser trocados por um outro equipamento, componente ou item novo, de mesma marca e modelo, com número de série diferente, em no máximo 15 dias úteis.
10.3.5. Equipamentos que a CONTRATANTE constate terem sido entregues com outras irregularidades (como por exemplo, falta de manuais, software ou firmware incorreto, configuração de hardware incorreta, equipamento incorreto), devem ter as mesmas sanadas em no máximo 5 dias úteis.
10.3.6. Todos os equipamentos devem ser fornecidos completos do ponto de vista da funcionalidade em rede, e incluir todos os adicionais necessários (de quaisquer espécie: licenças de software, cabos, manuais, etc).
10.3.7. Todos os roteadores devem ser entregues com o firmware estável mais novo disponibilizado pelo fabricante (quando da efetiva entrega do equipamento à CONTRATANTE) para detentores de contrato de manutenção (mesmo que tal versão seja mais recente que a normalmente enviada com os roteadores), ou tal firmware deve ser legalmente disponibilizado para a instalação pela CONTRATANTE, sem qualquer ônus para a CONTRATANTE, e independente da existência de contrato de manutenção.
10.4. DO CRITÉRIO DE HOMOGENEIDADE DE PARQUE E GERÊNCIA
10.4.1. Todos os roteadores, cartões de interface e módulos ofertados devem ter o mesmo fabricante, de forma a garantir a perfeita interoperabilidade dos recursos avançados das mesmas e redução do custo de manutenção, operação e gerenciamento do parque.
10.4.1.1. Módulos SFP, SFP+, ou XFP podem ter fabricantes diferentes, desde que tenham sido homologados pelo fabricante do roteador para serem utilizados naquele equipamento.
10.4.1.2. A documentação de comprovação da homologação do módulo SFP, SFP+, ou XFP pelo fabricante do roteador (por exemplo: carta do fabricante, página web do fabricante, ou documentação/manuais do equipamento) deverá ser fornecida em até 5 dias úteis se requisitada pela CONTRATANTE.
10.4.2. Caso os equipamentos com portas 10GbE utilizem tipos diferente de módulos 10GbE (XFP e SFP+), a CONTRATANTE indicará o tipo de módulo a ser fornecido na ordem de compra.
10.4.3. Todos os módulos 10GbE ofertados devem ser de tipo compatível com os equipamentos ofertados.
10.4.4. Para cada item do OBJETO onde é pedida mais de uma unidade, todas as unidades devem ser de mesmo fabricante e modelo, exceto módulos SFP, SFP+, ou XFP.
10.5. DA PROTEÇÃO DO INVESTIMENTO
10.5.1. Os equipamentos ofertados não podem estar em condição de fim-de-vida (end-of- life), nem poderão entrar em condição de fim-de-vida (end-of-life) no período de 5 anos a contar da data de primeira publicação deste edital.
10.5.2. Módulos (inclusive SFP, SFP+ e XFP), e placas modulares poderão ser substituídas por outro modelo em condição evolutiva (funcionalidades equivalentes ou superiores) desde que completamente compatíveis com o equipamento onde serão instaladas.
10.6. DO TREINAMENTO E SUPORTE TÉCNICO
10.6.1. A instalação e configuração inicial assistida de todos os itens é parte integrante do fornecimento e deve estar incluída no seu preço.
10.6.2. A primeira instalação e configuração inicial assistida de roteador núcleo IP deverá ser feita presencialmente, por técnico do fabricante, revenda ou terceiro, desde que devidamente qualificado pelo fabricante.
10.6.3. Deve cobrir a correta desembalagem, montagem e instalação dos equipamentos, procedimentos de ativação inicial e atualização de firmware, carga de configuração básica, conexão ao sistema de gerência e configuração, e uso básico do sistema de gerencia e configuração.
10.6.4. Deve também cobrir os procedimentos básicos de manutenção (remoção e troca de módulos, limpeza, etc).
10.6.5. Após a primeira instalação e customização inicial assistida presencial, a assistência a futuras instalações e customizações poderão ser feitas remotamente através de telefone e/ou sistemas de telepresença, sem a necessidade da presença local de técnico do fabricante, revenda ou terceiro, a critério da CONTRATADA.
10.6.6. Deverá ser fornecido o serviço de suporte técnico por telefone e e-mail por todo o período de garantia e manutenção do equipamento, ou por 5 anos, o que for maior.
10.6.6.1. Sem ônus de qualquer espécie para a CONTRATANTE.
10.6.6.2. Fornecido pelo fabricante ou por agente autorizado deste.
10.6.6.3. Deve incluir suporte nível 1, 2 e 3, inclusive escalando para as equipes de engenharia do fabricante caso necessário.
10.6.6.4. O serviço de suporte técnico deve ser fornecido em português em todos os casos (inclusive 2º e 3º nível de suporte), sendo aceito também o inglês no caso específico de comunicação com equipes de engenharia do fabricante.
10.6.6.5. Deve incluir suporte à operação e configuração do equipamento, e trouble- shooting de problemas de configuração, firmware e hardware.
10.6.6.6. Deve estar disponível em regime 24/7/365 (inclusive feriados nacionais e fins de semana).
10.6.6.7. Deve incluir ponto de contato efetivo para escalar problemas, acessível através de email direta, telefone fixo e celular direto, independentes do call-center de suporte.
10.6.6.8. Os engenheiros da CONTRATANTE devem poder escalar um chamado aberto diretamente para o nível 2 ou nível 3 sem empecilhos, caso haja dificuldade de comunicação com o nível 1. Este escalamento preferencialmente deve acontecer mediante simples solicitação do fato ao nível 1, ou se necessário, através do canal de escalamento.
10.7. DAS VELOCIDADES DE COMUTAÇÃO E ENCAMINHAMENTO (THROUGHPUT)
10.7.1. Neste edital, os termos envolvendo capacidade de encaminhamento, velocidades de portas ou de canais, também conhecidas como "throughput", referem-se a capacidade de encaminhamento e comutação de pacotes unidirecional, ou seja, 1Gbps significa 1 gigabit por segundo em uma única direção.
10.7.2. O equipamento deve sempre implementar encaminhamento bidirecional com a mesma capacidade em ambas as direções simultaneamente, portanto quando o edital referencia uma porta com capacidade de 1Gbps, o equipamento deve ser capaz de encaminhar simultaneamente 1Gbps de tráfego em cada uma das duas direções (entrante e sainte) nesta porta.
10.7.2.1. Exemplo: um módulo com conexão de 40Gbps com a matriz de comutação deve ser capaz de enviar 40Gbps para a matriz de comutação e receber 40Gbps da matriz de comutação simultaneamente.
10.7.3. Matrizes de comutação e routing engines serão especificadas pela sua capacidade somadas as duas direções do tráfego (entrante e sainte).
10.7.3.1. Exemplo: um equipamento wire-speed com 24 portas 1GbE e 2 portas 10GbE precisa de uma matriz de comutação e routing engine com no mínimo 88 Gbps.
10.8. DO SUPORTE AO PROTOCOLO IPv6
10.8.1. Os fabricantes e representantes dos mesmos devem atentar para a existência do documento RIPE-554, "Requisitos de suporte a IPv6 para equipamentos de TIC", xxxx://xxx0.xx/xxxxxxxx/xxxxxxxxxx-xxxxxxx-xxx0-xxxx-000-xx.xxx.
10.8.2. Todos os equipamentos ofertados devem suportar e implementar o protocolo IPv6, com equivalência de recursos com o protocolo IPv4 para todas as funções de “host” (por exemplo: gerência, sessões SSH, SNMP).
10.8.3. Funções de host não estão ligadas a roteamento, e sim à existência de endereços IPv6 e pilha IPv6 no equipamento para acessar as funções de gerência do próprio equipamento.
10.8.3.1. Implementar RFC 2460 IPv6 Specification.
10.8.3.2. Implementar RFC 2461 IPv6 Neighbor Discovery.
10.8.3.3. Implementar RFC 2462 IPv6 Stateless Address Auto-Configuration.
10.8.3.4. Implementar RFC 6724 Default Address Selection for Internet Protocol Version 6 (IPv6), ou alternativamente a versão mais antiga, RFC 3484.
10.8.3.5. Implementar RFC 4443 ICMPv6.
10.8.3.6. Implementar RFC 4193 Unique Local IPv6 Unicast Addresses (ULA).
10.8.3.7. Implementar RFC 4291 IPv6 Addressing Architecture.
10.8.3.8. Implementar RFC 3587 IPv6 Global Unicast Address Format.
10.8.3.9. Implementar RFC 2464 Transmission of IPv6 over Ethernet Networks.
10.8.3.10. Implementar RFC1981 Path MTU Discovery for IPv6.
10.8.3.11. Implementar RFC 4861 Neighbor Discovery for IPv6, preferencialmente segundo RFC 5942 IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes.
10.8.3.12. Implementar RFC 4862 IPv6 SLAAC.
10.8.3.13. Implementar RFC 4213 Transition Mechanisms for IPv6 Hosts and Routers - Dual IP Layer.
10.8.3.14. Implementar em IPv6: RFC4301, RFC4303, RFC4302, RFC5996 (IPSEC e IKEv2 em IPv6).
10.8.3.15. Implementar RFC 5095 Deprecation of Type 0 Routing Headers in IPv6, note que essa exigência não implica na existência de funcionalidade L3 no equipamento.
10.8.3.16. Implementar RFC 6980 Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery
10.8.4. Os equipamentos devem ser gerenciáveis em IPv6, inclusive SNMP e MIBs.
10.8.4.1. A capacidade de comutação e encaminhamento de pacotes IPv6 deverá ser idêntica a capacidade de comutação e encaminhamento de pacotes IPv4.
10.8.4.2. As exigências de capacidade de comutação e encaminhamento mínimo de pacotes definidas por este termo devem ser atendidas em qualquer combinação de tráfego IPv4, IPv6 e MPLS.
10.8.4.3. Todos os equipamentos deverão:
10.8.4.3.1. Implementar IPv6 em filtros/ACLs, inclusive para classificação de fluxos e QoS, em nível equivalente à funcionalidade IPv4.
10.8.4.3.2. Implementar RFC 4541 MLDv2 snooping.
10.8.4.4. Todos os equipamentos L3 deverão:
10.8.4.4.1. Possuir capacidade de encaminhamento, comutação e roteamento de pacotes IPv6 idêntica a capacidade de encaminhamento, comutação e roteamento de pacotes IPv4.
10.8.4.4.2. Possuir capacidade máxima de rotas IPv6 em hardware (FIB) que seja, no mínimo, a metade da capacidade máxima de rotas IPv4 em hardware (FIB), tanto para unicast como para multicast.
10.8.4.4.3. Possuir capacidade máxima de rotas IPv6 em memória (RIBs, etc) que seja, no mínimo, a metade da capacidade máxima de rotas IPv4 em memória.
10.8.4.4.4. Implementar amostragem de fluxos IPv6 via IPFIX/NetFlow/sFlow em nível de funcionalidade equivalente à implementada para IPv4.
10.8.4.4.5. Implementar RFC 2711 IPv6 Router Alert Option.
10.8.4.4.6. Implementar RFC 6398 IP Router Alert Considerations and Usage, provendo mecanismos de proteção do plano de controle contra flood de xxxxxxx XXX.
10.8.4.4.7. Implementar RFC 3810 MLDv2.
10.8.4.4.8. Implementar RFC 3056 Connection of IPv6 Domains via IPv4 Clouds (6to4).
10.8.4.4.9. Implementar RFC 5969 IPv6 Rapid Deployment on IPv4 Infrastructures (6rd).
10.8.4.4.10. Implementar RFC 4798 Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE).
10.8.4.4.11. Implementar Mobile IPv6 (MIPv6): RFC 6275, RFC 5555, RFC 4877.
10.8.4.4.12. Implementar DHCPv6 relay: RFC 3315.
10.9. DAS ESPECIFICAÇÕES GERAIS COMUNS AOS EQUIPAMENTOS
10.9.1. Todos os equipamentos devem implementar as funcionalidades contidas nesta seção.
10.9.2. Portas 1000BASE-T devem implementar os padrões gigabit ethernet, fast ethernet e ethernet, com auto detecção de velocidade (10/100/1000), modo duplex, e pause- frames.
10.9.3. Serão aceitas portas “combo” em lugar de portas fixas ou de portas modulares simples, desde que sejam do tipo exigido (FE ou 1GbE).
10.9.4. Serão aceitas portas 1000BASE-T em substituição a portas 100BASE-TX, desde que suportem auto negociação e velocidades 10/100/1000.
10.9.5. Portas 1000BASE-T fixas podem ser substituídas por porta SFP com SFP 1000BASE-T instalado e incluso no preço do equipamento, desde que o SFP e a porta suportem a auto detecção, e os padrões ethernet (10Mbps), fast-ethernet (100Mbps) e gigabit ethernet (1000Mbps).
10.9.6. Todas as portas 1GbE e 10GbE modulares devem utilizar módulos SFP, SFP+ ou XFP apropriados à velocidade da porta, e devem suportar monitoramento do estado do módulo (digital diagnostics).
10.9.7. As portas 1GbE e 10GbE modulares devem suportar todos os tipos de módulos SFP 1GbE e 10GbE (SFP+ ou XFP) constantes como item do objeto.
10.9.8. Módulos ópticos (SFP, SFP+ ou XFP) devem permitir o monitoramento da potência de transmissão e do nível de sinal recebido.
10.9.9. Não serão admitidas portas ópticas fixas, todas as portas ópticas devem ser modulares (receber módulos ópticos), sendo admitidas portas do tipo combo (uma porta modular agrupada a uma porta fixa elétrica).
10.9.10. Todas as portas 10GbE devem ser modulares.
10.10. DAS ESPECIFICAÇÕES PARA TODOS OS ROTEADORES
10.10.1. Estas especificações se aplicam inclusive para todos os cartões de interface em roteadores modulares, quando a funcionalidade a que se referem for implementada inteiramente ou com participação do cartão de interface.
10.10.2. Os roteadores deverão ter tamanho máximo de 2,5U (dois e meio “U”), preferencialmente 1U ou 2U, já inclusos todos os módulos e fontes.
10.10.3. SEPARAÇÃO DO PLANO DE DADOS E PLANO DE CONTROLE
10.10.3.1. Possuir plano de controle separado do plano de encaminhamento/plano de dados.
10.10.3.2. Possuir plano de encaminhamento/dados implementado em hardware.
10.10.3.3. Implementar para pacotes ethernet, IPv4, IPv6, e MPLS do plano de dados as funções de: manipulação, encaminhamento, filtragem, condicionamento (inclusive QoS) e contagem em hardware.
10.10.3.4. Implementar as funções de amostragem de fluxos (netflow, sFlow, IPFIX ou similar) em hardware.
10.10.3.5. Implementar em hardware as funções de proteção do plano de controle e gerência contra ataques provenientes do plano de dados.
10.10.3.6. Será considerada a implementação de hardware: a implementação através de ASICs e FPGAs especializados, e/ou através de NPUs (network processing units) baseadas em NPs (network processors).
10.10.4. MEMÓRIA E TCAM
10.10.4.1. Todos os módulos e equipamentos devem ser fornecidos com no mínimo 16GiB de RAM instalada.
10.10.4.2. Todos os equipamentos devem possuir FIB com capacidade para no mínimo 1 milhão de rotas IPv4, no mínimo 512.000 (quinhentas e doze mil) rotas IPv6, e no mínimo 10.000 (dez mil) labels MPLS.
10.10.4.3. Todos os equipamentos devem possuir RIB para no mínimo 2 milhões de rotas IPv4, e no mínimo 1 milhão de rotas IPv6.
10.10.5. OTIMIZAÇÃO
10.10.5.1. Os equipamentos devem ser otimizados para "service edge", e possuir facilidades de QoS avançadas e controle de assinantes.
10.10.6. ROTEAMENTO VIRTUALIZADO
10.10.6.1. Implementar a funcionalidade de roteamento e encaminhamento de pacotes virtualizado (VRF), efetivamente permitindo o particionamento do roteador em diversos conjuntos de (planos de dados + plano de controle) completamente isolados entre si.
10.10.6.2. Implementar a função de VRF para tráfego e plano de controle IPv4, IPv6 e MPLS.
10.10.6.3. Implementar conexões lógicas entre diferentes instâncias VRF, que permitam o encaminhamento de tráfego de uma instância VRF para a outra, interno à caixa, sem a utilização das portas de serviço (dados).
10.10.6.3.1. Estas conexões lógicas devem ter performance equivalente ou superior a interfaces 10GbE, e não devem impactar no uso de CPU do equipamento.
10.10.6.4. Implementar roteamento inter-VRF (possivelmente através de conexões lógicas).
10.10.6.5. Permitir que VLANs diferentes de uma mesma interface física pertençam a instâncias de VRF diferentes.
10.10.7. ROTEAMENTO BGP4
10.10.7.1. Implementar RFC 4271 BGPv4.
10.10.7.2. Implementar RFC 1997 Communities and Attributes.
10.10.7.3. Implementar RFC 2439 Route Flap Dampening.
10.10.7.4. Implementar RFC 2796 Route Reflection.
10.10.7.5. Implementar RFC 1965 BGP4 Confederations.
10.10.7.6. Implementar RFC 2842 Capability Advertisement.
10.10.7.7. Implementar RFC 1997 BGP Communities Attribute.
10.10.7.8. Implementar RFC 4360 BGP Extended Communities Attribute.
10.10.7.9. Implementar RFC 2918 Route Refresh Capability.
10.10.7.10. Implementar RFC 2385 BGP Session Protection via TCP MD5. 10.10.7.11. Implementar RFC 4893 BGP Support for Four-octet AS Number Space. 10.10.7.12. Implementar Outbound Route Filtering Capability for BGP-4.
10.10.7.13. Implementar RFC 5396 Textual Representation of Autonomous System (AS) Numbers - formato asplain.
10.10.7.14. Implementar RFC 2858 MP-BGP – Multiprotocol Extensions for BGP-4. 10.10.7.15. Implementar RFC 3107 Carrying Label Information in BGP-4.
10.10.7.16. Implementar pelo menos 1000 peers BGP.
10.10.7.17. Implementar a contabilização de tráfego via BGP para o tráfego entrante.
10.10.7.18. Implementar a contabilização de tráfego via BGP para o tráfego sainte. 10.10.7.19. Implementar eBGP multipath com pelo menos 8 caminhos.
10.10.7.20. Implementar iBGP multipath com pelo menos 8 caminhos. 10.10.7.21. Implementar NSR (Non-stop Routing) ou equivalente para BGP. 10.10.7.22. Implementar RFC 4724 Graceful Restart Mechanism for BGP.
10.10.7.23. Implementar definição de políticas de controle dos anúncios BGP.
10.10.7.24. Implementar aplicação de expressões regulares para filtragem de anúncios.
10.10.7.25. Implementar RFC 1657/RFC 4273 BGP4-MIB.
10.10.7.26. Implementar BFD para BGP4 em IPv4 e IPv6.
10.10.8. ROTEAMENTO OSPF
10.10.8.1. Implementar RFC 2328 OSPF Version 2.
10.10.8.2. Implementar RFC 3101 OSPF NSSA.
10.10.8.3. Implementar RFC 2370 OSPF Opaque LSA Option.
10.10.8.4. Implementar RFC 3137 OSPF Stub Router Advertisement.
10.10.8.5. Implementar RFC 3630 TE Extensions to OSPF v2.
10.10.8.6. Implementar NSR para OSPFv2.
10.10.8.7. Implementar RFC 3623 Graceful OSPF Restart.
10.10.8.8. Implementar pelo menos 30 áreas OSPFv2.
10.10.8.9. Implementar pelo menos 200 adjacências OSPFv2.
10.10.8.10. Implementar autenticação OSPFv2 via "simple-password" e "MD5". 10.10.8.11. Implementar RFC 2740 OSPF for IPv6 (OSPFv3).
10.10.8.12. Implementar NSR (non-stop routing) ou equivalente para OSPFv3. 10.10.8.13. Implementar Graceful-restart ou equivalente para OSPFv3.
10.10.8.14. Implementar pelo menos 30 áreas OSPFv3. 10.10.8.15. Implementar pelo menos 200 adjacências OSPFv3. 10.10.8.16. Implementar autenticação MD5 de sessões OSPFv3. 10.10.8.17. Implementar BFD para OSPF em IPv4 e IPv6.
10.10.9. ROTEAMENTO RIP
10.10.9.1. Implementar RFC 1058 RIP v1.
10.10.9.2. Implementar RFC 2453 RIP v2.
10.10.9.3. Implementar RIPng.
10.10.10. SUPORTE E ROTEAMENTO MULTICAST
10.10.10.1. Implementar Multicast IPv4.
10.10.10.2. Implementar pelo menos 4.000 rotas multicast.
10.10.10.3. Implementar RFC 4601 Protocol Independent Multicast - Sparse Mode (PIM-SM).
10.10.10.4. Implementar RFC 3569 An Overview of Source-Specific Multicast (SSM).
10.10.10.5. Implementar RFC 1112 IGMP.
10.10.10.6. Implementar RFC 2236 IGMP v2.
10.10.10.7. Implementar RFC 3376 IGMP v3. 10.10.10.8. Implementar Multicast IPv6.
10.10.10.9. Implementar PIM SM para IPv6 - RFC 4601. 10.10.10.10. Implementar PIM SSM para IPv6 - RFC 3569.
10.10.10.11. Implementar RFC 2710 Multicast Listener Discovery (MLD) for IPv6.
10.10.10.12. Implementar RFC 3810 Multicast Listener Discovery Version 2 (MLDv2) for IPv6.
10.10.10.13. Implementar RFC 2545 Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing.
10.10.10.14. Implementar IP Multicast in a Multi-Protocol Label Switching (MPLS) Environment.
10.10.11. ROTEAMENTO IPv4/IPv6 GERAL
10.10.11.1. Implementar rotas estáticas IPv4 e IPv6.
10.10.11.2. Implementar redistribuição de rotas entre diferentes protocolos. 10.10.11.3. Implementar a geração de logs dos protocolos.
10.10.11.4. Implementar RFC3768 - Virtual Router Redundancy Protocol (VRRP). 10.10.11.5. Implementar pelo menos 30 sessões VRRP.
10.10.11.6. Implementar Policy Based Routing (PBR) em hardware. 10.10.11.7. Implementar source-based routing em hardware.
10.10.11.8. Permitir implementação de RTBH e S/RTBH (real-time blackhole e source-based real-time blackhole), com a operação do filtro blackhole em hardware.
10.10.11.9. Implementar RFC 3021 - Using 31-Bit Prefixes on IPv4 Point-to-Point Links.
10.10.11.10. Implementar equal-cost-multipath (ECMP).
10.10.12. TRANSIÇÃO IPV4/IPV6
10.10.12.1. Implementar RFC 6146 Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers
10.10.12.2. Implementar RFC 6145 IP/ICMP Translation Algorithm
10.10.12.2.1. Implementar RFC 6791 Stateless Source Address Mapping for ICMPv6 Packets
10.10.12.2.2. Implementar RFC 5837 Extending ICMP for Interface and Next-Hop Identification
10.10.12.2.3. Implementar RFC 4884 Extended ICMP to Support Multi-Part Messages
10.10.12.3. Compatível com o uso de solução de DNS64 (RFC 6147) externa
10.10.12.4. Implementar RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators 10.10.12.4.1. Implementar RFC 3056 Connection of IPv6 Domains via IPv4 Clouds
(6to4).
10.10.12.4.2. Implementar RFC 5969 IPv6 Rapid Deployment on IPv4 Infrastructures (6rd).
10.10.12.4.3. Implementar RFC 4798 Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE).
10.10.13. MPLS GERAL
10.10.13.1. Implementar RFC 3031 MPLS Architecture. 10.10.13.2. Implementar RFC 3032 MPLS Label Stack Encoding. 10.10.13.3. Implementar RFC 5036 LDP Specification.
10.10.13.4. Implementar RFC 3270 MPLS Support of Differentiated Services. 10.10.13.5. Implementar pelo menos 100 sessões LDP.
10.10.13.6. Implementar autenticação MD5 para sessões LDP (RFC 5036). 10.10.13.7. Implementar RFC 5036 LDP targeted sessions (target hello).
10.10.13.8. Implementar pelo menos 5000 LDP targeted sessions. 10.10.13.9. Implementar proteção de sessões LDP.
10.10.13.10. Implementar sincronização de estado entre LDP e OSPFv2. 10.10.13.11. Implementar NSR (non-stop routing) para LDP.
10.10.13.12. Implementar RFC 3478 - Graceful Restart Mechanism for Label Distribution Protocol.
10.10.13.13. Implementar MPLS OAM: LSP Ping e LSP Traceroute.
10.10.14. MPLS VPN
10.10.14.1. Implementar RFC 2547/4364 BGP/MPLS IP VPNs.
10.10.14.2. Implementar RFC 4577 OSPF as the PE/CE Protocol in BGP/MPLS IP VPNs.
10.10.14.3. Implementar Multi-VRF/VRF-lite para MPLS. 10.10.14.4. Implementar pelo menos 1000 VRFs (MPLS/VPN). 10.10.14.5. Implementar VRF-Lite.
10.10.14.6. Implementar definição de máximo de prefixos por neighbour/vizinho. 10.10.14.7. Implementar eBGP como protocolo PE-CE.
10.10.14.8. Implementar BGP Site-of-Origin (RFC 4364). 10.10.14.9. Implementar iBGP como protocolo PE-CE.
10.10.14.10. Implementar coleta informações de fluxos por MPLS/VPN. 10.10.14.11. Implementar L2VPN - VPWS - Virtual Private Wire Service (RFC 4664).
10.10.14.12. Implementar pseudowires L2VPN - RFC 4447- Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP).
10.10.14.13. Implementar pelo menos 4000 pseudowires. 10.10.14.14. Implementar redundância de pseudowire.
10.10.14.15. Implementar associação de pseudowire com túnel de engenharia de tráfego.
10.10.14.16. Implementar L2VPN - VPLS - Virtual Private LAN Service.
10.10.14.17. Implementar VPLS com sinalização LDP - RFC 4762 - Virtual Private LAN Service Using Label Distribution Protocol (LDP) Signaling.
10.10.14.18. Implementar VRRP sobre as VRFs de L3 VPN.
10.10.14.19. Implementar protocolos RSTP e MSTP sobre instâncias L2 de VPLS.
10.10.15. MPLS-TE
10.10.15.1. Implementar RFC 2702 Requirements for Traffic Engineering Over MPLS.
10.10.15.2. Implementar RFC 3209 RSVP-TE.
10.10.15.3. Implementar RFC 3270 MPLS Support of Differentiated Services. 10.10.15.4. Implementar RFC 4090 Fast Reroute Extensions to RSVP-TE for LSP
Tunnels.
10.10.15.5. Implementar MPLS/TE sobre link bundles. 10.10.15.6. Implementar MPLS/FRR sobre link bundles.
10.10.15.7. Implementar inclusão de túnel de engenharia de tráfego no cálculo SPF do IGP do equipamento.
10.10.15.8. Implementar inclusão do túnel de engenharia de tráfego como mais um link do IGP.
10.10.16. PORTAS ETHERNET E BRIDGES ETHERNET
10.10.16.1. Implementar contadores de frames recebidos e descartados para interfaces 1GbE e 10GbE.
10.10.16.2. Implementar pelo menos 5 enlaces em um mesmo bundle de interfaces 10GbE - links por bundle.
10.10.16.3. Implementar pelo menos 8 bundles de interfaces por sistema. 10.10.16.4. Implementar 802.1Q para Link Bundling.
10.10.16.5. Implementar QoS para Link Bundling. 10.10.16.6. Implementar IPv6 para Link Bundling.
10.10.16.7. Deve ser compatível com o padrão IEEE 802.1Q Virtual Bridged LANs. 10.10.16.8. Deve ser compatível com o padrão IEEE 802.1Q-in-Q (VLAN stacking). 10.10.16.9. Deve ser compatível com o padrão IEEE 802.1ad (Provider Bridges).
10.10.16.10. Implementar jumbo frames maiores que 9000 bytes. 10.10.16.11. Implementar 802.1p tagging.
10.10.16.12. Implementar 802.3x flow control.
10.10.16.13. Implementar a auto-negociação segundo o padrão IEEE 802.3. 10.10.16.14. Implementar 802.3ad (LACP).
10.10.16.15. Operação, Administração e Gerência (OAM) 10.10.16.16. Implementar Ethernet Link OAM IEEE 802.3ah. 10.10.16.17. Implementar Ethernet CFM IEEE 802.1ag.
10.10.16.18. Implementar interoperação entre 802.3ah e 802.1ag. 10.10.16.19. Implementar Ethernet LMI.
10.10.16.20. Implementar Ethernet Y.1731 (ITU-T).
10.10.16.21. Implementar as funções de monitoramento pró-ativo de conectividade (Continuity Check), isolamento de falhas por meio de Loopback Messages (ping L2) e Link-trace Message (traceroute L2).
10.10.16.22. Implementar medição e monitoramento de desempenho através da medição de Frame Delay e Frame Delay Variation, tanto unidirecional quanto bidirectional.
10.10.17. FACILIDADES CAMADA 2 E CAMADA 3
10.10.17.1. Implementar pelo menos 4 mil VLANs ativas (não considerar mecanismos multiplicadores como por exemplo Q-in-Q).
10.10.17.2. Implementar 802.1D MAC Bridges. 10.10.17.3. Implementar 802.1w Rapid STP.
10.10.17.4. Implementar 802.1s Multiple Spanning Trees.
10.10.17.5. Implementar EAPS (RFC 3619) e/ou ERPS (ITU-T G.8032).
10.10.17.6. Implementar listas de controle de acesso (ACLs) layer 2.
10.10.17.7. Implementar dual-mode VLANs, isto é, VLANs cujas portas podem trabalhar simultaneamente no modo “tagged” e “untagged”.
10.10.17.8. Implementar tunelamento de protocolo L2STP e derivados. 10.10.17.9. Implementar controle do recebimento de BPDU (BPDU Guard). 10.10.17.10. Implementar entradas estáticas na tabela ARP.
10.10.17.11. Implementar roteamento inter-VLAN.
10.10.17.12. Implementar limites máximos de MAC por interface.
10.10.17.13. Implementar VLAN baseada em porta (port-based), com possibilidade de overlap de portas.
10.10.17.14. Deverá reescrever, incluir ou retirar VLAN IDs do Frame Ethernet, permitindo manipular inclusive a outer e inner tag.
10.10.17.15. Deverá Implementar os mecanismos de proteção aos protocolos L2 e L3 contra ataques de rede com limitação de banda para tráfegos de broadcast (storm), multicast e destination lookup failure (DLF).
10.10.17.16. Implementar taxa máxima de Broadcast, Multicast e Unicast- desconhecido controlada por porta (storm control).
10.10.17.17. Implementar "Aging" de L2 (MAC) por VLAN/Bridge Domain.
10.10.17.18. Implementar definição de "Aging" por inatividade ou por tempo absoluto.
10.10.17.19. Implementar definição de VLAN em VLAN, seguindo IEEE802.1ad (IEEE802.1QinQ).
10.10.17.20. Implementar Ethertype 0x8100 (IEEE 802.1Q), 0x88a8 (IEEE 802.1ad) e 0x9100 (QinQ) para tunelamento de VLAN (Tag externo).
10.10.17.21. Implementar 802.1QinQ seletivo.
10.10.17.22. Implementar tradução de VLANs (S-VLAN e C-VLAN).
10.10.17.23. Implementar restrição de encaminhamento de frames somente para MACs específicos, aprendidos dinamicamente (port security).
10.10.17.24. Implementar restrição de encaminhamento de frames somente para MACs específicos, definidos estáticamente (port security).
10.10.17.25. Implementar DHCP Helper Address (definição de endereço de servidor DHCP).
10.10.17.26. Implementar DHCP Relay, com inserção de informações (option 82). 10.10.17.27. Implementar desativação de ARP Learning por interface.
10.10.17.28. Implementar desativação de MAC Learning por VLAN. 10.10.17.29. Implementar RFC 2131 BOOTP/DHCP relay agent.
10.10.18. ESPECIFICAÇÕES MEF (Metro-Ethernet Forum)
10.10.18.1. Implementar ou estar em conformidade com os padrões MEF listados nesta seção.
10.10.18.2. MEF 2 - Requirements and Framework for Ethernet Service Protection.. 10.10.18.3. MEF 3 - Circuit Emulation Service Definitions, Framework and
Requirements in Metro Ethernet Networks.
10.10.18.4. MEF 4 - Metro Ethernet Network Architecture Framework - Part 1: Generic Framework.
10.10.18.5. MEF 6.1 - Ethernet Services Definitions - Phase 2. 10.10.18.6. MEF 7.1 - Phase 2 EMS-NMS Information Model. 10.10.18.7. MEF 9 - Abstract Test Suite for Ethernet Services at the UNI. 10.10.18.8. MEF 10.2 - MEF 10.2 Ethernet Services Attributes Phase 2.
10.10.18.9. MEF 11 - User Network Interface (UNI) Requirements and Framework.
10.10.18.10. MEF 12 - Metro Ethernet Network Architecture Framework Part 2: Ethernet Services Layer.
10.10.18.11. MEF 13 - User Network Interface (UNI) Type 1 Implementation Agreement.
10.10.18.12. MEF 14 - Abstract Test Suite for Traffic Management Phase 1.
10.10.18.13. MEF 15 - Requirements for Management of Metro Ethernet Phase 1 Network Elements.
10.10.18.14. MEF 16 - Ethernet Local Management Interface. 10.10.18.15. MEF 17 - Service OAM Framework and Requirements. 10.10.18.16. MEF 19 - Abstract Test Suite for UNI Type 1.
10.10.18.17. MEF 20 - UNI Type 2 Implementation Agreement. 10.10.18.18. MEF 21 - Abstract Test Suite for UNI Type 2 Part 1 Link OAM.
10.10.18.19. MEF 23 - Class of Service Phase 1 Implementation Agreement. 10.10.18.20. MEF 24 - Abstract Test Suite for UNI Type 2 Part 2 E-LMI.
10.10.18.21. MEF 25 - Abstract Test Suite for UNI Type 2 Part 3 Service OAM. 10.10.18.22. QoS
10.10.18.23. Implementar priorização de tráfego (QoS) por tipo de protocolo e por serviços da pilha TCP/IP.
10.10.18.24. Implementar RFC 2474 - Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers.
10.10.18.25. Implementar RFC 2475 - An Architecture for Differentiated Services. 10.10.18.26. Implementar RFC 2474 DiffServ Precedence.
10.10.18.27. Implementar RFC 2598 DiffServ Expedited Forwarding (EF). 10.10.18.28. Implementar RFC 2597 DiffServ Assured Forwarding (AF). 10.10.18.29. Implementar RFC 2475 DiffServ Core and Edge Router Functions. 10.10.18.30. Implementar Queue Management and Congestion Avoidance.
10.10.18.31. Implementar pelo menos 8 filas de QoS (em hardware) por porta.
10.10.18.32. Deverá implementar o Rate Shapping Bidirecional (Ingress e Egress) com granularidade a partir de 64K bit/s por porta.
10.10.18.33. Implementar Hierarchical QoS (H-QoS). 10.10.18.34. Implementar Ingress Shaping.
10.10.18.35. Implementar Egress Shaping. 10.10.18.36. Implementar Ingress Policing. 10.10.18.37. Implementar Egress Policing.
10.10.18.38. Implementar avaliação dos pacotes que excederem a especificação de banda, configurando ações tais como : transmissão sem modificação, transmissão com remarcação e descarte.
10.10.18.39. Implementar RFC 2697 A Single Rate Three Color Marker.
10.10.18.40. Implementar configuração de 2 rate 3 color policer ou shaper - RFC2698 - A Two Rate Three Color Marker.
10.10.18.41. Implementar mecanismo de priorização baseado em classes, com fila de alta prioridade.
10.10.18.42. Implementar mecanismos de QoS Strict Priority e WRR (Weighted Round Robin).
10.10.18.43. Implementar mecanismos de Strict Priority e WRR ao mesmo tempo na mesma interface.
10.10.18.44. Implementar WRED - Weighted Random Early Detection.
10.10.18.45. Implementar “head-of-queue drop” no mínimo para WRED, mas preferencialmente em todos os casos.
10.10.18.46. Implementar funcionalidades de controle e limitação de tráfego com garantia de banda por classe de serviço.
10.10.18.47. Implementar classificação e marcação de pacotes baseada em: 10.10.18.47.1. endereço de origem.
10.10.18.47.2. porta de origem. 10.10.18.47.3. endereço de destino. 10.10.18.47.4. porta de destino.
10.10.18.47.5. marcação DSCP.
10.10.18.47.6. marcação IP Precedence. 10.10.18.47.7. CoS (“Class of Service” – nível 2). 10.10.18.47.8. MPLS campo EXP.
10.10.18.48. Implementar funcionalidades que permitam o mapeamento do tráfego via lista de controle.
10.10.18.49. Implementar mapeamento automático do campo IP Precedence para MPLS EXP e vice-versa.
10.10.18.50. Implementar aplicação de políticas de QoS em todas as portas físicas do equipamento.
10.10.18.51. Implementar filas de prioridade para o tráfego unicast e multicast na switching fabric/forwarding engine.
10.10.18.52. Implementar a recuperação de estatísticas de QoS via SNMP.
10.10.18.53. A aplicação de funcionalidades de QoS e rate shaping não deve causar impactos significativos no sistema a ponto de degradar os serviços.
10.10.18.54. As funcionalidades de QoS (inclusive filas, filtros, políticas e medidores) devem implementadas em hardware.
10.10.18.55. GERÊNCIA
10.10.18.56. Implementar SNMPv2.
10.10.18.57. Implementar SNMPv3c.
10.10.18.58. Implementar pelo menos os seguintes níveis de segurança para SNMPv3: Sem autenticação e sem privacidade, Com autenticação e sem privacidade, com autenticação e com privacidade.
10.10.18.59. Implementar persistência do Interface Index (ifIndex).
10.10.18.60. Implementar Syslog Local e Remoto, com capacidade de armazenamento local em memória de massa de estado sólido.
10.10.18.61. Implementar múltiplos servidores Syslog remotos. 10.10.18.62. Implementar RFC 1492 TACACS+.
10.10.18.63. Implementar RFC 2138 RADIUS Authentication.
10.10.18.64. Implementar RFC 2139 RADIUS Accounting.
10.10.18.65. Implementar autenticação dos administradores de rede usando RADIUS e TACACS+.
10.10.18.66. Implementar mecanismos de AAA (Authentication, Authorization e Accounting) com garantia de entrega..
10.10.18.67. Implementar definição de grupos de usuários, com diferentes níveis de acesso.
10.10.18.68. Implementar permitir controlar quais comandos usuários ou grupos de usuários podem emitir.
10.10.18.69. Implementar autenticação mútua entre o servidor AAA e o cliente AAA.
10.10.18.70. Implementar RFC 1305 NTP versão 3, ou RFC 5905 NTP versão 4 ou
RFC 4330 SNTP versão 4.
10.10.18.71. Implementar a monitoração de fluxos - RFC 5101 - Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information ou similar.
10.10.18.72. Implementar capacidade para monitoração de fluxos IPv4. 10.10.18.73. Implementar capacidade para monitoração de fluxos IPv6. 10.10.18.74. Implementar capacidade para monitoração de fluxos MPLS.
10.10.18.75. Implementar capacidade para a exportação de flows de tráfego com uma amostragem mínima de 1:1000 para todas as interfaces de serviço e proporcional à capacidade do sistema.
10.10.18.76. Implementar capacidade de monitoração de tráfego de interfaces.
10.10.18.77. Implementar monitoração do uso de CPU do processador via SNMP 10.10.18.78. Implementar monitoração do uso de memória do processador via
SNMP.
10.10.18.79. Implementar monitoração do uso de CPU de cartão de interfaces via SNMP.
10.10.18.80. Implementar monitoração do uso de memória do cartão de interfaces via SNMP.
10.10.18.81. Implementar monitoração do uso de CPU do processador via comando de operação.
10.10.18.82. Implementar monitoração do uso de memória do processador via comando de operação.
10.10.18.83. Implementar monitoração do uso de CPU de cartão de interfaces via comando de operação.
10.10.18.84. Implementar monitoração do uso de memória do cartão de interfaces via comando de operação.
10.10.18.85. Implementar utilização de scripts para automação de tarefas. 10.10.18.86. Implementar definição de alarmes de utilização de recursos. 10.10.18.87. Implementar aplicação de atualizações no sistema, em serviço. 10.10.18.88. Possuir sistema operacional com arquitetura modular.
10.10.18.89. Permitir o reinício de processos, de forma individual. 10.10.18.90. Implementar SSH v2 server.
10.10.18.91. Implementar implementação de cópia de arquivos de configuração e imagens de firmware usando no mínimo um dos seguintes protocolos: TFTP/FTP/SFTP/SCP..
10.10.18.92. Implementar gerência fora de banda por interface dedicada.
10.10.18.93. Deverá possuir interface Console padrão RS232D (EIA/TIA 561 – conector RJ45), ou disponibilizar adaptador, na quantidade de portas console, que atenda esse padrão.
10.10.18.94. Implementar endereço virtual para gerência fora de banda.
10.10.18.95. Caso o equipamento possua funcionalidade de acesso por Telnet ou via HTTP, o equipamento deverá permitir que estas sejam desabilitadas, através de configuração, sem prejuízo às demais funcionalidades do mesmo.
10.10.18.96. Permitir a criação de listas de acesso baseadas em endereços IP para limitar o acesso ao elemento de rede via Telnet ou SSH, possibilitando a definição dos endereços IP de origem das respectivas sessões.
10.10.18.97. Implementar o armazenamento de múltiplas imagens de software e configuração(mínimo de 2 para imagens e 2 para configuração)..
10.10.18.98. Implementar comandos de depuração. 10.10.18.99. Implementar RFC 854 Telnet client and server. 10.10.18.100. Implementar RFC 1157 SNMPv1.
10.10.18.101. Implementar RFC 1212, RFC 1213, RFC 1215 MIB-II, Ethernet-Like MIB & TRAPs.
10.10.18.102. Implementar RFC 1573 Evolution of Interfaces Group of MIB II.
10.10.18.103. Implementar RFC 1650 Ethernet-Like MIB (update of RFC 1213 for SNMPv2).
10.10.18.104. Implementar RFC 1901 – 1908 SNMP Version 2c, SMIv2 and Revised MIB-II.
10.10.18.105. Implementar RFC 2570 – 2575 SNMPv3, user based security, encryption and authentication.
10.10.18.106. Implementar RFC 2576 Coexistence between SNMP Version 1, Version 2- and Version3.
10.10.18.107. Implementar RFC 2665 Ethernet-Like-MIB.
10.10.18.108. Implementar RFC 2233 Interface MIB.
10.10.18.109. Implementar RFC 1850 OSPFv2 MIB.
10.10.18.110. Implementar RFC 3812 MPLS TE MIB.
10.10.19. SEGURANÇA
10.10.19.1. Implementar listas de controle complexas sem perda significativa de desempenho que venha degradar os serviços.
10.10.19.2. A performance das listas de controle deve ser invariante em relação ao tráfego, ou seja, as características do tráfego sendo filtrado não podem influir na performance do plano de dados (filtragem, roteamento, comutação e encaminhamento de pacotes), plano de controle (protocolos e routing engine), e plano de administração.
10.10.19.3. Implementar contadores para as listas de acesso.
10.10.19.4. Implementar listas de acesso para o tráfego entrante e sainte. 10.10.19.5. Implementar policiamento do plano de controle.
10.10.19.6. Implementar customização do policiamento do plano de controle. 10.10.19.7. Implementar recursos contra ataques do tipo Denial of Service.
10.10.19.8. Implementar as ACLs em hardware, sem impacto no consumo dos processadores (CPUs) do equipamento.
10.10.19.9. Deve ser capaz de filtrar tráfego a 100% da capacidade nominal de encaminhamento de tráfego (tanto em throughput quanto em pacotes por segundo).
10.10.19.10. Deve ser capaz de filtrar e limitar tráfego destinado ao plano de controle em hardware, sem consumo de recursos da routing engine.
10.10.20. IPSEC, CRIPTOGRAFIA, GERADOR DE NÚMEROS ALEATÓRIOS (RNG)
10.10.20.1. Não deve possuir backdoors de qualquer espécie, particularmente não deve possuir nenhum dispositivo de hardware ou software que permita acesso remoto não autorizado, que comprometa o funcionamento do gerador de números aleatórios, que exponha material secreto (como chaves privadas), ou que de alguma forma reduza a segurança ou a privacidade de conexões cifradas.
10.10.20.2. Não deve, sob nenhuma hipótese, utilizar gerador de números aleatórios baseado apenas em funções matemáticas e processos determinísticos, sendo obrigatória a utilização de gerador de números aleatórios constantemente ou periodicamente realimentado por processos inerentemente não determinísticos, devidamente submetidos a processo de debiasing e whitening.
10.10.20.3. Não deve, sob nenhuma hipótese, utilizar o gerador de números aleatórios Dual_EC_DRBG (NIST SP 800-90).
10.10.20.4. Todos os equipamentos devem implementar IPSEC em IPv4 e IPv6, utilizando IKEv2, e devem implementar: RFC4301, RFC4303, RFC4302, RFC5996, RFC6989.
10.10.20.5. Implementar criptografia AES para IPSEC, RFC 4309. 10.10.20.6. Implementar criptografia por curvas elípticas, RFC 6379.
10.10.20.7. Implementar criptografia RSA e aceitar chaves com pelo menos 4096 bits.
10.10.20.8. O firmware de todos os equipamentos deve obrigatoriamente implementar criptografia AES 256 bits e 128 bits, protocolo SSH versão 2.0.
10.10.20.9. O acesso via protocolo SSH versão 2.0 deve obrigatoriamente interoperar perfeitamente com a implementação de referência do protocolo SSH em código aberto: OpenBSD portable OpenSSH (versão 5.5p1 ou mais recente).
10.10.21. CARTÕES DE INTERFACES
10.10.21.1. O roteador deve suportar cartões de interface para expansão das interfaces de dados.
10.10.21.2. Estas especificações são válidas para quaisquer cartões de interface que sejam fornecidos pré-instalados nos equipamentos com o objetivo de atender à especificação base para aquele modelo de equipamento.
10.10.21.3. O cartão de interfaces deve integrar-se perfeitamente ao roteador onde será instalado.
10.10.21.4. O roteador deve operar o canal de comunicações com o chassis/módulos de controle/outros cartões de interface, no mínimo, na capacidade máxima bidirecional agregada de todas as portas do cartão de interface, ou seja, sem utilizar de oversubscription.
10.10.21.5. Os cartões de interface devem implementar todas as exigências, funcionalidades e especificações que dependam de facilidades e características do cartão de interface, válidas para o roteador em que foram/serão instalados.
10.10.22. PORTAS FIXAS
10.10.22.1. O roteador deve operar portas fixas de dados (caso existam), no mínimo na capacidade máxima bidirecional agregada das mesmas, ou seja, sem utilizar de oversubscription.
10.10.22.2. As portas fixas de dados, caso existam, devem ser modulares (para módulos SFP, SFP+ ou XFP de acordo com a capacidade da porta), ou do tipo combo (formado pelo conjunto de um slot SFP, SFP+ ou XFP, e de uma porta 1000BASE-T ou 10GBASE-T dependendo se a porta é gigabit- ethernet ou 10-gigabit-ethernet).
10.10.22.3. As portas fixas de administração devem ser do tipo serial RS-232 para portas de console, e fast-ethernet IEEE 802.3 100BASE-TX ou gigabit- ethernet IEEE 802.3 1000BASE-T para administração remota e monitoramento via protocolo IPv4 e IPv6 (ssh, snmp, etc).
10.10.23. SUPORTE A MÓDULOS SFP/SFP+/XFP
10.10.23.1. O roteador deve suportar os seguintes tipos de módulos 1GbE padrão SFP, que devem estar disponíveis no mercado para aquisição:
10.10.23.1.1. Módulo SFP óptico 1000BASE-SX (550m).
10.10.23.1.2. Módulo SFP óptico 1000BASE-LX (10km), 1310nm.
10.10.23.1.3. Módulo SFP óptico 1000BASE-LX+ (30km), 1310nm.
10.10.23.1.4. Módulo SFP óptico 1000BASE-LX/LH (80km), 1550nm.
10.10.23.1.5. Módulo SFP óptico bidirecional 1000BASE-BX20-U (20km), 1310nm/1490nm.
10.10.23.1.6. Módulo SFP óptico bidirecional 1000BASE-BX20-D (20km), 1490nm/1310nm.
10.10.23.1.7. Módulo SFP óptico bidirecional 1000BASE-BX60-U (60km), 1310nm/1490nm.
10.10.23.1.8. Módulo SFP óptico bidirecional 1000BASE-BX60-D (60km), 1490nm/1310nm.
10.10.23.1.9. Módulo SFP 1000BASE-T 10/100/1000, RJ45.
10.10.23.2. O roteador deve suportar os seguintes tipos de módulos 10GbE padrão SFP+ ou XFP, que devem estar disponíveis no mercado para aquisição:
10.10.23.2.1. Módulo 10GbE óptico 10GBASE-SR, 850nm.
10.10.23.2.2. Módulo 10GbE óptico 10GBASE-LR (10km), 1310nm.
10.10.23.2.3. Módulo 10GbE óptico 10GBASE-ER (40km), 1550nm.
10.10.23.2.4. Módulo 10GbE óptico 10GBASE-ZR (80km), 1550nm.
10.10.23.2.5. Módulo 10GbE óptico bidirecional 10GBASE-BX20-U (20km), 1270nm/1330nm.
10.10.23.2.6. Módulo 10GbE óptico bidirecional 10GBASE-BX20-D (20km), 1330nm/1270nm.
10.10.24. OUTRAS ESPECIFICAÇÕES
10.10.24.1.1. Todos os slots não ocupados devem vir fechados com tampa cega. 10.10.24.1.2. Todos os requisitos, exceto quando explicitamente especificado em
contrário, devem ser atendidos de forma concomitante, ou seja, a conformidade de um requisitos não pode afetar a disponibilidade dos demais.
10.10.24.1.3. O cabo de console serial deve ser fornecido junto com o equipamento.
10.10.24.1.4. Os cabos de alimentação devem ser fornecidos junto com o equipamento.
10.11. DAS ESPECIFICAÇÕES PARA ROTEADOR DE BORDA IP
10.11.1. Possuir arquitetura de comutação non-blocking.
10.11.2. Possuir redundância de sistema de resfriamento/ventilação.
10.11.3. Deverá ser totalmente hot-swappable. Ou seja, os módulos, independentes de tipo, poderão ser inseridos e retirados do chassis sem a reinicialização do mesmo.
10.11.4. Permitir instalação em bastidor de 19".
10.11.5. As fontes de alimentação instaladas deverão ser internas ao chassis.
10.11.6. Possuir redundância de fontes de alimentação.
10.11.6.1. Suportar alimentação AC autorange redundante, com amplitude de no mínimo 100V a 240V, 50/60Hz, compatível com as variações de frequência causadas por grupo moto-gerador.
10.11.6.2. Suportar diferença de fase entre as alimentações AC.
10.11.6.3. Suportar alimentação DC -48V autorange, com amplitude de no mínimo - 44V a -56V.
10.11.6.4. A CONTRATANTE indicará na ordem de compra se o equipamento deverá ser fornecido com fontes AC redundantes, ou fontes DC redundantes.
10.11.7. As fontes de alimentação instaladas deverão suportar a capacidade máxima do equipamento.
10.11.8. Suportar operação normal em temperaturas de 5ºC a 40ºC.
10.11.9. Possuir indicadores luminosos do estado de alimentação (on/off) da fonte e de status operacional para cada módulo/porta instalado.
10.11.10. ALTA-DISPONIBILIDADE
10.11.10.1. Implementar NSF: non-stop forwarding ou equivalente para o plano de dados.
10.11.10.2. Implementar Graceful Restart ou equivalente para o plano de controle.
10.11.10.3. Implementar non-stop routing (NSR) ou equivalente para os protocolos OSPFv2, OSPFv3, BGP4, MP-BGP, para IPv4, IPv6, e MPLS.
10.11.10.4. Permitir a atualização do firmware/sistema operacional do roteador sem interrupção de serviço nas configurações ofertadas (ISSU ou equivalente).
10.11.11. PORTAS
10.11.11.1. Possuir no mínimo 10 (dez) portas 1GbE IEEE 802.3 para serviços de dados.
10.11.11.2. Possuir no mínimo uma porta 10GbE IEEE 802.3 para serviços de dados.
10.11.11.3. Deve poder ser expandido, através da inclusão de módulos de interfaces adicionais e/ou ativação de portas através de licença, para no mínimo 10 (dez) portas 1GbE IEEE 802.3 e três portas 10GbE IEEE 802.3.
10.11.11.4. Operar todas as portas em modo line-rate, non-blocking, sem oversubscription, inclusive portas nos módulos de comando.
10.11.11.5. Todas as portas de dados devem estar ativas e disponíveis para uso pela CONTRATANTE nos equipamentos ofertados.
10.11.12. CARTÕES DE INTERFACE
10.11.12.1. Suportar cartão de interface com no mínimo 10 portas 1GbE modulares para módulos SFP.
10.11.12.2. Suportar cartão de interface com no mínimo 1 porta 10GbE (10-gigabit- ethernet) modular, ou para módulos SFP+, ou para módulos XFP.
10.11.13. CAPACIDADE E DESEMPENHO
10.11.13.1. Implementar a mesma capacidade de comutação, encaminhamento e roteamento de pacotes para tráfego IPv4, IPv6 e MPLS.
10.11.13.2. Implementar comutação, encaminhamento e roteamento de pacotes wire-speed, non-blocking entre todas as portas de dados.
10.11.13.3. Deve rotear, comutar e encaminhar pacotes a no mínimo 5Gbps, independente do perfil de tráfego IPv4, IPv6, MPLS e multicast.
10.11.13.3.1. Dever permitir ampliar a capacidade de roteamento, comutação e encaminhamento de pacotes para no mínimo 36Gbps através da aplicação de licença de software, sem alterações de hardware.
10.11.13.3.2. Deve rotear, comutar e encaminhar pacotes a no mínimo 30Mpps (melhor caso) e a no mínimo 19Mpps (combinação típica de funcionalidades).
10.11.13.3.3. Deve implementar aceleração criptográfica em hardware para no mínimo 4Gbps de tráfego.
10.11.13.3.4. Implementar capacidade de memória RAM na routing engine de no mínimo 16GiB, com proteção ECC ou similar.
10.11.13.3.5. A arquitetura do equipamento e seus cartões de interface deve garantir funcionamento wire-speed com pacotes a partir de 64 bytes de tamanho e a presença de mecanismos para evitar congestionamentos em caso de Head of Line blocking.
10.11.13.3.6. Implementar os seguintes tamanhos de tabelas de busca em hardware (TCAM ou similar), simultaneamente e independente da quantidade/tipo de cartões de interface:
10.11.13.3.6.1. No mínimo 16.000 (dezesseis mil) endereços MAC. 10.11.13.3.6.2. FIB IPv4 (1 milhão de rotas).
10.11.13.3.6.3. FIB IPv6 (512 mil rotas).
10.11.13.3.6.4. No mínimo 5.000 (cinco mil) labels MPLS (LFIB). 10.11.13.3.6.5. No mínimo 4.000 (quatro mil) filtros (ACLs).
10.11.13.3.7. Implementar capacidade para pelo menos 16.000 (dezesseis mil) hosts IPv4 (L3) e 8.000 (oito mil) hosts IPv6 (L3), independente da quantidade de cartões de interface.
10.11.13.3.8. Implementar capacidade para no mínimo 1.000 (mil) grupos multicast L2, independente da quantidade de cartões de interface.
10.11.13.3.9. Implementar capacidade para no mínimo 4.000 (quatro mil) grupos multicast L3 IPv4 e 4.000 (quatro mil) grupos multicast L3 IPv6, independente da quantidade de cartões de interface.
10.11.13.3.10. Os cartões de interface ofertados, quando instalados, devem suportar no mínimo as mesmas capacidades de prefixos IPv4, IPv6, labels MPLS, hosts IPv4 e IPv6, filtros e grupos multicast L2 e L3 especificadas acima.
10.11.14. ESPECIFICAÇÕES TÉCNICAS PARA OS MÓDULOS SFP/SFP+/XFP
10.11.14.1. Módulos para 1GbE (gigabit ethernet) devem ser to tipo SFP. 10.11.14.2. Módulos para 10GbE (10-gigabit ethernet) devem ser do tipo SFP+ ou
XFP.
10.11.14.3. No caso de oferta de equipamentos que utilizem tanto módulos SFP+ quanto módulos XFP, a CONTRATANTE especificará na ordem de compra qual o tipo de módulo a ser fornecido e suas quantidades.
10.11.14.4. Todos os módulos SFP, SFP+ e XFP ópticos que operarem com fibra monomodo para distâncias superiores a 5km, devem possuir capacidade de monitoramento (digital diagnostics monitoring) e monitoramento do nível do sinal óptico (DOM).
10.11.14.5. Todos os módulos SFP, SFP+ e XFP ópticos devem possuir conectorização LC.
10.11.14.6. Módulos ópticos bidirecionais trabalham com apenas uma única fibra óptica monomodo, que é utilizada para transmissão e recepção simultânea full-duplex através de multiplexação por comprimento de onda (transmite em um comprimento de onda, e recebe em outro comprimento de onda, simultaneamente).
10.11.14.7. Módulos ópticos bidirecionais possuem dois subtipos, “U” e “D”, com os comprimentos de onda de transmissão e recepção invertidos entre os dois. Enlaces são formados conectando um módulo subtipo U com um módulo subtipo D.
10.11.14.8. Todos os módulos devem implementar os padrões IEEE relevantes ao tipo de conexão referenciado no item do objeto, em sua totalidade, e ter velocidade de canal compatível com a velocidade de interface (1GbE ou 10GbE).
10.11.14.9. Módulos 10GbE devem operar em modo LAN PHY.
10.11.14.10. Módulos 10GbE devem suportar operação em modo WAN PHY com G.709 FEC (standard FEC e advanced FEC) quando suportado pelo equipamento onde serão instalados.
10.11.14.11. Serão aceitos módulos ópticos para distâncias maiores em substituição a módulos ópticos de mesmo tipo para distâncias menores, entretanto deverá ser fornecido atenuador óptico adequado com o mesmo padrão de conectorização do módulo caso exista risco de causar ofuscamento/sobrecarga no receptor.
10.11.14.12. Os módulos devem ser homologados pelo fabricante dos roteadores para uso nos equipamentos ofertados.
10.11.14.13. Módulos SFP 1000BASE-T devem possuir trava robusta, particularmente se a mesma for uma trava móvel. A quebra desta trava sem a ocorrência de danos de outra espécie ao módulo caracterizará defeito do mesmo por trava fraca, e o módulo deverá ser reparado ou substituído por um módulo novo e em perfeito estado de funcionamento pela CONTRATADA, sem ônus para a CONTRATANTE.
Anexo III
LOTE 3
11. QOS 10 Gbps
11.1. Deve implementar paridade de funcionalidade e performance (largura de banda e encaminhamento de pacotes) entre tráfego IPv4 e IPv6, para qualquer combinação de tipo de tráfego IPv4/IPv6
11.2. Deve possuir pelo menos 8 (oito) filas de prioridade em hardware para as portas 10 Gigabit Ethernet e 4 (quatro) filas de prioridade em hardware para as portas Gigabit Ethernet.
11.3. A solução ofertada deve suportar classificação e priorização de tráfego de acordo com os seguintes critérios:
11.3.1. Por porta física de entrada.
11.3.2. Utilizando access-lists standard e extended.
11.3.3. Por endereços MAC de origem e destino.
11.3.4. Por valor de IP Precedence.
11.3.5. Por valor de DSCP (Differentiated Services Code Point).
11.3.6. Por valor de CoS (Class of Service, norma IEEE 802.1p).
11.3.7. Por protocolo de aplicação (Layer 7).
11.3.8. Por range de portas RTP (Real-time Transport Protocol).
11.4. A solução ofertada deve suportar o mapeamento de marcas de CoS para DSCP e de DSCP para CoS.
11.5. A solução ofertada deve suportar os seguintes mecanismos de controle de congestionamento: FIFO (First-in First-out), Weighted Fair Queuing (WFQ), Class-Based Weighted Fair Queuing (CBWFQ) e Low Latency Queuing (LLQ).
11.6. A solução ofertada deve suportar os seguintes mecanismos de prevenção ao congestionamento:
11.6.1. Random Early Detection (RED),
11.6.2. Weighted Random Early Detection (WRED)
11.6.3. Explicit Congestion Notification (ECN).
11.7. A solução ofertada deve suportar:
11.7.1. Class-Based
11.7.2. Traffic Policing
11.7.3. Class-Based Traffic Shaping.
11.8. A solução ofertada deve suportar a configuração de limitação de banda (Rate Limit).
11.9. Os equipamentos deverão proporcionar no mínimo as seguintes funções:
11.10. Protocolos
11.10.1. Suporte a pelo menos 600 protocolos mais utilizados
11.11. Desempenho
11.11.1. Throughput mínimo: 20 Gbps, 28Mpps (com todas as funcionalidades ativas simultaneamente)
11.11.2. Número mínimo de subscribers: 60.000
11.11.3. Número mínimo de fluxos simultâneos: 20.000.000
11.12. Monitoramento
11.12.1. Monitorar aplicações até a camada 7 do modelo OSI.
11.12.2. Monitorar o circuito por protocolo, endereço IP e endereço MAC.
11.12.3. Monitorar a utilização do circuito Inbound e Outbound.
11.12.4. Monitorar o circuito apresentando os top clients (subscribers) e servers.
11.13. Relatórios
11.13.1. Ferramenta para geração de relatórios com interface gráfica.
11.13.2. Emitir relatórios gráficos e analíticos.
11.13.3. Exportar relatórios para aplicativos como (Excel, Word, Access, etc).
11.13.4. Emitir relatórios por utilização (Kbps/inbound/outbound), IP, Portas, URL, Protocolos, Aplicações, subscribers/assinantes, por consumo de banda global, por media de banda consumida por assinante, total de banda consumida por serviço, consumo de banda consumida pelo assinante por hora e por dia, picos de utilização da banda total, consumo de banda por serviço e por grupos de assinantes, volume total consumidor por hora, por dia e por serviço, Top Ten de assinantes, banda consumida por serviço e por assinante, picos de utilização da banda por assinante, volume utilizado por assinante e por serviço, em hora e por dia, descoberta de tráfego em gráficos Top Ten por de cliente, servers, serviço e porta, IP e protocolos, IP server e server port, IP cliente e server port, mostrar total de assinantes ativos por serviços, mostrar grupos de assinantes ativos por serviços, informar volume de tráfego em Top Ten para web host, servidores FTP, servidores de serviços, mostrar gráficos de volume em Top Ten para servidores SMPT, POP3, NNTP, e-mails enviados e recebidos, servidor SMTP distribuídos por grupos de assinantes, servidor POP3 distribuídos por grupos de assinantes, mostrar em gráfico Top Ten os protocolos P2P, assinantes utilizando P2P, download em P2P e upload em P2P, banda global por serviço de Voip, banda consumida por assinante utilizando o serviço de Voip, mostrar gráfico Top Ten dos ataques DoS em hosts, ataques DoS sobre os assinantes, Top Ten dos assinantes atacados, top ten das portas scaneadas e atacadas, informar média banda por assinante em túnel IPV6, assinantes ativos utilizando IPV6.
11.13.5. Armazenar históricos por um período mínimo de 13 (treze) meses, em ambiente de alta disponibilidade e redundante.
11.13.6. Capacidade de exportação de históricos para banco de dados
11.14. Gerência de Banda
11.14.1. Permitir priorização do tráfego por IP / Porta / MAC / Protocolo / Aplicação.
11.14.2. Permitir no mínimo 08 níveis de prioridade.
11.14.3. Permitir reserva de banda por Aplicação / Protocolo / IP.
11.14.4. Permitir controle por horário.
11.15. Gerência de assinantes
11.15.1. Permitir a criação individualizada de banda por assinantes.
11.15.2. Permitir a criação de banda por grupos de assinantes.
11.15.3. Mapeamento do endereçamento de internet por assinantes
11.16. Os equipamentos deverão possuir no mínimo 4 interfaces 10 Gbps SR/LR/ER/ZR (IEEE 802.3ae), populadas com interface 10 Gbps SR com conectores do tipo LC full duplex. deverão garantir by-pass de interfaces, ou seja, em caso de falha operacional de hardware ou software, o equipamento deverá chavear as interfaces de entrada e saída, garantindo o funcionamento da rede mesmo sem as políticas de qualidade.
ANEXO IV
LOTE 3
12. SWITCH DATA CORE
12.1. Módulo Base.
12.1.1. Deve possuir fonte de alimentação com capacidade de operar em tensões de 100 a 240 V e em frequências de 50/60 Hz.
12.1.2. Deve possuir suporte a fonte de alimentação redundante interna.
12.1.3. Deve possuir MTBF de no mínimo 180.000 Horas
12.1.4. Tabela de endereços MAC com capacidade para no mínimo 32000 endereços MAC.
12.1.5. Deve possuir memória flash de no mínimo 32 MB.
12.1.6. Deve possuir memória DRAM de no mínimo 256 MB.
12.1.7. Deve vir acompanhado do kit de suporte específico para montagem em Rack de 19" ocupando uma unidade de Rack (1U).
.
12.2. Interfaces
12.2.1. Deve possuir no mínimo 4 portas Switch Gigabit Ethernet 10/100/1000BaseT com conectores RJ45.
12.2.2. Deve suportar auto negociação de velocidade, modo duplex e MDI/MDIX.
12.2.3. Deve suportar as seguintes tecnologias Ethernet, Fast Ethernet, Gigabit Ethernet e 10 Gigabit Ethernet, comunicando-se através de um único backplane.
12.2.4. Deve possuir no mínimo 10 portas 10 Gigabit Ethernet no equipamento ou através de modulo
12.2.5. Devem vir acompanhada de cordão óptico de LC/SC de no mínimo 10 Mts, um para cada porta.
12.2.6. Deve ser fornecido em conjunto com a Switch Core 8 interfaces Mini Gbic – Transceiver SR do tipo SFP+ (10 Gigabit Small Form Factor Pluggable) padrão 10.000Base-SR para uso nas portas 10 gigabit em fibra multímodo (MMF)
12.2.7. Deve ser fornecido em conjunto com a Switch Core quantidade necessária de cordões ópticos com a metragem de 10 Mts do tipo LC/SC para uso nas portas 10 gigabit.
12.3. Switching
12.3.1. Possuir no mínimo 4 (quatro) filas para priorização de tráfego por porta.
12.3.2. Deve implementar o protocolo 802.1p.
12.3.3. Deve implementar o protocolo 802.3X.
12.3.4. Deve implementar IGMP Snooping v1, v2 e v3.
12.3.5. Deve implementar MSDP.
12.3.6. Deve implementar Multicast Listener Discovery v1 e v2.
12.3.7. Deve implementar Multicast Listener Discovery Snooping v1, v2 e v3.
12.3.8. Implementar controle de broadcast, Multicast e Unicast permitindo fixar o limite máximo de broadcasts, Multicasts e Unicasts por porta.
12.4. Roteamento
12.4.1. Deve implementar roteamento IPv4 e IPv6 entre as Vlans internamente, sem a necessidade de equipamentos externos.
12.4.2. Deve implementar os seguintes protocolos de roteamento Ipv4 em todas as suas interfaces: RIPv1, RIPv2, OSPF, BGP4, RIPng, OSPFv3 e BGP4+.
12.4.3. Deve implementar o protocolo VRRP (Virtual Router Redundancy Protocol) conforme a RFC 2338.
12.4.4. Deve implementar roteamento Ipv4 usando o protocolo BGP4 em todas as suas interfaces
12.4.5. Deve implementar os seguintes protocolos de roteamento Multicast: PIM-DM, PIM- SM e PIM-SSM.
12.4.6. Deve Implementar Policy Based Routing.
12.4.7. Deve permitir no mínimo 16.000 (dezesseis mil) entradas na tabela ARP.
12.4.8. Deve permitir no mínimo 120.000 (cento e vinte mil) rotas de Ipv4 em hardware, armazenadas em CAMs localmente nos módulos de interface, considerando o somatório das capacidades individuais de cada módulo entregue na solução ofertada.
12.4.9. Deve implementar no mínimo 1.000 (mil) Rotas Estáticas Ipv4.
12.5. Convergência
12.5.1. Deve implementar limitação de banda baseada em porta física do switch, endereço MAC fonte e destino, endereço IP fonte e destino, port TCP/UDP fonte e destino e valor TOS.
12.5.2. Deverá permitir a limitação por valor absoluto em intervalos de no mínimo 64 Kbps.
12.5.3. Deve implementar DHCP Server.
12.5.4. Deve implementar DHCP Client.
12.5.5. Deve implementar DHCP Relay.
12.5.6. Deve implementar DHCP Snooping.
12.5.7. Possibilitar a implementação de 2 métodos de processamento de filas simultaneamente em uma mesma porta: Weighted Round Robin e Strict Priority.
12.5.8. Implementar protocolo NTP com autenticação
12.6. Disponibilidade
12.6.1. Deve implementar o protocolo Spanning Tree (IEEE 802.1D).
12.6.2. Deve implementar o protocolo Rapid Spanning Tree (IEEE 802.1w).
12.6.3. Deve implementar o protocolo Multiple Spanning Tree (IEEE 802.1s).
12.6.4. Deve implementar o protocolo Flow Control (IEEE802.3x)
12.6.5. Deve implementar BPDU Protection.
12.6.6. Deve implementar UDLD ou DLDP.
12.6.7. Deve possuir capacidade de configuração de até 30 troncos (Link Aggregation) utilizando o protocolo IEEE 802.3ad, com pelo menos 4 portas físicas por tronco. Deve suportar agregação de portas que estejam em módulos distintos.
12.6.8. Deve implementar jumbo frames até 9000 bytes nas portas Gigabit Ethernet e 10GbE.
12.6.9. Deve implementar o protocolo IGMP.
12.7. Gerenciamento
12.7.1. Deve suportar gerenciamento SNMP, v1, v2c e v3 com criptografia AES 128 bits.
12.7.2. Deve suportar gerenciamento RMON implementando no mínimo 4 grupos.
12.7.3. Deve suportar Syslog.
12.7.4. Deve possuir capacidade interna de teste de qualidade de serviço entre dois switches permitindo aferir para cada porta TCP e UDP os resultados de Round Trip Time, perda de pacotes e jitter e eco de pacotes UDP.
12.7.5. Deve suportar implementação espelhamento de tráfego de forma que o tráfego de um grupo de portas possa ser espelhado em outra para fins de monitoramento. Deverá permitir múltiplas sessões de espelhamento de tráfego simultaneamente.
12.7.6. Deve permitir a aplicação de listas de controle de acesso para espelhar somente parte do tráfego.
12.7.7. Deve permitir o espelhamento remoto em outro switch da rede (RSPAN).
12.7.8. Deve permitir o espelhamento de uma VLAN em uma porta destino.
12.7.9. Deve suportar configuração através de TELNET.
12.7.10. Deve suportar configuração através de SSHv2.
12.7.11. Deve suportar gerenciamento via interface web.
12.7.12. Deve suportar configuração através de HTTPS/SSL.
12.7.13. Deve suportar as seguintes MIBs: MIB II, Bridge MIB e RMON MIB.
12.7.14. Deve permitir a configuração através de porta serial.
12.7.15. Deve suportar autenticação através de Radius para acesso ao gerenciamento.
12.7.16. Deve implementar autenticação via TACACS+, com possibilidade de autenticação comando a comando.
12.7.17. Deve implementar Sflow.
12.7.18. Deve permitir o armazenamento de múltiplas imagens de firmware.
12.7.19. Deve permitir o download e o upload de configurações em formato .txt.
12.7.20. Deve suportar TFTP Client.
12.7.21. Deve suportar DNS Client.
12.7.22. Deve implementar sincronismo de relógio SNTP ou NTP.
12.7.23. Deve implementar o protocolo Syslog para funções de “logging” de eventos.
12.7.24. Deve suportar protocolo de coleta de informações de fluxos que circulam pelo equipamento contemplando no mínimo as seguintes informações de IP origem/destino, parâmetro “protocol type” do cabeçalho IP, porta TCP/UDP origem/destino, campo TOS do cabeçalho IP, interface de entrada do tráfego.
12.7.25. Deve possuir uma porta de gerenciamento out-of-band (10/100BASE-T ou 10/100/1000BASE-T), para permitir gerenciamento do equipamento sem interferência com o tráfego de dados.
12.7.26. Deve permitir o monitoramento de tráfego unidirecional ou bidirecional.
12.8. Segurança
12.8.1. Deve implementar no mínimo 4000 Vlans segundo o protocolo IEEE 802.1Q.
12.8.2. Deve possuir no mínimo proteção contra ataques DoS.
12.8.3. Deve implementar no mínimo network login através do padrão IEEE 802.1x.
12.8.4. Deve implementar no mínimo autenticação sando os padrões PEAP, EAP-TLS, EAP-MD5.
12.8.5. Deve configurar os parâmetros de VLAN e QoS de acordo com o usuário autenticado.
12.8.6. Deve permitir autenticação dos dispositivos de rede pelo endereço MAC utilizando servidor RADIUS.
12.8.7. Deve configurar VLAN de acordo com o dispositivo autenticado.
12.8.8. Deve permitir a autenticação simultânea na mesma porta através de IEEE 802.1x
12.8.9. Deve permitir a autenticação endereço MAC de forma centralizada para que apenas usuários autorizados em computadores cadastrados possam acessar a rede.
12.8.10. Deve permitir Implementar listas de controle de acesso baseadas em endereço MAC de origem/destino, endereço IP de origem/destino, porta TCP/UDP de destino/origem e Ethertype.
12.8.11. Deve implementar autenticação MD5 para os pacotes RIP V2 e OSPF e entre os peers BGP.
12.8.12. Deve implementar Guest VLAN.
12.8.13. Deve permitir a criação de grupo de portas isoladas, no qual as estações conectadas a diferentes portas configuradas como isoladas somente podem se comunicar com portas de fora do grupo.
12.8.14. Deve implementar SFTP.
12.8.15. Deve implementar proteção contra os ataques do tipo Deny of Service, incluindo proteção para os ataques do tipo Smurf e TCP SYN.
12.8.16. Deve permitir a criação de no mínimo 8.000 (oito mil) regras de ACLs de Camada 3 e 4, suportando filtragem de pacotes por endereço IP de origem e destino e por protocolo, para tráfego IPv4 e IPv6.
12.8.17. Deve implementar espelhamento de tráfego de múltiplas portas de origem de qualquer módulo para uma porta de destino (many-to-one).
12.8.18. Deve permitir a configuração de múltiplas portas para espelhamento de tráfego, de forma que vários equipamentos de coleta de dados possam ser conectados simultaneamente a várias portas do equipamento.
12.8.19. Deve implementar configuração por linha de comando CLI.
12.9. Desempenho
12.9.1. Deve suportar agregação de links segundo o padrão IEEE 802.1ad possibilitando que no mínimo até 8 links Gigabit Ethernet operem como um único link lógico com balanceamento de carga.
12.9.2. Deve suportar Jumbo Frames.
12.9.3. Deve possuir capacidade de vazão de ao menos 128 Gbps.
12.9.4. Deve possuir capacidade de comutação de no mínimo 65.5 Mbps.
12.9.5. Deve suportar a criação de cluster de switches gerenciados através de um único endereço IP.
12.9.6. Deve possuir no mínimo 8 (oito) filas de prioridade em hardware para as portas 10Gigabit Ethernet e 4 (quatro) filas de prioridade em hardware para as portas Gigabit Ethernet.
12.9.7. Deve permitir classificação e priorização do tráfego recebido de acordo com os seguintes critérios: prioridade por porta física de entrada, prioridade por endereço MAC e prioridade definida pelos protocolos IEEE 802.1p (CoS) e DiffServ (DSCP).
12.9.8. Deve permitir a marcação de pacotes para transmissão para outros equipamentos com prioridades definidas pelo protocolo IEEE 802.1p (CoS) e DiffServ (DSCP).
12.9.9. Deve permitir a configuração do mapeamento de prioridades de acordo com IEEE 802.1p (CoS) para DiffServ (DSCP.
12.9.10. Deve possuir capacidade implementar mecanismo Weighted Random Early Detection (WRED) ou Weighted Round Robin (WRR) para monitoração de congestionamento e descarte de pacotes.
12.9.11. Deve suportar pelos menos os seguintes métodos para utilização das filas de priorização: Weighted Fair Queueing (WFQ) ou Strict Priority (SP).
12.9.12. Deve permitir a configuração de regras de controle de banda (Rate Limiting) por porta física.
12.9.13. Deve permitir a configuração simultânea de no minimo 1.000 regras de Rate Limiting.
12.10. Padronização
12.10.1. Deve suportar os seguintes padrões:
12.10.1.1. IEEE standards
12.10.1.2. IEEE 802.1D (STP)
12.10.1.3. IEEE 802.1p (CoS)
12.10.1.4. IEEE 802.1 PAE (PAE MIB)
12.10.1.5. IEEE 802.1Q GVRP (GVRP)
12.10.1.6. IEEE 802.1w (RSTP)
12.10.1.7. IEEE 802.3 LAG (LAG MIB)
12.10.1.8. IEEE 802.3ac (VLAN Tagging Extension)
12.10.1.9. IEEE 802.3ad (Link Aggregation) 12.10.1.10. IEEE 802.3ae (10 Gigabit Ethernet) 12.10.1.11. IEEE 802.3i (10BASE-T) 12.10.1.12. IEEE 802.3u (Fast Ethernet) 12.10.1.13. IEEE 802.3x (Flow Control) 12.10.1.14. IEEE 802.3z (Gigabit Ethernet) 12.10.1.15. RFC 791 (IP)
12.10.1.16. RFC 792 (ICMP)
12.10.1.17. RFC 793 (TCP)
12.10.1.18. RFC 854 and RFC 856 (TELNET)
12.10.1.19. RFC 925 (Multi-LAN Address Resolution)
12.10.1.20. RFC 950 (IP Datagram Forwarding)
12.10.1.21. RFC 951 (BootP)
12.10.1.22. RFC 1058 (RIP v1)
12.10.1.23. RFC 1122 (IP Options)
12.10.1.24. RFC 1141 (IP Datagram Forwarding)
12.10.1.25. RFC 1157 (SNMPv1/v2)
12.10.1.26. RFC 1212 (Concise MIB Definitions)
12.10.1.27. RFC 1213 (SNMP MIB II)
12.10.1.28. RFC 1215 (SNMP Traps)
12.10.1.29. RFC 1253 (OSPFv2 MIB)
12.10.1.30. RFC 1305 (NTPv3)
12.10.1.31. RFC 1350 (TFTP)
12.10.1.32. RFC 1389 (RIP MIB)
12.10.1.33. RFC 1492 (HWTACACS)
12.10.1.34. RFC 1519 (CIDR)
12.10.1.35. RFC 1542 (BootP)
12.10.1.36. RFC 1587 (OSPF NS SA)
12.10.1.37. RFC 1657 (BGP-4 MIB)
12.10.1.38. RFC 1723 (RIPv2)
12.10.1.39. RFC 1724 (RIPv2 MIB Extension)
12.10.1.40. RFC 1757 (RMON I MIB)
12.10.1.41. RFC 1771 (BGP)
12.10.1.42. RFC 1812 (IPv4 Router Compliance)
12.10.1.43. RFC 1850 (OSPFv2 MIB)
12.10.1.44. RFC 1881 (IPv6 Address Allocation Management) 12.10.1.45. RFC 1886 (IPv6 DNS Extensions)
12.10.1.46. RFC 1887 (IPv6 Unicast Address Allocation Architecture) 12.10.1.47. RFC 1901 (SNMPv2)
12.10.1.48. RFC 1907 (SNMPv2c, SMIv2 and Revised MIB-II)
12.10.1.49. RFC 1918 (Private Internet Address Allocation) 12.10.1.50. RFC 1981 (IPv6 Path MTU Discovery) 12.10.1.51. RFC 2096 (IP Forwarding Table MIB) 12.10.1.52. RFC 2012 (TCP SNMPv2 MIB)
12.10.1.53. RFC 2080 (IPv6/RIPng)
12.10.1.54. RFC 2131 (DHCP Client)
12.10.1.55. RFC 2233 (MIB)
12.10.1.56. RFC 2236 (IGMP Snooping)
12.10.1.57. RFC 2284 (EAP over LAN)
12.10.1.58. RFC 2328 (OSPFv2)
12.10.1.59. RFC 2338 (VRRP Virtual Router Redundancy Protocol) 12.10.1.60. RFC 2373 (IPv6 Addressing Architecture)
12.10.1.61. RFC 2375 (IPv6 Multicast Address Assignments) 12.10.1.62. RFC 2401 (IP Security Architecture)
12.10.1.63. RFC 2402 (IP Authentication Header) 12.10.1.64. RFC 2406 (IP Encapsulating Security Payload) 12.10.1.65. RFC 2409 (IKE)
12.10.1.66. RFC 2452 (TCP/IP)
12.10.1.67. RFC 2454 (UDP6)
12.10.1.68. RFC 2460 (IPv6 Specification)
12.10.1.69. RFC 2461 (IPv6/ND)
12.10.1.70. RFC 2462 (IPv6 Stateless Address Auto-configuration)
12.10.1.71. RFC 2463 (ICMPv6)
12.10.1.72. RFC 2464 (IPv6 Over Ethernet)
12.10.1.73. RFC 2465 and 2466 (IPv6 MIB)
12.10.1.74. RFC 2474 (DSCP Diffserv)
12.10.1.75. RFC 2475 (IPv6 Diffserv Architecture) 12.10.1.76. RFC 2526 (Reserved IPv6 Anycast Addresses) 12.10.1.77. RFC 2571 (SNMP Framework)
12.10.1.78. RFC 2572 - 2576 (SNMP)
12.10.1.79. RFC 2578 (New Traps)
12.10.1.80. RFC 2581 (TCP6)
12.10.1.81. RFC 2597 (DSCP Diffserv Expedited Forwarding) 12.10.1.82. RFC 2616 (HTTP Compatibility v1.1)
12.10.1.83. RFC 2618 (RADIUS Authentication Client MIB) 12.10.1.84. RFC 2620 (RADIUS Accounting Client MIB) 12.10.1.85. RFC 2644 (Directed Broadcast Control) 12.10.1.86. RFC 2710 (MLD IPv6 / MLD Snooping)
12.10.1.87. RFC 2740 (OSPFv3)
12.10.1.88. RFC 2767 (Dual stacks IPv4 & IPv6)
12.10.1.89. RFC 2819 (RMON I MIB)
12.10.1.90. RFC 2858 (BGP-4 Multi-protocol Extensions) 12.10.1.91. RFC 2865 (Remote Authentication Dial-In User RADIUS) 12.10.1.92. RFC 2866 (RADIUS RFC 2138/Accounting)
12.10.1.93. RFC 2893 (IPv6 Host and Router Transition Mechanism) 12.10.1.94. RFC 2925 (Ping MIB)
12.10.1.95. RFC 3056 (6to4 Tunneling)
12.10.1.96. RFC 3246 (Expedited PHB)
12.10.1.97. RFC 3306 (Unicast Prefix-Based IPv6 Multicast Addresses) 12.10.1.98. RFC 3307 (IPv6 Multicast Address Allocation)
12.10.1.99. RFC 3410 (SNMP)
12.10.1.100. RFC 3414 (SNMP User-Based SM MIB)
12.10.1.101. RFC 3415 (SNMP View-based ACMMIB)
12.10.1.102. RFC 3416 (SNMPv2)
12.10.1.103. RFC 3417 (SNMP Transport)
12.10.1.104. RFC 3484 (IPv6 Default Address Selection) 12.10.1.105. RFC 3493 (IPv6 Basic Socket Interface) 12.10.1.106. RFC 3513 (IPv6 Addressing Architecture)
12.10.1.107. RFC 3542 (Advanced Sockets API for IPv6) 12.10.1.108. RFC 3587 (IPv6 Global Unicast Address) 12.10.1.109. RFC 3596 (IPv6/DNS6 Extensions)
12.10.1.110. RFC 3623 (OSPF GR)
12.10.1.111. RFC 3768 (VRRP)
12.10.1.112. RFC 3810 (MLDv2)
12.10.1.113. RFC 4113 (IPv6 MIB for UDP)
12.10.1.114. RFC 4213 (IPv6 Host and Routers Transition Mechanisms) 12.10.1.115. RFC 4443 (ICMPv6 for IPv6)
ANEXO V
LOTE 3
13. FIREWALL 10 Gbps
13.1. TIPO DE FIREWALL: Firewall appliance (hardware), baseado na tecnologia Stateful Packet Inspection com capacidade de Deep Packet Inspection para filtragem de tráfego IP e com funcionalidade de operação em modo de Alta Disponibilidade.
13.2. Deverá operar com os protocolos IPv4 e IPv6 simultaneamente. O desempenho deverá ser semelhante para ambos os protocolos em termos de entrada, saída e rendimento do fluxo de dados, transmissão e processamento de pacotes.
13.2.1. O firewall deverá permitir o a tradução de IPv4 para IPv6 bem como IPv6 para IPv4.
13.2.2. O suporte ao protocolo IPv6 deverá ser evidenciado e comprovado através da certificação IPv6 Ready Logo.
13.2.3. Os equipamentos que não foram submetidos aos procedimentos de teste do programa IPv6 Ready, deverão estar em conformidade com as RFCs listadas abaixo:
13.2.3.1. RFC2460 - Internet Protocol, Version 6 (IPv6) Specification
13.2.3.2. RFC4291 - IP Version 6 Addressing Architecture
13.2.3.3. RFC3484 - Default Address Selection for Internet Protocol version 6 (IPv6)
13.2.3.4. RFC4443 - Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification
13.2.3.5. RFC4862 - IPv6 Stateless Address Autoconfiguration
13.2.3.6. RFC1981 - Path MTU Discovery for IP version 6
13.2.3.7. RFC4861 - Neighbor Discovery for IP version 6 (IPv6)
13.2.3.8. RFC4213 - Basic Transition Mechanisms for IPv6 Hosts and Routers
13.2.3.9. RFC4301, RFC4303, RFC4302, RFC5996 – IPSEC/IKEv2 IPv6
13.2.3.10. RFC4891 - Using IPsec to Secure IPv6-in-IPv4 Tunnels
13.2.4. Cada Firewall deve possuir no mínimo 8 (oito) interfaces de redes distintas sendo, no mínimo 06 (seis) com velocidade de 10/100/1000 Mbps, autosense, compatíveis com os padrões IEEE 802.3i, IEEE 802.3u e IEEE 802.3ab e 02 (duas) interfaces com velocidade de 10 Gbps, autosense, compatíveis com o padrão XFP.
13.2.5. Permitir a criação de, no mínimo, 1000 (mil) VLANs, padrão IEEE 802.1Q, definindo interfaces virtuais por identificadores de VLAN (VLAN ID tag). As interfaces virtuais devem permitir as mesmas funcionalidades das interfaces físicas, incluindo designação de zona de segurança, servidores DHCP, NAT, VPN e regras de controle de acesso.
13.2.6. Deve possuir licenças e recursos de hardware, dimensionados para permitir a configuração de, no mínimo, 10 firewalls virtuais, possibilitando o gerenciamento de interfaces, VLAN, zonas, regras, rotas e VPN, de forma individualizada para cada firewalll.
13.2.7. Possuir performance de firewall Stateful Inspection de, no mínimo, 10 Gbps, operando tanto em IPv4 como em IPv6.
13.2.8. Possuir suporte a número ilimitado de endereços IP nas redes internas.
13.2.9. Permitir a implementação de no mínimo 40.000 policies.
13.2.10. Possuir capacidade para um mínimo de 1.500.000 conexões TCP/IP concorrentes e simultâneas.
13.2.11. Possuir capacidade para um mínimo de 150.000 novas sessões por segundo.
13.2.12. Possuir capacidade para um mínimo de 2.000.000 de pacotes (64 bytes) por segundo.
13.2.13. Deverá permitir a configuração dos seguintes modos de operação: transparent mode, NAT mode e routing mode.
13.2.14. Permitir a criação de túneis VPN (Virtual Private Network) Site to Site e Client to Site sob o protocolo IPSec. Deverão ser inclusas gratuitamente no mínimo 500 licenças para VPN Client to Site e 200 licenças Site to Site. Deverá ser fornecido software cliente VPN IPSec, do mesmo fabricante, compatível com o modelo ofertado e compatível com sistema operacional Windows XP, Windows 7, Windows 8 ou superior.
13.2.15. Possuir performance de VPN IPsec, por appliance, de no mínimo 3 Gbps (throughput) bidirecional.
13.2.15.1. Os equipamentos deverão estar em conformidade com as RFCs: 6379, 5996, 5998, 6989.
13.2.15.2. Implementar "Suite-B-GCM-256" e "Suite-B-GCM-128" conforme descrito no RFC 6379 e todos os RFCs por ele referenciados.
13.2.15.3. Suporte a IKEv2 com PFS (perfect forward secrecy), conforme RFC 5996.
13.2.15.4. Implementar RFC 6311 (IKEv2 secure HA clustering).
13.2.16. Deverá fornecer funcionalidade de VPN SSL (incluir licença para no mínimo 1.500 (um mil e quinhentos) usuários).
13.2.17. Implementar recurso de NAT (network address translation) do tipo um-para-um (one-to-one), muitos-para-um (many-to-one) e muitos-para-muitos (many-to-many) e tradução simultânea de endereço IP e porta TCP de conexão (NAPT).
13.2.18. Possuir suporte a NAT simétrico.
13.2.19. Suportar NAT em todas as interfaces.
13.2.20. Deverá possuir a função de TOLERANCIA A FALHAS (Alta Disponibilidade), nos modos Ativo/Passivo e/ou Ativo/Ativo, com todas as licenças de software habilitadas para tal, de forma a garantir que, se um dos firewalls parar de funcionar, o outro deverá assumir automaticamente, suportando todo o tráfego e processamento.
13.2.21. Possibilitar o acesso via protocolo HTTP e/ou HTTPS, inclusive via interface WAN, para a configuração e administração remota, com total capacidade de administração sobre o sistema, utilizando somente navegadores WEB (Internet Explorer, Firefox, Opera, Chrome etc), sem a necessidade de instalação ou utilização de módulos de extensão (plug-ins, add-ons, applets Java etc) ou outros componentes.
13.2.22. Suportar protocolo NTP para sincronismo de relógio do equipamento.
13.2.23. Suportar o protocolo SNMP, para checagem de status e TRAP para envio e notificação de alarmes.
13.2.24. Deve possuir suporte completo a protocolos de roteamento (rotas estáticas e dinâmicas – OSPF e BGP).
13.2.25. Permitir a definição de rotas de tráfego baseadas em regras definidas por: port de serviço (TCP/UDP), endereço IP de origem ou destino e interface de saída.
13.2.26. Possibilitar a especificação de política por tempo, ou seja, permitir a definição de regras para determinado horário ou período (dia da semana e hora).
13.2.27. Deve possuir fonte de alimentação redundante operando nas tensões 110/220 V, com seleção automática de voltagem e freqüência de 50/60 Hz.
13.2.28. A quantidade de firewalls para atender esta demanda não poderá ser superior a 2 (dois) equipamentos.
13.2.29. Possuir estatística de utilização de CPU e memória do firewall.
13.2.30. Possibilitar a criação de entradas ARP estáticas para fixação de endereço IP com um número MAC específico.
13.2.31. Deverá permitir backup remoto de configuração.
13.2.32. Possuir função de DHCP Server e Client interno.
13.2.33. Capacidade de enviar e armazenar logs em um servidor remoto via protocolo syslog.
13.2.34. O Firewall não deve possuir nenhum dispositivo de hardware ou software que permita acesso remoto não autorizado, que comprometa o funcionamento do gerador de números aleatórios, que exponha material secreto (como chaves privadas), ou que de alguma forma reduza a segurança ou a privacidade de conexões cifradas.
13.2.35. O Firewall não deve, sob nenhuma hipótese, utilizar gerador de números aleatórios baseado apenas em funções matemáticas e processos determinísticos, sendo obrigatória a utilização de gerador de números aleatórios constantemente ou periodicamente realimentado por processos físicos inerentemente não determinísticos, devidamente submetidos a processo de debiasing e whitening.
13.2.36. O Firewall não deve, sob nenhuma hipótese, utilizar o gerador de números aleatórios Dual_EC_DRBG (NIST SP 800-90).
13.2.37. Deverá possuir função de debug on-line, com pesquisa por endereço IP (origem/destino) identificando no mínimo, informações do cabeçalho, porta e protocolo do pacote capturado.
13.2.38. Deverá ser fornecida a versão mais recente para todos os hardwares e softwares internos dos equipamentos.
ANEXO VI
LOTE 3
14. IDS/IPS 5 Gbps
14.1.1. Aquisição de solução de segurança do tipo IDS (Intrusion Detection System), IPS (Intrusion Prevention System), com troughput mínimo de 5 Gbps.
14.1.2. A solução de IDS/IPS poderá ser fornecida em appliance dedicado ou acoplado ao firewall. Porém, a segunda opção ao ser ativada não pode afetar a performance do firewall.
14.1.3. Deverá operar com os protocolos IPv4 e IPv6 simultaneamente. O desempenho deverá ser semelhante para ambos os protocolos em termos de entrada, saída e rendimento do fluxo de dados, transmissão e processamento de pacotes.
14.1.4. O suporte ao protocolo IPv6 deverá ser evidenciado e comprovado através da certificação IPv6 Ready Logo.
14.1.5. Os equipamentos que não foram submetidos aos procedimentos de teste do programa IPv6 Ready, deverão estar em conformidade com as RFCs listadas abaixo:
14.1.5.1. RFC2460 - Internet Protocol, Version 6 (IPv6) Specification
14.1.5.2. RFC4291 - IP Version 6 Addressing Architecture
14.1.5.3. RFC3484 - Default Address Selection for Internet Protocol version 6 (IPv6)
14.1.5.4. RFC4443 - Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification
14.1.5.5. RFC4862 - IPv6 Stateless Address Autoconfiguration
14.1.5.6. RFC1981 - Path MTU Discovery for IP version 6
14.1.5.7. RFC4861 - Neighbor Discovery for IP version 6 (IPv6)
14.1.5.8. RFC4213 - Basic Transition Mechanisms for IPv6 Hosts and Routers
14.1.5.9. RFC4301, RFC4303, RFC4302, RFC5996 – IPSEC/IKEv2 IPv6
14.1.5.10. RFC4891 - Using IPsec to Secure IPv6-in-IPv4 Tunnels
14.1.6. Possuir recurso capaz de detectar e evitar automaticamente (no mínimo), IP Source Spoofing, IP Source Routing, Tunel IPsec e ataques tipo DoS (Denial-of-Service) como Ping of Death, SYN Flood, LAND Attack, IP Spoofing, com a possibilidade de atualização automaticamente e carregamento das novas assinaturas sem interrupção, através da atualização do software de sistema operacional da solução.
14.1.7. Permitir a aplicação de políticas por subrede, endereço IP ou porta.
14.1.8. Possibilidade de criação/alteração de assinaturas pelo administrador.
14.1.9. Inspeção, no mínimo, dos seguintes protocolos: IP, TCP, UDP, ICMP, ARP, 802.1Q, IGMP,GRE.
14.1.10. Inspeção, no mínimo, dos seguintes protocolos de aplicação: HTTP, FTP, DHCP, DNS, FINGER, IMAP, SMTP, SNMP, SOCKS, SQL, SSH, TELNET, TFTP, H.323, LDAP, WINS, MSSQL, IRC.
14.1.11. Deverá ser fornecida ferramenta para gerenciamento centralizado da solução de IDS/IPS, instalados na CONTRATANTE, para geração de relatórios, com funções de análise de logs para emissão de alertas de eventos, via console de gerenciamento e email.
14.1.12. A solução de IPS/IDS deverá disponibilizar ferramenta para correlação de eventos com filtragem de logs e envio de mensagens de maneira automática.
14.1.13. Caso a solução de IDS/IPS seja acoplada ao Firewall, a quantidade de portas necessárias devem ser seguidas de acordo com a especificação do firewall. Caso contrário, cada IDS/IPS deve possuir no mínimo 4 (quatro) interfaces de redes distintas com velocidade de 10/100/1000 Mbps, autosense, compatíveis com os padrões IEEE 802.3i, IEEE 802.3u e IEEE 802.3ab.
14.1.14. Deverá possuir a função de TOLERANCIA A FALHAS (Alta Disponibilidade), nos modos Ativo/Passivo e/ou Ativo/Ativo, com as licenças de software habilitadas para tal, de forma a garantir que, se um dos IDS/IPS parar de funcionar, o outro deverá assumir automaticamente, suportando todo o tráfego e processamento.
14.1.15. Deverá possuir interface de configuração através de acesso via SSH e/ou Telnet, http e/ou https.
14.1.15.1. O acesso via protocolo HTTP e/ou HTTPS para a configuração e administração remota, deverá prover total capacidade de administração sobre o sistema, utilizando somente navegadores WEB (Internet Explorer, Firefox, Opera, Chrome etc), sem a necessidade de instalação ou utilização de módulos de extensão (plug-ins, add-ons, applets Java etc) ou outros componentes.
14.1.16. Suportar autenticação de usuários via RADIUS.
14.1.17. Suportar protocolo NTP para sincronismo de relógio do equipamento.
14.1.18. Suportar o protocolo SNMP, para checagem de status e TRAP para envio e notificação de alarmes.
14.1.19. Deve possuir fonte de alimentação redundante operando nas tensões 110/220 V, com seleção automática de voltagem e freqüência de 50/60 Hz.
14.1.20. Caso a solução de IDS/IPS seja ofertada em appliance, a quantidade para atender esta demanda não poderá ser superior a 2 (dois) equipamentos.
14.1.21. Possuir estatística de utilização de CPU e memória do IDS/IPS.
14.1.22. Capacidade de enviar e armazenar logs em um servidor remoto via protocolo syslog.
14.1.23. Deverá possuir função de debug on-line identificando no mínimo, informações do cabeçalho, IP, porta e protocolo do pacote capturado.
14.1.24. Possuir mecanismo de atualização automática das assinaturas.
14.1.25. Deverá ser fornecida a versão mais recente para todos os hardwares e softwares internos dos equipamentos.
ANEXO VII
LOTE 3
15. PROXY/CACHING
A solução ofertada deve permitir as seguintes funcionalidades:
15.1.1. solução de Proxy/Caching poderá ser fornecida em appliance dedicado ou acoplado ao filtro de conteúdo. Porém, a segunda opção ao ser ativada não pode afetar a performance do filtro de conteúdo.
15.1.2. Serviço Proxy/Caching deverá ser compatível com qualquer browser e sistema operacional.
15.1.3. Possuir a funcionalidade de Proxy Web e suportar os protocolos HTTP, HTTPS e FTP.
15.1.4. Suportar active/passive mode e FTP over http.
15.1.5. Deverá permitir a configuração das portas usadas para cada um dos protocolos suportados.
15.1.6. Possuir a capacidade de utilizar o proxy com o método CONNECT para portas.
15.1.7. O equipamento deve permitir requisições dos clientes da rede interna em uma interface de rede e a comunicação com a Internet em outra interface, possibilitando usar um endereço IP privado na interface de rede interna e um IP público na interface de rede externa.
15.1.8. A solução deve suportar no mínimo 90.000 usuários simultâneos.
15.1.9. Deve permitir o armazenamento em Cache de conteúdo de streaming de vídeo e áudio trafegados pelo protocolo HTTP.
15.1.10. Deve permitir o armazenamento em Cache de páginas Web.
15.1.11. Possuir a funcionalidade de eliminar o conteúdo do Cache (limpar o Cache).
15.1.12. Possuir sistema de arquivos que armazene o conteúdo de cada página em setores contíguos do disco para otimizar o acesso aos objetos armazenados.
15.1.13. Cache seguro com varredura completa a cada atualização de vacinas.
15.1.14. Capacidade de criar listas de um ou mais domínios que não deverão ser armazenados em Cache.
15.1.15. Possuir espaço em cache para no mínimo 100GB.
15.1.16. Deverá ser fornecida a versão mais recente para todos os hardwares e softwares internos dos equipamentos.
ANEXO VIII
16. FILTRO DE CONTEÚDO E GATEWAY ANTIMALWARE
A solução de filtro de conteúdo web e gateway de malware deverá ser baseada em appliance para atender a uma demanda inicial estimada em 90.000 usuários simultâneos. A solução deve ser escalável, permitindo crescimento futuro mediante a aquisição de novos equipamentos e/ou licenças. A solução ofertada deve permitir as seguintes funcionalidades:
16.1.1. A solução de Filtro de Conteúdo web e gateway de malware deverá ser fornecida em appliance dedicado.
16.1.2. Cada equipamento componente da solução deverá possuir, no mínimo, 4 interfaces de 1Gbps, com suporte a agregação de interfaces.
16.1.3. A solução deve possuir um throughput mínimo de 1 Gbps.
16.1.4. A solução deve funcionar nativamente com os protocolos IPv4 e IPv6.
16.1.5. A solução deve suportar, no mínimo, 90.000 usuários simultâneos.
16.1.6. A solução deve possuir capacidade de suportar, no mínimo, 1.000.000 de requisições HTTP por segundo.
16.1.7. A solução deve possuir mecanismos para garantir a alta disponibilidade e alta performance para o serviço de filtragem de conteúdo do tráfego Web e gateway de malware através da utilização de equipamentos em cluster, onde cluster está sendo definido como dois ou mais equipamentos trabalhando em conjunto e visíveis como um ponto único no ambiente. A solução deverá ser implantada de maneira que a retirada de algum equipamento do cluster não afete a sua disponibilidade, mesmo que sua capacidade de tratamento do tráfego web seja reduzida até o restabelecimento do equipamento retirado. Deverão ser respeitados os níveis de serviço definidos anteriormente.
16.1.8. A quantidade máxima disposta na solução não deverá ultrapassar o número de 8 (oito) equipamentos.
16.1.9. A solução deve permitir o modo de operação by-pass na qual, em caso de falha ou indisponibilidade, o conjunto deverá deixar passar qualquer tráfego.
16.1.10. Deve possuir uma base de filtro de conteúdo com, no mínimo, 65 categorias pré- definidas.
16.1.11. Deve possuir capacidade para bloqueio de conteúdos que contenham, no mínimo, as seguintes categorias:
16.1.11.1. Sites de conteúdos de pedofilia.
16.1.11.2. Sites de proxies avoidance, ou seja, que fornecem recursos para contornar o servidor proxy corporativo, obtendo acesso à web sem passar pelo controle do filtro de conteúdo.
16.1.11.3. Sites com compartilhamento de conteúdos.
16.1.11.4. Site de bate-papo (chat) e fóruns on-line.
16.1.11.5. Sites de relacionamento.
16.1.11.6. Sites de pornografia (conteúdo adulto e erótico).
16.1.11.7. Sites de webmails.
16.1.11.8. Sites de download e peer-to-peer (P2P).
16.1.11.9. Sites de streaming (audio e video on-line). 16.1.11.10. Sites de jogos.
16.1.11.11. Sites de hacking. 16.1.11.12. Sites de conteúdo racial 16.1.11.13. Sites de apologia a drogas 16.1.11.14. Sites de apologia à violência 16.1.11.15. Sites de armas.
16.1.12. A solução deve possuir a funcionalidade de “IP Spoofing”, possibilitando encaminhar o endereço IP do cliente que solicitou a requisição, e não o da solução.
16.1.13. A base de dados do filtro de conteúdo deve ser atualizada pelo sistema, de maneira automática, através de downloads incrementais disponibilizados pelo fornecedor da solução. A solução deverá permitir a customização, pelo administrador, deste processo de atualização.
16.1.14. Toda política criada ou modificada deverá ser aplicada em todos os equipamentos da solução (cluster) automaticamente.
16.1.15. A solução deve garantir que, além das atualizações pré-programadas, novas páginas sejam adicionadas automaticamente à lista de URLs (categorização) imediatamente após suas descobertas pelo fabricante da solução, sem necessidade de haver interação humana ou aguardar pelo horário pré-determinado.
16.1.16. Deve permitir a criação de, no mínimo, 100 categorias extras customizadas, baseadas no mínimo em:
16.1.16.1. endereço IP do servidor.
16.1.16.2. sub-rede.
16.1.16.3. domínio.
16.1.16.4. expressões regulares nas URLs.
16.1.17. A solução deve permitir a recategorização de URLs pelo administrador.
16.1.18. O sistema deve reconhecer automaticamente URLs não cadastradas e possibilitar o envio ao fabricante para a devida categorização automaticamente, recurso que poderá ser ativado ou não pelo administrador, sem custo adicional.
16.1.19. A solução deve oferecer recursos de análise de sites duvidosos por reputação.
16.1.20. A solução deve realizar filtragem do tráfego web criptografado baseado na categoria do site de destino e/ou baseado na reputação do site de destino, além do status do certificado fornecido pelo site de destino (ex. sites com certificados expirados ou assinados por uma CA não confiável sempre serão descriptografados). Esta funcionalidade também deverá ser customizável para que tal filtragem seja aplicada apenas em categorias determinadas pelo administrador.
16.1.21. O conteúdo descriptografado deve ser inspecionado pelo filtro de URL.
16.1.22. A solução deve permitir que se incluam URLs ou Expressões Regulares manualmente, para que determinadas páginas sejam tratadas diferentemente da categorização original do fabricante da solução.
16.1.23. A solução deve possuir mecanismo de bloqueio através de palavras-chave.
16.1.24. A solução deve permitir a personalização da página de bloqueio a ser exibida para os usuários. A solução deve possuir a funcionalidade de apresentar esta pagina no idioma Português.
16.1.25. A solução deve permitir a aplicação das seguintes políticas para cada categoria: permitir o acesso livremente, bloquear o acesso incondicionalmente, permitir o acesso com o monitoramento, permitir o acesso após a exibição de tela de advertência.
16.1.26. A solução deve verificar os diversos tipos de conteúdo que podem estar contidos em uma página web ou portal de rede social, como chat, postagens, status de usuário, comentários, perguntas, downloads e uploads, eventos, jogos, aplicativos, compartilhamentos, links e conteúdo do tipo “embedded URLs” (conteúdo proveniente de diferentes urls inseridas em determinada página web principal), aplicando sobre este conteúdo as regras de classificação e filtragem.
16.1.27. A solução deve verificar conteúdo do tipo arquivo (tais como streaming de vídeo e/ou áudio – educativo, informativo, entretenimento, nudez. arquivos compactados. arquivos executáveis, documentos, etc.) embutido nas páginas web, aplicando sobre este conteúdo as regras de classificação e filtragem.
16.1.28. A solução deve permitir o bloqueio de páginas que contenham, no mínimo, os seguintes códigos: ActiveX, JavaScript e VBScript.
16.1.29. A solução deve ser capaz de analisar em tempo real o conteúdo dinâmico de um site e efetuar a recategorização automática, caso seu conteúdo seja modificado. Ela deve garantir que, dentro do conteúdo misto e dinâmico, as políticas de uso da internet sejam mantidas.
16.1.30. A solução deve possuir interface de gerência via Web e linha de comando.
16.1.31. Para todo e qualquer acesso web, o sistema deve gravar log, onde conste no mínimo: data do acesso (no formato dd/mm/aaaa), horário do acesso (no formato hh:mm:ss), endereço IP do equipamento (origem), usuário, URL de destino da requisição (site visitado), Domínio, categoria do site, tamanho do objeto solicitado (em bytes), ação tomada pelo sistema (bloqueado, permitido, etc).
16.1.32. A solução deverá permitir a exportação automática do log gerado, em intervalos de tempo pré-definidos e em formato que possa ser lido por outra aplicação, possibilitando seu armazenamento e consulta de forma independente da solução. A periodicidade da exportação do log deverá ser configurada pelo administrador da solução e deverá contemplar todo o log gerado desde a última exportação.
16.1.33. A solução de filtro de conteúdo web deve permitir geração de relatórios baseados nos logs, com gráficos, resumos e relatórios detalhados dos acessos de maneira geral, por usuário, grupo, endereço IP, intervalo de endereços IPs ou intervalo de tempo, com data e horário (no formato dd/mm/aaaa hh:mm:ss). A ferramenta deverá fornecer modelos pré-definidos de relatórios, permitindo ainda a customização destes (alteração de cabeçalho, inclusão ou exclusão de campos).
16.1.33.1. Os relatórios devem ser gerados, no mínimo, nos seguintes formatos: html, pdf e xls ou csv.
16.1.33.2. A solução deverá possuir, no mínimo, os seguintes relatórios gerenciais:
16.1.33.3. visão geral da situação de funcionamento do sistema.
16.1.33.4. detalhes do consumo de banda por usuário, endereço IP e rede.
16.1.33.5. categorias e sites mais visitados.
16.1.33.6. atividades do usuário com informações detalhadas e sumarizadas.
16.1.33.7. sites bloqueados por apresentarem riscos de segurança.
16.1.33.8. protocolos, categorias, sites, grupos, usuários, endereço IP e redes mais bloqueados.
16.1.33.9. principais sites e categorias mais visitadas por tempo de acesso.
16.1.33.10. principais sites e categorias mais visitadas por quantidade de acesso e volume de dados acessados.
16.1.33.11. principais grupos, usuários, endereços IP e redes que mais acessaram a internet por tempo de acesso.
16.1.33.12. grupos, usuários, endereços IP e redes que mais acessaram a internet, por volume de dados.
16.1.33.13. consumo de banda por categoria, site, protocolo, grupo, usuário, endereço IP e rede.
16.1.33.14. A solução deverá permitir a programação de geração automática de relatórios com base diária, semanal, mensal ou em intervalos de tempos configuráveis (data e horário, no formato dd/mm/aaaa hh:mm:ss)
16.1.33.15. A solução deverá permitir a distribuição dos relatórios gerados através de email para os destinatários especificados em cada conjunto de relatórios.
16.1.34. Deve possuir pelo menos três classes de usuários, sendo elas administrador (com permissão de alterar configurações, gerenciar usuários e atualizar sistema operacional), operador (com permissão de alterar configurações) e convidado (somente acessar informações de relatório e status do equipamento).
16.1.35. A solução deverá permitir delegação de geração de relatórios, através de logins criados para administradores de grupos, onde as informações acessadas se limitem ao grupo configurado. Desta forma, gestores de áreas poderão acessar informações de suas respectivas equipes a qualquer momento, através pelo browser.
16.1.36. Deve ser capaz de criar lista de destinos que poderão pular as regras de proxy e políticas baseadas no mínimo em:
16.1.36.1. Endereço IP.
16.1.36.2. CIDR.
16.1.36.3. Domínio.
16.1.36.4. Hostname completo ou parte.
16.1.37. Deverá criar e hospedar arquivos PAC (Proxy Auto Configuration) e WPAD (Web Proxy Auto Discovery).
16.1.38. Possuir a capacidade de atuar como proxy explícito e transparente através do redirecionamento de conexões utilizando WCCP v2.
16.1.39. Possuir integração com serviços de diretório LDAP e domínios Windows 2003, 2012 ou superior, para auditoria e autenticação sem a necessidade de instalação de agentes ou plugins em nenhuma estação de trabalho ou servidor.
16.1.40. A solução deverá fazer a autenticação do usuário via NTLM de modo transparente, ou seja, utilizando usuário já autenticado em domínio Windows sem pedir novamente a senha para o usuário.
16.1.41. O equipamento deve pedir autenticação (login, senha e domínio) para usuários que estejam utilizando sistemas operacionais diferentes do Windows, validando estes usuários no serviço de diretórios Microsoft Active Directory 2003, 2012 ou superior e LDAP.
16.1.42. Autenticação de usuários e estações de trabalho sem a necessidade de instalação e/ou execução de clientes ou quaisquer módulos em nenhuma estação de trabalho e/ou servidor.
16.1.43. Deve possuir integração total com Microsoft Active Directory 2003, 2012 ou superior, para autenticação e importação de usuários e grupos, sem a necessidade de instalação e/ou execução de clientes ou quaisquer módulos nas estações de trabalho dos usuários ou nos servidores.
16.1.44. Deve permitir a criação de políticas usando, no mínimo, os seguintes critérios:
16.1.44.1. Grupos do domínio ou serviço de diretórios LDAP e AD aos quais o usuário pertence.
16.1.44.2. Classificação das páginas (categorias de URLs).
16.1.44.3. Tipos de arquivo.
16.1.44.4. Porta do serviço de proxy a que o usuário conectou.
16.1.44.5. Reputação do site de destino.
16.1.44.6. Listas de URLs cadastradas.
16.1.44.7. Base de URLs com contratação de atualizações com o fornecedor.
16.1.44.8. Tipo de conteúdo.
16.1.44.9. Tamanho do download. 16.1.44.10. Endereço IP. 16.1.44.11. User Agents.
16.1.45. Deverá permitir políticas baseadas em tempo ( dias da semana, hora do dia) afim de restringir acesso em horários pré estipulados (ex. horário comercial).
16.1.46. Deverá prover solução de gateway de antimalware, contendo, no mínimo, 200 mil assinaturas de malware com atualização automática.
16.1.47. A solução deve implementar simultaneamente múltiplas ferramentas de filtragens e proteção contra malware (no mínimo duas) e de fabricantes diferentes.
16.1.48. A solução deverá realizar verificação em busca de código malicioso em tempo real, para todos os conteúdos acessados.
16.1.49. A solução deverá realizar a verificação de malware nos dois sentidos (download e upload).
16.1.50. A solução deve efetuar todas as verificações de malware simultaneamente para cada objeto do site, em tempo real, e não seqüencialmente, para minimizar a latência.
16.1.51. O mecanismo de verificação de malware deve reconhecer códigos maliciosos pelo menos nas seguintes categorias:
16.1.51.1. Adware.
16.1.51.2. Phishing.
16.1.51.3. Tracking cookies.
16.1.51.4. Session hijackers.
16.1.51.5. Rootkits.
16.1.51.6. Keyloggers.
16.1.51.7. Vírus
16.1.52. A verificação de segurança em tempo real deve conseguir detectar e bloquear o código malicioso dentro de aplicações ricas (RIA - Rich Internet Applications), como as desenvolvidas em Adobe Flash, Microsoft Silverlight, Java, AJAX etc.
16.1.53. A solução deve permitir o armazenamento do resultado das verificações de malware em cache, visando minimizar a latência.
16.1.54. Deve possuir mecanismo de verificação de tráfego na camada 4 do modelo OSI, permitindo identificar estações de trabalho infectadas por malwares na rede interna do cliente, com as seguintes características:
16.1.54.1. A monitoração de tráfego na camada 4 deve examinar o tráfego em todas as 65.535 portas do protocolo TCP.
16.1.54.2. A verificação de tráfego na camada 4 deve ser capaz de apenas monitorar ou monitorar e bloquear o tráfego suspeito.
16.1.55. Deve possuir a funcionalidade de IP Spoofing (possibilitar encaminhar o endereço IP do cliente, e não do próprio proxy).
16.1.56. Deverá suportar o protocolo ICAP para integração com outras soluções da rede, como por exemplo DLP (Data Loss Prevention).
16.1.57. A solução deverá ser compatível com SNMP Traps.
16.1.58. O equipamento (hardware) fornecido para a solução deverá atender aos requisitos abaixo descritos:
16.1.58.1. O equipamento ofertado deverá trabalhar na freqüência de 60Hz nas seguintes faixas de tensão: 127V AC entre fase e neutro ou 220V AC entre duas fases.
16.1.58.2. Temperatura (faixa de operação): 16º a 32º C.
16.1.58.3. Todos os equipamentos e componentes ofertados deverão ser novos, sem uso anterior, não remanufaturados ou recondicionados e estar na linha de produção atual do fabricante.
16.1.58.4. Deve possuir fonte de alimentação redundante operando nas tensões 110/220 V, com seleção automática de voltagem e freqüência de 50/60 Hz.
16.1.58.5. Os conectores necessários para a alimentação elétrica dos equipamentos deverão ser fornecidos de acordo com os cabos de alimentação que acompanham os equipamentos.
16.1.59. É de responsabilidade da PROPONENTE o dimensionamento de todos os recursos adicionais de hardware e software necessários para instalação da solução nas dependências da CONTRATANTE.
16.1.60. Todos os requisitos e funcionalidades descritos nesta especificação devem ser fornecidos ativos e licenciados para uso imediato pela CONTRATANTE.
16.1.61. Deverá ser fornecida a versão mais recente para todos os hardwares e softwares internos dos equipamentos.
16.2. TREINAMENTO DE FIREWALL
16.2.1. O treinamento refere-se ao FIREWALL especificado no item 2.1 deste termo.
16.2.2. A CONTRATADA deverá prover treinamento para 10 (dez) empregados da PRODAM-SP (divididos em, no mínimo, 3 (três) turmas sendo duas turmas de 3 (três) empregados e uma turma de 4 (quatro) empregados, agendadas em datas distintas, a critério da Prodam).
16.2.2.1. Os treinamentos deverão ser ministrados dentro do município de São Paulo, caso contrário, a CONTRATADA deverá ser responsável pelo transporte, refeições e hospedagem pelo tempo que durar o treinamento.
16.2.2.2. A CONTRATADA poderá oferecer como opção, vagas individuais em seus treinamentos de turmas abertas, respeitando a disponibilidade da PRODAM-SP.
16.2.3. Não será aceito que os treinamentos sejam realizados em qualquer dependência da CONTRATANTE.
16.2.4. Os treinamentos deverão ser reconhecidos como oficiais pelos fabricantes dos equipamentos (constando em listas de cursos), com emissão de certificado de participação, incluindo teoria e prática em laboratório aprovado pelo fabricante.
16.3. TREINAMENTO IDS/IPS
16.3.1. O treinamento refere-se ao IDS/IPS especificado no item 2.2 deste termo.
16.3.2. A CONTRATADA deverá prover treinamento para 10 (dez) empregados da PRODAM-SP (divididos em, no mínimo, 3 (três) turmas sendo duas turmas de 3 (três) empregados e uma turma de 4 (quatro) empregados, agendadas em datas distintas, a critério da Prodam).
16.3.2.1. Os treinamentos deverão ser ministrados dentro do município de São Paulo, caso contrário, a CONTRATADA deverá ser responsável pelo transporte, refeições e hospedagem pelo tempo que durar o treinamento.
16.3.2.2. A CONTRATADA poderá oferecer como opção, vagas individuais em seus treinamentos de turmas abertas, respeitando a disponibilidade da PRODAM-SP.
16.3.3. Não será aceito que os treinamentos sejam realizados em qualquer dependência da CONTRATANTE.
16.3.4. Os treinamentos deverão ser reconhecidos como oficiais pelos fabricantes dos equipamentos (constando em listas de cursos), com emissão de certificado de participação, incluindo teoria e prática em laboratório aprovado pelo fabricante.
16.4. TREINAMENTO PROXY/CACHING
16.4.1. O treinamento refere-se ao PROXY/CACHING especificado no item 2.3 deste termo.
16.4.2. A CONTRATADA deverá prover treinamento para 10 (dez) empregados da PRODAM-SP (divididos em, no mínimo, 3 (três) turmas sendo duas turmas de 3 (três) empregados e uma turma de 4 (quatro) empregados, agendadas em datas distintas, a critério da Prodam).
16.4.2.1. Os treinamentos deverão ser ministrados dentro do município de São Paulo, caso contrário, a CONTRATADA deverá ser responsável pelo transporte, refeições e hospedagem pelo tempo que durar o treinamento.
16.4.2.2. A CONTRATADA poderá oferecer como opção, vagas individuais em seus treinamentos de turmas abertas, respeitando a disponibilidade da PRODAM-SP.
16.4.3. Não será aceito que os treinamentos sejam realizados em qualquer dependência da CONTRATANTE.
16.4.4. Os treinamentos deverão ser reconhecidos como oficiais pelos fabricantes dos equipamentos (constando em listas de cursos), com emissão de certificado de participação, incluindo teoria e prática em laboratório aprovado pelo fabricante.
16.5. TREINAMENTO FILTRO DE CONTEÚDO E GATEWAY ANTIMALWARE
16.5.1. O treinamento refere-se ao Filtro de Conteúdo especificado no item 2.4 deste termo.
16.5.2. A CONTRATADA deverá prover treinamento para 10 (dez) empregados da PRODAM-SP (divididos em, no mínimo, 3 (três) turmas sendo duas turmas de 3 (três) empregados e uma turma de 4 (quatro) empregados, agendadas em datas distintas, a critério da Prodam).
16.5.2.1. Os treinamentos deverão ser ministrados dentro do município de São Paulo, caso contrário, a CONTRATADA deverá ser responsável pelo transporte, refeições e hospedagem pelo tempo que durar o treinamento.
16.5.2.2. A CONTRATADA poderá oferecer como opção, vagas individuais em seus treinamentos de turmas abertas, respeitando a disponibilidade da PRODAM-SP.
16.5.3. Não será aceito que os treinamentos sejam realizados em qualquer dependência da CONTRATANTE.
16.5.4. Os treinamentos deverão ser reconhecidos como oficiais pelos fabricantes dos equipamentos (constando em listas de cursos), com emissão de certificado de participação, incluindo teoria e prática em laboratório aprovado pelo fabricante.
ANEXO IX
17. Firewall de Gerenciamento
17.1. A solução ofertada deverá ser em hardware independente, baseado na tecnologia Statefull Inspection, com licença de IDS/IPS, possuindo no mínimo:
17.2. 03 segmentos de redes distintas, para atender as funções de:
17.2.1. Segmento WAN, com 01 (uma) porta padrão, Ethernet, 10/100BaseTX – Auto- Sense.
17.2.2. Segmento LAN, com no mínimo 04 (quatro) portas padrão, Ethernet, Lan-Switch 10/100 BaseTX – Auto-Sense.
17.2.3. Segmento de LAN secundária ou DMZ com no mínimo 01 (uma) porta padrão, Ethernet, 10/100 BaseTX – Auto-Sense.
17.3. Possuir suporte a número ilimitado de endereços IP nas redes internas.
17.4. Permitir a implementação de no mínimo 1.000 (um mil) policies.
17.5. Possuir performance de firewall Statefull Inspection de no mínimo 100 (cem) Mbps de throughput.
17.6. Possuir recurso de IDS e IPS interno, capaz de detectar e evitar automaticamente (no mínimo), IP Source Spoofing, IP Source Routing, Tunel IPsec e ataques tipo DoS (Denial- of-Service) como Ping of Death, SYN Flood, LAND Attack, IP Spoofing, com a possibilidade de se atualizar as assinaturas e carregar as novas sem interrupção, através da atualização do software de sistema operacional do equipamento (appliance).
17.7. Deverá ser fornecida a versão mais recente para todos os softwares internos dos equipamentos.
17.8. Suporte a failover para permitir a redundância automática com o outro firewall idêntico a ser fornecido, nos modos ativo-ativo e ativo-standby
17.9. NAT (network address translation) do tipo um-para-um (one-to-one), um-para-muitos (one-to-many), muitos-para-um (many-to-one) e muitos-para-muitos (many-to-many).
17.10. Gerenciamento com interface amigável através de HTTPS ou por software de gerenciamento.
17.11. Permitir a análise e manipulação de arquivos syslog ou outro padrão proprietário, desde que este permita interação com outros aplicativos de correlação de eventos.
17.12. Capacidade de back-up / export da configuração completa do firewall.
17.13. Monitoração de processos em tempo real, ou seja, da utilização da unidade central de processamento (CPU) do firewall, com informação de valores correntes e totais.