Allegato G Fac simile Offerta Tecnica

Gara d’appalto per la fornitura degli apparati del backbone di alcune componenti del data center e dei PoP Anycast del Registro .it - CIG 5278144E34

Nei capitoli seguenti saranno riferiti:

Core-HD =

Core-LD =

Accesso-DC =

Accesso-ANYCAST =

Data: 09 agosto 2013

Sommario

1 Requisiti minimi generali 6

1.1 Unico produttore 6

1.2 Unico sistema operativo 7

1.3 Omogeneità apparati e hardware 7

1.4 Vincoli progettuali 8

1.4.1 Separazione dei piani di controllo e di inoltro 8

1.4.2 Architettura a forwarding distribuito (distributed forwarding) 9

1.4.3 Piattaforma non bloccante (wire speed o, equivalentemente, non-blocking) 10

1.4.4 Architettura modulare a chassis passivo 11

1.4.5 Architettura modulare a stack 11

1.4.6 Ridondanza componenti attive del sistema (no single point of failure system) 11

1.4.7 Line rate packet forwarding 12

1.4.8 Line rate packet processing 13

1.4.9 Carrier Class 14

1.4.10 Performance benchmarking 15

2 Nodi L3 Core-HD e Core-LD - Requisiti minimi 15

2.1 Sistema Operativo e Strumenti di Monitoraggio 15

2.1.1 Architettura OS 15

2.1.2 Amministrazione OS e configurazioni 16

2.1.3 Alta disponibilità 17

2.1.4 Monitoraggio e OA&M 18

2.2 Funzionalità layer1 & layer2 OSI 19

2.2.1 Synchronous Ethernet 19

2.2.2 Optical transceiver 20

2.2.3 802.1D-2004 - MAC Bridges 20

2.2.4 Bridge Domain 20

2.2.5 802.1AB 21

2.2.6 MTU e Protocols Encapsulation 21

2.2.7 Local Traffic Cross-Connect 22

2.2.8 Spanning Tree Protocols 22

2.2.9 802.1Q - Virtual LANs e CoS 22

2.2.10 802.1ad – Provider Bridges 23

2.2.11 Integrated Bridging and Routing (IRB) 24

2.2.12 802.1AX-2008 – Link Aggregation 24

2.3 Funzionalità di Routing IP 27

2.3.1 IPv4-IPv6 Router 27

2.3.6 Routing Multicast 32

2.3.7 Policy Routing 34

2.3.8 Network Address Translation 34

2.4 Funzionalità MPLS 35

2.4.1 MPLS 35

2.4.2 MPLS-TE (Traffic Engineering) 37

2.4.3 L3 VPN 39

2.4.4 L2 VPN e VPLS 41

2.4.5 MPLS multicast VPNs 43

2.5 Operations, Administration, and Maintenance (OAM) & Protection 44

2.5.1 Layer2: Ethernet 44

2.5.2 Layer3: IP 45

2.5.3 Transport Layer: MPLS 46

2.5.4 Traffic load balancing 49

2.6 Qualità del Servizio (QoS) 49

2.6.1 Packet filtering 49

2.6.2 Policing, Shaping & Scheduling 50

2.6.3 Gestione QoS su traffico MPLS 53

3 Nodi L2 (Accesso-DC e Accesso-Anycast) – Requisiti minimi 54

3.1 Funzionalità di stacking 54

3.1.1 Modularità stack 54

3.1.2 Flessibilità stack 55

3.1.3 Connettività Stack 55

3.1.4 Forwarding Distribuito Stack 55

3.2 Sistema Operativo e Strumenti di Monitoraggio 56

3.2.1 Architettura OS 56

3.2.2 Amministrazione OS e configurazioni 57

3.2.3 Alta disponibilità 57

3.2.4 Monitoraggio e OA&M 58

3.3 Funzionalità layer2 OSI 59

3.3.1 802.1D-2004 - MAC Bridges 59

3.3.2 802.1AB 59

3.3.3 MTU 60

3.3.4 Spanning Tree Protocols 60

3.3.5 802.1Q - Virtual LANs e CoS 60

3.3.6 802.1ad – Provider Bridges 61

3.3.7 802.1AX-2008 – Link Aggregation 61

3.3.8 Power over Ethernet 62

3.3.9 Port authentication 62

3.4 Funzionalità di Routing IP 64

3.4.7 Routing Multicast 67

3.4.8 VRF lite 68

3.4.9 Funzionalità IPv6 68

3.5 OAM, protection & security 69

3.5.1 Layer2: Ethernet 69

3.5.2 Layer3: IP 70

3.6 Qualità del Servizio (QoS) 71

3.6.1 Packet filtering 71

3.6.2 Policing, Shaping & Scheduling 72

4 Architettura e dotazione hardware – Requisiti minimi 74

4.1 Categoria L3 (4 + 7 router IP/MPLS) 74

4.1.1 Quantità 75

4.1.2 Definizioni relative agli apparati di tipologia Core-HD e Core-LD 75

4.2 Categoria L2 (2 + 6 multilayer switch) 87

4.2.1 Quantità 87

4.2.2 Apparati di tipologia Accesso-DC (2 multilayer switch) 87

4.2.3 Apparati di tipologia Accesso-Anycast (6 multilayer switch) 93

4.2.4 Requisiti di compatibilità ottiche 98

5 Servizio di assistenza specialistica e manutenzione – Requisiti minimi 99

5.1 Definizioni 100

5.2 Caratteristiche del servizio 101

5.2.1 Registrazione codici prodotto 101

5.2.2 Knowledge base & software 102

5.2.3 Trouble ticket system 103

5.2.4 Apertura ticket 104

5.2.5 Emissione codice RMA 105

5.3 Livelli di servizio 105

5.3.1 Servizio Gold 106

5.3.2 Servizio Standard 106

5.4 Formazione e training 106

6 Requisiti migliorativi 109

6.1 Metodo di valutazione 109

6.2 Criteri di valutazione 110

7 Sistema operativo e monitoraggio - Requisiti migliorativi (punti 16) 110

7.1 Sistema operativo (punti 11) 110

7.1.1 Apparati tipologie Core-HD, Core-LD, Accesso-DC e Accesso-Anycast. 110

7.1.2 Apparati tipologia Core-HD e Core-LD 111

7.2 Strumenti di monitoraggio (punti 5) 112

7.2.1 Apparati tipologia Core-HD e Core-LD 112

7.2.2 Apparati tipologia Accesso-DC e Accesso-Anycast 113

8 MPLS - Requisiti migliorativi (punti 18) 115

8.1 Apparati tipologia L3 (Core-HD e Core-LD) 115

8.1.1 Servizi MPLS (punti 15) 115

8.1.2 Gestione traffico multicast in ambienti MPLS (punti 3) 124

9 Alta disponibilità - Requisiti migliorativi (punti 12) 125

9.1 Apparati tipologia L3 (Core-HD e Core-LD) (punti 8) 125

9.1.1 Fault tolerance: mantenimento del piano di controllo (Core-HD) 125

9.1.2 Alta disponibilità layer2 126

9.1.3 Fault tolerance & restoration 127

9.1.4 Strumenti di OA&M 129

9.2 Apparati tipologia Accesso-DC e Accesso-Anycast (punti 4) 129

9.2.1 Fault tolerance: mantenimento del piano di controllo 129

9.2.2 In Service Software Upgrade 130

9.2.3 Alta disponibilità layer2 131

9.2.4 Traffic load balancing 132

9.2.5 Strumenti di OA&M 133

10 Qualità del Servizio (QoS) e Filtering - Requisiti migliorativi (punti 6) 133

10.1 Apparati tipologia Core-HD e Core-LD (punti 4) 133

10.1.1 Route filtering 133

10.1.2 Azioni effettuabili dall’access list dopo un eventuale match 134

10.1.3 Quality of Service – Hardware, Policing, Shaping & Scheduling 135

10.1.4 Gestione QoS su traffico MPLS 136

10.2 Apparati tipologia Accesso-DC e Accesso-Anycast (punti 2) 137

10.2.1 Route filtering 137

10.2.2 Packet filtering 137

10.2.3 Policing & Scheduling 138

11 Performance - Requisiti migliorativi (punti 16) 139

11.1 Apparati tipologia Core-HD e Core-LD (punti 12) 139

11.1.1 Performance hardware di forwarding 139

11.1.2 Caratteristiche fisiche 140

11.1.3 Prestazioni globali apparati 141

11.1.4 L3 tunneling 142

11.1.5 Performance traffico layer2 e IP 142

11.1.6 Performance MPLS 143

11.2 Apparati tipologia Accesso-DC e Accesso Anycast (punti 4) 143

Apparati tipologia Accesso-DC 143

11.2.1 143

11.2.2 Apparati tipologia Accesso-Anycast 145

12 Servizio di assistenza specialistica e manutenzione - Requisiti migliorativi (punti 2) 147

12.1 Apparati tipologie L2 e L3 147

12.1.1 Technical escalation e supporto evoluto 147

12.1.2 Technical Assistance Center 148

1Requisiti minimi generali

Per ogni requisito richiesto si specifichi puntualmente e in modo esauriente l’implementazione utilizzata per operare le funzionalità richieste. Si indichino inoltre i riferimenti alle pagine della documentazione tecnica ufficiale del produttore degli apparati allegata.

Lo schema e le definizioni utilizzate nel presente documento sono le medesime utilizzate nel Capitolato Speciale di Appalto e Allegati.

1.1Unico produttore

Gli apparati oggetto della fornitura dovranno essere realizzati da un unico produttore e tutte le parti hardware e software della fornitura devono comparire nel listino del produttore senza nessun avviso di uscita di produzione o di termine di manutenzione o supporto specialistico.

Specifiche:

__________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

1.2Unico sistema operativo

Tutti gli apparati Core-HD e Core-LD dovranno essere dotati di stesso sistema operativo e utilizzare la stessa versione e revisione dello stesso.

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

Tutti gli apparati Accesso-DC e Accesso-Anycast dovranno essere dotati di stesso sistema operativo e utilizzare la stessa versione e revisione dello stesso.

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

1.3Omogeneità apparati e hardware

Gli apparati L3 (Nodi L3), all'interno del portafoglio del produttore, dovranno appartenere alla stessa linea/serie di prodotti.

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

Le tipologie Core-HD dovranno prevedere, all'interno dello chassis, identico hardware mentre la tipologia Core-LD non richiedendo chassis passivo, dovrà condividere con le altre tipologie (Core-HD e Core-LD) i moduli adattatori di interfaccia.

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

Gli apparati Accesso-DC dovendo essere tra loro identici, soddisferanno intrinsecamente tale richiesta di omogeneità.

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

Gli apparati Accesso-Anycast, dovendo essere tra loro identici, soddisferanno intrinsecamente tale richiesta di omogeneità.

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

1.4Vincoli progettuali

1.4.1Separazione dei piani di controllo e di inoltro

Apparati Core-HD e Core-LD, Accesso-DC e Accesso-Anycast. La separazione dei piani di controllo e di inoltro permette l'ottimizzazione delle strutture dati, dei processori e delle componenti hardware e software nel complesso, in funzione delle prestazioni richieste (tipicamente relative a operazioni di aggiornamento e modifica, da parte del control plane, e operazioni time-critical, come “table lookup” e “multi-field classification packet processing”, da parte del forwarding plane).

Tale separazione, implicando il disaccoppiamento anche fisico delle parti hardware e software preposte alle due funzioni, garantisce inoltre che il deterioramento dell'uno non impatti sull'altro (con possibili limitazioni per le tipologie Core-LD,Accesso-DC e Accesso-Anycast per la quale non è richiesta ridondanza 1:1 sui componenti).

Specifiche apparati Core-HD:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

Specifiche apparati Core-LD:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

Specifiche apparati Accesso-DC:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

Specifiche apparati accesso-Anycast:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

1.4.2Architettura a forwarding distribuito (distributed forwarding)

Apparati Core-HD e Core-LD. Caratteristica di un apparato consistente nel mantenere le informazioni di inoltro, pertinenti alla funzione dell'apparato nello stack ISO/OSI (comprese le politiche di filtraggio e di trattamento differenziato del traffico), sui moduli di I/O (line cards) e/o, in generale, sui moduli preposti al forwarding.

Specifiche apparati Core-HD e Core-LD:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

1.4.3Piattaforma non bloccante (wire speed o, equivalentemente, non-blocking)

Apparati Core-HD e Core LD, Accesso-DC e Accesso-Anycast. Capacità di un apparato di:

operare le decisioni di filtering e forwarding del traffico in condizioni di massimo carico su tutte le porte di I/O simultaneamente
redirigere arbitrariamente la totalità delle capacità delle porte di I/O tra tutte le porte dell'apparato.

Affinché la piattaforma sia wire speed (non-blocking) le due caratteristiche di table lookup performance (1) e data flow capacity (2) devono essere verificate entrambe in assenza di perdita di pacchetti.

Specifiche apparati Core-HD e Core-LD:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

Specifiche apparati Accesso-DC:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

Specifiche apparati Accesso-Anycast:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

1.4.4Architettura modulare a chassis passivo

Apparati Core-HD. Caratteristica progettuale di un apparato che prevede l'alloggiamento di tutti i moduli preposti al funzionamento del sistema, compresi i sistemi di raffreddamento e di alimentazione, all'interno di appositi slot di uno chassis completamente passivo.

Tutti i moduli devono essere hot-pluggable e hot-swappable senza che tale azione influisca in alcun modo, o con impatto minimo nel caso dei fabric module, sul funzionamento del sistema nell'esercizio delle proprie funzioni.

Specifiche apparati Core-HD:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

1.4.5Architettura modulare a stack

Apparati Accesso-DC e Accesso-Anycast. Caratteristica progettuale di un apparato che prevede l'alloggiamento di tutti i moduli preposti al funzionamento del sistema, compresi i sistemi di raffreddamento, di alimentazione e di stack, all'interno di appositi slot.

I moduli di raffreddamento e alimentazione devono essere hot-pluggable e hot-swappable senza che tale azione influisca in alcun modo sul funzionamento del sistema nell'esercizio delle proprie funzioni.

Specifiche apparati :

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

1.4.6Ridondanza componenti attive del sistema (no single point of failure system)

Apparati Core-HD. All'interno dello chassis completamente passivo, che rappresenta l'unico punto di fallimento del sistema, deve esserci predisposizione alla ridondanza (secondo gli schemi 1:1 o 1+1) su tutte le componenti che partecipano al funzionamento del sistema.

Apparati Core-LD. Viene richiesta la ridondanza a livello di alimentazione e la ridondanza almeno N+1 sulle ventole.

Apparati Accesso-DC e Accesso-Anycast. Viene richiesta la ridondanza a livello di alimentazione e la ridondanza almeno N+1 sulle ventole.

Specifiche apparati :

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

1.4.6.1Modulo con funzionalità avanzate

Viene richiesto un modulo aggiuntivo per il supporto di funzionalità a valore aggiunto (e.g. Stateful Firewall, IDP, tunneling, NAT). Per questo modulo non è prevista ridondanza.

Specifiche apparati Core-HD:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

Specifiche apparati Accesso-DC:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

Specifiche apparati Accesso-Anycast:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

1.4.7Line rate packet forwarding

Apparati Core-HD e Core-LD, Accesso-DC e Accesso-Anycast. L’esecuzione dei compiti di packet forwarding all'interno di un apparato, che lavora a line rate, implica che tale operazione sia implementata con dei network processor ottimizzati per tali funzioni e dotati di hardware dedicato alle operazioni di table lookup, pattern matching e header rewriting.

La latenza introdotta dalla catena di processing dei pacchetti deve essere quindi trascurabile, nei limiti dello stato dell'arte dei sistemi per il packet forwarding di categoria carrier-class attuali, rispetto alla latenza teorica dell'apparato al layer OSI al quale esso opera.

Specifiche apparati Core-HD:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

Specifiche apparati Core-LD:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

Specifiche apparati Accesso-DC:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

Specifiche apparati Accesso-Anycast:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

1.4.8Line rate packet processing

Apparati Core-HD, Core-LD, Accesso-DC e Accesso-Anycast. Oltre alle funzioni di packet forwarding, implementate a line rate, si includono nel fast path dell'apparato le funzioni di multi-field classification, filtering, metering e policing tipiche delle esigenze di traffic management e security degli operatori di rete.

In particolare riferimento agli apparati Core-HD e Core-LD, le attività di packet classification, filtering e policing in ambiente misto IPv4, IPv6 e MPLS, configurate in aggiunta alle operazioni di inoltro di protocolli non proprietari, non devono introdurre latenze che impattino sul throughput dichiarato dell'apparato e delle sue interfacce di rete.

Specifiche apparati Core-HD :

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

Specifiche apparati Core-LD:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

Specifiche apparati Accesso-DC:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

Specifiche apparati Accesso-Anycast:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

1.4.9Carrier Class

Apparati Core-HD. Con il terminine carrier-class o carrier-grade si individuano apparati e architetture di rete con prestazioni e funzionalità parametrati in base alle esigenze dei fornitori di connettività e servizi in ambito networking.

Tali sistemi devono avere, oltre a performance di eccellenza, massimi livelli di affidabilità e implementare meccanismi di fault tolerance e recovery per garantire un grado di disponibilità necessario all'erogazione di servizi critici e il rispetto di Service Level Agreement (SLA) stringenti.

Valori target corrispondono ad una disponibilità almeno pari al 99.999% del tempo di esercizio e tempi di recovery inferiori ai 50 millisecondi.

Specifiche apparati Core-HD:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

1.4.10Performance benchmarking

Apparati Core-HD, Core-LD, Accesso-DC e Accesso-Anycast. Per il confronto delle performance degli apparati ci si avvale fondamentalmente delle metodologie e delle definizioni standard proposte nell’ambito del “Benchmarking Methodology Working Group (BMWG)” IETF: 2544 (IPv4), 2889 (LAN switch), 3918 (Multicast), 5180 (IPv6) e 5695 (IP/MPLS).

Nelle tabelle di layout dovrà essere specificato se i dati di throughput sono al netto dei 20 Byte di overhead dovuti al preambolo e allo “inter-packet gap”.

Nei dati di performance dichiarati il throughput massimo di sistema deve essere al netto dell'overhead introdotto per lo switching interno all'apparato (non va quindi utilizzato il dato relativo al “raw bitrate”).

Si confermi il rispetto dei vincoli di performance sopra esposti per la presentazione dei dati:

________________________________________________________________________________

2Nodi L3 Core-HD e Core-LD - Requisiti minimi

2.1Sistema Operativo e Strumenti di Monitoraggio

2.1.1Architettura OS

2.1.1.1Caratteristiche sistema

Sistema operativo di rete ad architettura modulare;
Multitasking con preemptive scheduler;
Esecuzione di processi in aree di memoria riservate e protette;
Multiutenza;
Definizione distinta del piano di servizio, del piano di controllo e del piano di gestione.

Specifiche (punto per punto):

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

2.1.1.2Xxxxxxxx Xxxxxxxxxx

(Apparati Core-HD) devono essere dotati di meccanismi e di processi per la gestione della sincronizzazione degli stati tra due kernel in configurazione fisicamente ridondata (propedeutici ai metodi di switchover tra i moduli ospitanti le Routing Engine e le Switching Fabric);
(Apparati Core-LD) devono essere dotati di meccanismi e di processi per la gestione della sincronizzazione degli stati tra le logiche e i processori distribuiti su elementi fisicamente distinti nell’apparato (propedeutici al supporto per il forwarding distribuito).

Specifiche (punto per punto):

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

2.1.2Amministrazione OS e configurazioni

2.1.2.1Amministrazione sistema, utenti e sicurezza

Interfaccia utente (shell) con comandi per system administration, file manipulation, system monitoring e troubleshooting;
Interfaccia utente (shell) con comandi per il controllo e restart dei processi;
Server e client IPv4 e IPv6 di: telnet, SSHv2, FTP o TFTP;
AAA Radius con fallback su database utenti locale al nodo;
Profilazione e gestione di utenti e gruppi con relativi privilegi;
Supporto un meccanismo per filtrare e limitare il traffico destinato al “Piano di Controllo” dell’apparato;
Supporto meccanismi “anti-DoS” (Denial of Service) configurabili;
Registrazione (logging) tutte le informazioni rilevanti circa le possibili anomalie riguardanti la sicurezza.

Specifiche (punto per punto):

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

2.1.2.2Amministazione Configurazioni

Interfaccia utente (shell) con ambiente separato per l’editing delle configurazioni (e.g. configuration mode);
Spazio in memoria per l'archiviazione di almeno 20 differenti configurazioni;
Accesso ed editing per utenti concorrenti con possibilità di editing esclusivo (“lock” su tutta o su parte della configurazione);
Possibilità di editing su più configurazioni con funzione di confronto (sul tipo del comando unix “diff”), funzione di controllo sintattico e semantico delle stesse prima della loro messa in produzione e possibilità di schedulazione del “rollback” automatico ad una delle qualsiasi configurazioni precedentemente attive (eventualmente selezionabile tra quelle archiviate sull'apparato);
Logging: con tracciamento delle attività deve essere remotizzato tramite protocollo Syslog su un server esterno ed essere accessibile anche localmente tramite la shell utente (CLI);
Debugging: il livello di dettaglio delle attività di debug deve poter essere configurabile così come il suo output (file, CLI...) e non deve avere impatto sulle prestazioni dell'apparato;
Linguaggio di scripting: con possibilità di sviluppo di script locali sul nodo per la personalizzazione di comandi, per la schedulazione automatica di modifiche di elementi di configurazione, per la gestione di statistiche periodiche o per l’esecuzione di specifiche azioni innescate da determinati eventi verificatosi sul nodo.

Specifiche (punto per punto):

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

2.1.3Alta disponibilità

Process Restart: deve essere possibile riavviare i processi a “runtime” senza impatto sul sistema;
Graceful Restart (GR): supporto delle estensioni di graceful restart dei protocolli di routing (unicast e multicast) e label switching del piano di controllo;
Relativamente agli apparati Core-HD, per le funzionalità RE/SF Failover/Switchover: lo switchover tra le routing engine/switching fabric deve poter avvenire in modo automatico, senza impatto sui piani di controllo e di inoltro del sistema (“near 0 packet loss”), che non richiedono la collaborazione dei nodi di rete adiacenti (protocolli GR). La possibilità di richiedere la collaborazione dei nodi di rete adiacenti (protocolli GR) deve essere configurabile in alternativa ai meccanismi di mantenimento del piano di controllo¹ IP/MPLS.
Relativamente agli apparati Core-HD, per le funzionalità In Service Software Upgrade (ISSU): gli aggiornamenti e i cambi di release software devono poter essere effettuati senza corrompere il piano di controllo e con minimo impatto sul funzionamento del sistema; in particolare non deve essere richiesta collaborazione ai nodi di rete adiacenti.

Specifiche (punto per punto):

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

2.1.4Monitoraggio e OA&M

2.1.4.1Strumenti di controllo

Comandi ICMP ping, traceroute, MPLS LSP ping e traceroute;
Supporto SNMPv1, v2, v3, SNMP Trap, RMON e Syslog. In particolare è richiesto il supporto delle “Management Information Base” (MIB) previste dagli standard IETF e IEEE e delle estensioni proprietarie.

Specifiche (punto per punto):

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

2.1.4.2Mirroring, Xxxxxxxx & Accounting

Supporto di funzionalità di mirroring del traffico e dei protocolli NetFlow, IPFIX o equivalenti con configurabilità della frequenza di campionamento (sampling rate);
Monitoraggio e campionamento del traffico “policy-based”: le funzioni di sampling (NetFlow, IPFIX o equivalenti) e quelle di mirroring devono essere configurabili in base a politiche definibili e configurabili dagli amministratori di sistema;
Supporto di funzionalità di accounting, non su base statistica, del traffico per la produzione di report per il billing;
Il sampling, l’accounting e il mirroring del traffico devono essere operati a “line rate” quindi in hardware senza impattare sulle performance del sistema. Per la funzionalità di port mirroring gli apparati devono poter gestire un numero di istanze di port mirroring non limitato in software (no hard-coded). Nel caso si debba utilizzare hardware aggiuntivo, la scheda/modulo preposta potrà essere installata negli apparati, in modalità hot swappable, in uno degli slot liberi richiesti e riservati per espansioni future.

Specifiche (punto per punto):

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

2.1.4.3Strumenti di OA&M

Gli apparati dovranno prevedere strumenti per la misura in tempo reale di parametri prestazionali di rete quali: delay, latency, jitter;
Supporto dello standard OAM “Connectivity Fault Management” secondo la raccomandazione IEEE 802.1ag;
Supporto dello standard OAM “Link Fault Management” secondo la raccomandazione IEEE 802.3ah;
Supporto del protocollo “Bidirectional Forwarding Detection” (BFD).

Specifiche (punto per punto):

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

2.2Funzionalità layer1 & layer2 OSI

2.2.1Synchronous Ethernet

L’apparato deve supportare il meccanismo di sincronizzazione della frequenza su collegamenti Ethernet SyncE (Synchronous Ethernet).

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

2.2.2Optical transceiver

Si richiede l’implementazione del “Digital Diagnostics Monitoring” (DDM) per i transceiver ottici.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

2.2.3802.1D-2004 - MAC Bridges

Gli apparati devono supportare la funzionalità di switching Ethernet in accordo con lo standard IEEE 802.1D-2004 (MAC bridges). Devono essere in grado di inoltrare le trame/frame Ethernet (unicast, multicast e broadcast), senza perdite, line rate tra qualunque interfaccia in stato operativo

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

2.2.4Bridge Domain

Gli apparati, nell’implementare la raccomandazione 802.1D, devono poter realizzare Bridge Domain distinti per macchina e porta. Inoltre devono poter supportare l’applicazione selettiva dei meccanismi di isolamento delle interfacce in merito al verso di trasmissione delle frame (e.g. funzionalità di tipo “Split Horizon”).

Il Bridge Domain limita l’ampiezza del processo del MAC learning (Media Access Control) determinando quindi il limite oltre il quale il dispositivo non deve propagare le trame destinate ad indirizzi di tipo broadcast, unknown unicast e multicast (BUM traffic).

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

2.2.5802.1AB

L’apparato deve supportare il protocollo Link Layer Discovery Protocol (LLDP), secondo lo standard IEEE 802.1AB.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

2.2.6MTU e Protocols Encapsulation

L’apparato deve inoltrare trame Ethernet con payload di dimensione superiore ai 1500 Byte (in particolare si richiede che il payload possa raggiungere i 9000 Byte).

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

Il parametro MTU, per permettere il supporto del mapping o incapsulamento sulle trame Ethernet di protocolli supplementari, deve essere configurabile e supportare la modalità jumbo frames. In particolare l’apparato deve supportare il trasporto di trame MPLS in maniera trasparente.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

2.2.7Local Traffic Cross-Connect

Gli apparati devono poter implementare funzionalità di tipo “cross connect”, cioè deve essere possibile interconnettere localmente agli apparati flussi di dati, identificati da outer-tag o inner-tag, attestati su porte degli apparati stessi (e.g. cross-connection di VLAN X su porta x con traffico di VLAN Y su porta y).

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

2.2.8Spanning Tree Protocols

Gli apparati devono supportare tutti i protocolli standard IEEE di tipo Spanning Tree Protocols (xSTP). In particolare, devono essere implementate tutte le evoluzioni in accordo con gli standard IEEE 802.1D-2004 (Sezione 17: Rapid STP ex 802.1w-2001), 802.1Q-2005 (Sezione 13: Multiple STP ex 802.1s-2002) e 802.1Q-REV (2011).

Gli apparati devono essere in grado di filtrare BPDU e altre frame di controllo di Layer2 ricevute in funzione della porta e della VLAN su cui queste potrebbero essere ricevute.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

2.2.9802.1Q - Virtual LANs e Class of Services (CoS)

Gli apparati devono gestire VLAN ID in accordo con la raccomandazione IEEE 802.1Q-REV (2011) senza limitazioni dipendenti da line cards o da qualunque altro tipo di equipaggiamento degli apparati. Gli apparati devono supportare 4K VLANs per porta, per una gestione complessiva di almeno 32K VLANs.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

Gli apparati devono gestire la CoS in accordo con la raccomandazione IEEE 802.1p: “LAN Layer 2 QoS/CoS Protocol for Traffic Prioritization” (raccomandazione successivamente inclusa nella specifica 802.1D/802.1Q).

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

2.2.10802.1ad – Provider Bridges

È richiesto che gli apparati proposti implementino lo standard IEEE 802.1ad “Stacked VLAN”. Gli apparati devono essere in grado di gestire correttamente trame Ethernet con più tag ed effettuare il push, pop o translate delle etichette.

L’apparato deve poter preservare gli identificativi di VLAN (VLAN ID Preservation) anche in modalità “Stacked VLAN”. L’apparato deve consentire la preservazione del campo CoS del VLAN Tag (VLAN CoS Preservation) anche in modalità “Stacked VLAN”.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

Gli apparati devono implementare funzionalità tipiche di VLAN ID manipulation (VLAN ID push, pop, swap ed eventuali combinazioni) senza limitazioni sul numero di VLAN gestibili dal sistema o implicando degrado delle performance di trasmissione delle trame.

È richiesta la capacità di selezionare il traffico in base al differente numero di tag posseduti dal frame, l’abilità di analizzare solo una parte dell’header Ethernet e l’abilità di utilizzare intervalli di VLAN tag configurati.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

2.2.11Integrated Bridging and Routing (IRB)

Sull’apparato devono essere supportate interfacce con funzionalità di layer2 configurabili con VLAN tag. Le singole porte devono poter essere configurate sia in “access mode” sia in “802.1Q trunking mode”.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

È richiesto il supporto di layer2 bridging e di layer3 routing sulla stessa interfaccia. Le trame Ethernet devono essere trattate a livello 2 se non sono inviate al MAC address del router. Le trame Ethernet devono essere trattate a livello 3 e quindi ruotate alle altre interfacce di livello 3, laddove inoltrate al MAC address del router.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

2.2.12802.1AX-2008 – Link Aggregation

È richiesto il supporto della funzionalità di Link Aggregation Group (LAG) secondo lo standard IEEE 802.1AX-2008 (ex 802.3ad): Link Aggregation Control Protocol (LACP).

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

Deve essere possibile realizzare aggregati di porte 1GbE sia in modalità intra-linecard che inter-linecard su slot differenti dello chassis.

Deve essere possibile realizzare aggregati di porte 10GbE sia in modalità intra-linecard che inter-linecard su slot differenti dello chassis.

Deve essere possibile realizzare aggregati di porte 1GbE e 10GbE, rispettivamente, anche in modalità inter-chassis.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

La configurazione degli aggregati non deve avere alcun impatto sulle prestazioni puntuali e complessive dell’apparato in termini di throughput e di funzionalità.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

I LAG (sia statici che dinamici) devono essere equivalenti alle interfacce fisiche o logiche del sistema anche in termini di configurabilità: tutte le funzionalità configurabili sulle interfacce fisiche o logiche (QoS, filtering, encapsulation, shaping...) devono poter essere configurate anche sui gruppi aggregati. Deve essere possibile utilizzare VLAN tagging su aggregati 802.1AX senza perdita di configurabilità rispetto ai trunk 802.1Q realizzati sulle interfacce fisiche.

La medesima equivalenza deve essere garantita anche per la configurazione di tutte le istanze protocollari pertinenti ai livelli superiori dello pila OSI.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

L’implementazione deve supportare, oltre alla modalità LAG N con bilanciamento del traffico sui link dell’aggregato, la modalità LAG N+N (link protection) almeno nel caso N=1, che prevede che una parte dei link dell’aggregato venga utilizzata per l’inoltro del traffico e un’altra parte sia in standby fino al failure dei link attivi. Le due modalità devono essere configurabili per ogni aggregato e non a livello di apparato (chassis-wide).

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

Il sistema deve disporre di meccanismi configurabili di bilanciamento del traffico (load balancing) all’interno di un link aggregato sia se formato staticamente sia se formato utilizzando LACP.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

È richiesto il supporto della funzionalità “Multi-Chassis LACP” per gestire la ridondanza di porte Ethernet (1GbE e 10GbE) su nodi distinti. La soluzione non deve richiedere alcun cambiamento nel modo di operare del protocollo LACP sul nodo adiacente.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

2.3Funzionalità di Routing IP

2.3.1IPv4-IPv6 Router

L’apparato deve supportare le funzionalità di indirizzamento, routing e forwarding dei pacchetti IPv4 e IPv6 (“Dual Stack”), unicast e multicast, in conformità alle specifiche di Classless Routing con Variable Length Subnet Masking e agli standard IETF rilevanti.

Gli apparati devono supportare la configurazione, per i protocolli IPv4 e IPv6, di rotte statiche (static routes) e della default route. Inoltre devono supportare il routing dinamico tramite i vari protocolli di routing appartenenti alle classi EGP e IGP.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

Per IPv4 è richiesto il supporto del protocollo BGP-4, dei protocolli di Routing IGP RIPv2, OSPFv2 e IS-IS e del protocollo multicast PIM. Per IPv6 è richiesto il supporto dei seguenti protocolli e delle pertinenti estensioni: BGP-4 con le estensioni per IPv6, RIPng, OSPFv3 e IS-IS per IPv6 e IPv6 PIM. In particolare gli apparati devono supportare la funzionalità di IPv6 “Path MTU Discovery”.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

All’interno dei due paradigmi (IPv4 e IPv6) deve essere possibile configurare la ridistribuzione di rotte statiche (static) e direttamente connesse (connected) nei vari protocolli delle classi EGP/IGP, con la possibilità di applicare filtri per la selezione delle rotte stesse.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

All’interno dei due paradigmi (IPv4 e IPv6) deve essere possibile configurare la ridistribuzione delle informazioni di routing, tra differenti protocolli di routing e tra istanze differenti dello stesso protocollo, con la possibilità di applicare filtri per la selezione delle rotte.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

All’interno dei due paradigmi (IPv4 e IPv6) il sistema deve supportare funzionalità di filtering delle rotte dai processi EGP/IGP alle tabelle di routing.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

Gli apparati devono supportare la configurazione di Loopback multiple e la configurazione di multipath ECMP.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

È richiesto il supporto di protocolli di Layer3 tunnelling tra cui almeno il meccanismo Generic Routing Encapsulation (GRE); si specifichi se per tale funzionalità si propone modulo “hardware” aggiuntivo.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

L’apparato deve supportare funzionalità di “DHCP relaying” configurabili per interfaccia e per VLAN.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

All’interno dei due paradigmi (IPv4 e IPv6) devono essere supportati i seguenti protocolli: ICMP (comando ping e comando traceroute), telnet, SSHv2 e FTP o TFTP.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

Le funzionalità specificate nei paragrafi seguenti prevedono, anche se non esplicitamente citate, le conformità sugli standard IEEE e IETF. Nel caso la conformità agli standard richiesti non sia completa o non contempli l’aderenza a particolari funzionalità avanzate incluse nello standard, si dettaglino le motivazioni.

2.3.2RIP

L’apparato deve garantire il supporto del protocollo di routing RIPv2 secondo lo standard RFC 2453 e di RIPng secondo qRFC 2080. Deve essere supportato un meccanismo di autenticazione MD5 secondo la raccomandazione RFC 2082 (è ammessa l’implementazione anche solo parziale dello standard).

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

2.3.3OSPF

È richiesto il supporto standard OSPFv2 (RFC 2328) e OSPFv3 (RFC 2740 o 5340) con le estensioni OSPF NSSA Option (RFC 3101) e OSPF-TE (RFC 3630).

È richiesto il supporto per l’"OSPF Refresh and Flooding Reduction in Stable Topologies" (RFC 4136), l’“OSPF Opaque LSA Option” (RFC 2370 o 5250) e il “Support of Address Families OSPFv3” (RFC 5838).

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

L’apparato deve consentire la configurazione, su base interfaccia, dei costi OSPF, implementare la funzionalità di OSPF Passive Interface e supportare la configurazione di più di un’Area OSPF.

È richiesto il supporto di OSPF Prefix Priority, OSPF Route Tagging e OSPF auto-cost reference-bandwidth.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

2.3.4IS-IS

L’apparato deve implementare il supporto al protocollo di routing Intermediate System to Intermediate System (IS-IS) secondo le specifiche ISO/IEC 10589:2002, second edition, e operare routing IP secondo la modalità "Integrated IS-IS" o "Dual IS-IS" (RFC 1195).

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

L’apparato deve, inoltre, implementare integralmente il supporto per le funzionalità Level 1 router (intra-area), Level 2 router (inter area) e Level 1-2 router per lo scambio delle informazioni tra i due tipi di router IS-IS.

Gli apparati devono consentire l’abilitazione esplicita e la configurazione delle metriche di IS-IS su base interfaccia; devono supportare la IS-IS Route Summarization e la Router Priority IS-IS e queste devono essere configurabili manualmente.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

2.3.5BGP

È richiesto il supporto degli standard: BGP-4 (RFC 4271), “BGP Communities Attribute” (RFC 1997), “Protection of BGP Sessions via the TCP MD5 Signature” (RFC 2385), "BGP Route Flap Damping" (RFC 2439), "Route Refresh Capability for BGP-4" (RFC 2918), “Communities BGP Standard and Extended” (RFC 4360) e “BGP Route Reflection client and server” (RFC 4456).

Gli apparati devono supportare le estensioni multiprotocollo per BGP secondo gli standard RFC 2545 e RFC 4760 e devono implementare la componente di Management Information Base (MIB) relativa a BGP-4 secondo la raccomandazione "Definitions of Managed Objects for BGP-4" (RFC 4273).

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

Gli apparati devono consentire la configurazione del BGP Router ID, dei peer-group BGP, della Local Preference BGP, dell’iBGP Multipath, dell’eBGP Multipath e del Path MTU Discovery per le sessioni BGP. Xxxxxx, inoltre, permettere la configurazione del numero massimo di hop consentiti per stabilire una sessione eBGP Multihop (RFC 3682).

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

Gli apparati devono fornire dei meccanismi per consentire all’amministratore di rete di limitare il numero di prefissi BGP in tabella di routing e supportare l’applicazione di nuove policy senza la necessità di effettuare il clear dell’intera sessione BGP.

Gli apparati devono implementare funzionalità di filtering sulle rotte BGP in uscita e in ingresso e supportare l’AS path prepending

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

2.3.6Routing Multicast

Gli apparati devono supportare i protocolli Protocol Independent Multicast – Sparse Mode (PIM-SM, RFC 4601), Protocol Independent Multicast – Dense Mode (PIM-DM, RFC 3973) e Source-Specific Multicast for IP (PIM-SSM, RFC 4607).

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

Gli apparati devono supportare PIM SSM configurabile per gruppo multicast e il meccanismo Anycast-RP per ambienti PIM.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

È richiesto il supporto dei protocolli IPv4 IGMPv2 (RFC 2236), IGMPv3 (RFC 3376) e dei protocolli IPv6 MLDv1 (RFC 2710) e MLDv2 (RFC 3810 e RFC 4604).

Gli apparati devono essere in grado di eseguire la conversione e la mappatura di IGMPv2 in IGMPv3. Deve essere garantito il supporto per “IGMP fast leave”, per le “static IGMP joins” per interfaccia e deve essere supportata la funzione “IGMP querier”.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

Come richiesto per tutte le operazioni di inoltro, l’apparato deve supportare la replica dei flussi multicast a “line rate” in modalità “hardware” e in modo distribuito sulle line cards.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

2.3.7Policy Routing

Gli apparati devono supportare il “Policy Based Routing” consentendo di prendere decisioni di routing basandosi su policy configurate dall’amministratore invece di seguire i passi previsti dal flusso decisionale standard previsto dalla specifica dell’algoritmo di routing preso in esame.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

In particolare, deve essere possibile configurare politiche di routing in funzione almeno dei seguenti campi dell’header IP: source/destination IP address, TCP e UDP destination/source port. Deve inoltre essere possibile specificare come next-hop della policy di routing un prefisso di rete di un router non adiacente.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

2.3.8Network Address Translation

(Apparati Core-HD) L’apparato deve supportare servizi di NAT almeno 1:1 a “line rate”.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

2.4Funzionalità MPLS

2.4.1MPLS

Gli apparati devono implementare i meccanismi di funzionamento previsti per la realizzazione del piano di controllo e di forwarding dei pacchetti all’interno del paradigma MPLS. I meccanismi suddetti devono essere supportati con l’implementazione della segnalazione LDP (RFC 3036), secondo quanto specificato nella documentazione relativa al framework MPLS (RFC 3031, RFC 3032) e protocolli associati.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

In particolare, gli apparati devono supportare il meccanismo di LDP authentication, la funzionalità di filtering per LDP advertisement, i meccanismi di LDP session protection, la sincronizzazione LDP-IGP e i targeted LDP (T-LDP) per la distribuzione delle inner label.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

Dello standard Multi-Protocol Label Switching (MPLS) Support of Differentiated Services (RFC 3270) è richiesto il supporto per la QoS in modalità E-LSP (cioè utilizzando i bit del campo Exp dell’header MPLS).

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

Gli apparati devono supportare le funzionalità di MPLS “P Router” (Provider Router) e MPLS “PE Router” (Provider Edge Router).

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

Gli apparati devono supportare la funzionalità di “Penultimate Hop Popping” ed “Explicit Null” e consentire la configurabilità del TTL propagation.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

Gli apparati devono supportare la possibilità di configurare il protocollo MPLS per singola interfaccia e devono supportare la configurazione dell’interface MTU a livello MPLS.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

Gli apparati devono supportare la segnalazione delle label MPLS mediante il protocollo BGP, secondo quanto specificato nella specifica RFC 3107.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

L’apparato deve supportare la frammentazione di pacchetti IP in MPLS LSPs.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

2.4.2MPLS-TE (Traffic Engineering)

Gli apparati devono supportare il funzionamento del piano di controllo e di forwarding in modalità MPLS-TE, secondo quanto specificato dall’architettura di MPLS Traffic Engineering e protocolli associati.

In particolare, devono supportare il protocollo di segnalazione RSVP-TE (RFC 3209).

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

È richiesto il supporto delle estensioni dei protocolli di routing per MPLS-TE, in particolare:

Traffic Engineering (TE) Extensions to OSPF Version 2 (RFC 3630);
IS-IS Extensions for Traffic Engineering (RFC 5305).

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

Gli apparati devono supportare il setup di Tunnel MPLS-TE (Traffic Engineered Tunnel) secondo le modalità previste dai meccanismi di:

Explicit Routing;
Constraint Based Routing;
Dynamic Routing.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

Gli apparati devono supportare le funzionalità di protezione basate sui meccanismi di MPLS-TE Fast Rerouting (FRR) secondo quanto descritto in RFC 4090; tali meccanismi devono poter garantire performance di riconvergenza sub-50 msec.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

È richiesta un’implementazione dei meccanismi di tipo Make-Before-Break (MBB) che garantisca un tasso di perdita nullo e devono essere supportati strumenti di MPLS Operations, Administration, and Maintenance (OAM).

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

2.4.3L3 VPN

Gli apparati devono supportare servizi di connettività di tipo VPN MPLS in conformità con gli standard IETF per la realizzazione dell’applicazione MPLS Layer3 VPN (RFC 4364 e raccomandazioni collegate).

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

Gli apparati devono supportare l’implementazione del protocollo BGP secondo lo standard “Multiprotocol Extensions for BGP-4” (RFC 4760) per lo scambio delle informazioni di controllo tra i nodi che svolgono funzione di Provider-Edge (PE) della VPN MPLS e fornire il supporto completo di BGP per l’implementazione delle funzionalità di tipo Route-Reflector su MPLS VPN.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

Gli apparati devono, inoltre, supportare le estensioni del protocollo BGP per il controllo del traffico IPv6 su MPLS VPN (BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing, RFC 2545) e BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN (RFC 4659) e Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers 6PE (RFC 4798).

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

Gli apparati devono supportare l’implementazione di funzionalità inter-Provider e inter-AS VPN aderenti allo standard RFC 4364, BGP/MPLS IP Virtual Private Networks (VPNs), secondo le tecnologie di Inter-Provider & Carrier’s Carrier VPNs (option A, B & C).

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

Gli apparati devono supportare l’implementazione di funzionalità di TTL propagation (IP to MPLS su operazione PUSH & MPLS to IP su operazione POP).

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

Gli apparati devono supportare la configurazione granulare dell’eventuale route-leaking tra diverse VRF per mettere in comunicazione diverse VPNs

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

2.4.3.1CE-PE protocols e VRFs

Gli apparati devono supportare l’implementazione CustomerEdge-ProviderEdge dei protocolli e-BGP, i-BGP, OSPF e le relative estensioni IPv6. In particolare gli apparati devono supportare la reciproca ridistribuzione delle rotte: da BGP CE-PE in VRF in OSPF e da OSPF CE-PE in BGP (internal OSPF routes).

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

Gli apparati devono supportare la configurazione di rotte statiche IPv4 e IPv6 tra PE-CE.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

Gli apparati devono permettere la configurazione di:

Routing statico in VRF verso le reti del customer;
Allocazione di label per VRF (una unica label per ogni VRF).

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

2.4.4L2 VPN e VPLS

Gli apparati, oltre al supporto di servizi Layer 3 VPN MPLS, devono garantire il supporto per i servizi di Virtual Private Wire Service (VPWS) o EoMPLS (Ethernet over MPLS).

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

Gli apparati devono fornire una soluzione di connettività per la realizzazione di applicazioni VPLS in conformità con gli standard IETF per la realizzazione di servizi L2 VPN su una rete di tipo Metro MPLS per l’emulazione di servizi E-LAN.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

Il meccanismo per la segnalazione dei nodi PE della singola istanza VPLS deve essere implementato secondo la raccomandazione RFC 4761 (Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling) o RFC 4762 (Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling).

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

È richiesto il supporto di meccanismi per la gestione e la limitazione del traffico BUM (Broadcast, Unknown Unicast, Multicast) all’interno del singolo dominio layer2 VPLS e, più in generale, un metodo efficiente per la gestione dei MAC address relativi all’istanza VPLS che limiti eventuali problemi derivanti dalla loro quantità.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

L’implementazione VPLS proposta deve poter essere compatibile con meccanismi di multi-homing e ridondanza di CE connessi all’architettura VPLS.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

2.4.5MPLS multicast VPNs

Gli apparati devono supportare il servizio multicast in MPLS/BGP VPNs con l’utilizzo del protocollo Multi-Protocol BGP (estensioni NLRI per BGP multicast VPN).

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

È richiesto che gli apparati supportino funzionalità di trasporto MPLS P2MP conformi con quanto definito nello standard “Signaling Requirements for Point-to-Multipoint Traffic-Engineered MPLS Label Switched Paths” (IETF Informational RFC 4461). In particolare è richiesto il supporto per la segnalazione degli LSP point-to-multipoint con segnalazione RSVP-TE (RFC 4875).

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

La soluzione proposta deve possedere meccanismi automatici e dinamici per il discovery dei nodi foglia dell’albero multicast e il setup dei tunnel MPLS P2MP.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

L’implementazione MPLS P2MP sugli apparati deve poter interagire con soluzioni di tipo IP multicast routing basate sul protocollo PIM seguendo il paradigma ASM e il paradigma SSM, sia in ambito di connettività CE-PE che in ambito di trasporto sull’infrastruttura di backbone del provider, quest’ultima basata su distribuzione multicast PIM con GRE tunneling.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

2.5Operations, Administration and Maintenance (OAM) & Protection

Gli apparati devono implementare una suite di protocolli e meccanismi di monitoraggio e controllo per la rilevazione e la gestione dei guasti o dei malfunzionamenti. Tali meccanismi, oltre a fornire strumenti per il monitoraggio delle performance, devono collaborare in maniera strutturata con i meccanismi automatici di protezione e recovery ad ogni livello del modello di riferimento OSI, di seguito specificato.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

2.5.1Layer2: Ethernet

Supporto dello standard OAM “Connectivity Fault Management” secondo la raccomandazione IEEE 802.1ag o ITU-T Y.1731;
Supporto dello standard OAM “Link Fault Management” secondo la raccomandazione IEEE 802.3ah;
Si richiede che gli apparati supportino funzionalità di protezione per recovery sub-50ms assimilabili alle raccomandazioni XXX-X X.0000 “Ethernet Linear Protection” o XXX-X X.0000 “Ethernet Ring Protection”.

Specifiche (punto per punto):

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

2.5.2Layer3: IP

Gli apparati devono supportare il protocollo Virtual Router Redundancy Protocol (VRRP).

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

Gli apparati devono supportare funzionalità di protezione a livello IP (Basic Specification for IP Fast Reroute: Loop-Free Alternates) per i protocolli OSPF e IS-IS secondo quanto descritto nell’RFC 5286; tali meccanismi devono poter garantire performance di ri-convergenza sub-50 msec per il traffico IP.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

Gli apparati devono implementare il protocollo Bidirectional Forwarding Detection (BFD) secondo la raccomandazione RFC 5880 e devono supportare il suo utilizzo in collaborazione con i protocolli di routing EGP (BGP) e IGP (OSPF, IS-IS).

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

Gli apparati devono supportare le estensioni dei protocolli di routing per i seguenti meccanismi di “Graceful Restart” (GR):

“Graceful OSPF Restart” (RFC 3623);
“Restart Signaling for IS-IS” (RFC 3847);
“Graceful Restart Mechanism for BGP” (RFC 4724).

Specifiche (punto per punto):

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

2.5.3Transport Layer: MPLS

2.5.3.1MPLS L2 e L3 VPN

Gli apparati devono implementare il protocollo Bidirectional Forwarding Detection (BFD) secondo la raccomandazione RFC 5880 e devono supportare il suo utilizzo, congiuntamente a LSP Ping, per il controllo degli LSPs basati su RSVP-TE.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

Le funzionalità layer3 di Loop-Free Alternates devono poter garantire performance di ri-convergenza sub-50 msec per il traffico MPLS con segnalazione LDP.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

Il sistema deve supportare le funzionalità di protezione basate sui meccanismi di MPLS-TE Fast Rerouting (FRR) secondo quanto descritto in RFC 4090; tali meccanismi devono poter garantire performance di riconvergenza sub-50 msec.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

È richiesta un’implementazione dei meccanismi di tipo Make-Before-Break (MBB) con perdite a tasso nullo (“near 0 packet loss”) e devono essere supportati strumenti di MPLS Operations, Administration, and Maintenance (OAM).

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

Gli apparati, nel ruolo di LSR, al rilevamento del fault dalla segnalazione BFD, RSVP “hellos” o “Resv/Path messages”, devono essere in grado di redirigere gli LSP protetti localmente (local protection) secondo l’approccio “one-to-one” (detour) o “many-to-one” (facility backup) in meno di 50 msec.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

Gli apparati devono supportare le estensioni dei protocolli di label distribution per la realizzazione dei seguenti meccanismi di “Graceful Restart” (GR):

“Graceful Restart Mechanism for Label Distribution Protocol” (RFC 3478);
“Resource Reservation Protocol - Traffic-Engineered (RSVP-TE) Graceful Restart Extensions/Procedures”.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

2.5.3.2VPLS

L’implementazione VPLS proposta deve poter essere compatibile con meccanismi di multi-homing e ridondanza dei CE coinvolti nelle applicazioni VPLS, nonché disporre di meccanismi di selezione del path primario/secondario e di loop-avoidance.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

2.5.3.3MPLS Multicast

La soluzione MPLS P2MP deve poter garantire, in caso di fault, le medesime performance dei servizi P2P avvalendosi dei meccanismi di MPLS FRR (riconvergenze sub-50 msec) ed evitando eventuali duplicazioni di traffico. È inoltre richiesta un’implementazione dei meccanismi di tipo Make-Before-Break con perdite a tasso nullo (“near 0 packet loss”).

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

Devono essere supportati strumenti di MPLS Operations, Administration, and Maintenance (OAM) per il traffico multicast.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

2.5.4Traffic load balancing

Gli apparati devono disporre di meccanismi di load balancing per il traffico Ethernet, IPv4, IPv6 e MPLS; tali meccanismi devono essere configurabili almeno in base agli indirizzi sorgente e destinazione o ai vari tags degli header protocollari.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

2.6Qualità del Servizio (QoS)

2.6.1Packet filtering

Gli apparati devono supportare la funzionalità di packet filtering, Access Control List (ACL), sulle interfacce fisiche e logiche a “line rate” in input e in output, con funzioni di classificazione del traffico di elevata granularità e configurabilità all’interno dei campi degli header protocollari dei vari livelli della pila OSI.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

Devono essere implementate e configurabili almeno le seguenti operazioni “post pattern matching”:

Accept
Discard
Reject (Discard sending ICMP destination unreachable message)

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

Devono essere implementate e configurabili almeno le seguenti azioni associate:

Count
Syslog

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

2.6.2Policing, Shaping & Scheduling

Gli apparati devono gestire la CoS in accordo con la raccomandazione IEEE 802.1p: “LAN Layer 2 QoS/CoS Protocol for Traffic Prioritization” (successivamente in standard 802.1D/802.1Q). Gli apparati devono supportare la QoS secondo il modello DiffServ e poter operare sul campo DSCP dell’header IP per il trattamento differenziato del traffico in classi di servizio (precedence trust and marking).

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

Gli apparati devono prevedere, in relazione al traffico in uscita, la possibilità di configurare almeno 8 code per ciascuna interfaccia fisica. Le code devono essere implementate in “hardware”, il dimensionamento dei buffer di ogni interfaccia fisica dell’apparato deve fornire una profondità temporale minima di almeno 50 msec per interfaccia (sia 1GbE sia 10GbE) e l’accodamento dei pacchetti nelle stesse deve essere effettuabile in base ai criteri descritti nei requisiti successivi.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

Gli apparati devono supportare sulle interfacce di ingresso funzioni di classificazione del traffico almeno sulla base dei seguenti parametri (uno o una loro qualunque combinazione):

Physical Port;
VLAN tag;
S-Vlan + C-Vlan (Vlan Stacking);
MAC address;
Ethernet header CoS field;
Ethernet header Protocol field;
Traffic Flow (e.g. coppie IP_SRC – IP_DST, MAC_SRC – MAC_DST, Multicast Group).

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

Nel caso in cui il protocollo incapsulato sia IP, è richiesto che gli apparati supportino funzioni di classificazione del traffico almeno sulla base dei seguenti campi dell’header IP, TCP, UDP (uno o una loro qualunque combinazione):

IP source address;
IP destination address;
DiffServ Code Point (DSCP) ToS field;
IP Protocol (e.g. TCP, UDP);
TCP/UDP source port;
TCP/UDP destination port;
Bit-field value (e.g. IP options, TCP flags, IP fragmentation fields).

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

Gli apparati devono supportare la configurazione di politiche di Shaping in uscita e di Policing in ingresso sulle interfacce in base ai precedenti parametri di classificazione del traffico.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

I Policer devono essere di tipo “Two Rate Three Color Marker” secondo il modello dello standard RFC informational 2698.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

I Policer devono essere configurabili per l’esecuzione delle seguenti azioni:

Field Rewriting: CoS, DSCP, Exp bits…;
Differentiated Queuing;
Discard Traffic;

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

La gestione della QoS deve essere indipendente dal protocollo utilizzato per il trasporto. Deve essere possibile definire i parametri di traffico (bandwidth, shaping, policing) su insiemi di VLAN trasportate verso destinazioni differenti (e.g. diversi pseudowire) anche utilizzando metodologie diverse di trasporto (e.g. alcune VLAN mediante L2 bridging, altre su VPLS, altre su pseudowire punto-punto).

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

Gli apparati devono offrire la possibilità di definizione del rate limiting in ingresso ed uscita dalle interfacce fisiche e logiche in maniera indipendente.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

2.6.3Gestione QoS su traffico MPLS

Gli apparati devono supportare funzionalità di gestione delle classi del servizio e di controllo del traffico basate su MPLS EXP-bits.

In particolare si richiedono le seguenti funzionalità:

Marking e remarking del campo EXP-bits (in funzione dei campi L2 CoS o L3 ToS);
Policing/Rate Limiting sui pacchetti in ingresso su base interfaccia fisica;
Policing/Rate Limiting sui pacchetti in ingresso su base interfaccia logica.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

Gli apparati devono supportare sulle interfacce di ingresso, sia fisiche che logiche, funzioni di classificazione del traffico almeno sulla base dei seguenti parametri (uno o una loro qualunque combinazione):

Physical Port;
Exp bits.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

3Nodi L2 (Accesso-DC e Accesso-Anycast) – Requisiti minimi

3.1Funzionalità di stacking

3.1.1Modularità stack

È richiesto che l’architettura di stacking preveda la possibilità di interconnettere in stack almeno 10 apparati sia per la tipologia Accesso-DC che per la tipologia Accesso Anycast.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

3.1.2Flessibilità stack

È richiesto che il sistema di stacking, previsto per le tipologie di apparati Accesso-DC e Accesso-Anycast, renda possibile l’implementazione di uno stack misto (fino a 10 apparati) in cui sono presenti entrambe le tipologie (Accesso-DC e Accesso-Anycast) in qualsiasi combinazione.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

3.1.3Connettività Stack

Le connessioni fisiche per la realizzazione dello stack devono potere essere implementate sia attraverso connessioni locali (con cavi proprietari) sia attraverso connessioni geografiche con interfacce ottiche standard 10 Giga SFP+ e 1 Giga SFP, supportando e rispettando i vincoli di distanza indicati nelle specifiche delle ottiche standard 10 Giga e 1 Giga. Queste due modalità di connessione devono poter convivere contemporaneamente.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

3.1.4Forwarding Distribuito Stack

All’interno dello stesso stack deve essere possibile inoltrare il traffico tra porte appartenenti allo stesso apparato e tra porte appartenenti ad apparati diversi senza che il forwarding del traffico richieda interventi e, più in generale, risorse computazionali dell’apparato su cui risiedono le funzionalità di controllo del piano di routing e/o forwarding.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

3.2Sistema Operativo e Strumenti di Monitoraggio

3.2.1Architettura OS

3.2.1.1Caratteristiche sistema

È richiesto che il sistema operativo degli apparati proposti possegga le seguenti proprietà:

Sistema operativo di rete ad architettura modulare;
Multitasking;
Multiutente.

Specifiche (punto per punto):

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

3.2.1.2Xxxxxxxx Xxxxxxxxxx

È richiesto che il sistema operativo degli apparati sia dotato di meccanismi e di processi per la gestione della sincronizzazione degli stati tra due kernel in configurazione fisicamente ridondata (propedeutici ai meccanismi di switchover tra l’unità master e l’unità backup). Per configurazione fisicamente ridondata si intende un sistema costituito da almeno due apparati (unità master e unità backup) appartenenti al medesimo stack con funzionalità centralizzate di Route Processor e Control Board.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

3.2.2Amministrazione OS e configurazioni

3.2.2.1Amministrazione sistema, utenti e sicurezza

È richiesto che il sistema operativo sia dotato delle seguenti funzionalità:

interfaccia utente (shell) con comandi per system administration, file manipulation, system monitoring e troubleshooting;
server e client di: telnet, SSHv2, FTP o TFTP;
AAA Radius con fallback su database utenti locale al nodo;
definizione di profili;
gestione di utenti e gruppi;
registrazione (logging) di tutte le informazioni rilevanti circa le possibili anomalie riguardanti la sicurezza;
supporto di un meccanismo per filtrare e limitare il traffico destinato al “Piano di Controllo” dell’apparato.

Specifiche (punto per punto):

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

3.2.2.2Amministazione Configurazioni

È richiesto che il sistema operativo sia dotato di un’interfaccia utente (shell) con ambiente separato per l’editing delle configurazioni (e.g. configuration mode).

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

3.2.3Alta disponibilità

I dispositivi offerti devono essere predisposti allo stacking ed implementare le funzioni centralizzate di Route Processor e Control Board su almeno due apparati fisicamente distinti (unità master e unità backup) e in configurazione ad alta disponibilità. Per maggiori dettagli tecnici sull’architettura si consulti il capitolo “Architettura e dotazione hardware – Requisiti minimi (par. 5)”;
I dispositivi offerti devono supportare la funzionalità di Failover/Switchover: lo switchover tra l’unità master e l’unità backup dello stack deve avvenire in modo automatico;
I dispositivi offerti devono supportare la funzionalità di Service Software Upgrade (ISSU): gli aggiornamenti e i cambi di release software devono essere eseguiti senza il reboot dell’intero sistema di stack.

Specifiche (punto per punto):

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

3.2.4Monitoraggio e OA&M

3.2.4.1Strumenti di controllo

È richiesto che il sistema operativo sia dotato delle seguenti funzionalità:

Comandi ICMP: ping, traceroute;
Supporto SNMPv1,v2,v3, SNMP Trap, RMON. In particolare è richiesto il supporto delle “Management Information Base” (MIB) previste dagli standard IETF e IEEE e delle relative estensioni proprietarie.

Specifiche (punto per punto):

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

3.2.4.2Traffic Mirroring e Sampling

È richiesto che il sistema operativo supporti le funzionalità di mirroring del traffico e dei protocolli della famiglie NetFlow, sFlow o equivalenti. Le operazioni di campionamento del traffico devo poter avvenire in tempo reale e senza degrado delle prestazioni.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

3.2.4.3Strumenti di OA&M

Gli apparati devono prevedere strumenti per la misura, in tempo reale, di parametri prestazionali di rete quali: delay, latency, jitter e packet loss.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

3.3Funzionalità layer2 OSI

3.3.1802.1D-2004 - XXX Xxxxxxx

Gli apparati devono supportare la funzionalità di switching Ethernet in accordo con lo standard IEEE 802.1D-2004 (MAC bridges). Devono essere in grado di inoltrare le trame/frame Ethernet (unicast, multicast e broadcast), senza perdite, a line rate tra qualunque interfaccia in stato operativo.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

3.3.2802.1AB

Gli apparati devono supportare il protocollo Link Layer Discovery Protocol (LLDP) secondo lo standard IEEE 802.1AB.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

3.3.3MTU

Gli apparati devono inoltrare trame Ethernet con payload di dimensione superiore ai 1500 Byte (in particolare si richiede che il payload possa raggiungere i 9000 Byte).

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

3.3.4Spanning Tree Protocols

Gli apparati devono supportare tutti i protocolli standard IEEE di tipo Spanning Tree Protocols (xSTP). In particolare devono essere implementate tutte le evoluzioni in accordo con gli standard IEEE 802.1D-2004 (Sezione 17: Rapid STP ex 802.1w-2001), 802.1Q-2005 (Sezione 13: Multiple STP ex 802.1s-2002) e 802.1Q-REV (2011).

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

3.3.5802.1Q - Virtual LANs e CoS

Gli apparati devono gestire VLAN ID in accordo con la raccomandazione IEEE 802.1Q-REV (2011) senza alcuna limitazione.

Gli apparati devono gestire CoS in accordo con la raccomandazione IEEE 802.1p: “LAN Layer 2 QoS/CoS Protocol for Traffic Prioritization” (poi inclusa nello standard 802.1D/802.1Q).

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

3.3.6802.1ad – Provider Bridges

È richiesto che gli apparati implementino lo standard IEEE 802.1ad “Stacked VLAN”. Gli apparati devono poter preservare gli identificativi di VLAN (VLAN ID Preservation) anche in modalità “Stacked VLAN”. Gli apparati devono consentire di preservare il campo CoS del VLAN Tag (VLAN CoS Preservation) anche in modalità “Stacked VLAN”. Gli apparati devono permettere la configurazione di S-VLAN multiple sulla stessa interfaccia di accesso.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

3.3.7802.1AX-2008 – Link Aggregation

È richiesto il supporto della funzionalità di Link Aggregation Group (LAG) secondo lo standard IEEE 802.1AX-2008 (ex 802.3ad): Link Aggregation Control Protocol (LACP).

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

Deve essere possibile realizzare aggregati di porte 1GbE sia tra porte dello stesso apparato che tra porte appartenenti ad apparati diversi se in modalità stack. Deve essere possibile realizzare aggregati di porte 10GbE sia tra porte dello stesso apparato che tra porte appartenenti ad apparati diversi se in modalità stack.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

La configurazione degli aggregati non deve avere alcun impatto sulle prestazioni individuali e complessive dell’apparato in termini di throughput e di funzionalità. Deve essere possibile utilizzare VLAN tagging su aggregati 802.1AX senza perdita di flessibilità in relazione alla configurazione, laddove paragonati ai trunk 802.1Q realizzati sulle interfacce fisiche.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

3.3.8Power over Ethernet

Deve essere possibile aggiungere, all’interno dello stesso stack, apparati in grado di erogare potenza ai “powered device” (PD), secondo gli standard IEEE 802.3af e 802.3at, contemporaneamente su tutte le porte di rete 10/100/1000 con connettore RJ45.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

3.3.9Port authentication

Il sistema deve implementare, in modo esaustivo, le raccomandazioni per il “Port-based Network Access Control” (PNAC) secondo lo standard IEEE 802.1X. È richiesto il supporto per i seguenti metodi di autenticazione:

protocollo 802.1X e framework di autenticazione EAP. Nello specifico è richiesto il supporto dello schema EAP-TLS con utilizzo della PKI con certificati X.509 (lato utente e lato server per le comunicazioni tra Radius server e x-supplicant) ed assegnamento della VLAN utente;
“MAC Authentication”;
autenticazione tramite “Captive Portal”.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

Deve essere inoltre supportata l’autenticazione concorrente di utenti multipli per singola porta di rete e deve essere possibile l’utilizzo dei tre metodi di autenticazione (sopra descritti) sulla stessa porta di rete.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

Si richiede l’implementazione delle MIB come da RFC 2011 "SNMPv2 Management Information Base for the Internet Protocol using SMIv2" e, in particolare, il supporto completo della tabella “ipNetToMediaTable”.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

Si richiede il supporto di “RADIUS authentication” (RFC 2138), “RADIUS Extensible Authentication Protocol (EAP) support for 802.1x” (RFC 3579) e “Dynamic authorization extensions to RADIUS” (RFC 5176).

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

Si richiede il supporto di "RADIUS Accounting" come da RFC 2866 e, in particolare, devono essere implementati i seguenti requisiti minimi:

Tipologia Accounting Status Type:
1. Accounting Start;
2. Accounting Stop.
Attributi Radius richiesti:
1. User-Name;
2. NAS-Identifier;
3. NAS-Port;
4. NAS-Port-Type;
5. Acct-Session-Id;
6. Acct-Input-Octets;
7. Acct-Output-Octets;
8. Acct-Terminate-Cause;
9. Called-Station-Id;
10. Calling-Station-Id;
11. Framed-IP-Address.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

3.4Funzionalità di Routing IP

3.4.1IP Router

Gli apparati devono supportare le funzionalità di indirizzamento, routing e forwarding dei pacchetti IP, unicast e multicast, in conformità alle specifiche di Classless Routing con Variable Length Subnet Masking e agli standard IETF rilevanti.

Gli apparati devono supportare la configurazione del routing statico (static routes), di una default route e il routing dinamico tramite le famiglie di protocolli EGP e IGP.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

È richiesto il supporto del protocollo BGP-4, dei protocolli di Routing IGP RIPv2, OSPFv2 e del protocollo multicast PIM.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

Gli apparati devono permettere la configurazione della ridistribuzione delle informazioni di routing tra differenti protocolli con la possibilità di applicare filtri per la selezione delle rotte.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

Gli apparati devono supportare funzionalità di filtering delle rotte dai processi EGP/IGP alle tabelle di routing.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

Gli apparati devono supportare la configurazione di multipath ECMP per le rotte.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

Gli apparati devono supportare i protocolli: ICMP (comando ping e traceroute), telnet, SSHv2 e FTP o TFTP Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

Le funzionalità specificate nei paragrafi seguenti prevedono, anche se non esplicitamente citate, le conformità sugli standard IEEE e IETF.

Nel caso la conformità agli standard richiesti non sia completa o non sia contemplata l’aderenza a particolari funzionalità avanzate incluse nello standard, se ne dettaglino le motivazioni

3.4.2DHCP

Gli apparati devono supportare il protocollo “Dynamic Host Configuration Protocol (DHCP)” secondo la raccomandazione “BootP/DHCP relay agent and DHCP server” (RFC 2131).

Gli apparati devono svolgere le funzioni di “DHCP server” e di “DHCP relay agent” sia per VLAN che per interfacce layer3 OSI.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

3.4.3RIP

Gli apparati devono garantire il supporto del protocollo di routing RIPv2 secondo lo standard RFC 2453 e del protocollo RIPng secondo l’RFC 2080.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

3.4.4OSPF

È richiesto il supporto dello standard OSPFv2 (RFC 2328) con le estensioni OSPF NSSA Option (RFC 1587 o 3101) e “OSPF Opaque LSA Option” (RFC 2370 o 5250).

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

3.4.5IS-IS

Gli apparati devono prevedere la possibilità di supportare il protocollo di routing Intermediate System to Intermediate System (IS-IS), eventualmente soggetto a licenza di attivazione.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

3.4.6BGP

Gli apparati devono prevedere la possibilità di supportare i protocolli di routing Border Gateway Protocol (BGP) e Multiprotocol BGP (MBGP), eventualmente soggetti a licenza di attivazione.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

3.4.7Routing Multicast

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

È richiesto il supporto dei protocolli IGMPv2 (RFC 2236), IGMPv3 (RFC 3376) e delle funzionalità di Snooping per entrambe le versioni.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

Gli apparati, in particolare, devono supportare i meccanismi configurabili di filtering IGMP.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

Così come richiesto per tutte le operazioni di inoltro, gli apparati devono supportare la replica dei flussi multicast a “line rate” in modalità “hardware”.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

3.4.8VRF lite

Gli apparati devono supportare le funzionalità di “Virtual routing and forwarding” (VRF), comunemente denominate VRF-lite. In particolare, devono supportare istanze VRF per i protocolli PIM e IGMP.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

3.4.9Funzionalità IPv6

Gli apparati devono prevedere la possibilità di supportare i seguenti protocolli IPv6, eventualmente soggetti a licenza di attivazione:

OSPFv3;
RIPng;
BGP e MBGP for IPv6;
Ipv6 Multicasting: PIM, MLDv1, MLDv2 e MLD snooping;
Ipv6 CoS: multi-field classification e rewrite.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

3.5OAM, protection & security

Gli apparati devono implementare una suite di protocolli e meccanismi di monitoraggio e controllo per la rilevazione e la gestione dei guasti, dei malfunzionamenti e delle anomalie. Tali meccanismi, oltre a fornire strumenti per il monitoraggio delle performance, devono collaborare in maniera strutturata con i meccanismi automatici di protezione e recovery ad ogni livello del modello di riferimento OSI.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

3.5.1Layer2: Ethernet

Gli apparati devono implementare meccanismi di snooping a layer3 per la segnalazione di anomalie di sicurezza. Sono richiesti, in paricolare, funzionalità di “DHCP snooping” e meccanismi di tipo “IP source guard”.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

Sono inoltre richieste funzionalità layer2 per la gestione e il controllo dei MAC address a livello di porta e la possibilità di mantenere elementi in modo permanente (persistent MAC learning).

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

3.5.2Layer3: IP

Gli apparati devono supportare il Virtual Router Redundancy Protocol (VRRP) secondo lo standard RFC 2338.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

Gli apparati devono implementare il protocollo Bidirectional Forwarding Detection (BFD).

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

Gli apparati devono supportare le estensioni per i meccanismi di “Graceful Restart” (GR), secondo lo standard “Graceful OSPF Restart” (RFC 3623).

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

3.6Qualità del Servizio (QoS)

3.6.1Packet filtering

Gli apparati devono supportare la funzionalità di packet filtering e Access Control List (ACL) sulle interfacce fisiche e logiche a “line rate” in input e in output, con funzioni di classificazione del traffico ad elevata granularità e configurabilità, all’interno dei campi delle intestazioni protocollari dei vari livelli dello stack OSI.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

Devono essere implementate e configurabili almeno le seguenti operazioni “post pattern matching”:

Accept;
Discard.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

Devono essere implementate e configurabili almeno le seguenti azioni associate:

Count.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

3.6.2Policing, Shaping & Scheduling

Gli apparati devono gestire CoS in accordo con la raccomandazione IEEE 802.1p: “LAN Layer 2 QoS/CoS Protocol for Traffic Prioritization” (poi inclusa negli standard 802.1D/802.1Q). Gli apparati devono supportare la QoS secondo il modello DiffServ e poter operare sul campo DSCP dell’header IP per il trattamento differenziato del traffico in classi di servizio (precedence trust and marking).

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

Gli apparati devono prevedere, per il traffico in uscita, la possibilità di configurare sulle interfacce il queueing su almeno 8 code hardware.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

Gli apparati, per le operazioni di “traffic policing” e “scheduling”, devono supportare sulle interfacce di ingresso funzioni di classificazione del traffico sulla base di combinazioni di “header field” protocollari a layer2, layer3 e layer4.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

Gli apparati devono offrire la possibilità di definizione del rate limiting in ingress ed egress delle interfacce.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

4Architettura e dotazione hardware – Requisiti minimi

All’interno di questo capitolo sono dettagliate, oltre ai vincoli architetturali, le richieste minime in termini di capacità e throughput, di modularità e numero interfacce di rete, degli apparati oggetto del presente bando. Tali requisiti sono vincolanti ai fini della fornitura.

4.1Categoria L3 (4 + 7 router IP/MPLS)

Gli apparati della categoria L3 dovranno rispettare i requisiti progettuali e le specifiche tecniche riportate nei capitoli precedenti, che riassumiamo brevemente:

piattaforme di routing IP/MPLS multiservizio con caratteristiche tecniche e prestazionali di categoria “carrier class”.
piattaforme con piano di controllo separato e distinto da quello di inoltro, non bloccanti, ad architettura di forwarding distribuito e “no single point of failure”.
funzioni di packet forwarding e packet processing implementate per la loro esecuzione a line rate.

Possono derogare alle specifiche, di cui ai punti 1 e 2 sopra descritti, gli apparati di tipologia Core-LD che possono operare in oversubscription e per i quali si richiede, come condizione minima, ridondanza solo sugli alimentatori (secondo lo schema 1+1 o 1:1).

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

Le configurazioni hardware e le capacità minime richieste per i nodi Core-HD e Core-LD sono specificate anche alla luce di eventuali espansioni che potrebbero essere necessarie in futuro.

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

Tutti gli apparati dovranno avere lo stesso sistema operativo, le stesse funzionalità e condividere lo stesso hardware modulare; nel caso della tipologia Core-LD, non richiedendo chassis passivo, si richiede, comunque, che i moduli con le interfacce di rete (MDA) siano gli stessi inseribili nelle line card modulari installate negli chassis degli apparati Core-HD.

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

4.1.1Quantità

La fornitura dovrà prevedere i seguenti router IP/MPLS:

Apparati	Tipologia	Quantità
Router IP/MPLS	Core-HD	4
Router IP/MPLS	Core-LD	7

4.1.2Definizioni relative agli apparati di tipologia Core-HD e Core-LD

Di seguito sono fornite le definizioni di alcuni termini utilizzati:

Chassis Slot

Con il termine slot si intende uno degli alloggiamenti, all'interno dello chassis, adibito ad ospitare le line cards per il collegamento alle matrici di switching.

Line Card

Con il termine line card si intende il modulo adibito ad ospitare le interfacce di rete e le forwarding engine con la logica per il forwarding distribuito.

Fabric Module

Con il termine fabric module si intende il modulo fisico, installabile nello slot dello chassis, adibito ad ospitare la control board di sistema, la switching fabric e il routing processor.

4.1.2.1Caratteristiche fisiche

Gli apparati Core-HD devono essere modulari a chassis passivo, predisposti ad uno schema di ridondanza 1:1 o 1+1 su tutte le componenti attive e sugli alimentatori.

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

Il sistema di raffreddamento deve prevedere la possibilità di estrarre e inserire dal telaio i sistemi di ventilazione (hot-insertable and hot-removable fan tray) senza provocare interruzioni nel funzionamento dell'apparato.

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

Si richiede che gli alimentatori forniscano alimentazione in schema di ridondanza N+N, con potenza massima per alimentatore pari a 3000W.

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

Tutti i moduli (fabric, line card, alimentatori) installati all'interno degli chassis devono essere:

Hot-swappable (rimozione moduli senza impatto sul funzionamento del sistema);
Hot-pluggable (inserimento nuovi moduli senza impatto sul funzionamento del sistema).

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

4.1.2.2Alta disponibilità e prestazioni

La configurazione prevede la presenza di un doppio apparato per i siti di Pisa e Milano, quindi la ridondanza è prevista a livello di apparato. Ogni apparato, considerato singolarmente, dovrà avere le seguenti caratteristiche:

i fabric module devono potere essere predisposti per operare con configurazione ridondata 1:1, cioè il blocco di un modulo non deve avere effetto sul throughput del sistema; in caso di schema 1+1 (che prevede la divisione del carico tra moduli) il fault di un modulo non deve comunque avere effetto sul throughput del sistema. Ne deriva che, in entrambi gli schemi di ridondanza, una singola fabric è in grado di fornire il massimo throughput al sistema a pieno carico e in configurazione massima;

Specifiche:

Riferimento pagine documentazione tecnica allegata:

__________________________________________________________________________

i moduli adibiti ad ospitare le control board di sistema, le switching fabric e i routing processor (fabric module) non devono ospitare interfacce di rete se non per la gestione del modulo stesso;

Specifiche:

Riferimento pagine documentazione tecnica allegata:

__________________________________________________________________________

la capacità dei collegamenti tra la matrice di switching e le slot di I/O deve essere la stessa per ogni slot del router (indipendentemente dal numero e tipo delle line cards installate) e deve essere pari ad almeno 160 Gbps Full Duplex (160 + 160 Gbps Half Duplex) per ogni singola switching fabric;

Specifiche:

Riferimento pagine documentazione tecnica allegata:

__________________________________________________________________________

ogni switching fabric, realizzando da sola una architettura non bloccante, deve aver una capacità totale almeno pari alla somma delle capacità di tutti gli slot secondo la formula:

dove N = numero di I/O slot dello chassis

Specifiche:

Riferimento pagine documentazione tecnica allegata:

__________________________________________________________________________

Tutti gli chassis degli apparati Core-HD devono essere identici e installabili in rack standard 800x800 mm e non devono superare le 8 RU (RU, Rack Unit²) in altezza;

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

Tutti i moduli ospitanti le control board di sistema, le switch fabric e i routing processor degli apparati Core-HD devono essere fisicamente identici, avere le stesse prestazioni (throughput compreso) ed essere installabili indifferentemente in qualunque chassis della fornitura.

Specifiche:

Riferimento pagine documentazione tecnica allegata:

4.1.2.3Line card

Tutti i moduli di I/O (line card) e i moduli per i servizi di NAT, IDP e Firewall Stateful Inspection devono essere installabili in tutti gli chassis appartenenti alla tipologia Core-HD.

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

Per ottimizzare l'utilizzo degli slot e per motivi di scalabilità, i moduli di I/O (line card) adibiti ad ospitare le interfacce 1GbE SFP, le interfacce 10 GbE XFP e i gruppi di quattro interfacce OC3-OC12 o una OC48 devono essere realizzati in architettura modulare (separazione delle funzioni dipendenti dal mezzo trasmissivo da quelle di packet processing e packet forwarding) e prevedere due alloggiamenti per moduli adattatori di interfacce fisiche (MDA, Media Dependent Adapters).

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

Il minimo throughput consentito per queste line card modulari, con due slot adibiti ad ospitare due MDA, è 70 Gbps Full Duplex (70 + 70 Half Duplex) al fine di consentire l’alloggiamento di MDA da almeno 20 x 1GbE e di MDA da almeno 4 x 10GbE.

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

I moduli adattatori di interfacce fisiche 1GbE SFP e OC3-OC12-OC48 e le line card modulari che li ospitano devono essere tutti identici tra loro.

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

Gli apparati devono poter ospitare line card con due slot MDA per interfacce di tipo 10/100/1000, 1GbE, 10GbE e line card con throughput idoneo a rispettare la condizione di non-blocking per l’alloggiamento di MDA per interfacce di tipo 40 GbE e 100 GbE. Tutte le interfacce devono lavorare a “line rate” con throughput aggregato “wire-speed” secondo la seguente modularità:

line card con almeno due alloggiamenti per le seguenti tipologie di MDA le quali possono essere combinate arbitrariamente:
1. MDA da almeno 20 interfacce 1GbE (IEEE 802.3z – 802.3ab³ – 802.3ah⁴) con alloggiamenti per transceiver SFP hot-swappable;
2. MDA da almeno 4 interfacce 10GbE (IEEE 802.3ae) con alloggiamenti per transceiver XFP o SFP+ hot-swappable;
line card con almeno due alloggiamenti per le seguenti tipologie di MDA le quali possono essere combinate arbitrariamente:
1. MDA da almeno 10 interfacce 10GbE (IEEE 802.3ae) con alloggiamenti per transceiver SFP+ hot-swappable;
2. MDA da almeno 2 interfacce 40GbE (IEEE 802.3ba) con alloggiamenti per transceiver QSFP+ hot-swappable;
3. MDA da almeno 1 interfaccia 100GbE (IEEE 802.3ba) con alloggiamenti per transceiver CFP hot-swappable.

Le line card dovranno essere previste nel listino del produttore alla data di presentazione dell’offerta da parte del fornitore.

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

4.1.2.4Configurazione chassis per gli apparati di tipologia Core-HD (4 apparati)

Ogni chassis Core-HD dovrà poter alloggiare i seguenti gruppi di interfacce di rete su line card in slot differenti e prevedere, come minimo, il richiesto numero di slot per future espansioni.

4.1.2.4.1Configurazione di 4 chassis Core-HD

Due chassis da almeno 6 slot con seguente modularità e dotazione (fig. 2):

una fabric module con capacità/throughput ≥ 160xN Gbps FD (N=numero di slot);
una line card modulare (throughput ≥ 70 Gbps FD) a due alloggiamenti per MDA hot-swappable: un MDA da almeno 20 x 1GbE SFP e un MDA da almeno 4 porte OC3/OC12 configurabili anche come 1 porta OC48;
una line card per gestire in hardware i servizi di NAT, IDP e Firewall Stateful Inspection;
due slot riservati per espansioni future, di cui almeno uno per l'alloggiamento di un eventuale modulo aggiuntivo per servizi “line rate”.

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

Gli slot per espansioni future dovranno poter ospitare line card con le seguenti modularità:

Almeno 16x10GbE SFP+;
Almeno 1x100GbE;
Almeno 4x40GbE .

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

Slot1: Fabric Module A
Slot2: vuoto (predisposto per ridondanza)
Slot3: MDA 4xOC3/OC12-1OC48	Slot3: MDA 20x1GbE
Slot Vuoto
Line card per servizi di NAT, IDP e Firewall Stateful Inspection
Slot6: riservato future espansioni
Altri eventuali Slot

Figura 1: Configurazione minima per i 2 Router Core-HD di Pisa

Due chassis da almeno 6 slot con seguente modularità e dotazione (fig. 3):

una fabric module con capacità/throughput ≥ 160xN Gbps FD (N=numero di slot)
una line card modulare (throughput ≥ 70 Gbps FD) a due alloggiamenti per MDA hot-swappable: un MDA da almeno 4 porte 10 GbE XFP e un MDA da almeno 4 porte OC3/OC12 configurabili anche come 1 porta OC48.
una line card per gestire in hardware i servizi di NAT, IDP e Firewall Stateful Inspection
due slot riservati per espansioni future, di cui almeno uno per l'alloggiamento di un eventuale modulo aggiuntivo per servizi “line rate”.

Gli slot per espansioni future dovranno poter ospitare line card con le seguenti modularità:

Almeno 16x10GbE SFP+;
Almeno 1x100GbE;
Almeno 4x40GbE.

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

Slot1: Fabric Module A
Slot2: vuoto (predisposto per ridondanza)
Slot3: MDA 4xOC3/OC12-1OC48	Slot3: MDA 4x10 GbE
Slot Vuoto
Line card per servizi di NAT, IDP e Firewall Stateful Inspection
Slot6: riservato future espansioni
Altri eventuali Slot

Figura 3: Configurazione minima per i 2 Router Core-HD di Milano

4.1.2.5Configurazione chassis per gli apparati di tipologia Core-LD (7 apparati)

Per i router Core-LD non è richiesto lo stesso livello di ridondanza dei router Core-HD.

Tutti gli chassis dei nodi Core-LD devono essere identici e installabili in rack standard 800x800 mm.

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

È richiesta ridondanza sugli alimentatori secondo gli schemi 1:1 o 1+1.

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

La modularità è richiesta solo per le line card e le componenti hardware con cui sono implementate le funzionalità di routing processor, switching fabric e control board potranno essere integrate nello chassis.

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

Sono ammesse interfacce 10GbE integrate (“built in”) e gli slot, per l'inserimento dei moduli MDA con le interfacce di rete, dovranno essere almeno due. I moduli MDA con le interfacce di rete dovranno essere gli stessi moduli MDA proposti per le line card modulari degli chassis della tipologia Core-HD; in particolare si richiede il modulo MDA da almeno 4x1GbE SFP (fig. 4).

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

Il router dovrà poter disporre di almeno 2 interfacce 10GbE XFP o SFP+ integrate (eventualmente soggette a licenza di attivazione e delle quali dovranno essere fornite le ottiche opportune) e il throughput minimo del sistema dovrà essere di 40 Gbps Full Duplex (20 + 20 Gbps Half Duplex); è quindi ammesso un tasso di oversubscription.

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

Routing processor, switching fabric, control board e 2x10GbE built in
MDA slot1: 4x1GbE	Vuoto

Figura 4: configurazione minima per 7 router Core-LD

4.1.2.6Transceiver per apparati categoria L3

Si richiede la fornitura di transceiver secondo i seguenti standard IEEE per trasmissione su fibra ottica (62.5/125 MMF, 50/125 MMF e 9/125 SMF) e su ram, e per il trasporto su interfacce OC48:

Interfacce OC48/STM16 di tipo LR:
1. OC48/STM16 transceiverSFPLong Reach LR per fibra SM 80 Km;

IEEE 802.3z – 1000BASE-X
1. Con l’estensione a 10km della distanza trasmissiva (IEEE 802.3ah-2004 – 1000BASE-LX10);
IEEE 802.3ae-10GBASE-L con 10 Km di distanza trasmissiva;
IEEE 802.3ab – 1000BASE-T
1. Compresa l’autonegoziazione delle velocità di trasmissione 10/100/1000 (Section 28D.5 Extensions required for Clause40 - 1000BASE-T);
IEEE 802.3z – 1000BASE-ZX.

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

4.1.2.6.1Moduli SFP

La tabella seguente indica le quantità richieste:

Standard	Tipo di transceiver	Quantità richieste
1000BASE-T	SFP	20
1000BASE-LX	SFP	26
10GBASE-L	SFP+/XFP	16
1000BASE-ZX	SFP	10
SFP-1OC48-LR	SFP	4

4.1.2.7Requisiti di compatibilità

4.1.2.7.1Transceiver SFP

Fermo restando l'adesione ai relativi Multi-Source Agreement (MSA), deve essere certificata la compatibilità dei transceiver SFP con gli omologhi di altri produttori.

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

Deve essere possibile inserire negli slot delle line card degli apparati, transceiver di differenti produttori, senza impatto su funzionamento e throughput. Eventuali perdite di funzionalità di monitoraggio (e.g. come nel caso di “Digital Diagnostics Monitoring”) devono essere specificate.

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

L'utilizzo di transceiver presenti nella matrice di compatibilità non deve invalidare alcun servizio di manutenzione o SLA attivato per l'apparato in oggetto, se non per guasti riguardanti il transceiver stesso o la fibra ottica ad esso collegata.

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

4.2Categoria L2 (2 + 6 multilayer switch)

Gli apparati della categoria L2 dovranno rispettare i requisiti progettuali e le specifiche tecniche riportati nei capitoli precedenti che riassumiamo brevemente:

multilayer Ethernet switch a elevata densità di porte di rete 1G/10G (per la tipologia Accesso-DC) e con porte 10/100/1000 RJ45 (per la tipologia Accesso-Anycast);
piattaforme non bloccanti, con piano di controllo separato da quello di inoltro;
la commutazione del traffico tra apparati diversi appartenenti allo stesso stack non deve impegnare le unità centralizzate (unità master e unità backup dello stack) ;
le funzioni di packet forwarding e packet processing devono essere implementate per la loro esecuzione a line rate.

Tutti gli apparati L2 dovranno avere lo stesso sistema operativo e le stesse funzionalità.

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

4.2.1Quantità

La fornitura dovrà prevedere i seguenti multilayer switch:

Apparati	Tipologia	Quantità
Multilayer Ethernet Switch	Accesso-DC	2
Multilayer Ethernet Switch	Accesso-Anycast	6

4.2.2Apparati di tipologia Accesso-DC (2 multilayer switch)

4.2.2.1Caratteristiche fisiche

Gli apparati della tipologia Accesso-DC devono possedere alimentatori e moduli di raffreddamento identici.

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

Gli apparati della tipologia Accesso-DC devono essere stackable con ridondanza 1+1 sugli alimentatori.

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

Il sistema di raffreddamento deve prevedere ridondanza almeno N+1 sulle ventole con la possibilità di estrarre e inserire il sistema di ventilazione (hot-insertable and hot-removable fan tray) senza provocare interruzioni nel funzionamento dell'apparato.

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

Si richiede che gli alimentatori forniscano alimentazione in schema di ridondanza 1+1 (potenza massima per alimentatore: 1200W).

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

Gli alimentatori e i moduli di uplink installati all'interno degli apparati devono essere:

Hot-swappable (rimozione di moduli senza impatto sul funzionamento del sistema);
Hot-pluggable (inserimento di nuovi moduli senza impatto sul funzionamento del sistema).

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

4.2.2.2Alta disponibilità e prestazioni

Gli apparati devono essere in configurazione ridondata 1+1 o 1+N, cioè il guasto di uno o più apparati componenti lo stack non deve avere effetto sul funzionamento del sistema.

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

Pertanto le funzioni centralizzate di Route Processor e Control Board devono essere eseguite su almeno due apparati fisicamente distinti appartenenti allo stack e in configurazione di alta disponibilità.

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

Nel caso di stack con connessioni locali, la larghezza di banda, o capacità dei collegamenti tra i diversi switch appartenenti allo stack, deve essere pari almeno a 128 Gbps Full-duplex.

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

L’architettura interna deve essere di tipo non bloccante, quindi la capacità totale deve essere almeno pari alla somma delle capacità di tutte le porte aumentata dal throughput totale degli uplink a 10GbE.

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

Tutti gli apparati della tipologia Accesso-DC devono essere identici tra loro e devono poter essere installati in rack standard 800x800 mm e non devono superare le 2 RU (RU, Rack Unit) in altezza.

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

4.2.2.3Moduli Uplink

Gli apparati devono potere ospitare moduli di uplink con interfacce 10 GbE (IEEE 802.3ae) a line rate con throughput aggregato wire-speed secondo la seguente modularità:

Fino a 2 moduli da 4 interfacce 10 GbE (IEEE 802.3ae) ciascuno.

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

Per i moduli di uplink è richiesto che le interfacce siano sempre attive in termini di forwarding e che siano raggruppabili in aggregati 802.1AX, anch’essi sempre attivi, su moduli differenti.

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

4.2.2.4Configurazione apparati di tipologia Accesso-DC

Tutti gli apparati di tipologia Accesso-DC dovranno essere dello stesso modello e prevedere almeno 48 porte 10GbE.

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

4.2.2.4.1Configurazione di 2 apparati (1 stack da 2 apparati) tipologia Accesso-DC

Due apparati con seguente dotazione e modularità:

numero di porte 10GbE SFP+ ≥ 44 ;
alimentatori in configurazione di ridondanza 1+1;
sistema di raffreddamento in configurazione ventole almeno N+1;
slot riservati per espansione ≥1;
Gli apparati in piena configurazione devono poter ospitare quindi fino a 48 porte 10GbE (IEEE 802.3ae), anche attraverso uso di moduli aggiuntivi.

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

4.2.2.5Transceiver per apparati tipologia Accesso-DC

Si richiede la fornitura di transceiver secondo i seguenti standard IEEE per trasmissione su fibra ottica (9/125 SMF) e su rame:

IEEE 802.3ab – 1000BASE-T.

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

4.2.2.5.1Moduli SFP

Nella tabella seguente le quantità richieste:

Standard	Tipo di transceiver	Quantità richieste
1000BASE-T	SFP	70

4.2.3Apparati di tipologia Accesso-Anycast (6 multilayer switch)

4.2.3.1Caratteristiche fisiche

Gli apparati della tipologia Accesso-Anycast devono possedere alimentatori e moduli di raffreddamento identici.

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

Gli apparati di tipologia Accesso-Anycast devono essere stackable con ridondanza 1+1 sugli alimentatori.

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

Si richiede che gli alimentatori forniscano alimentazione in schema di ridondanza 1+1 (potenza massima per alimentatore: 320W).

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

Gli alimentatori e i moduli di uplink installati all'interno degli apparati devono essere:

Hot-swappable (rimozione di moduli senza impatto sul funzionamento del sistema);
Hot-pluggable (inserimento di nuovi moduli senza impatto sul funzionamento del sistema).

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

4.2.3.2Alta disponibilità e prestazioni

Gli apparati devono poter supportare una configurazione ridondata 1+1 o 1+N, cioè il guasto di uno o più apparati componenti lo stack non deve avere effetto sul funzionamento del sistema.

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

Nel caso di connessioni locali, la larghezza di banda o capacità dei collegamenti tra i diversi switch componenti lo stack deve essere pari almeno a 128 Gbps Full-duplex.

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

Tutti gli apparati di tipologia Accesso-Anycast devono essere identici tra loro e devono poter essere installati in rack standard 800x800 mm e non devono superare 1 RU (RU, Rack Unit) in altezza.

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

4.2.3.3Moduli Uplink

Gli apparati devono potere ospitare moduli di uplink con interfacce 1 GbE/10 GbE a line rate con throughput aggregato wire-speed secondo la seguente modularità:

1 modulo da 2 interfacce 10 GbE SFP+ o, senza necessità di sostituire il modulo, 4 interfacce 1GbE SFP.

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

Per i moduli di uplink è richiesto che le interfacce siano sempre attive in termini di forwarding e che siano raggruppabili in aggregati 802.1AX.

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

4.2.3.4Configurazione apparati di tipologia Accesso-Anycast

Tutti i 6 apparati Accesso-Anycast dovranno essere dello stesso modello e prevedere almeno 24 porte 10/100/1000 RJ45 e almeno 2 porte 10GbE.

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

4.2.3.4.1Configurazione di 6 apparati di tipologia Accesso-Anycast

Sei apparati con seguente dotazione e modularità:

numero porte 10/100/1000 RJ45 ≥ 24;
numero porte 10GbE ≥ 2;
alimentatori in configurazione di ridondanza 1+1;
sistema di raffreddamento in configurazione ventole almeno N+1;
Gli apparati in piena configurazione devono poter ospitare fino a 24 porte 10/100/1000 RJ45 e fino a 2 porte 10GbE (IEEE 802.3ae), anche attraverso uso di moduli aggiuntivi.

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

4.2.3.5Transceiver per apparati di tipologia Accesso-Anycast

Si richiede la fornitura di transceiver secondo i seguenti standard IEEE per trasmissione su fibra ottica (9/125 SMF) e su rame:

IEEE 802.3z - 1000BASE-LX.
IEEE 802.3ab – 1000BASE-T.

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

4.2.3.5.1Moduli SFP Fibra

Nella tabella seguente le quantità richieste:

Standard	Tipo di transceiver	Quantità richieste
1000BASE-LX	SFP	10

4.2.3.5.2Moduli SFP Rame

Nella tabella seguente le quantità richieste:

Standard	Tipo di transceiver	Quantità richieste
1000BASE-T	SFP	7

4.2.4Requisiti di compatibilità ottiche

Fermo restando l'adesione ai relativi Multi-Source Agreement (MSA) deve essere certificata la compatibilità dei transceiver SFP e SFP+ con gli omologhi di altri produttori.

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

Deve essere possibile inserire, nelle line card degli apparati, dei transceiver di differenti produttori senza impatto su funzionamento e throughput. Eventuali perdite di funzionalità di monitoraggio (e.g. come nel caso di “Digital Diagnostics Monitoring”) devono essere specificate.

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

5Servizio di assistenza specialistica e manutenzione – Requisiti minimi

La fornitura degli apparati dovrà prevedere un servizio di assistenza specialistica e manutenzione atto a garantire l'esercizio corretto e continuativo delle funzionalità implementate sulla infrastruttura di rete.

Esso deve comprendere servizi di assistenza sistemistica (correzione bug software, rilascio relative patch, aggiornamenti release OS...) e procedure per la gestione e sostituzione delle parti hardware non rientranti nei parametri dichiarati di performance.

Il contratto di assistenza specialistica e manutenzione avrà una durata di 36 mesi dalla data di consegna degli apparati.

Le modalità e le tempistiche alle quali devono essere soggette tali attività costituiscono gli SLA (Service Level Agreement) che il fornitore sarà tenuto a rispettere e che sono definiti nei paragrafi seguenti.

5.1Definizioni

Sono fornite le definizioni di alcuni termini utilizzati:

Network Operations Center (NOC): struttura preposta alle attività riguardanti il corretto funzionamento della rete telematica.

Technical Assistance Center (TAC): centro di supporto tecnico del produttore.

Return Materials Authorization (RMA): autorizzazione alla spedizione delle componenti hardware in sostituzione di quelle riconosciute guaste a seguito dell’analisi della TAC.

Business Day (BD): giorno lavorativo utilizzato dal cliente per la parametrizzazione dello SLA e corrispondente all’intervallo temporale 8:30 am – 5:00 pm (UTC+1) dei giorni feriali (Lun – Ven).

Service Level Agreement (SLA): modalità e tempistiche, concordate tra fornitore e committente, che definiscono le metriche contrattuali per l’erogazione del servizio di assistenza.

Tipologie di SLA oggetto del presente bando di gara:

24x7x365: 24 ore al giorno per tutti i giorni dell'anno;
24x7x1h: entro il tempo massimo di 1 ora a qualunque orario della giornata;
24x7x4h: entro il tempo massimo di 4 ore a qualunque orario della giornata;
8x5xNBD: entro il giorno lavorativo successivo al rilascio dell’autorizzazione RMA.

Guasto: malfunzionamento o degrado di prestazioni parziale o totale del sistema inteso come entità, hardware e software, preposta all’espletamento di determinate funzionalità. Si definiscono quattro livelli di guasto:

Severity1: sistema compromesso nell’esercizio delle proprie funzioni e/o blocco di un servizio ritenuto critico;
Severity2: sistema parzialmente compromesso nell’esercizio delle proprie funzioni, che risultano degaradate, ma con disponibilità dei servizi o perdita di ridondanza nei componenti del sistema;
Severity3: sistema soggetto a malfunzionamenti o anomalie occasionali che non impattano sui servizi erogati, o attività di implementazione di nuovi servizi la cui messa in produzione richiede una certa urgenza;
Severity4: attività riguardanti configurazioni particolari o implementazione di nuovi servizi.

Hardware Delivery: il processo di consegna presso il committente delle parti hardware giudicate guaste. Tipicamente facente parte delle metriche soggette a SLA in alternativa alla semplice spedizione (shipment) che contrariamente al delivery non offre garanzie temporali di ricezione.

5.2Caratteristiche del servizio

Il servizio di assistenza specialistica e manutenzione dovrà essere erogato direttamente dal produttore degli apparati.

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

Gli apparati oggetto del servizio saranno consegnati nelle sedi e i punti di presenza del cliente e installati a cura del personale del Registro stesso.

Sedi cliente:

Area della Ricerca del CNR, Pisa

POP del cliente:

Milan Internet Exchange (MIX), Milano;

London Internet Exchange (LINX), Londra;

New York Internet Exchange (NYIIX), New York;

Equinix, Los Angeles;

Toronto Internet Exchange (TORIX), Toronto;

PTT Metro, San Paolo;

Japan Internet Exchange (JPIX), Tokyo.

Il delivery delle parti in sostituzione di quelle giudicate guaste, laddove previsto dagli specifici servizi di assistenza, prevederà come indirizzo di consegna le sedi e i pop del cliente.

5.2.1Registrazione codici prodotto

Tutte le parti hardware e software proposte nella fornitura dovranno essere registrate ufficialmente sotto il contratto di assistenza specialistica e manutenzione del produttore, tramite il proprio codice identificativo (serial number).

Al cliente deve essere garantita visibilità di tale registrazione tramite accesso su base 24x7x365 a una sezione riservata al contratto presente nel portale web del produttore degli apparati.

La lista dei codici identificativi deve essere sempre sincronizzata con le attività di sostituzione delle parti ritenute guaste a seguito di emissione dei codici RMA.

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

5.2.2Knowledge base & software

Il produttore degli apparati dovrà mettere a disposizione, con accesso 24x7x365, la manualistica completa degli apparati, con esempi di configurazione, la knowledge base relativa, la rendicontazione di tutte le anomalie e limitazioni note, Tech Notes, Security bulletin, alert sul rilascio di nuove release

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

Il produttore degli apparati dovrà mettere a disposizione su base 24x7x365 il servizio di download e di aggiornamento delle release software e firmware installabili sugli apparati oggetto del servizio di supporto.

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

Il produttore degli apparati dovrà mettere a disposizione la possibilità di iscriversi ai technical bulletin per ricevere in maniera tempestiva, alert via email relativamente a bug o notifiche di sicurezza

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

Tutti questi servizi devono essere resi disponibili dal produttore degli apparati attraverso un portale web accessibile dal cliente; tale portale web deve essere lo stesso utilizzato per il servizio al paragrafo 6.2.3 della Scheda Tecnica.

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

5.2.3Trouble ticket system

Per le attività di “troubleshooting” (il processo di analisi e ricerca delle cause dei guasti) dovrà essere garantita la relazione diretta tra il NOC del cliente e la TAC del produttore; non è ammessa nessuna forma di mediazione, all'interno del processo di supporto, tra questi due soggetti. L'apertura della segnalazione di malfunzionamento o guasto deve prevedere l'assegnazione di un ticket di segnalazione e deve essere tracciabile e gestita tramite un sistema di “Trouble Ticket System“. Le comunicazioni tra il NOC del cliente e la TAC del produttore nel processo di supporto dovranno poter essere svolte indifferentemente tramite telefono, posta elettronica e interfaccia web.

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

Il servizio di assistenza specialistica e manutenzione dovrà prevedere un unico punto di contatto per ogni mezzo di comunicazione previsto: unico numero telefonico, unico indirizzo di posta elettronica e di accesso al portale web. In particolare il NOC del cliente dovrà avere accesso al sistema di ticketing del produttore per avere completa visibilità del processo di “troubleshooting” in tempo reale; l’accesso al sistema di ticketing deve essere garantito almeno su canale web.

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

5.2.4Apertura ticket

Per tutti i profili di servizio è richiesto l'accesso diretto e con modalità 24x7x365 alla TAC del produttore degli apparati oggetto della fornitura da parte del personale del NOC del cliente.

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

L’apertura dei ticket deve essere su base 24x7x365 e deve prevedere un tempo massimo di presa in carico della segnalazione di un’ora, cioè secondo la modalità 24x7x1h.

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

Per tutti i profili di servizio è richiesto che tutti i ticket vengano emessi secondo la severity richiesta dal NOC del cliente e eventualmente scalati ad altra severity solo dopo un’analisi congiunta tra detto NOC e l’engineering della TAC del produttore.

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

5.2.5Emissione codice RMA

L’attività di “troubleshooting” deve prevedere, in caso di guasto di una parte hardware del sistema, l’emissione di un codice RMA per la spedizione della parte sostitutiva.

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

5.3Livelli di servizio

Sono richieste due tipologie di SLA in funzione della categoria degli apparati:

Servizio Gold: nodi CORE-LD, Accesso-Anycast; NDCE (= Next Business Day con intervento onsite di un tecnico del produttore)
Servizio Standard: nodi Core-HD, Accesso-DC; ND (= Next Business Day)

5.3.1Servizio Gold

Per gli apparati appartenenti alle tipologie CORE-LD, Accesso-Anycast è richiesto lo SLA minimo di seguito dettagliato.

Servizio di hardware delivery delle parti in sostituzione di quelle ritenute guaste secondo modalità 8x5xNBD dalla diagnosi finale del processo di “troubleshooting” aperto direttamente con il produttore, ed intervento di installazione da parte di un tecnico del produttore per l’attivazione dell’apparato sostitutivo (Installazione, cabling, powering, basic IP configuration, configuration restoration e test di raggiungibilità) . Le spese di consegna e di ritiro delle parti hardware devono essere a carico del produttore o del fornitore.

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

5.3.2Servizio Standard

Per gli apparati appartenenti alle tipologie nodi Core-HD, Accesso-DC è richiesto lo SLA minimo di seguito dettagliato.

Servizio di hardware delivery delle parti in sostituzione di quelle ritenute guaste secondo modalità 8x5xNBD dalla diagnosi finale del processo di “troubleshooting” aperto direttamente con il produttore. Le spese di consegna e di ritiro delle parti hardware devono essere a carico del produttore o del fornitore.

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

5.4Formazione e training

Il fornitore dovrà mettere a disposizione un percorso di formazione, della durata totale di almeno venticinque giorni per due unità di personale tecnico del NOC del cliente da svolgersi entro due anni dalla data di stipula del contratto. Tale percorso di formazione si suddivide in due parti, la prima costituita da un insieme di corsi ufficiali del produttore per una durata di quindici giorni di formazione, la secodna parte consta di un insieme di corsi di altissima specializzazione sul framework MPLS e le relative applicazioni per una durata di dieci giorni di formazione.

PARTE A – Corsi di formazione ufficiali del produttore.

I corsi devono essere tenuti presso l’headquarter del produttore in Europa ed il percorso di formazione dovrà essere composto dai corsi ufficiali dei programmi di certificazione del produttore degli apparati rispettando le tempistiche per le tematiche presentate nelle specifiche tecniche del presente bando di gara. Dovranno essere forniti i dettagli che specificano per quali esami di certificazione il personale del NOC del cliente ottiene l’abilitazione in seguito al completamento del percorso di formazione proposto.

In particolare gli operatori del NOC del cliente dovranno essere in grado di operare autonomamente sugli apparati proposti negli ambiti seguenti:

Configurazione e amministrazione di funzionalità MPLS;

Nello specifico sono richiesti quindici (15) giorni di attività di formazione avanzata sulle tematiche relative al framework MPLS, con speciico riferimento ai protocolli LDP, RSVP, MPLS. E’ richiesto che le tematiche trattate nel percorso di formazione siano complementate da un’approfondita ed estesa attività di laboratorio eseguita su apparati analoghi a quelli oggetto del presente bando di gara.

Configurazione e amministrazione di funzionalità di Qualità del Servizio, QoS;

Nello specifico sono richiesti due (2) giorni di attività di formazione avanzata sulle tematiche relative a protocolli tecniche e tecnologie per l’applicazine delle class-of-service (CoS) ale traffico di rete, con specifico riferimento alla classificazione del traffico, al policyng, allo scheduling al rewriting e al class-based forwarding. E’ richiesto che le tematiche trattate nel percorso di formazione siano complementate da un’approfondita ed estesa attività di laboratorio eseguita su apparati analoghi a quelli oggetto del presente bando di gara.

Configurazione e amministrazione di funzionalità di routing intra dominio e inter dominio;

Nello specifico sono richiesti sei (6) giorni di attività di formazione avanzata sulle tematiche relative ai protocolli di routing IGP ed EGP, con specifico riferimento ad OSPF, IS-IS, BGP, alle tecniche e strumenti di policy routing e load balancing. E’ richiesto che le tematiche trattate nel percorso di formazione siano complementate da un’approfondita ed estesa attività di laboratorio eseguita su apparati analoghi a quelli oggetto del presente bando di gara.

Identificazione e gestione dei problemi hardware, software e problemi di prestazione della rete.

Nello specifico sono richiesti due (2) giorni di attività di formazione avanzata sulle tematiche di troubleshooting dell’hardware, del sistema operativo, dei problemi quali la perdita di pacchetti e variazioni anomale della latenza nonchè il troubleshooting dei protocolli IGP ed EGP, delle politiche di routing, del framework MPLS, delle applicazioni VPN di Layer 2 e Layer 3, del multicast e del CoS. E’ richiesto che le tematiche trattate nel percorso di formazione siano complementate da un’approfondita ed estesa attività di laboratorio eseguita su apparati analoghi a quelli oggetto del presente bando di gara.

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

PARTE B – Corsi di formazione specifici sul framework MPLS e le sue applicazioni.

Il fornitore dovrà inoltre mettere a disposizione un percorso di formazione avanzata della durata di dieci giorni per due unità di personale tecnico del NOC del cliente.

Le attività di formazione devono essere tenute presso l’headquarter del produttore in Europa e devono essere erogate da un istruttore certificato dal produttore che ricopre ruolo di coordinatore e supervisore (xxxxxxx) nello sviluppo dei programmi di certificazione ufficiali del produttore stesso.

Dovranno essere trattate approfonditamente le tematiche relative al framework MPLS con particolare riferimento a quanto esposto nei punti sottostanti:

protocolli e metodologie per l’implementazione di soluzioni di Traffic Engineering (MPLS-TE) mediante protocolli di segnalazione LDP e RSVP;
progettazione e implementazione di servizi VPN basati su MPLS, sia di tipo Layer-3 che Layer-2, questi ultimi dovranno essere discussi e confrontati approfonditamente;
metodologie e strumenti atti all’identificazione e soluzione dei problemi relativi ai servizi VPN basati su MPLS con specifico riferimento all’applicazione delle molte funzionalità previste da questi ambiti.

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

Il fornitore deve produrre la documentazione tecnica che dettaglia le attività proposte, le fasi utilizzate nel programma di formazione e training, la relativa durata e le sedi in cui verrà tenuta l’attività di formazione stessa.

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

Si consideri che il personale del NOC del cliente è già in possesso di conoscenze avanzate negli ambiti sopra elencati e che quindi la formazione richiesta dovrà essere specifica per gli apparati proposti.

6Requisiti migliorativi

6.1Metodo di valutazione

La valutazione tecnica degli elementi migliorativi, come per i requisiti minimi, sarà effettuata in base al contenuto della documentazione consegnata.

Verranno valutate le prestazioni, in termini di capacità di elaborazione e ricchezza di funzionalità, degli apparati secondo le sei macrocategorie costituenti i criteri di valutazione.

Per ogni criterio verranno valutate le prestazioni in termini di performance alla luce della completezza e della qualità dell’implementazione proposta.

Le valutazioni verranno fatte sulle differenti tipologie di apparati basandosi sulle rispettive peculiarità e verranno poi considerati, laddove significativi, elementi di omogeneità e di interdipendenza tra le tipologie in quanto costituenti un unico progetto funzionale.

Ogni requisito tecnico o prestazionale non presente o non chiaramente dettagliato nella documentazione fornita sarà considerato mancante. Si raccomanda la compilazione ordinata e puntuale del documento; la commissione si riserva il diritto di considerare mancante la documentazione non rispondente al layout specificato nel Capitolato Speciale d’Appalto e nei relativi allegati.

E’ richiesto, per la valutazione delle prestazioni degli apparati proposti, di allegare i report dei test di performance prodotti da tester ad alte prestazioni (e.g. Agilent, Ixia, Spirent). Si sottintende che tali tester abbiano throughput e parametri di precisione adeguati alle misure per la categoria degli apparati (carrier grade) oggetto di questo bando di gara. In caso contrario i report non avranno validità e sarà considerato mancante il requisito.

Nei report deve essere chiaramente specificato, onde permettere la valutazione dell’idoneità dello strumento, marca e modello del tester usato. Nel caso i tester utilizzati siano sottodimensionati allo scopo, i report allegati saranno considerati nulli.

6.2Criteri di valutazione

Le soluzioni proposte verranno esaminate alla luce dei seguenti criteri trasversali alle due categorie di apparati:

Criteri	Punteggio
Sistema Operativo e strumenti di monitoraggio	16
Sistema Operativo: omogeneità OS, funzioni, modularità e sicurezza nodi L2 e L3	11
Monitoraggio: monitoring (802.1X), sampling, mirroring “line rate” nodi L2 e L3	5
MPLS	18
Servizi MPLS( L3 VPN, L2 VPN e VPLS) e MPLS-TE: nodi L3	15
Gestione traffico multicast in ambienti MPLS: nodi L3	3
Alta Disponibilità	12
Meccanismi di alta disponibilità a livello di sistema, di rete e strumenti OA&M: nodi L3	8
Meccanismi di alta disponibilità a livello di sistema, di rete e strumenti OA&M: nodi L2	4
QoS e Filtering	6
Granularità e livello di configurabilità delle azioni eseguibili, gestione delle code e funzionalità supportate a “line rate”: nodi L3	4
Granularità e livello di configurabilità delle azioni eseguibili, gestione delle code e funzionalità supportate a “line rate”: nodi L2	2
Performance	16
Dotazione hardware, prestazioni Ethernet, MPLS e IP, replicazione flussi multicast e tunneling nodi L3	12
Dotazione hardware, prestazioni Ethernet e IP, replicazione flussi multicast nodi L2	4
Servizio di assistenza specialistica e manutenzione	2
Qualità del supporto tecnico e della manutenzione.	2

7Sistema operativo e monitoraggio - Requisiti migliorativi (punti 16)

7.1Sistema operativo (punti 11)

7.1.1Apparati tipologie Core-HD, Core-LD, Accesso-DC e Accesso-Anycast.

La capacità di utilizzare il medesimo sistema operativo su tutte le tipologie di apparati: Core-HD,Core-LD, Accesso-DC e Accesso-Anycast. (punti 3)

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

7.1.2Apparati tipologia Core-HD e Core-LD

La presenza di meccanismi interni al sistema operativo atti alla protezione da attacchi DDoS. Al fine della corretta valutazione del requisito in oggetto le funnzionalità devono essere in grado di proteggere dagli attacchi anche per singolo protocollo. Almeno i seguenti protocolli devono essere supportati: ppp, dhcp, tcp. Deve essere inoltre possibile definire manualmente le soglie oltre le quali un flusso di traffico viene definito attacco DDoS; (punti 4)

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

la possibilità di definizione di MIB personalizzate, ovvero MIB che siano popolate da informazioni definite dall’utente. Al fine della corretta valutazione del requisito in oggetto devono essere dettagliate le “Management Information Base” (MIB) presenti sul sistema; (punti 0,5)

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

la possibilità di eseguire gli script automaticamente al cambiare della configurazione dell’apparato (gestione condizioni di trigger). Al fine della corretta valutazione del requisito in oggetto devono essere dettagliate le funzionalità degli strumenti di scripting disponibili; (punti 2,5)

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

la disponibilità di un ambiente di sviluppo (SDK) completamente gratuito per la creazione di nuove applicazioni da utilizzare sulla piattaforma. Al fine della corretta valutazione del requisito in oggetto devono essere dettagliate le “Application Programming Interface” (API) disponibili e il loro livello di interazione con le funzionalità del sistema. (punti 1)

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

7.2Strumenti di monitoraggio (punti 5)

7.2.1Apparati tipologia Core-HD e Core-LD

La presenza di funzioni di port mirroring che supporti almeno i seguenti protocolli: XXx0, XXx0, XXXX, XXXX, X0XXX/Xxxxxxx (Xxxxxx) & bridging; (punti 3,5)

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

la presenza della funzionalità di remotizzazione del traffico in mirroring descrivendo le modalità disponibili; (punti 0,25)

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

la possibililità di configurare le politiche di sampling, accounting e mirroring selezionando il traffico sulla base degli header a livello 2, 3 e 4; (punti 0,25)

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

l’implementazione del protocollo di campionamento del traffico in modalità distribuita sensa degrado delle prestazioni (quindi in hardware) per la generazione dei pacchetti di sampling, in modo tale da non generare impatto sul forwarding. (punti 0,25)

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

7.2.2Apparati tipologia Accesso-DC e Accesso-Anycast

La possibilità di configurare le politiche di mirroring selezionando il traffico sulla base degli header a livello 2, 3 e 4. (punti 0,25)

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

7.2.2.1802.1X

Il supporto di tutti i seguenti attributi RADIUS: (punti 0,25)

accounting-session-id [ access-request | accounting-on | accounting-off | accounting-stop];
accounting-terminate-cause [ accounting-off ];
called-station-id [ access-request | accounting-start | accounting-stop ];
calling-station-id [ access-request | accounting-start | accounting-stop ];
dhcp-gi-address [ access-request | accounting-start | accounting-stop ];
dhcp-mac-address [ access-request | accounting-start | accounting-stop ];
dhcp-options [ access-request | accounting-start | accounting-stop ];
event-timestamp [ accounting-on | accounting-off | accounting-start | accounting-stop];
framed-ip-address [ accounting-start | accounting-stop ];
framed-ip-netmask [ accounting-start | accounting-stop ];
input-filter [ accounting-start | accounting-stop ];
interface-description [ access-request | accounting-start | accounting-stop ];
nas-identifier [ access-request | accounting-on | accounting-off | accounting-start | accounting-stop ];
nas-port [ access-request | accounting-start | accounting-stop ];
nas-port-id [ access-request | accounting-start | accounting-stop ];
nas-port-type [ access-request | accounting-start | accounting-stop ];
output-filter [ accounting-start | accounting-stop ];
accounting-off—RADIUS Accounting-Off messages;
accounting-on—RADIUS Accounting-On messages;
accounting-start—RADIUS Accounting-Start messages;
accounting-stop—RADIUS Accounting-Stop messages;

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

la presenza del meccanismo di DHCP Snooping: specificare se è implementata la possibilità di salvaguardare le tabelle di associazione DHCP anche a fronte di fault o reboot del sistema. (punti 0,25)

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

8MPLS - Requisiti migliorativi (punti 18)

8.1Apparati tipologia L3 (Core-HD e Core-LD)

8.1.1Servizi MPLS (punti 15)

8.1.1.1MPLS

La presenza della funzionalità di frammentazione di pacchetti IPv4 incapsulati in MPLS e il loro instradamento su tunnel: in particolare la gestione degli LSP end-to-end in presenza di collegamenti instradati su tunnel GRE con MTU inferiore alla MTU dell’architettura di rete del Service Provider. Si richiede che tale operazione avvenga a “line rate” con “zero packet loss” e senza l’utilizzo di hardware aggiuntivo. (punti 2)

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

8.1.1.2MPLS L3-VPN

Il supporto dei seguenti standard & features relativi ai servizi L3 VPN MPLS:

L3VPN Service any-to-any, partial meshed & hub-spoke; (punti 0,25)

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

annunci selettivi di informazioni di routing utilizzando il protocollo MP-BGP come indicato da RFC4364, con supporto a extended communities quali target & site-of-origin; (punti 0,25)

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

possibilità di load balancing del traffico all’interno della VRF; (punti 0,25)

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

assegnamento di una label per interfaccia e per VPN oppure di una singola label per VPN; (punti 0,25)

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

supporto della funzionalità di egress-protection per L3VPN come da draft draft-minto-2547-egress-node-fast-protection-01; (punti 3,5)

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

integrazione completa tra diversi servizi L2 MPLS e L3 VPN ad esempio: la possibilità di integrare a livello di routing un servizio di livello 2 quale VPLS utilizzando l’apparato come gateway dei client afferenti e inserendo l’interfaccia di routing all’interno di una Layer 3 MPLS VPN; la capacità di discriminare le VLAN utilizzando construtti di virtualizzazione di livello 2 (virtual switches) con granularità su base interfaccia logica (ovvero suddivisione di interfaccia fisica in più sotto-interfacce logiche ognuna afferente a diversi servizi virtualizzati di livello 2 a loro volta instradate da un gateway inserito in una Layer 3 VPN); (punti 0,5)

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

supporto di configurazioni di router-id & autonomous-system numbers locali alla VRF e diversi da quelli globali; (punti 0,25)

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

supporto della funzionalità “indipendent-domains”; (punti 0,5)

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

supporto del valore di 9192 bytes per l’MTUsull’interfaccia fisica. (punti 0,25)

Specifiche:

Riferimento pagine documentazione tecnica allegata:

______________________________________________________________________________

8.1.1.3MPLS L2-VPN e VPLS

Il supporto dei servizi MPLS L2 Point-to-Point e Multi-Point VPLS, con particolare riferimento all’implementazione degli standard e delle funzionalità sotto menzionate.

PLS L2 Point to Point Services:

supporto segnalazione LDP (Draft-Martini); (punti 0,2)

Specifiche:

Riferimento pagine documentazione tecnica allegata:

_____________________________________________________________________

supporto segnalazione MP-BGP (Draft Kompella); (punti 0,2)

Specifiche:

Riferimento pagine documentazione tecnica allegata:

_____________________________________________________________________

supporto della funzionalità di egress protection per L2Circuits; (punti 0,2)

Specifiche:

Riferimento pagine documentazione tecnica allegata:

_____________________________________________________________________

supporto ridondanza di pseudowire e di circuito d’accesso; (punti 0,2)

Specifiche:

Riferimento pagine documentazione tecnica allegata:

_____________________________________________________________________

supporto di “pseudowire-status-tlv”; (punti 0,2)

Specifiche:

Riferimento pagine documentazione tecnica allegata:

_____________________________________________________________________

supporto segnalazione “Standby Pseudowire” via LDP/PW Status TLV; (punti 0,2)

Specifiche:

Riferimento pagine documentazione tecnica allegata:

_____________________________________________________________________

supporto di OAM; (punti 0,2)

Specifiche:

Riferimento pagine documentazione tecnica allegata:

_____________________________________________________________________

supporto della creazione di uno pseudowire locale per interconnettere due interfacce (local-switching); (punti 0,2)

Specifiche:

Riferimento pagine documentazione tecnica allegata:

_____________________________________________________________________

supporto Multi-Homing (solo per draft Kompella); (punti 0,2)

Specifiche:

Riferimento pagine documentazione tecnica allegata:

_____________________________________________________________________

segnalazione dello stato del link di accesso via MP-BGP (solo per draft Kompella); (punti 0,2)

Specifiche:

Riferimento pagine documentazione tecnica allegata:

_____________________________________________________________________

MPLS L2 Multi-Point Services (VPLS):

supporto FEC 128 (LDP VPLS), FEC 129 (BGP Auto-Discovery + LDP signalling); (punti 0,1)

Specifiche:

Riferimento pagine documentazione tecnica allegata:

_____________________________________________________________________

supporto di Ethernet (0x0005) & Ethernet-VLAN (0x0004) pseudowires; (punti 0,2)

Specifiche:

Riferimento pagine documentazione tecnica allegata:

_____________________________________________________________________

supporto di Interworking tra BGP VPLS & LDP VPLS (possibilità, ad esempio, di aggregare isole LDP VPLS su un Core BGP-VPLS); (punti 0,2)

Specifiche:

Riferimento pagine documentazione tecnica allegata:

_____________________________________________________________________

supporto di Hierarchical VPLS; (punti 0,2)

Specifiche:

Riferimento pagine documentazione tecnica allegata:

_____________________________________________________________________

supporto di BGP VPLS & BGP AD+LDP Signaling VPLS Multi-Homing; (punti 0,2)

Specifiche:

Riferimento pagine documentazione tecnica allegata:

_____________________________________________________________________

supporto di trasporto traffico BUM (Broadcast, Unknown & Multicast) attraverso l’utilizzo di P2MP RSVP-TE; (punti 0,1)

Specifiche:

Riferimento pagine documentazione tecnica allegata:

_____________________________________________________________________

supporto Best-Site ID per riconvergenza rapida del multi-homing; (punti 0,1)

Specifiche:

Riferimento pagine documentazione tecnica allegata:

_____________________________________________________________________

supporto prioritizzazione delle istanze VPLS a seconda dell’importanza del servizio (almeno 3 livelli supportati, high, medium & low); (punti 0,2)

Specifiche:

Riferimento pagine documentazione tecnica allegata:

_____________________________________________________________________

Mac-flushing supportato sia su LDP VPLS che su BGP VPLS; (punti 0,1)

Specifiche:

Riferimento pagine documentazione tecnica allegata:

_____________________________________________________________________

meccanismi di gestione dei MAC Address clienti nell’istanza VPLS richiesti: (punti 0,2)
- MAC Table Timeout Intervals per gestione aging MAC Address;
- gestione della massima dimensione della MAC Table consentita;
- limitazione del massimo numero di MAC Address imparati su una interfaccia;

Specifiche:

Riferimento pagine documentazione tecnica allegata:

_____________________________________________________________________

interoperabilità servizi Layer 2 P2P & Multipoint; terminazione di pseudowire all’interno di una istanza VPLS per realizzare topologie di servizio Hub-Spoke; (punti 0,2)

Specifiche:

Riferimento pagine documentazione tecnica allegata:

_____________________________________________________________________

interoperabilità Spanning Tree Protocol & VPLS Multi-homing nella misura in cui un sito con porta bloccata da STP sia segnalato come sito Standby in VPLS; (punti 0,2)

Specifiche:

Riferimento pagine documentazione tecnica allegata:

_____________________________________________________________________

8.1.1.4MPLS-TE

Le seguenti funzionalità in ambito di MPLS Traffic Engineering:
- supporto dell’annuncio di IGP shortcuts su MPLS-TE per entrambi gli IGP di riferimento, ovvero IS-IS e OSPFv2/v3; (punti 1)

Specifiche:

Riferimento pagine documentazione tecnica allegata:

_____________________________________________________________________

supporto delle seguenti funzionalità MPLS-TE: (punti 2)

Explicit path in Loose Mode (solo OSPF);
Path selection with bandwidth constraint;
Equal cost Load-Balancing tra LSP;
Link protection con LSP secondario;
BFD triggered FRR;
Inter-area MPLS-TE (solo OSPF).

Specifiche:

Riferimento pagine documentazione tecnica allegata:

_____________________________________________________________________

8.1.2Gestione traffico multicast in ambienti MPLS (punti 3)

8.1.2.1MPLS Multicast VPN

Il supporto del proposed standard “Multicast in MPLS/BGP IP VPNs” (RFC 6513) con standard collegati; (punti 1)

Specifiche:

Riferimento pagine documentazione tecnica allegata:

_____________________________________________________________________

il supporto di tutte le seguenti funzionalità in ambito RSVP P2MP LSP: (punti 1)
- meccanismi di Call Admission Control (CaC);
- meccanismi di creazione di rate limiter automatici per forzare le policy di CaC di cui al punto precedente;
- meccanismi di FRR Link-Protection;
- meccanismi di constraint quali link coloring and bandwith reservation.

Specifiche:

Riferimento pagine documentazione tecnica allegata:

_____________________________________________________________________

il supporto di P2MP LSP segnalati via mLDP (draft-ietf-mpls-ldp-p2mp). (punti 0,5)

Specifiche:

Riferimento pagine documentazione tecnica allegata:

_____________________________________________________________________

8.1.2.2IP over MPLS Multicast

La possibilità di instradamento del traffico multicast IP utlizzando P2MP LSPs (punti 0,5);

Specifiche:

Riferimento pagine documentazione tecnica allegata:

_____________________________________________________________________

9Alta disponibilità - Requisiti migliorativi (punti 12)

9.1Apparati tipologia L3 (Core-HD e Core-LD) (punti 8)

9.1.1Fault tolerance: mantenimento del piano di controllo (Core-HD)

Il mantenimento dello stato, nel caso di guasto di uno dei fabric module nella fase di switchover/failover tra i routing processor/switching fabric, per i seguenti protocolli (punti 1) :

OSPF
IS-IS
BGP
MPLS L2 VPN
MPLS L3 VPN
VPLS
LDP based VPLS
RSVP-TE based VPLS (non in auto-mesh)
RSVP-TE LSPs
LDP

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

9.1.2 Alta disponibilità layer2

9.1.2.1 Spanning Tree Protocol

Il supporto del RapidSTP e del MultipleSTP con tempi di convergenza minori o uguali a 1 secondo, anche in condizioni di massimo carico dell’apparato (numero massimo di VLAN/Bridge Domain supportati). (punti 0,5)

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

9.1.2.2802.1AX-2008 – Link Aggregation - scalabilità

Solo per gli apparati Core-HD, il supporto di un numero minimo di 480 LAG per ciascun apparato, con un numero minimo di 16 link per LAG; (punti 2,5)

Specifiche:

_____________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

_____________________________________________________________________________

Solo per gli apparati Core-HD, il supporto dello stesso numero di LAG anche in configurazione MC-LAG (sono ammessi un numero di link per LAG inferiore a 16 nel caso di apparato standalone); (punti 0,5)

Specifiche:

_____________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

_____________________________________________________________________________

il supporto della funzionalità di virtual-switch che permetta la configurazione, al proprio interno, di bridge domain che possono contenere gli stessi VLAN-ID, essendo questi ultimi disambiguati dal fatto di essere presenti all’interno di virtual-switch differenti. Le associazioni Virtual Switch – Porte devono essere fatte sia a livello di porta fisica che a livello di porta logica. (punti 1)

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

9.1.3Fault tolerance & restoration

Al fine di garantire meccanismi di path-protection che garantiscano la protezione dell’endpoint con prestazioni nell’intorno dei 50 msec, il supporto di tutte le seguenti funzionalità: (punti 0,25)

IP Fast Reroute;
Loop Free Alternate (LFA) su protocollo IS-IS;
Loop Free Alternate (LFA) su protocollo OSPF;
MPLS Fast-Reroute con protocollo RSVP-TE sia in modalità facilty backup che one-to-one backup.

l’implementazione del protocollo “Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6” secondo le indicazioni dello standard RFC 5798; (punti 0,25)

Specifiche:

_____________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

_____________________________________________________________________________

un comportamento di tipo “event driven” su protocollo BGP; (punti 0,25)

Specifiche:

_____________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

_____________________________________________________________________________

l’implementazione di meccanismi MPLS di tipo Make-Before-Break (MBB) a “zero loss” direttamente in hardware; (punti 0,25)

Specifiche:

_____________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

_____________________________________________________________________________

il supporto della funzionalità “fast restoration” su servizi Layer 3 VPN come descritto nel draft-minto-2547-egress-node-fast-protection-01; (punti 0,5)

Specifiche:

_____________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

_____________________________________________________________________________

l’implementazione nella soluzione P2MP LSPs che utilizzi RSVP-TE di un meccanismo di protezione di tipo “ facility backup” (N:1) con link protection; (punti 0,25)

Specifiche:

_____________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

_____________________________________________________________________________

la possibilità di assegnazione di differenti livelli di priorità alle diverse istanze VPLS presenti sul nodo al fine di poter personalizzare gli SLA da rispettare per tipologie diverse di servizi VPLS. (punti 0,25)

Specifiche:

_____________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

_____________________________________________________________________________

9.1.4 Strumenti di OA&M

Il supporto dei seguenti protocolli: (punti 0,5)

BFD come da draft-ietf-bfd-mpls-02;
BFD Triggered Local Repair;
MPLS Transport Profile for OAM come da RFC 5654.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

9.2Apparati tipologia Accesso-DC e Accesso-Anycast (punti 4)

9.2.1Fault tolerance: mantenimento del piano di controllo

La possibilità di riavviare i processi a “runtime” (Process Restart); (punti 1)

Specifiche:

_____________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

_____________________________________________________________________________

il supporto alle estensioni di Graceful Restart (GR) relative ai protocolli di routing BGP, OSPF e IS-IS; (punti 0,75)

Specifiche:

_____________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

_____________________________________________________________________________

Nel caso di apparati in stack che sperimentino il guasto di uno degli apparati con funzioni centralizzate di Route Processor e Control Board (unità master e unità backup),il supporto della funzionalità di mantenimento dello stato nella fase di switchover/failover tra i routing processor per i seguenti protocolli di routing: (punti 0,20)

per IPv4: BGP, IS-IS, IGMP con BFD, RIP, OSPFv2;
per IPv6: IPv6 RIPnG, OSPFv3, ISIS con BFD;

Specifiche:

_____________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

_____________________________________________________________________________

nel caso di apparati in stack che sperimentino il guasto di uno dei componenti, la capacità del piano di controllo e di forwarding di non subire alcun degrado prestazionale, con particolare riferimento ai seguenti protocolli di livello 2: (punti 0,25)

protocolli di Spanning Tree:

RSTP;
VSTP;
MSTP;

protocollo di aggregazione delle interfacce:

LAG-LACP;

LLDP e LLDP-MED.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

9.2.2 In Service Software Upgrade

La disponibilità di un processo di upgrade dei componenti dello stack che non causi il riavvio contemporaneo di tutte le unità dello stack stesso, ma bensì il riavvio selettivo di ogni singolo componente; (punti 0,20)

Specifiche:

_____________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

_____________________________________________________________________________

la procedura di upgrade dello stack, la convivenza momentanea di unità con release di sistema operativo diverse, senza alcuna interruzione del processo di forwarding dei pacchetti sulle unità non coinvolte nella procedura di riavvio; (punti 0,20)

Specifiche:

_____________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

_____________________________________________________________________________

nel caso di LAG configurati per aggregare interfacce appartenenti a unità diverse dello stack, l’interfaccia appartenente ad un LAG condiviso tra un apparato che sta effettuando il reboot ed un altro attivo, deve mantenere attiva la procedura di forwarding. (punti 0,20)

Specifiche:

_____________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

_____________________________________________________________________________

9.2.3Alta disponibilità layer2

9.2.3.1802.1AX-2008 – Link Aggregation

Il numero massimo di Link Aggregation Group deve essere non inferiore a 64; (punti 0,20)

Specifiche:

_____________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

_____________________________________________________________________________

la completa equivalenza funzionale dei LAG alle singole interfacce fisiche, senza alcuna differenza di tipo logico o fisico in tutte le loro funzionalità, singolarmente per ogni gruppo aggregato; (punti 0,20)

Specifiche:

_____________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

_____________________________________________________________________________

la presenza di un algoritmo di bilanciamento del traffico che operi nello stesso modo sia in modalità Layer 2 che Layer 3, sia per pacchetti unicast che per pacchetti multicast. (punti 0,20)

Tale algoritmo deve essere di questo tipo:

per pacchetti di tipo IP: S/D IP (su base indirizzo IP Sorgente verso IP Destinazione);
per pacchetti di tipo IP in TCP/UDP: S/D IP, S/D Port ;
non-IP: S/D MAC ;

Specifiche:

_____________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

_____________________________________________________________________________

la capacità di trasportare sui LAG sia traffico di tipo untagged che traffico di tipo tagged 802.1Q (Tagged ports support in LAG). (punti 0,20)

Specifiche:

_____________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

_____________________________________________________________________________

9.2.4Traffic load balancing

La capacità degli apparati di effettuare bilanciamento di traffico anche di tipo Layer 3 se i protocolli di routing rilevano più percorsi paralleli per la stessa rete di destinazione, funzionalità definita Equal Cost Multi Path (ECMP). (punti 0,20)

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

9.2.5Strumenti di OA&M

L’implementazione di uno strumento di misura in tempo reale di dati prestazionali come delay, latency, jitter e packet loss per soddisfare le richieste di real-Time performance Monitoring. Tale strumento deve poter permettere la configurazione di probes generate periodicamente dal router allo scopo di collezionare informazioni in merito ai tempi di attraversamento della rete. (punti 0,20)

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

10Qualità del Servizio (QoS) e Filtering - Requisiti migliorativi (punti 6)

10.1Apparati tipologia Core-HD e Core-LD (punti 4)

10.1.1Route filtering

La presenza di strumenti per la definizione di politiche atte alla manipolazione del routing per mutua redistribuzione tra differenti protocolli, sia dinamici che statici. La mutua redistribuzione deve essere configurabile mediante: (punti 0,5)

scelta del protocollo di origine con supporto esplicito dei seguenti protocolli:
scelta mediante prefissi di rete puntuali o aggregati;
supporto dei seguenti criteri per protocollo:

Specifiche:

_____________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

_____________________________________________________________________________

relativamente al protocollo BGP, la possibilità di creare un annuncio condizionale subordinato alla presenza o meno di uno specifico prefisso nella tabella di routing. (punti 0,25)

Specifiche:

_____________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

_____________________________________________________________________________

10.1.2Azioni effettuabili dall’access list dopo un eventuale match

La capacità di eseguire le seguenti operazioni/azioni dopo il “pattern matching” sulle regole di classificazione: (punti 0,25)

accept;
discard;
reject (Discard sending ICMP destination unreachable message);
count (restituisce il numero di pacchetti che soddisfano l’access-list);
Dscp/Traffic Class (setta dscp/traffic class);
traffic mirroring;
rate-limiting;
Rate Limiting Gerarchico;
log;
sampling per protocollo netflow;
selezione di una routing table/interfaccia/next-hop alternativo per effettuare policy routing;
selezionare una coda specifica per effettuare operazioni di multi-field classification.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

10.1.3Quality of Service – Hardware, Policing, Shaping & Scheduling

Il supporto delle seguenti tecnologie in termini di hardware, funzionalità di rate limiting, shaping & scheduling, come di seguito dettagliato: (punti 2)

Hardware
- 8 code hardware per porta e 16 classificazioni possibili, mediante l’eventuale associazione di più di una classe di forwarding alla singola coda fisica;
- dotazione di un buffer maggiore o uguale a 100msec per ogni singola porta fisica, indipendentemente dalla velocità dell’interfaccia stessa;
- dotazione di un buffer maggiore di 100msec per le porte mediante l’utilizzo di un buffer condiviso fra tutte le porte della singola scheda;
- condivisione dell’hardware da più porte fisiche, da più network processors o da più Packet Forwarding Engines per line card;
- supporto di una coda hardware a diverse priorità (high, medium, low) e di una specifica coda a bassa latenza ove accodare il traffico particolarmente sensibile in termini di ritardi/jitter (e.g., tipicamente il traffico voce su IP);
Policing/Rate Limiting
- supporto di policing della banda con possibilità di scartare il traffico non conforme o di diminuire la priorità per essere eventualmente scartato da meccanismi RED (Random Early Detection);
- supporto di policing “three color” nelle seguenti modalità:
  - “Single rate” oppure “two rate”;
  - “Color blind” oppure “Color aware”;
- supporto di policing gerarchico che supporti due tipologie di traffico, una “Premium” ed una generica;
- supporto a policer di tipo per interfaccia fisica o per interfaccia logica;
- supporto di policer “a cascata”;
Shaping
- supporto dello shaping su interfaccia fisica;
- supporto dei concetti di banda garantita (CIR) e banda massima (PIR);
- supporto di diversi livelli di priorità per CIR & PIR;
- supporto della eventuale possibilità di alzare/abbassare la priorità del traffico garantito e in eccesso;
Scheduling
- supporto della configurazione di:
  - dimensione dei buffer su base temporale e percentuale;
  - CIR espresso in banda/sec o in percentuale;
  - PIR espresso in banda/sec o in percentuale;
  - ripartizione della banda in eccesso (differenza tra PIR e CIR) in maniera proporzionale o percentuale;
  - configurazione esplicita della priorità (ad esempio, alta, media, bassa) della banda in eccesso (differenza tra PIR & CIR);
  - possiblità di limitare il CIR anche indipendentemente dalla banda disponibile mediante la configurazione automatica di un policer da parte del sistema operativo;
Random Early Detection
- supporto delle seguenti caratteristiche in merito al RED:
  - supporto alla configurazione di livelli di probabilità di scarto al raggiungimento di un determinato livello di occupazione della banda;
  - supporto all’interpolazione a fronte della configurazione di un livello minimo e massimo di occupazione banda e le rispettive probabilità di drop;
  - drop dei pacchetti causati dal profilo RED in modalita’ tail-queue (alla fine della coda e non all’inizio);
  - supporto a 4 profili RED per coda.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

10.1.4Gestione QoS su traffico MPLS

L’implementazione dei meccanismi “Maximum Allocation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering” (RFC 4125) e “Russian Dolls Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering” (RFC 4127 ). (punti 1)

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

10.2Apparati tipologia Accesso-DC e Accesso-Anycast (punti 2)

10.2.1Route filtering

La disponibilità delle seguenti funzionalità in termini di politiche di manipolazione del routing per mutua redistribuzione tra diversi protocolli di routing, sia dinamici che statici. La mutua redistribuzione deve essere configurabile mediante: (punti 0,25)

Scelta del protocollo di origine con supporto esplicito dei seguenti protocolli
scelta utilizzando prefissi di rete puntuali o aggregati.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

10.2.2 Packet filtering

La possiblità di poter effettuare le seguenti operazioni/azioni dopo il “pattern matching” sulle regole di classificazione: (punti 0,5)

accept;
discard;
reject (Discard sending ICMP destination unreachable message);
count (conta pacchetti che soddisfano l’access-list;)
Dscp/Traffic Class (setta dscp/traffic class);
traffic mirroring;
rate-limiting;
Rate Limiting Gerarchico;
log;
sampling per protocollo netflow;
selezione di una routing table/interfaccia/next-hop alternativo per effettuare policy routing;
selezionare una coda specifica per effettuare operazioni di multi-field classification.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

10.2.3Policing & Scheduling

La disponibilità di un numero di code harware per porta non inferiore a 8; (punti 0,25)

Specifiche:

_____________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

_____________________________________________________________________________

la presenza di una memoria fisica uguale o superiore a 4 MB avente funzione di buffer di interfaccia. La memoria pari a 4 MB è da intendersi come memoria totale condivisa tra tutte le porte o come somma delle singole capacità di memoria assegnate a ciascuna porta; (punti 0,5)

Specifiche:

_____________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

_____________________________________________________________________________

la capacità dell’apparato di assegnare il traffico in ingresso alle classi di servizio sulla base dei seguenti parametri: (punti 0,5)

informazioni presenti negli header di livello 2 e livello 3 (802.1p, DSCP) dei pacchetti in transito;
i seguenti campi degli header dei pacchetti stessi :
- informazioni L2 (source/destination MAC address, VLAN-ID, e/o 802.1p);
- informazioni L3 (source/destination IP address o network field);
- informazioni L4 (source/destination TCP o UDP port).

Specifiche:

_____________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

_____________________________________________________________________________

11Performance - Requisiti migliorativi (punti 16)

Nella valutazione delle performance, gli elementi migliorativi verranno considerati alla luce del valore aggiunto apportato alle prestazioni del sistema nel suo complesso. A titolo di esempio si consideri il caso in cui si propongano interfacce aggiuntive ma con dati di performance scadenti (e.g. limitazioni sull’efficacia di inoltro in contesti misti IP e MPLS, prestazioni modeste nella classificazione del traffico in presenza di politiche complesse o limiti eccessivi nell’inoltro in presenza di ACL composte da un elevato numero di termini).

Si considera limitato il vantaggio fornito dalla larghezza di banda disponibile in quanto non sfruttabile in contesti richiedenti elevata capacità di forwarding in presenza di politiche di filtraggio o di “multi-field classification” di una certa complessità.

Allo stesso modo si considera limitato l’utilizzo di link aggregati in quanto non sempre utilizzabili per limiti nella configurabilità di funzionalità avanzate e nel bilanciamento del traffico (nonché nella gestione delle code) all’interno del bundle, soprattutto in contesti ad alevata complessità nel “packet processing”.

11.1Apparati tipologia Core-HD e Core-LD (punti 12)

11.1.1Performance hardware di forwarding

Il supporto dei seguenti dati prestazionali a livello di forwarding, sia per la fabric sia per il forwarding della line card. Si ricorda che per i soli apparati Core-LD, la presenza di una fabric rimane un requisito facoltativo e non vincolante.

capacità fabric per slot attuale:
- maggiore di 160 Gbit/s Full Duplex e fino a 230 Gbit/s Full Duplex (punti 1)
- maggiore di 230 Gbit/s Full Duplex (punti 1,5)

Specifiche:

_____________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

_____________________________________________________________________________

capacità massima del backplane non inferiore a 400 Gb Full Duplex; (punti 0,5)

Specifiche:

_____________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

_____________________________________________________________________________

capacità di forwarding aggregato per apparati Core-LD non inferiore a 75 Gbit/s Full Duplex. (punti 0,25)

Specifiche:

_____________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

_____________________________________________________________________________

11.1.2Caratteristiche fisiche

La descrizione dettagliata delle conformità soddisfatte degli apparati proposti alle raccomandazioni NEBS (Network Equipment-Building System); (punti 0,25)

Specifiche:

_____________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

_____________________________________________________________________________

la presenza di documentazione tecnica che specifica la potenza assorbita dagli apparati, espressa in Watt, considerati in configurazione massima ed alimentati a 220V AC; (punti 0,25)

Specifiche:

_____________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

_____________________________________________________________________________

la presenza di documentazione tecnica che specifica la quantità di calore dissipata dagli apparati in configurazione massima, epsressa in Btu/hr. (punti 0,25)

Specifiche:

_____________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

_____________________________________________________________________________

11.1.3Prestazioni globali apparati

Il supporto minimo delle seguenti prestazioni per motivi di scalabilità:

Feature	Core-HD	Core-LD	Punti assegnati
IPv4 RIB	10 Milioni	4 Milioni	0.25
IPv6 RIB	5 Milioni	3 Milioni	0.25
IPv4 FIB	3 Milioni	1 Milione	0.25
IPv6 FIB	3 Milioni	512,000	0.25
Mac Learning	512,000 Mac x NP 1Milione per chassis Rate >100,000 mac/sec HW	512,000 Max Mac >100,000 Mac/sec HW	0.25
Tunnel IP-IP/GRE	4,000 ip-in-ip/gre per Line Card	2,000 ip-in-ip/GRE	0.25
MPLS L2 P2P Services	10,000 L2VPN / 64,000 L2 Circuits	2,000 L2VPN / 16,000 L2 Circuits	0.25
L3 VPN	10,000	2,000	0.50
VPLS	8,000	2,000	0.25

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

11.1.4 L3 tunneling

Il supporto di meccanismi di tunneling a layer 3 implementati direttamente in hardware. L’encapsulation e la decapsulation del traffico deve avvenire direttamente a livello di piano di controllo della Line Card, senza l’ausilio di altro hardware aggiuntivo; (punti 0,25)

Specifiche:

_____________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

_____________________________________________________________________________

il supporto di tutte le seguenti tipologie di tunnel: (punti 0,25)

GRE con Incapsulazione come da RFC2784 e supporto del GRE keep-alive;
tunnel logici per interconnettere partizioni virtuali all’interno dello stesso apparato. Questi tunnel devono supportare almeno i protocolli XXx0, XXx0, XXX, XXXX, XXXXXX;
tunnel IP-in-IP (interfaccia ip) come da RFC2003.

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

11.1.5Performance traffico layer2 e IP

La produzione dei report dei test prestazionali secondo le raccomandazioni RFC 2544 (per traffico Ethernet e IP) e RFC 2889 (caso full-duplex), RFC 3918 (Multicast) e RFC 5180 (IPv6) con l’aggiunta di trame da 3.000, 6.000 e 9.000 Byte. I report per essere considerati validi dovranno essere prodotti secondo i layout commercialmente più diffusi (e.g. Agilent, Ixia, Spirent) e preferibilmente secondo metrica LI-FO (Last In – First Out). I report per essere considerati validi dovranno essere prodotti indicando chiaramente per ogni tipologia di test il numero massimo di termini o filtri (match conditions) supportati per l’esecuzione a wire speed delle funzionalità testate. Nel caso il processing dei pacchetti dipenda dal tipo e dalla profondità di incapsulamento del campo dell’header protocollare utilizzato si specifichino le differenze in termini di delay aggiuntivo e se ne motivi la ragione (e.g. ulteriore lookup o iterazione di processing). Più in generale si raccomanda la maggior completezza possibile nell’esposizione del test setup (in particolare si specifichi sempre in modo chiaro la matrice dei flussi di traffico tra porte e schede) e dei dati aggregati. (punti 3)

11.1.6Performance MPLS

La produzione dei report dei test prestazionali secondo le raccomandazioni RFC 5695 (non si consideri POS/SONET) per ambienti full-duplex con l’aggiunta di trame da 3.000, 6.000 e 9.000 Byte (compreso l’overhead MPLS nel caso la MTU non permetta payload di 9.000 Byte). I report per essere considerati validi dovranno essere prodotti secondo i layout commercialmente più diffusi (e.g. Agilent, Ixia, Spirent) e preferibilmente secondo metrica LI-FO (Last In – First Out). I report per essere considerati validi dovranno essere prodotti indicando chiaramente per ogni tipologia di test il numero massimo di termini o filtri (match conditions) supportati per l’esecuzione a wire speed delle funzionalità testate. Nel caso il processing dei pacchetti dipenda dal tipo e dalla profondità di incapsulamento del campo dell’header protocollare utilizzato si specifichino le differenze in termini di delay aggiuntivo e se ne motivi la ragione (e.g. ulteriore lookup o iterazione di processing). Più in generale si raccomanda la maggior completezza possibile nell’esposizione del test setup (in particolare si specifichi sempre in modo chiaro la matrice dei flussi di traffico tra porte e schede) e dei dati aggregati. (punti 3)

11.2 Apparati tipologia Accesso-DC e Accesso Anycast (punti 4)

11.2.1 Apparati tipologia Accesso-DC

11.2.1.1Dotazione hardware

La disponibilità di capacità switching non inferiore a 480 Gbps Half-Duplex (960 Full-Duplex) e una capacità di trattamento dei pacchetti non inferiore a 14 Milioni di pacchetti per secondo su trame ethernet di dimensione minima di 64 Byte. (punti 0,25)

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

11.2.1.2 Caratteristiche fisiche

La presenza di documentazione tecnica che specifichi la quantità di calore massima dissipata dagli apparati in configurazione massima, espressa in Btu/hr e che non ecceda la soglia di 3.000 BTU/hr. (punti 0,5)

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

11.2.1.3 Power e cooling system - Apparati Accesso-DC:

La presenza di almeno due alimentatori per ridondanza; (punti 0,5)

Specifiche:

_____________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

_____________________________________________________________________________

la presenza di un sistema di raffreddamento con almeno tre (3) ventole con ridondanza in caso di guasto di 1 delle ventole. (punti 0,5)

Specifiche:

_____________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

_____________________________________________________________________________

11.2.1.4 Moduli di uplink - Apparati Accesso-DC:

La presenza delle seguenti caratteristiche: (punti 0,25)

throughput del modulo di uplink di 40 Gbps Half-Duplex (80 Gbps Full-Duplex);
numero di interfacce 10GbE sul modulo non inferiore a quattro interfacce 10 Gbps per modulo);
nessun tasso di oversubscription nel throughput (0 Oversubscriptions).

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

11.2.1.5Performance traffico layer2 e IP

La produzione dei report dei test prestazionali secondo le raccomandazioni RFC 2544 (per traffico Ethernet e IP), RFC 2889 (caso full-duplex) e 3918 (Multicast) con l’aggiunta di trame da 3.000, 6.000 e 9.000 Byte. I report per essere considerati validi dovranno essere prodotti secondo i layout commercialmente più diffusi (e.g. Agilent, Ixia, Spirent) e preferibilmente secondo metrica LI-FO (Last In – First Out). I report per essere considerati validi dovranno essere prodotti indicando chiaramente per ogni tipologia di test il numero massimo di termini o filtri (match conditions) supportati per l’esecuzione a wire speed delle funzionalità testate. Nel caso il processing dei pacchetti dipenda dal tipo e dalla profondità di incapsulamento del campo dell’header protocollare utilizzato si specifichino le differenze in termini di delay aggiuntivo e se ne motivi la ragione (e.g. ulteriore lookup o ciclo di processing). Più in generale si raccomanda la maggior completezza possibile nell’esposizione del test setup (in particolare si specifichi sempre in modo chiaro la matrice dei flussi di traffico tra porte e schede) e dei dati aggregati. (punti 0,5)

11.2.2Apparati tipologia Accesso-Anycast

11.2.2.1Caratteristiche fisiche

La presenza di documentazione tecnica che specifichi la quantità di calore massima dissipata dagli apparati in configurazione massima, espressa in Btu/hr e che risulti inferiore alla soglia di 400BTU/hr. (punti 0,25)

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

11.2.2.2Power e cooling system

La presenza di alimentazione ridondata all’interno dello stesso chassis dell’apparato (senza elementi aggiuntivi); (punti 0,25)

Specifiche:

_____________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

_____________________________________________________________________________

la presenza di un sistema di ventole di raffreddamento costituito da almeno 3 ventole che può essere inserito e rimosso a caldo (hot-swappable). (punti 0,25)

Specifiche:

_____________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

_____________________________________________________________________________

11.2.2.3Capacità sistema

L’assenza di oversubscription nel throughput in condizioni di forwarding line-rate su tutte le porte (uplink e downlink). (punti 0,25)

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

11.2.2.4 Performance traffico layer2 e IP

La produzione dei report dei test prestazionali secondo le raccomandazioni RFC 2544 (per traffico Ethernet e IP), RFC 2889 (caso full-duplex) e 3918 (Multicast) con l’aggiunta di trame da 3.000, 6.000 e 9.000 Byte. I report per essere considerati validi dovranno essere prodotti secondo i layout commercialmente più diffusi (e.g. Agilent, Ixia, Spirent) e preferibilmente secondo metrica LI-FO (Last In – First Out). I report per essere considerati validi dovranno essere prodotti indicando chiaramente per ogni tipologia di test il numero massimo di termini o filtri (match conditions) supportati per l’esecuzione a wire speed delle funzionalità testate. Nel caso il processing dei pacchetti dipenda dal tipo e dalla profondità di incapsulamento del campo dell’header protocollare utilizzato si specifichino le differenze in termini di delay aggiuntivo e se ne motivi la ragione (e.g. ulteriore lookup o ciclo di processing). Più in generale si raccomanda la maggior completezza possibile nell’esposizione del test setup (in particolare si specifichi sempre in modo chiaro la matrice dei flussi di traffico tra porte) e dei dati aggregati. (punti 0,5)

12Servizio di assistenza specialistica e manutenzione - Requisiti migliorativi (punti 2)

Per ogni paragrafo si dettaglino i processi e si illustrino esaustivamente le caratteristiche del servizio proposto. In particolare si diano informazioni corrette per il raggiungimento e per l’accesso alle risorse specifiche richieste.

12.1Apparati tipologie L2 e L3

12.1.1Technical escalation e supporto evoluto

La possibilità di attivare un processo di escalation all’interno della TAC del produttore per la gestione dei trouble ticket; tale escalation deve essere possibile via telefono e via medesimo portale web di cui al paragrafo 6.2.3. (punti 0,25)
la possibilità di un accesso diretto al secondo livello dell’engineering della TAC del produttore già all’apertura del “trouble ticket”. La presenza di questo requisito migliorativo dovrà essere comprovata da un documento ufficiale del produttore in cui è descritto il flusso organizzativo e le eventuali personalizzazioni. (punti 0,25)

Specifiche:

________________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

________________________________________________________________________________

12.1.2Technical Assistance Center

La disponibilità di sistemi di monitoraggio a carattere proattivo e metodi di automazione nella gestione dei trouble ticket (ad esempio la generazione automatica di report sugli apparati per la diagnosi dei guasti o delle anomalie). In particolare sarà valutata la disponibilità di script, in esecuzione sui dispositivi forniti, che rilevano eventuali problemi (hardware, software e funzionali) sui dispositivi e che raccolgono informazioni sugli apparati stessi utili alla risoluzione dei problemi. Di seguito una descrizione più dettagliata delle caratteristiche e funzioni che, se presenti, costituiranno un requisito migliorativo:

gli script devono inviare, nella forma di incident/case, le informazioni raccolte ad una console software centrale installabile presso il cliente ed accessibile via web dallo stesso; (punti 0,5)

Specifiche:

_____________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

_____________________________________________________________________________

il cliente deve poter identificare, sulla console, gli incident di interesse e per questi aprire in automatico, attraverso il semplice click di un pulsante presente sull’interfaccia web della console, casi tecnici presso la TAC del produttore; il sistema dovrà allegare automaticamente al caso tutte le informazioni rilevanti in termini di log, file diagnostica, support-information, ecc, ecc di cui tipicamente una TAC necessita per gestire tempestivamente le problematiche; (punti 0,5)

Specifiche:

_____________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

_____________________________________________________________________________

la console, utilizzando i dati di inventario, delle versioni software installate e dello stato di salute dei dispositivi, dati raccolti attraverso gli script sopra descritti, dovrà offrire funzionalità di gestione proattiva come: notifica proattiva di Bug ai quali l’ambiente specifico del cliente e le sue relative configurazioni hardware e software potrebbero essere soggette; l’analisi e la segnalazione di stati di EOL – end of life / EOS – end of support, ai quali la propria infrastruttura hardware/software potrebbe essere soggetta. (punti 0,5)

Specifiche:

_____________________________________________________________________________

Riferimento pagine documentazione tecnica allegata:

_____________________________________________________________________________

1 Per meccanismi di mantenimento del piano di controllo si intendono le soluzioni proprietarie commercialmente indicate sotto il nome di “Non Stop Routing”

2La RU è l'unità di misura dell'altezza dei rack per apparati di rete. È definita nel documento EIA-310 ed equivale a 1,75 pollici (44,45 mm).

3Si richiede l'implementazione corretta dello standard 802.3ab (1000BASE-T) che prevede l'autonegoziazione

4Qui inteso per la parte di standard relativa alla trasmissione 1000BASE-LX10

Document Metadata

Table of Contents

Allegato G Fac simile Offerta Tecnica

Document Metadata