DOCSLIB.ORG

Split Architecture

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Split Architecture SPARC Deliverable 2.2 Revised definition of use cases and carrier requirements Editor: Fritz-Joachim Westphal, Mario Kind, Deutsche Telekom AG Deliverable nature: Report (R) Dissemination level: Public (PU) (Confidentiality) Contractual delivery date: M24 Actual delivery date: M27 Version: 1.0 Total number of pages: 80 Keywords: Use cases, carrier requirements, techno-economic analysis, business developments Abstract This document reviews the use case access/aggregation and the related defined use cases on Seamless MPLS or SDN approaches to MPLS transport, multi-service/-provider environments (service creation), mobile backhaul, Software Defined Networking application in context of IEEE 802.11 compliant devices and dynamic control composition. It compromises the feedback from the work packages 3, 4 and 5 about development of concepts, prototypical implementation and validations. In addition it contains a review of the selected carrier requirements and groups of requirements accordingly. Moreover the deliverable provides a comprehensive overview of the results of task 2.3, a techno-economic evaluation of a mobile backhaul network scenario with detailed analysis of capital as well as operational expenditures. In addition uncertainties based on the estimated assumptions are covered by a sensitivity analysis. Beside techno-economic analysis, the evaluation of the business environment was continued and scenarios about future directions developed, verified and evaluated. Deliverable 2.2 Split Architecture - SPARC Disclaimer This document contains material, which is the copyright of certain SPARC consortium parties, and may not be reproduced or copied without permission. In case of Public (PU): All SPARC consortium parties have agreed to full publication of this document. In case of Restricted to Programme (PP): All SPARC consortium parties have agreed to make this document available on request to other framework programme participants. In case of Restricted to Group (RE): All SPARC consortium parties have agreed to full publication of this document. However this document is written for being used by <organisation / other project / company etc.> as <a contribution to standardisation / material for consideration in product development etc.>. In case of Consortium confidential (CO): The information contained in this document is the proprietary confidential information of the SPARC consortium and may not be disclosed except in accordance with the consortium agreement. The commercial use of any information contained in this document may require a license from the proprietor of that information. Neither the SPARC consortium as a whole, nor a certain party of the SPARC consortium warrant that the information contained in this document is capable of use, nor that use of the information is free from risk, and accepts no liability for loss or damage suffered by any person using this information. Imprint [Project title] Split Architecture [short title] SPARC [Number and title of work package] WP2 – Use cases / Business scenarios [Document title] D2.2 Revised definition of use cases and carrier requirements [Editor] Mario Kind, Deutsche Telekom AG [Work package leader] Fritz-Joachim Westphal, Deutsche Telekom AG [Task leader] Fritz-Joachim Westphal, Deutsche Telekom AG Copyright notice © 2012 Participants in project SPARC Optionally list of organisations jointly holding the Copyright on this document © SPARC consortium 2012 Page 2 of (80) Deliverable 2.2 Split Architecture - SPARC Executive summary Besides analysing new business opportunities of a Split Architecture, the objective of work package 2 is the description of use-cases and the definition of carrier-grade requirements, derived from these use cases. Both will be provided as input to the development of the technical aspects of a SplitArchitecture in work package 3. The second and final contribution to fulfil the objective is covered in this deliverable. The deliverable gives an overview of the work on the use case access/aggregation, which was selected from three use- cases covering all important aspects of a carrier environment as defined for next-generation-networks by ITU-T. The use case was subdivided into six sub-use cases representing service areas as well: - General architecture - Seamless MPLS or SDN approaches to MPLS transport - Multi-service and multi-provider environments (service creation) - Mobile backhaul - Software Defined Networking application in context of IEEE 802.11 compliant devices - Dynamic control composition Each use case was covered by work streams, starting with a set of requirements (WP2), followed by the development of concepts (WP3) and prototypical implementations (WP4) and finally testing of functional and performance aspects (WP5). Overall it is guaranteed that each use case is sufficiently covered by the developments of SPARC. The work was based on 67 requirements detailed in D2.1. They were prioritized with respect to overall importance, fulfillment in existing architecture concepts and/or existing implementations and their relevance for one or more use cases. In the SPARC context four requirement groups were identified. During the course of the project, these groups required further refinement. In total, twelve requirement groups have been identified: (a) Recursive control plane (b) Network management (c) Openness and extensibility (d) Virtualization and isolation (e) OAM (technology-specific MPLS OAM / technology-agnostic Flow OAM) (f) Network resiliency (g) Control channel bootstrapping and topology discovery (h) Service creation (i) Energy-efficient networking (j) Quality of service (k) Multilayer aspects (l) Scalability These twelve groups of requirements cover the majority of high priority requirements identified in D2.1. The mobile backhaul use-case was further analysed with a first attempt of a techno-economic cost study. Given the immaturity of SDN in the mobile backhaul context several assumptions have to be made, often based on expert opinions or results from previous preliminary studies. To cope with the uncertainty related to the gathered input a sensitivity analysis was performed to examine the effects of modifications of the critical parameters on the overall results. Two different scenarios were defined, one scenario covering state of the art design principles (“classical scenario”) and the other scenario to reflect advanced SDN developments (“SDN scenario”). For the considered parameters, the SDN scenario provides a capital expenditure advantage at 12%. The majority of capital expenditures savings is based on modifications in the pre-aggregation stages which is explained by the high number of sites at this partition of the network. A second contribution is based on the lower cost of first time installation. The savings in the pre-aggregation sites amount to up to 13% which is a bit higher than the total reduction of 12%. Introducing SDN however also involves introducing of centralized controllers to the network architecture which accounts for an extra 3% of the total cost. © SPARC consortium 2012 Page 3 of (80) Deliverable 2.2 Split Architecture - SPARC Within the OpenFlow community the focus is often on the promised capital expenditures reductions. Little attention is however given towards operational expenditures. The analysis shows an 11% reduction in OpEx in the SDN based scenario. The main benefits can be located in the network operations center where the cost of operational processes such as service provisioning and service management is reduced by 3% and 6% respectively. The environmental cost (energy consumption) has not been increased nor reduced. It could be however argued that the energy consumption of the router is reduced because part of the control plane functionality is now taken over by the SDN controller. This is open for further research. The performed sensitivity analysis introduces an overview on the level of uncertainty on the following parameters: - Cost of a SDN controller has a rather low impact on the capital expenditures - Number of OpenFlow enabled network elements one SDN controller is able to steer has a rather low impact as well on the overall cost basis - Effect of wholesale price discounts by vendor on SDN advantage has a contradictory effect o The benefits of SDN on capital expenditures are reduced when higher discounts are applied o The benefits of software defined networking on operational expenditures increase when higher discounts are applied o The overall delta between the scenarios varies from 12% without discount to 9% for capital expenditures and from 10.7% to 12.3% for operational expenditures with 50% discount - Effect of cost reduction in cost of operating system of router increases the delta between the scenarios by 50% for capital expenditures - The highest effect of change has the effect of extra reductions in hardware cost because of specialization and interoperability of devices with potential reduction of price points for the SDN scenario by 50% and a delta of up to 47% (CapEx) and 25% (OpEx) respectively. Again one has to mention that there exist a number of uncertainties in the techno-economic analysis and this has to be taken into account when viewing the results. Up to date, the impact of SDN on the existing telecommunication business environment is unclear. Therefore experts from the project tried to outline today’s market roles, their functions and possible future market roles. Based on this analysis, a questionnaire was developed, trying to answer the key questions: Which
Load more

Recommended publications
  • The Compelling Case for Modernizing Your Campus and Branch Office Networks Now
    Datasheet | June 2019 The Compelling Case for Modernizing Your Campus and Branch Office Networks Now Enterprise networking has become a true challenge Vendor lock-in, aging and soon-to-be-unsupported architecture, sprawling switch farms, and aggressive sales for most IT shops. cycles all conspire to make it seemingly impossible to innovate in the current network switching landscape. Pica8 addresses IT’s need to reduce the complexity of the switch environment while enhancing functionality. Our unique, powerful open, standards-based approach to white-box networking reduces the number of managed switch network elements by up to 25x per site. Pica8 reduces CapEx and OpEx costs by as much as 80% through simplified deployment and management that supports the flexibility, agility, and scalability today’s competitive climate demands. Founded in 2009, Pica8 has been at the cutting edge of networking, ensuring open white box switches offer the same benefits in enterprise networking as they’ve afforded in the server world. For too long, organizations have been trapped by brand name gear, costly licensing, and one-size-fits-all code with glacial update cycles. With open white box networking, IT and DevOps teams can put their programming skills to work to tailor a switch network customized to their organization’s needs. Pica8 is committed to unshackling businesses from the confines of their decades-old network architecture, enabling them to manage dozens to hundreds of multivendor open switches – including branch, core, and field offices – as if they were a single, logical, high-bandwidth switch. By building all elements of the network for an open environment, Pica8 has also created a switch universe that caters to the creativity of internal IT and DevOps teams.
    [Show full text]
  • Whitebox Networking Hardware
    IPv6 Capability of Whitebox Networking Jeremy Duncan [email protected] @TachyonDynamics Overview • What is Whitebox Networking • Pros/Cons • The hardware • The software • The IPv6 Capability and the SDN intersection What is Whitebox Networking? OEM 3rd Party Operating System Switch What is Whitebox Networking? • The software disconnected from the hardware • Buy switch/router hardware, buy or install another operating system • The operator decides the mix of the two – not the networking vendor • Some big uses: • Facebook uses Wedge/FBOSS – Centos-like • Google uses Pluto – Big Switch-like Pros – Whitebox Networking • No vertical lock-in – bare metal philosophy • Hardware servers don’t do this, why should switches? • Scripting!!! Perfect for auto provisioning • BASH, Python, Ruby, Puppet, etc • You build to your network, not the other way • Avoid the self-licking ice cream cone • Largest expense in enterprise IT today is the network Cons – Whitebox Networking • Network engineers can no longer be sectarian in their chosen vendor • Operators have to understand the details of their network now, in order to choose the OS • OS and hardware support is so-so • Getting better, various on OS vendor • Must be familiar in GNU/Linux Whitebox Networking Hardware • The “big 5” hardware switch makers Quanta • Quanta • Acton/Edge-Core Acton/Edge-Core Penguin Arctica • Delta/DNI/Agema • Dell (limited) Delta/DNI • Penguin Computing Agema ToR Dell S4810-S6000 Whitebox Network OS • The “big 3” Network OS • Big Switch (SwitchLight OS) • Pica8 (PicOS)
    [Show full text]
  • Bare Metal Networking- Leveraging “White Box'' Thinking
    Bare Metal Networking- Leveraging “White Box’’ Thinking WHITEPAPER Bare Metal Networking-Leveraging “White Box’’ Thinking Switch commoditization has created new approaches to lower CapEx while improving functionality Conversations are swirling throughout the tech industry about whether white box switches are disrupting the networking industry in the same way that white box manufacturers helped commoditize the server industry. $4 Blade/Embedded Fixed/ Top-of-Rack Modular/Chassis $2 CREHAN RESEARCH Inc. Revenue in $ Billions $0 1H09 1H13 Figure 1. Data Center Ethernet Switch Revenue If this InfoWorld article where the authors predict a sizeable uptick in white box sales over the next five years is not enough to persuade you—see Figure 1, consider that Cisco CEO John Chambers himself has recently discussed the threat of white boxes eroding his company’s margins. Conceptually, white box switching helps leverage the idea of communization of mass-produced hardware, while creating an operational abstraction between the “metal” (in our case, white box switches from original device manufacturers, or ODMs) and the network operating system (OS). Bare Metal, White Box Switches Defined The “white box” phrase has been used to describe generic PCs built by non-branded manufacturers for many years. “Bare metal” refers to the hardware only, and is similar conceptually to a server with no loaded software. Regardless of server hardware differences, all servers get our choice of a server OS that is mostly unified across a specific operation. In recent years, the networking industry has embraced “bare metal” and “white box” terminology. For example, the recognized network stack is considered to include the hardware or “white box” network OS and applications that run on the OS.
    [Show full text]
  • Pica8 Enterprise Solution
    Contact Pica8 at: www.pica8.com/company/contact-us Solution Brief Secure White-Box Networks for the Enterprise The new best practice: A dual-control Linux Network Operating System (NOS) paired with disaggregated L2/L3 white-box switching brings innovation back to the enterprise The intent-based Networking suite of technologies—and the white-box networking market it ushered in (open software running on multiple hardware platforms) are collectively on track to become a $12.7 billion market by the year 2020. In the last 12 months, white-box networking has escaped the event horizon of its birth in the data center and has expanded into wholly new market segments, specifically mainline enterprises—and their remote branch offices—and SMBs. With the maturation of underlying Network Operating System (NOS) technologies over the last few years, 2018’s white-box-centric solutions—now sporting higher specs, bulletproof reliability and global support—are successfully penetrating a number of enterprise verticals, where maintaining differentiation depends on keeping a technological edge against the competition. These next-gen white-box solutions are surpassing the limitations that legacy L2/L3 network equipment, architecture, and support have historically placed on their users. As a result, enterprise companies are now rediscovering their ability to differentiate in their own markets based on new technology that also slashes their networking equipment and operational costs. White-Box Network Operating System for the Enterprise Solution Brief 1 With hundreds to thousands of devices needing to be connected in each location, managing network services in Enterprise offices presents significant challenges. Network services support everything from the core Data Center to employee and IoT devices; internal and guest Wi-Fi; Internet access; forward-deployed specialized data centers; and VoIP phones and video.
    [Show full text]
  • White Box Networking in Remote and Branch Offices
    White Box Networking in Remote and Branch Offices WHITEPAPER White Box Networking in Remote and Branch Offices With hundreds or thousands of locations to be connected, managing network services in remote or branch offices can be a significant challenge. Network services support everything from internal and guest Wi-Fi to Internet access, internal data networking, VoIP phones and video. All of these services have to be delivered and managed in a cost-effective way, but many solutions require rolling an IT truck to each location (prohibitively expensive) or adopting expensive proprietary hardware along with onerous support contracts. Pica8 offers a different solution – white box switches and networking software that support all the features a branch office needs with remote management, but without the high cost and without vendor lock-in. This paper describes Pica8’s approach to remote and branch office networking. Remote and Branch Office Networking Challenges Branch office networks have several common elements. Branches are hundreds or thousands of miles away from the corporate headquarters, and there are typically no trained IT people on site in each branch. Rather, these networks are centrally controlled and administered from the corporate data center. Recognizing the need for trouble-free, centrally-managed networking infrastructure many years ago, branch office equipment vendors built proprietary, fully-integrated systems to handle networking chores. The problem with this approach is that entrenched vendors with proprietary hardware/software architectures demand high costs as they extend their contracts with locked-in enterprise customers. In addition, full-service 24x7 solution support (hardware, software, interoperability and applications) adds to the cost, exacting the steepest possible pricing from enterprise customers.
    [Show full text]
  • Big Iron, Fast Photons and SDN: the Hard, Bright and Soft Sides of Arista's Strategy
    Big iron, fast photons and SDN: the hard, bright and soft sides of Arista's strategy Analyst: Eric Hanselman Peter Christy 2 Jul, 2013 It's been a busy spring for Arista Networks, with expanded software functionality, upgraded switch modules and a Best of Interop/Grand Prize win for its 7500 Series modular switches. The new software capabilities include integration of its Arista EOS switch operating system with OpenStack (enabling fully automatic provisioning); a contribution to the OpenStack Neutron networking project (formerly OpenStack Quantum); OpenFlow support with a controller-less option; and a significant enhancement of its eAPI interfaces for EOS. The hardware upgrades encompass big increases in capacity and port density for its 7500 Series switches, as well as hardware VXLAN support and an approach to 100Gb Ethernet interfaces that breaks new ground in terms of price/performance and flexibility. All of these enhancements are delivered with what Arista pitches as a stress-free migration path for existing customers. The 451 Take While Arista's original product designs could have claimed to do SDN 'before SDN was cool,' the vendor's latest announcements extend integration into the major SDN camps of OpenStack and OpenFlow, and also increase programmability. These enhancements can offer value in both simplified datacenter cores and complex multi-tenant networks. Arista is also building on its high-performance legacy, leveraging its relatively modern, clean software design and merchant-silicon-based hardware to add a level of capacity in its large-chassis switch products that should challenge rivals. A simple upgrade path will please Arista customers, but the true innovation value may lie in a gamble on 10/40/100Gb Ethernet optics, whose lower cost could really pay off.
    [Show full text]
  • Installation Guide: Switch: Pica8 P-3295
    Installation Guide: Switch: Pica8 P-3295 Prerequisites We are assuming that you have successfully configured and launched ONOS and Quagga. This section will help you launch the Pica8 P-3295 switch to connect to the control plane stack that you have already installed. Questions about the Pica8 P-3295 can be directed to Sudhir Modali ([email protected] ) Configuration & Launch Some of these directions have been copied from: http://www.pica8.com/document/v2.6/html/picos-system-configuration/ Initial configuration of the switch requires you to connect either a terminal or computer to the switch via the console port. Once connected, assign an IP address to the management port and establish an IP route to the gateway. Important things to know: The console port provides serial access to the switch. The Ethernet management port is used for out-of-band network management tasks. Before using a management port for the first time, an IP address must be assigned to that port. Console Port The console port is located at the front of the switch (see Figure 1). You can connect a terminal or computer to the console port using a serial or RS-232 cable. The accessory kit includes an RJ-45 to DB-9 adapter cable. Port Settings When connecting a terminal or computer to the console port, use the following settings: The baud rate is 115200 The data bits value is 8 The stop bits value is 1 User Log In PicOS operates in two modes. Layer 2 / Layer 3 mode (L2/L3). This is the default mode.
    [Show full text]
  • The First Hardware Agnostic, Open Network Operating System What
    WWW.PICA8.COM Open Systems for Software Defined The First Hardware Agnostic, Open Networking (SDN) Network Operating System Pica8™ is the first in the world to offer hardware-agnostic open switches. Network Application A pioneer in software-defined networking (SDN), we pair high-performance, APPLICATION TAP Tunneling Application LAYER white box switch hardware with PicOS: our hardware-agnostic, open network operating system that supports standards-based Layer 2 / Layer 3 protocols and Industry-leading OpenFlow* 1.3. In one complete package, Pica8 provides the physical switch, comprehensive switching and routing features, and the fulfilled promise of open networking. What makes PicOS open? CONTROLLER OTHER PicOS is hardware agnostic: because of PicOS's hardware abstraction LAYER EXAMPLES layer, the operating system is not tightly coupled to any switching ASIC, CPU or memory hardware. We continue to expand our ODM partners, offering a portfolio of pre-qualified white box, bare metal switches to select from Redundant Controllers Debian Linux is exposed, so you can use your existing tools (such as Puppet, Chef or CFEngine) for hands-free provisioning and myriad APIs through the Debian-Linux environment, helping you personalize Pica8 switches to support your open network PicOS supports OpenFlow 1.3, through Open vSwitch (OVS) v1.10 integration: OVS runs as a process within PicOS, providing the OpenFlow interface for external programmability DATA PLANE LAYER Leverage Linux Tools Multiprocess OS customize, optimize Pica8 Open Switch With
    [Show full text]
  • An Enterprise Approach to White Box Networking Contents
    Pica8 White Paper An Enterprise Approach to White Box Networking Contents Introduction 1 Powering Effective White Box Switches 1 Defining an “Open” Switch 2 The Myriad Benefits of Open, Disaggregated Networking 3 ELIMINATE VENDOR LOCK-IN 3 LOWER TCO 3 DELIMITED FLEXIBILITY AND HIGHER PERFORMANCE 3 IMPROVED RELIABILITY 3 EASE OF USE 3 THE PICA8 APPROACH: ENTERPRISE-READY 4 PICOS NETWORK OPERATING SYSTEM 4 PicaPilot Plus PICOS Makes White Box Networks Enterprise-ready 4 CrossFlow 5 Choice of Hardware Plus Superior Support 5 Realize the Full Benefits of Pica8 5 Pica8 White Paper | June 2018 Introduction White box switches running a modern, Linux-based network operating system (NOS) are disrupting the enterprise campus ESCAPE FROM THE DATA CENTER: network market, providing a viable alternative to customers who have spent decades bending to the will of their entrenched switch and router equipment vendors. PICA8 BRINGS SIMPLIFIED LEAF-SPINE ARCHITECTURE TO THE REST OF THE Similar to the virtual server concept, where the server software ENTERPRISE is abstracted from underlying hardware, with white box switches the network operating system itselfis abstracted – Enterprise and data center networks traditionally used a three-tier model, with access switches or disaggregated – from the underlying switch hardware. This closest to endusers feeding larger aggregation creates the potential for an “open,” portable NOS that can run on switch/routers which, in turn, connect to larger a wide variety of switches from multiple vendors. No longer is core routers that form the network backbone. an enterprise permanently wedded to a single vendor’s hardware and software development cycle. In this architecture, network architects must configure redundant pathways to ensure resiliency, The white box networking movement is now proving to be just typically using the Spanning Tree Protocol (STP).
    [Show full text]
  • Cisco Live 2014
    Introduction to Software-Defined Networking (SDN) and Network Programmability BRKSDN-1014 Jason Davis, Distinguished Engineer (Services) Abstract SDN is an exciting new approach to network IT Service Management. You may have questions about SDN, Controllers, APIs, Overlays, OpenFlow and ACI. You may also be wondering what products and services are SDN-enabled and how you can solve your unique business challenges and enhance your differentiated services by leveraging network programmability. In this introductory session we will cover the genesis of SDN, what it is, what it is not, and Cisco's involvement in this space. Cisco's SDN- enabled Products and Services will be explained enabling you to consider your own implementations. Since SDN extends network flexibility and functionality which impacts Network Engineering and Operations teams, we'll also cover the IT Service Management impact. Network engineers, network operation staff, IT Service Managers, IT personnel managers, and application/compute SMEs will benefit from this session. BRKSDN-1014 © 2015 Cisco and/or its affiliates. All rights reserved. Cisco Public 3 Agenda • What is SDN & Network Programmability • What are the Use Cases and Problems Solved with SDN? • An Overview of OpenFlow • What Are Cisco's solutions? • An Overview of Network Overlays • An Overview of Network Controllers • An Overview of ACI • The Impact to IT Service Management • How to Get Ready BRKSDN-1014 © 2015 Cisco and/or its affiliates. All rights reserved. Cisco Public 4 What is Software-Defined Networking (SDN)? • An approach and architecture in networking where control and data planes are decoupled and intelligence and state are logically centralized • Enablement where underlying network infrastructure is abstracted from the applications [network virtualization] • A concept that leverages programmatic interfaces to enable external systems to influence network provisioning, control and operations BRKSDN-1014 © 2015 Cisco and/or its affiliates.
    [Show full text]
  • OFLOPS-Turbo: Testing the Next-Generation Openflow Switch
    OFLOPS-Turbo: Testing the Next-Generation OpenFlow switch Charalampos Rotsos∗{, Gianni Antichi∗, Marc Bruyereyzx, Philippe Owezarskiyz, Andrew W. Moore∗ { School of Computing and Communications, Infolab 21, Lancaster University ∗Computer Laboratory, University of Cambridge yUniversite´ de Toulouse zCNRS, LAAS, France xDELL Inc. Abstract—The heterogeneity barrier breakthrough ment. OpenFlow introduces a reduction in the network achieved by the OpenFlow protocol is currently paced by control timescales which closely approximate flow control the variability in performance semantics among network timescales. As a result, OpenFlow switch implementation devices, which reduces the ability of applications to take complete advantage of programmable control. As a result, influences the control architecture of the network and control applications remain conservative on performance its overall performance. A switch which provides poor requirements in order to be generalizable and trade performance in the support of a protocol functionality performance for explicit state consistency in order to can become a bottleneck for architectures that rely heav- support varying performance behaviours. In this paper ily on the specific functionality; e.g., high latency in we argue that network control must be optimized towards network device capabilities and network managers and flow_stats_reply functionality of a switch can be application developers must perform informed design critical for traffic monitoring control applications. Protocol decision using accurate switch performance profiles. This support variability is equally critical for the consistency becomes highly critical for modern OpenFlow-enabled of the control plane. Most switches do not provide any 10 GbE optical switches which significantly elevate switch guarantees on the installation order and latency of a performance requirements.
    [Show full text]
  • Insight MFR By
    Manufacturers, Publishers and Suppliers by Product Category 6/16/2020 10/100 Hubs & Switch BRAINBOXES EXTRON MICRON CONSUMER PRODUCTS GROUP RARITAN MILESTONE SYSTEMS A/S BROCADE FORTINET MICROSEMI CORP RED LION CONTROLS 3COM BUFFALO TECHNOLOGY FUJITSU SCANNERS MIKROTIK RIVERBED TECHNOLOGIES 4XEM CORP. CABLE MATTERS INC. FUJITSU SERVER STORAGE MILESTONE SYSTEMS INC ROCSTOR AB DISTRIBUTING CABLE RACK GARRETTCOM MITEL ROLAND CORP ABLENET INC CABLES TO GO GEAR HEAD MONOPRICE ROSE ELECTRONIC ACCELL CALRAD ELECTRONICS GEFEN MOTOROLA ISG ROSEWILL ADESSO CHECK POINT SOFTWARE TECHNOLOGIE GEOVISION INC. MOXA TECHNOLOGIES, INC. RUCKUS WIRELESS ADTRAN CIENA HARMAN INTERNATIONAL MUXLAB SABRENT ADVANTECH AUTOMATION CORP. CISCO PRESS HAVIS SHIELD NEO4J INC SANHO ADVANTECH CO LTD CISCO SYSTEMS HEWLETT PACKARD ENTERPRISE NETAPP SANS DIGITAL AEROHIVE NETWORKS CITRIX HIKVISION DIGITAL TECHNOLOGY CO. LT NETEON TECHNOLOGIES INC. SATECHI ALCATEL LUCENT COMMUNICATION DEVICES INC. HITACHI NETGEAR, INC. SAVVIUS INC ALLEN TEL COMNET HITACHI DATA SYSTEMS NETRIA SCALE COMPUTING ALLEN‐BRADLEY COMPREHENSIVE CABLE HOWARD MEDICAL NETSCOUT SYSTEMS, INC SDA ALLIED TELESIS COMTROL HP INC NOVATEL WIRELESS SEGA OF AMERICA ALTONA CONNECTPRO HYPERCOM OMNITRON SENNHEISER ALTRONIX COOLGEAR IBM ORACLE SERVER TECH ALURATEK, INC. CP TECHNOLOGIES INNOVATIVE ELECTRONIC DESIGNS OVERLAND STORAGE SHARP AMER NETWORKS CRESTRON ELECTRONICS INSIGHT P.I. ENGINEERING SHORETEL AMX CUMULUS NETWORKS INTEL PALO ALTO NETWORKS SIGNAMAX ANKER CYBERDATA SYSTEMS INTELLINET NETWORK SOLUTIONS PANASONIC SIIG ANTAIRA TECHNOLOGIES, INC. CYBERPOWER SYSTEMS IOGEAR TECHNOLOGY PANDUIT SISOFTWARE APC DATAMATION SYSTEMS, INC. IRECORD.TV PERLE SYSTEMS SMARTAVI INC ARISTA CORPORATION DATTO, INC. IXIA PHOENIX CONTACT SMC NETWORKS ARISTA NETWORKS DELL JETWAY COMPUTER CORP. PHYBRIDGE INC SOLE SOURCE TECHNOLOGY ARRIS GROUP INC DELL EMC JUNIPER NETWORKS PICA8, INC SONUS NETWORKS, INC ASUS DIGI INTERNATIONAL KANEX PIVOT3 INC.
    [Show full text]