Ref: GDS_Prumyslové_dny_FINAL_141031_CZ

Zpracování tohoto dokumentu bylo provedeno s veškerou odpovídající profesionální péčí na základě interních informací a dokumentace Ministerstva obrany České republiky (MO) a veřejných zdrojů. Na straně MO tím nevzniká žádná odpovědnost za úplnost a/nebo přesnost uvedených údajů. Toto se vztahuje také na všechny další informace, ústní či písemné, poskytnuté zaměstnanci nebo spolupracovníky MO v průběhu workshopů a případné komunikace před vypsáním případného výběrového řízení. Údaje uvedené v tomto dokumentu jsou informativní, nemají závazný charakter a pro MO z nich nevyplývají žádné závazky a povinnosti.

Ref: GDS_Prumyslové_dny_FINAL_141031_CZ

V souvislosti s připravovaným projektem budování GDS (globální datové sítě) pořádá Ministerstvo obrany České republiky průmyslové dny s výrobci a potenciálními dodavateli technologií a služeb. Cílem workshopů GDS je seznámit výrobce a dodavatele (dále jen zájemce) s předběžným záměrem a způsobem budování GDS a současně získat od zájemců zpětnou vazbu ve formě  základních informací a zkušeností z budování robustních, spolehlivých a bezpečných sítí, které poskytnou garantované datové přenosy s implementovanými službami Quality of Service (QoS) a Multiprotocol Label Switching (MPLS),  informací o síti využívající vlastností Virtual Private Network (VPN) a Virtual Local Area Network (VLAN) pro tvorbu samostatných, bezpečně oddělených datových a hlasových sítí s podporou protokolu TCP/IP IPv6 s bezpečnými bránami do prostorů sítí s protokolem IPv4,  informaci o podpoře nových technologií budování a provozu datových sítí. Ideově plánujeme budování GDS včetně multimediálních služeb rozdělit do několika modulů podle následujícího předběžného schématu (podrobněji je schéma uvedeno v příloze včetně příkladů typických topologií jednotlivých částí sítě; všechny tyto návrhy jsou předběžné a nezávazné). NATO

Řídící a dohledový systém (hlasové služby) Multimediální síť (hlasové služby, IP telefonie)

Dohledový a řídící systém

Dohledový a řídící systém

Datová síť velení a řízení vzdušných sil (řízení leteckého provozu)

Datová síť

TDM/ analog

GSM, pevné linky, VoIP sítě

Důvodem navržené struktury budování GDS je nejen přesněji specifikovat požadavky na jednotlivé části sítě odpovídající potřebám rezortu MO (např. požadavky na síť velení a řízení vzdušných sil vs. požadavky na datovou síť mimo řízení letového provozu), ale i nalézt optimální řešení pro jednotlivé vrstvy sítě (datová část, dohledový a řídicí systém, hlasové služby apod.). Jedním z důležitých cílů průmyslových dní je také získat informace o přístupu zájemců k současným trendům v oblasti síťových řešení, především SDN (software defined networking), a jejich názoru na využití této technologie v budoucím provozu i rozvoje GDS. Obsah workshopů je rozdělen do tří základních oblastí:  Řešení robustní, spolehlivé a bezpečné datové sítě – GDS.  Řešení spolehlivé a bezpečné sítě velení a řízení vzdušných sil.  Multimediální služby v prostředí GDS.

GDS – Průmyslové dny / Tematické oblasti pro workshopy Ref: GDS_Prumyslové_dny_FINAL_141031_CZ

-1-

V následujících částech naleznete stručný popis jednotlivých tematických oblastí pro prezentace na workshopech včetně případných otázek k vyjasnění některých technických požadavků resortu MO na výsledné řešení. Zvolte si, prosím, vlastní úroveň detailu, do kterého chcete při prezentaci svého návrhu řešení v jednotlivých oblastech směřovat. Pozn. Oblasti pro diskusi na workshopech jsou omezeny tímto dokumentem a budou ze strany zástupců MO striktně dodržovány tak, aby všichni zájemci měli stejné podmínky a informace. Pokud budou kladeny ze strany zájemců na workshopech upřesňující dotazy, všechny tyto dotazy včetně odpovědí budou zaznamenány a po skončení průmyslových dní zveřejněny na webových stránkách MO.


-2-

 základní návrh řešení MPLS páteřní a přístupové infrastruktury - vize designu (např. dual-prvky pro vysokou dostupnost), rychlosti 100M, 1G, 10G, přehled podporovaných routovacích protokolů, představení MPLS sítě s možnostmi tvorby L2 point-to-point, L2 multipoint a L3 VPN  oblast QoS a možnosti rozpoznání provozu (QoS marking)  napojení na existující systémy - rozhraní Ethernet, E1 a možná integrace páteřní sítě s WDM řešením  způsoby řešení vysoké dostupnosti sítě (vlastního prvku, v případě výpadku konektivity);  identifikace kritických komponent pro provoz systému a pro zajištění pokračování (kontinuity) činnosti systému  řešení bezpečnosti a centralizování služeb: - přístup pro management - spolupráce s centrálními monitorovacími systémy - přístupová bezpečnost - šifrování provozu - virtualizace služeb - firewall - oddělení kritických centrálních bodů;  řešení „IP ekosystému“ pro zabezpečení základních služeb IP a multimediálních služeb, které jsou centralizovány, ale pro zajištění vysoké dostupnosti a spolehlivosti (režim High availability) jsou jako celek distribuovány do několika center, která především obsahují: - DNS / DHCP server - centrální správa IP adres - AAA server - centrální autentikace - NTP server - centrální zdroj přesného času - dohledový systém a centralizovaná správa - služby Unified communication - server hlasové pošty - tarifikační SW - SW nahrávání  řešení možného nasazení bezdrátových sítí s vazbou na GDS: - předpokládané nasazení bezdrátové technologie v prostředí GDSby mělo zabezpečit bezdrátovou datovou konektivitu a bezdrátovou hlasovou komunikaci; - základním prvkem WLAN má být rozšiřitelný distribuovaný systém s centrálním prvkem, který pracuje v režimu HA (High availability); - WLAN systém musí zajistit bezešvý přechod uživatelských zařízení mezi jednotlivými přístupovými body (AP) bez ztráty IP adresy; - uživatelská oprávnění budou uživatelům přidělována automaticky AAA serverem na základě přihlášení (loginu) do WLAN/SSID; - celý systém bezdrátové sítě musí podporovat monitoring centrálním dohledovým systémem. -


-3-

 jakou verzi (předběžného) standardu SDN Vaše technologie podporují (otevřené standardy, proprietární řešení), jaká jsou Vaše doporučení  možnosti nasazení SDN ve WAN síti s modelovými situacemi, architektura řešení, řídicí systém  podpora/využití v back bone a využití SDN v datových centrech  jaký je přínos SDN proti non-SDN řešení – vhodnost, nevhodnost, zkušenosti;  jaký je přínos SDN z hlediska bezpečnosti;  využití SDN v LAN infrastruktuře (prvky LAN, WLAN, xDSL)  možnosti integrace s páteřní MPLS infrastrukturou  rozšiřitelnost a licenční politika

 řešení napájení jednotlivých komponent  popis řešení napájecího systému  popis řešení vysoké dostupnosti  management a dohledový systém  rozšiřitelnost a licenční politika

 způsoby školení správců systému, stanovení minimálních požadavků.  způsob instalace technologií datové sítě.  způsoby stanovení SLA.  stanovená licenční politika výrobce.  standardní délka záruky, délka garantované podpory (hardware + náhradní díly, firmware, software..)  dostupný web portál pro technické informace a zjišťování informací o dílech v opravě  způsob řešení pozáručního servisu tak, aby byla zachována dostupnost sítě; posouzení výhodnosti nákupu vlastních náhradních dílů nebo zabezpečení pomocí smluvní servisní organizace po celou dobu životnosti systému

Základní (předběžné) požadavky, které musí být v dohledovém systému implementovány: 

rozhraní pro implementaci dalších technologií a produktů jiných výrobců

 víceúrovňová škálovatelnost, která zabezpečí hierarchickou doménovou strukturu a rozdělení dohlížených objektů do logických celků,  analýza APM (Application Performance Management), která zabezpečí: - optimalizaci QoS

1

Tato oblast má přímou souvislost s napájením prvků hlasové sítě a bude vhodné je řešit současně


-4-

- optimalizaci transakcí klientů (sloučení skupiny souvisejících operací s databází, při komunikaci server – klient), sítí a využití serverů - grafické zobrazení stavu aplikační vrstvy pro rychlou detekci problémů - detailní výpisy pro lokalizaci, izolování a řešení daného problému (Drill-down) - monitorování a analýzu VPN tunelů, - diagnostiku a stanovení postupů analýzy problémů a doporučení řešení,  analýza síťového prostředí (Network Performance Management), která zabezpečí: - automatický sběr a agregaci dat o provozním zatížení - grafické zobrazení provozního zatížení a možnost zobrazení problematických míst v síťové infrastruktuře - detailní síťová analýza provozní zátěže s možností nabízení řešení případných problémů (Drill-down) - automatické sledování předem definovaných SLA (Service Level Agreement)  analýza v reálném čase s proaktivní diagnostikou: - nepřetržitý dohled síťové infrastruktury - filtrování událostí, analýza grafické shrnutí syrových dat - přeposílání definovaných událostí pomocí E-mailu/SMS/IM - měření, analýza a vizualizace zátěže v reálném čase s okamžitou identifikací síťových prostředků, ze kterých jsou data analyzována - možnost změn uživatelského nastavení  analýza provozu (Flow Analysis): - sběr informací o zátěži z jednotlivých komponentů sítě, - agregování výsledků a automatické generování předdefinovaných reportů, - ověřený přístup k managementu dle autentizačního serveru (radius, tacacs …) Přístup do centralizované správy hlasového systému musí být ověřovaný pomocí autentizačního serveru (radisu, tacacs, …). Každý správce systému má přístup jen k části, která je v jeho působnosti. Veškerý management je zaznamenáván a lze jej na jednom zobrazovacím zařízení.

Uveďte Váš návrh řešení pro oblasti  implementace šifrování mezi aktivními prvky sítě a mezi aktivními prvky sítě a koncovými zařízeními, transparentní pro přenášené rámce;  použití standardizovaných šifrovacích metod;  řešení odolnosti přenosové technologie proti odposlechu a případné kompromitaci přenášeného obsahu;  vliv šifrování na zatížení provozu aktivních prvků;  systém centralizované správy bezpečnostních politik v síťové infrastruktuře s využitím Vámi nabízených zařízení;  napojení na PKI pro systémy centralizované správy bezpečnostních politik, za předpokladu, že implementace PKI infrastruktury je nedílnou součástí služeb komunikační infrastruktury zajišťující ochranu důvěrnosti a integrity přenášených dat a která bude sloužit pro vydávání certifikátů jednotlivým zařízením a systémům připojeným do komunikační sítě v rámci sítě


-5-

GDS s využitím vlastní resortní veřejné certifikační autority; návrh distribuce certifikátů pro nová klientská zařízení připojovaná do sítě;  šifrování aplikačního provozu nad MPLS VPN infrastrukturou při zajištění dynamického provozu, tj. bez předem definovaných bod-bod tunelů;  aplikace bezpečnostních pravidel přímo na přístupových prvcích sítě (ve vazbě na požadovaný centralizovaný systém správy přístupu sítě2 – LAN, WiMAX, VPN).  způsob detekce typu a stavu3 zařízení;  rozhraní API pro komunikaci s MDM managementem pro získání informací o koncové stanici nebo pro instruování MDM z rozhraní bezpečnostního managementu;  specifikujte u Vašeho řešení zařízení konkrétní možnosti kryptografických algoritmů4 Suite-B na VPN koncentrátorech a VPN klientovi;  správa klientských zařízení (mobilních i stacionárních), aplikaci bezpečnostních politik na VPN koncentrátoru podle bezpečnostní role uživatele, typu zařízení, stavu zařízení (např. jestli je instalována konkrétní verze antiviru, zapnutý personální FW, jaká je hodnota určitých registrů, jestli běží konkrétní procesy, apod.); podporované platformy pro SW VPN klient;  přístup k aplikacím nebo serverům uvnitř sítě přes webovský prohlížeč včetně metod šifrování pro VPN koncentrátor. Funkci www portálu zpravidla poskytuje právě VPN koncentrátor;  relevantní funkce bezpečnostního managementu a uveďte možnosti napojení na další systémy jako SIEM, threat management, apod.;  bezpečnostní pravidla firewallu určujícího jaký provoz může být přenášen dovnitř sítě; funkce firewallu, který musí zajišťovat rozlišení provozu podle typu aplikace (např. musí zamezovat tunelování na portech pro určité síťové služby), klasifikovat webové stránky do kategorií a servery podle reputace;  analýza provozu procházejícího bezpečnostním perimetrem; použití IPS systému na odhalení útoků na zranitelnosti v síti při konkrétních operačních systémech a aplikacích použitých v síti s nastavením Vámi navrženého systému k porovnání vzorků (signatur) tak, aby byl relevantní ke konkrétnímu obrazu sítě (předpokládá se použití samostatných bran pro email a web provoz);  využití prostředků síťové infrastruktury pro poskytnutí informací o datových komunikacích ve vztahu k detekcím bezpečnostních událostí5;  poskytnutí relevantních informací pro forenzní analýzu bezpečnostního incidentu na konkrétní platformě „threat management“?

Mobilita uživatelů a podpora různých typů přístupu do sítě s sebou nese nové nároky na řízení tohoto přístupu. Cílem je eliminovat nesourodé a izolované možnosti správy přístupu v prostředí LAN, WLAN a VPN a vybudovat jednotný systém unifikovaného přístupu do sítě, plně redundantní, splňující nároky na vysokou dostupnost. 2

Pod stavem zařízení rozumíme, jestli zařízení splňuje nebo nesplňuje určitá bezpečnostní kritéria, nejen z hlediska identifikace mapováním skupinové bezpečnostní politiky podle Active Directory nebo LDAP, ale i např., jestli je instalována konkrétní verze antiviru, jestli je zapnutý personální FW, jaká je hodnota určitých registrů, jestli běží konkrétní procesy, jaký je typ zařízení a operačního systému, jaké je místo a technologie připojení, jaký je použitý autentizační protokol, jaké je jméno SSID při WiFi přístupu, apod. 3

např. metoda IPsec s podporou Suite-B s kryptografickými algoritmy AES-GCM/GMAC šifrování, IKEv2, SHA-2 autentizace ESP paketu, šifry na bázi eliptických křivek ECDH a ECDSA. 4

Tyto informace by měly být korelovány se sledováním chování síťové infrastruktury, tak aby bylo možné detekovat, že se v síti vyskytuje kompromitovaná stanice se zasíláním dat na centrální systém s automatickou aktivací předdefinované akce nebo metodologie. 5


-6-

 nástroje pro detekci bezpečnostních incidentů6;  nástroje včetně jejich charakteristiky pro detekci tzv. „Zero Day“ útoků7 mimo výše uvedené;  centralizovaná infrastruktura pro pevný a bezdrátový přístup se společným operačním systémem, společným konfiguračním rozhraním, jednotným řízením přenosového pásma (QoS politiky) s jednotným monitorováním uživatelů a se společnou správou celé infrastruktury pro pevný a bezdrátový přístup (jedním nástrojem).

Oblasti pro workshopy:  monitorování aplikačních toků na end-to-end úrovni, a to jak z pohledu samotné infrastruktury (využití přenosového pásma, síťové zpoždění apod.), tak především z pohledu koncového uživatele (odezva konkrétních aplikací, počty aplikačních transakcí, poruchové stavy aplikací v korelaci na stav sítě apod.);  podpora multimediálních aplikací (interaktivní komunikace pomocí hlasu a videa – point–to– point nebo vícebodová spojení), online nástroje pro týmovou spolupráci uživatelů (sdílení dokumentů, pracovní plochy) a jejich transport z pohledu nastavení QoS a přidělování přenosového pásma; u multibodových multimediálních spojení návrh multicast technologie (architektury a řešení signalizace požadavků na zdroje a služby);  nástroje pro prevenci detekce, troubleshooting a izolaci problémů, ztrátu malých fragmentů komunikace, vyššího rozptylu zpoždění, asymetrického směrování a simulace reálných multimediálních aplikací;  sběru informací o aktuální a dlouhodobé spotřebě elektrické energie, jak vlastních infrastrukturních prvků, tak i koncových zařízení a také způsoby řízení jejich spotřeby.

např. mapování interní infrastruktury a aplikací, odhalení systémů s bezpečnostními slabinami, distribuce škodlivého SW, snaha o komunikaci s řídicími systémy botnet sítě, export dat, apod. 6

7

tj. útoků, které nelze odhalit čistě kontrolou na datové vzorky (signatury)


-7-

SVŘ VzS je tvořená strukturou směrovačů rozmístěných na lokalitách tak, aby topologicky postihly požadavky na datovou a hlasovou komunikaci v prostředí ATM a PVO pro jednotlivé systémy (aplikace) a uživatele. Cílem workshopu je definovat možnosti technologií výrobců z hlediska omezujících podmínek platných pro SVŘ VzS.

Síť musí splňovat normy, které vyplývají z její funkce LPZ (Letecké pozemní zařízení):  předpis ČOS 584103 „KOMUNIKACE ZEMĚ-ZEMĚ, PROVOZNÍ A TECHNICKÉ NORMY LETECKÝCH POZEMNÍCH ZAŘÍZENÍ LETECKÉ RADIONAVIGAČNÍ SLUŽBY“  požadavky na komunikaci jednotlivých konkrétní IS ATM/ATS  národní norma - předpis L 10  EUROCONTROL - ED 136 - ED 138 - ICAO Doc 9869, vydání 2008-Manual on Required Communication Performance (RCP) Ed 1 Pro dosažení certifikace Odborem vojenského letectví (OVL) jsou definovány následující podmínky, které musejí být splněny:  typová certifikace dle technických podmínek  provozní certifikace testy FAT  testy SAT  technická část analýzy rizik. Současné technické podmínky zahrnují použití rychle konvergujícího směrovacího protokolu (např. EIGRP).


-8-

Resort obrany předpokládá provoz multimediálních služeb (hlasové, videokonference atd.) v oddělených virtuálních privátních sítích s podporou QoS (priority queuing) pro hlas a video na všech aktivních prvcích. Aktivní prvky by měly umožňovat dálkové napájení IP telefonů přes Ethernet síť (PoE) dle IEEE 802.3af a dálkový dohled a centralizovanou správu pomocí protokolu SNMP v3. Cílem workshopu je také definovat možnosti realizace multimediálních služeb v prostředí resortu obrany ČR, v návaznosti na různorodé parametry uživatelských vedení na jednotlivých lokalitách. Hlasová síť musí umožňovat připojení dalších resortních i mimo-resortních sítí včetně veřejných poskytovatelů hlasových služeb a sítí NATO. Musí dodržovat standardy ITU-T vydané pro tento způsob komunikace. Navrhovaná hlasová síť musí umožnit připojení koncových šifrovacích zařízení pro přenos utajované informace. Všechna zařízení musí umožňovat vzdálený i místní řízený a zabezpečený přístup.

Základní varianty konfigurace: 1) Nejvyšší dostupnost služeb při vzniku závady  Nezávislý prvek pro spojování hovorů (controller, který zajistí plné služby pro místní účastníky i při výpadku konektivity směrem do WAN sítě, přitom nesmí dojít k přerušení již navázané komunikace).  Veškeré informace o voláních musí zůstat zachovány a po obnovení přenosového prostředí přeneseny do centrálního tarifikačního systému.  Zajištění veškerých služeb bez přerušení již navázané komunikace v případě poruchy nezávislého prvku pro spojování hovorů dalším dostupným prvkem v síti WAN nebo LAN se stejnou funkcionalitou.  Připojení lokality nejméně dvěma nezávislými technologiemi s dalšími prvky sítě.  Přenosovým prostředím na úrovni páteřní sítě je IP prostředí (protokol SIP, H323).  Možnost využití TDM prostředí (E1 rozhraní se signalizací QSIG-GF/SS) podle stavu místní přenosové infrastruktury. 2) Vyšší dostupnost služeb při vzniku závady  Pomocný prvek pro spojování hovorů (controller pro zajištění plných služeb pro místní účastníky i při výpadku konektivity směrem do WAN sítě, přitom může dojít k přerušení již navázané komunikace. Výpadek lokálních služeb nesmí přesáhnout 1 minutu).  Veškeré informace o voláních musí zůstat zachovány a po obnovení přenosového prostředí přeneseny do centrálního tarifikačního systému.  Připojení lokality nejméně dvěma nezávislými technologiemi s dalšími prvky sítě.  Přenosovým prostředím na úrovni páteřní sítě je IP prostředí (protokol SIP, H323).  Možnost využití TDM prostředí (E1 rozhraní se signalizací QSIG-GF/SS) podle stavu místní přenosové infrastruktury. 3) Nižší dostupnost služeb při vzniku závady  Pomocný prvek pro spojování hovorů (controller pro zajištění plných služeb pro místní účastníky i při výpadku konektivity směrem do WAN sítě, přitom může dojít k přerušení již navázané místní komunikace).


-9-

 Přenosovým prostředím na úrovni páteřní sítě je IP prostředí (protokol SIP, H323)  Možnost využití TDM prostředí (E1 rozhraní se signalizací QSIG-GF/SS) podle stavu místní přenosové infrastruktury. 4) Nejnižší dostupnost služeb při vzniku závady  Zabezpečení konektivity analogovým nebo IP rozhraním pro vzdálenou lokalitu (nad 1km).

Workshopy mají v části multimediální služby přinést odpovědi na tato základní témata: 1)

Jak je navrhovaná multimediální síť schopna provozu videotelefone, videokonferencí (HW) a integrace se softwarovými konferenčními systémy, předpoklady a úroveň integrace se zařízeními třetích stran?

2)

Resort obrany předpokládá rozdělení hlasového systému na pobočkovou část a páteřní IPhlasový systém s rozhraními a pro směrování hovorů mezi lokalitami po IP (kde není IP po E1), pomocí controlleru zpracovávajícího uživatelské a systémové požadavky. Vymezení celého hlasového systému směrem k rozhraní DMZ, které musí získat podporu pro komunikační protokoly.

3)

Zohlednění problémů využití VoIP v prostředí bezdrátové datové infrastruktury (WiFi, LTE,..)

4)

Možnosti řešení různých úrovní dostupnosti služeb v různých lokalitách.

5)

Způsob řešení vysoké dostupnosti; úroveň do jaké lze rozdělit jednotlivé služby napříč sítí (škálovatelnost). Vysoká dostupnost značí také, kolik bude použito stupňů zálohy 1, 2, 3,… a kvalita zálohy (např. úroveň služeb přes záložní systém na všech úrovních je stejná = bez omezení uživatele)

6)

Otázka preference používání otevřených standardních komunikačních protokolů v řídící části, koncových zařízení a API u aplikací, které jsou plně zdokumentovány, tzn. podporují alternativy k vlastním proprietárním protokolům s plným zachováním služeb?

7)

Jakým způsobem je u technologie výrobců řešen požadavek na záznam komunikace, případně spolupráce se záznamovými zařízeními jiných výrobců na úrovni IP přenosů?

8)

Způsob udržení centralizace správy i při použití samostatných hlasových bran na lokalitách, minimálně na úrovni dohledových systémů, ale s podporou hromadných = dávkových úprav uživatelských poboček, importů a exportů nastavení atp.

9)

Umí výrobci dodat hlasové brány schopné splnit parametry hlasu s dosahem do 1 km a nad 1 km, a nikoliv jen brány pro kancelářské použití?

10) Jaké standardní a dodatečné ochranné prvky portů hlasových bran proti přepětí lze použít a jaké výrobci doporučují? 11) Je technologie hlasových brán výrobců připravena na opravy po částech (kartách) za provozu? Bránu o 700 účastnících nelze měnit celou kvůli např. 1 portu. 12) Jak se z licenčního hlediska komunikační systémy chovají při použití koncových zařízení od jiných výrobců, přestože používají standardní komunikační protokoly. Z pohledu garance podpory přístrojů lze je užívat i v jiných hlasových systémech (pokud používají standardní komunikační protokoly)?


- 10 -

13) Pokud výrobce upřednostňuje využití digitálních poboček jaký je jejich uživatelský přínos oproti analogovému telefonu se stejnými službami (např. rozdíl v celkových nákladech rozložených na port - cenách na pobočku). 14) Softwarová telefonie – multiplatformní klientský software (Windows, Mac, Apple IOS, Android, Windows Phone) 15) Licenční politika možnosti v rámci nakoupených licencí migrace z jednoho typu do jiného (Voip SW <-> Voip HW <-> Analog / TDM), při zachování celkového počtu i v závislosti na změnách v rezortu bez vícenákladů. 16) Pozáruční licenční politika - je pro udržení aktuálnosti systému (update/upgrade), změnách v kapacitě (počtu licencí) a množství lokalit nutný jakýkoliv placený kontrakt s výrobcem? 17) Možnost a úroveň virtualizace na všech aplikačních serverech (tj. včetně hlasových systémů). 18) Virtualizace obecně nezávislá na dodavatelích těchto prostředků. Vliv na licence při migraci virtuálních strojů (potřeba placené spolupráce s výrobcem/kontraktorem). 19) Nutnost integrace virtualizačních prostředí do dohledových systémů a zpráva virtuálních strojů přes webové rozhraní nebo clientskými aplikacemi spustitelnými ve Windows? 20) Management dohledu s preferencí univerzálních (OS nezávislých) řešeních, případně využití webových rozhraní ve standardech zvládnutelných v běžných web-prohlížečích (bez nutnost pluginů třetích stran). 21) Centrální hlasové služby voicemail, presence (pro ovládání IP telefonů, chat), tarifikace, centrální adresář, faxserver včetně jejich virtualizace a následná schopnost migrace do datového centra. 22) Způsob integrace služeb s komunikačními prostředky (Exchange, MS Lync, atp). 23) V případě řešení hlasových služeb softwarovou telefonií z PC je nutné určit způsob oddělení pouze hlasového provozu od zbytku datového provozu z konkrétního PC (vliv na QoS). Datová infrastruktura musí softwarové telefonii umožnit na definovaných přístupových routerech nastavit řízený prostup pouze RTP toků a signalizace mezi počítači a prvky hlasového systému. 24) Způsob spolupráce mezi přístupovými routery a řídícími prvky hlasových systémů (brány a servery) na rezervaci pásma pro multimediální provoz ještě před začátkem komunikace (spolupráce Qos a RSVP). 25) Možnosti využití otevřeného SW řešení (open source application); modelová aplikace v prostředí GDS včetně centrální správy a licenční politiky; porovnání tohoto otevřeného řešení s proprietálním řešením výrobců.


- 11 -

Ref: GDS_Prumyslové_dny_FINAL_141031_CZ

Recommend Documents