DOCSLIB.ORG

Rethinking Packet Forwarding Hardware

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Rethinking Packet Forwarding Hardware 1 Rethinking Packet Forwarding Hardware Martin Casado∗x Teemu Koponeny Daekyeong Moonz Scott Shenkerzx 1 Introduction should not be tied to particular networking hardware, For routers and switches to handle ever-increasing band- and networking hardware should not be restricted width requirements, the packet “fast-path” must be to particular protocols. General-purpose network handled with specialized hardware. There have been two processors have largely failed the first requirement, approaches to building such packet forwarding hardware. while the current generation of commodity network- The first is to embed particular algorithms in hardware; ing chips fail the second requirement. this is what most commodity forwarding chips do (e.g., • Hardware simplicity: In order to scale to increasing those from Broadcom, Marvell, and Fulcrum). These speeds, the hardware functionality should be of chips have led to amazing increases in performance and very limited complexity. Again, both current reductions in cost; for instance, one can now get 24 ports approaches to hardware acceleration fail to satisfy of gigabit ethernet for under $1000. this requirement. Unfortunately, this approach offers only very rigid func- • Flexible and efficient functionality: The resulting tionality; one can’t change protocols or add new features software-hardware combination should be capable that require hardware acceleration without redoing the of realizing a wide variety of networking functions chip. This forces network forwarding enhancements to at high-speed and low-cost, while having short evolve on hardware design timescales, which are glacially development cycles. Commodity chips work at slow compared to the rate at which network applications high-speed and low-cost, but have long development and requirements are changing. cycles for new functionality. General-purpose To counter this inflexibility, several vendors have network processors are not yet competitive on speed taken a different approach by introducing more flexible or cost. “network processors”. These have not been as successful In this paper we propose a different approach to as anticipated, for at least two reasons. First, designers hardware packet forwarding that has the potential to were never able to find a sweet-spot in the tradeoff realize all of these goals. Our approach assigns a between hardware simplicity and flexible functionality, completely different role to hardware. Traditionally, so the performance/price ratios have lagged well behind hardware implementations have embodied the logic commodity networking chips. For another, the interface required for packet forwarding. That is, the hardware provided to software has proven hard to use, requiring had to capture all the complexity inherent in a packet protocol implementors to painstakingly contort their forwarding decision. code to the idiosyncrasies of the particular underlying In contrast, in our approach all forwarding decisions hardware to achieve reasonable performance. These two are done first in software, and then the hardware merely problems (among others) have prevented general-purpose mimics these decisions for subsequent packets to which network processors from dislodging the more narrowly that decision applies (e.g., all packets destined for the targeted commodity packet forwarding hardware that same prefix). Thus, the hardware does not need to dominates the market today. understand the logic of packet forwarding, it merely In this paper, we step back from these two well-known caches the results of previous forwarding decisions (taken approaches and ask more fundamentally: what would we by software) and applies them to packets with the want from packet forwarding hardware, how might we same headers. The key task is to match incoming achieve it, and what burden does that place on networking packets to previous decisions, so the required hardware software? is nothing more than a glorified TCAM, which is simple Ideally, hardware implementations of the forwarding to implement (compared to other networking hardware) paths should have the following properties: and simple to reason about. We describe this approach in more detail in Section 2. • Clean interface between hardware and software: One key challenge in this approach is scaling to The hardware-software interface should allow each high speeds. Achieving high forwarding rates is not a to evolve independently. Protocol implementations matter of the number of clock cycles needed to make ∗Nicira Networks Inc. a forwarding decision, but instead is one of cache hit yHelsinki Institute for Information Technology (HIIT) rates; what fraction of packet forwarding can be done zUC Berkeley, Computer Science Division based on the forwarding of previous packets? This xInternational Computer Science Institute (ICSI) question is central to the viability of this approach, and 1 2 we address it in Section 3. Another key challenge but other rules (such as “packets with TTL=1 should be is deciding to which packets a particular forwarding dropped”) can be applied to all ingress ports. decision applies (i.e., which fields in the packet header Matching rule: The software specifies the fields in the must match in order to apply a decision), and when this packet header that must match for the flow entry to decision has been rendered obsolete by changing network apply. This could be the entire header (i.e., requiring state (e.g., changes in forwarding tables); these system a perfect match), or only some fields (e.g., perhaps only design issues are addressed in Section 4. the destination address to match). This approach has been motivated by a long line Forwarding action: The forwarding action is the set of of flow-oriented approaches to networking hardware, output ports to which the packet should be sent, along from [5] to [2] (and many others). What makes our with (optionally) the rewritten packet headers for each approach different from traditional connection-oriented port. Dropping the packet is represented by a special null architectures (e.g., ATM) is that our approach does output port. not require any change to networking protocols. Our State dependence: This represents the local state on approach (similar to the references [2, 5]) only changes which the forwarding decision is based (such as entries in the interface between hardware and software, but does a routing table or ACL database). not affect protocols or the Internet architecture. Like [3] When a packet arrives, it is compared to the table of we seek to provide a flexible software model with flow entries corresponding to its ingress port. If its packet hardware forwarding speeds, however in our approach we header does not match any of the entries, then it is sent propose to fully decouple the software from the hardware, to software for processing. If it matches a flow entry, the while [3] provides direct access to hardware resources packet is handled according to the specification of the such as the TCAM and special purpose ASICs. We view forwarding action in the flow entry. Whenever a piece this as a necessary and complimentary step for integrating of local state changes, such as an update to an ACL or with existing hardware. routing table, then all flow entries that depended on that state are invalidated and removed from the flow table. 2 Our Approach Before proceeding to examples, we mention a few more 2.1 General Description detailed points. First, the matching rules must be defined so a packet matches no more than one rule. Since we Packet forwarding decisions deterministically depend on assume that the software deterministically forwards each the header of the arriving packet and on some local state in packet based on its header fields and particular system 1 the router/switch (such as a routing table). For example, state, it should be possible to generate non-conflicting the header/state combination for ethernet forwarding is entries at runtime. the destination MAC address and the L2 learning table, Second, we view stateful tunneling (e.g., IPsec in whereas for IP forwarding it is the destination IP address which a sequence number is updated for every packet) as and the FIB. virtual output ports rather than part of the forwarding The forwarding decision includes both the output logic. This is similar to how they are handled in port(s) on the network device as well as possible modifi- standard software IP forwarding engines in which they are cations to the packet header, such as the label swapping in modeled as networking interfaces. If we did not use this MPLS or packet encapsulation/decapsulation. As long as technique then no flow entry would be recorded for such the relevant pieces of local state have not changed, then flows, because the state on which the forwarding actions all packets with the same packet header should receive the depends (which includes per-packet modifications) would same forwarding behavior. This statement applies to any be updated on every new packet arrival. forwarding protocol that depends only on packet headers Third, there are a number of possible system designs and local state. that could determine the headers and system state used To leverage this fact, we treat packet forwarding as a in a decision, such as a special-purpose programming matching process, with all packets matching a previous language, a specialized compiler or even hardware decision handled by the hardware, and all non-matching support. We discuss these further in Section 4. However, packets handled by the software. We assume that when a the primary goal of this paper is not to give a specific and packet is handled by software, we can infer a flow entry comprehensive system design (we are working on this for that packet which contains four pieces of information: and plan to discuss it in future work), but rather to explore Ingress port(s): This specifies to which ingress ports a the fundamental viability of our general approach. flow entry applies. Many rules will only apply to the ingress port of the packet that generated the flow entry, 2.2 Examples 1We are ignoring forwarding decisions based on deep-packet To demonstrate how our proposal operates in practice, we inspection.
Load more

Recommended publications
  • Fortinet and Vyatta Fortinet and Vyatta
    DEPLOYMENT GUIDE Fortinet and Vyatta Fortinet and Vyatta Overview . 3 Deployment Prerequisites . 3 Architecture Overview . 3 Figure 1: Topology.......................................... 3 Partner Configuration....................................... 4 Hardware Installation . 4 Figure 2: Vyatta Dashboard .................................. 4 Figure 3: Vyatta Virtualization ................................ 5 Fortinet Configuration . 5 Figure 4: Vyatta Virtualization Console Access .................. 5 Summary . 6 Access to Vyatta Demo . 6 How To Get Help........................................... 6 2 DEPLOYMENT GUIDE | Fortinet and Vyatta Overview The Brocade 5600 vRouter (formerly Vyatta 5600 vRouter) provides a solution Deployment Prerequisites for network functions virtualization (NFV). It offers easy scalability, a broad set of capabilities, and reliability. The Fortinet and Brocade Vyatta deployment requires the following: In addition, it utilizes Intel Data Plane Development Kit (DPDK) to deliver higher performance, and it can be installed on hypervisors and any x86-based system. 1. Vyatta OS Together, Fortinet and Brocade deliver an industry-leading security and network 2. Supermicro x86-Based Hardware solution. FortiGate virtual firewall products enable customers to deploy branch office 3. FortiGate KVM Firewall services. Customers can deploy virtual CPE (vCPE) combined with industry-leading FortiGate security. The Brocade Vyatta Network OS with Fortinet network security appliances and subscription services provides broad, integrated,
    [Show full text]
  • Rule-Based Forwarding (RBF): Improving the Internet's Flexibility
    Rule-based Forwarding (RBF): improving the Internet’s flexibility and security Lucian Popa∗ Ion Stoica∗ Sylvia Ratnasamy† 1Introduction 4. rules allow flexible forwarding: rules can select ar- From active networks [33] to the more recent efforts on bitrary forwarding paths and/or invoke functionality GENI [5], a long-held goal of Internet research has been made available by on-path routers; both path and to arrive at a network architecture that is flexible.Theal- function selection can be conditioned on (dynamic) lure of greater flexibility is that it would allow us to more network and packet state. easily incorporate new ideas into the Internet’s infras- The first two properties enable security by ensuring tructure, whether these ideas aim to improve the existing the network will not forward a packet unless it has network (e.g., improving performance [36, 23, 30], relia- been explicitly cleared by its recipients while the third bility [12, 13], security [38, 14, 25], manageability [11], property ensures that rules cannot be (mis)used to attack etc.) or to extend it with altogether new services and the network itself. As we shall show, our final property business models (e.g., multicast, differentiated services, enables flexibility by allowing a user to give the network IPv6, virtualized networks). fine-grained instructions on how to forward his packets. An unfortunate stumbling block in these efforts has In the remainder of this paper, we present RBF, a been that flexibility is fundamentally at odds with forwarding architecture that meets the above properties. another long-held goal: that of devising a secure network architecture.
    [Show full text]
  • Routing and Packet Forwarding
    Routing and Packet Forwarding Tina Schmidt September 2008 Contents 1 Introduction 1 1.1 The Different Layers of the Internet . .2 2 IPv4 3 3 Routing and Packet Forwarding 5 3.1 The Shortest Path Problem . .6 3.2 Dijkstras Algorithm . .7 3.3 Practical Realizations of Routing Algorithms . .8 4 Autonomous Systems 10 4.1 Intra-AS-Routing . 10 4.2 Inter-AS-Routing . 11 5 Other Services of IP 11 A Dijkstra's Algorithm 13 1 Introduction The history of the internet and Peer-to-Peer networks starts in the 60s with the ARPANET (Advanced Research Project Agency Network). Back then, when computers were expen- sive and linked to several terminals, the aim of ARPANET was to establish a continuous network inbetween mainframe computers in the U.S. Starting with only three computers in 1969, mainly universities were involved in establishing the ARPANET. The ARPANET became a network inbetween networks of mainframe computes and therefore was called inter-net. Today it became the internet which links millions of computers. For a long time nobody knew what use such a Wide Area Netwok (WAN) could have for the pop- ulation. The internet was used for e-mails, newsgroups, exchange of scientific data and some special software, all in all services that were barely known in public. The spread of 1 Application Layer Peer-to-Peer-networks, e.g. Telnet = Telecommunication Network FTP = File Transfer Protocol HTTP = Hypertext Transfer Protocol SMTP = Simple Mail Transfer Protocol Transport Layer TCP = Transmission Control Protocol UDP = User Datagram Protocol Internet Layer IP = Internet Protocol ICMP = Internet Control Message Protocol IGMP = Internet Group Management Protocol Host-to-Network Layer device drivers or Link Layer (e.g.
    [Show full text]
  • Brocade Vyatta Network OS Data Sheet
    DATA SHEET Brocade Vyatta Network OS HIGHLIGHTS A Network Operating System for the Way Forward • Offers a proven, modern network The Brocade® Vyatta® Network OS lays the foundation for a flexible, easy- operating system that accelerates the adoption of next-generation to-use, and high-performance network services architecture capable of architectures meeting current and future network demands. The operating system was • Creates an open, programmable built from the ground up to deliver robust network functionality that can environment to enhance be deployed virtually or as an appliance, and in concert with solutions differentiation, service quality, and from a large ecosystem of vendors, to address various Software-Defined competitiveness Networking (SDN) and Network Functions Virtualization (NFV) use cases. • Supports a broad ecosystem for With the Brocade Vyatta Network OS, organizations can bridge the gap optimal customization and service between traditional and new architectures, as well as leverage existing monetization investments and maximize operational efficiencies. Moreover, they can • Simplifies and automates network compose and deploy unique, new services that will drive differentiation functions to improve time to service, increase operational efficiency, and and strengthen competitiveness. reduce costs • Delivers breakthrough performance flexibility, performance, and operational and scale to meet the needs of any A Proven, Modern Operating efficiency, helping organizations create deployment System The Brocade Vyatta Network OS new service offerings and value. Since • Provides flexible deployment options separates the control and data planes in 2012, the benefits of this operating to support a wide variety of use cases software to fit seamlessly within modern system have been proven by the Brocade SDN and NFV environments.
    [Show full text]
  • Internet Telephony Digital August Issue 2006
    Where Can You Turn for a Total Solution? As a total solutions provider, NEC understands the complexities today’s converged networks can present to your business. With our proven experience, we know what it takes to help you avoid traveling in the wrong direction. NEC delivers the most choices of IP communications platforms to meet the unique needs of your business. Add to that a strong portfolio of applications and services, and before you know it, your business is traveling in the direction of improved customer experience, enhanced employee productivity, increased revenue generation and maximum return on investment. Why go in different directions when you can focus on a Total Solution? Turn to NEC! www.necunified.com/tmc © 2006 NEC Corporation NEC and the NEC logo are registered trademarks of NEC Corporation. By Greg Galitzine Group Publisher and Editor-In-Chief, Rich Tehrani ([email protected]) EDITORIAL Location, Location, Editorial Director, Greg Galitzine ([email protected]) Associate Editor, Erik Linask ([email protected]) Location TMC LABS Executive Technology Editor/CTO/VP, Tom Keating ([email protected]) Let’s take a trip back to the late 1990s, right ART about the time when every thing connected to Senior Art Director, Lisa D. Morris Art Director, Alan Urkawich telecom was seemingly awash in money, and EXECUTIVE OFFICERS there was WAP, and with WAP there was the Nadji Tehrani, Chairman and CEO Rich Tehrani, President early promise of location-based services. Dave Rodriguez, VP of Publications and Conferences Who remembers this WAP enabled application? You’re walking down the street and, as Kevin J.
    [Show full text]
  • The Essential Guide to Telecommunications, Sixth Edition
    PRAISE FOR THE ESSENTIAL GUIDE TO TELECOMMUNICATIONS, SIXTH EDITION “Dodd’s The Essential Guide to Telecommunications provides the history and context that make a fundamental underpinning of modern business more accessible to technologists and businesspeople alike. This new edition of her primer is an essential reference in the continuously evolving communica- tions landscape.” —Tom Hopcroft, President and CEO, Mass Technology Leadership Council “Annabel Dodd’s book is a clear guide and big-picture view of technologies and industries. It is an up-to-date guide for anyone who wants to be familiar with important innovations and key technologies. This is truly an industry bible for mobile, Internet, and networking services.” —Hiawatha Bray, Technology Reporter, The Boston Globe “Ms. Dodd’s aptly titled The Essential Guide to Telecommunications has been my bible for all things telecom since my days as an AT&T transmission network engineer nearly twenty years ago. Exhaus- tively and meticulously researched, concisely written for lay folks and techs/engineers alike, this book aids me in my current role as an IT Support Technician II when discussing new technology with our telecommunications department. Thank you to Ms. Dodd for keeping us all current!” —Todd Garbarini, IT Support Technician II Commvault Systems, Inc. “The Essential Guide to Telecommunications is probably one of the most useful and well-written books on our telecom bookshelf. Annabel Z. Dodd does a great job of capturing a snapshot of the current telecom industry. Even those with little or no technical training should be able to understand the text. This is the perfect book for salespeople who want to learn more about the products and services they are selling, or for those who just want to keep up to date on the latest in telecom technology.” —William Van Hefner, President, Vantek Communications, Inc.
    [Show full text]
  • Introduction to IP Multicast Routing
    Introduction to IP Multicast Routing by Chuck Semeria and Tom Maufer Abstract The first part of this paper describes the benefits of multicasting, the Multicast Backbone (MBONE), Class D addressing, and the operation of the Internet Group Management Protocol (IGMP). The second section explores a number of different algorithms that may potentially be employed by multicast routing protocols: - Flooding - Spanning Trees - Reverse Path Broadcasting (RPB) - Truncated Reverse Path Broadcasting (TRPB) - Reverse Path Multicasting (RPM) - Core-Based Trees The third part contains the main body of the paper. It describes how the previous algorithms are implemented in multicast routing protocols available today. - Distance Vector Multicast Routing Protocol (DVMRP) - Multicast OSPF (MOSPF) - Protocol-Independent Multicast (PIM) Introduction There are three fundamental types of IPv4 addresses: unicast, broadcast, and multicast. A unicast address is designed to transmit a packet to a single destination. A broadcast address is used to send a datagram to an entire subnetwork. A multicast address is designed to enable the delivery of datagrams to a set of hosts that have been configured as members of a multicast group in various scattered subnetworks. Multicasting is not connection oriented. A multicast datagram is delivered to destination group members with the same “best-effort” reliability as a standard unicast IP datagram. This means that a multicast datagram is not guaranteed to reach all members of the group, or arrive in the same order relative to the transmission of other packets. The only difference between a multicast IP packet and a unicast IP packet is the presence of a “group address” in the Destination Address field of the IP header.
    [Show full text]
  • Analysis and Improvement of Name-Based Packet Forwarding
    Analysis and Improvement of Name-based Packet Forwarding over Flat ID Network Architectures Antonio Rodrigues Peter Steenkiste Ana Aguiar [email protected] [email protected] [email protected] Carnegie Mellon University Carnegie Mellon University Faculty of Engineering, Univ. of Porto Pittsburgh, PA, USA Pittsburgh, PA, USA Instituto de Telecomunicações Faculty of Engineering, Univ. of Porto Porto, Portugal Instituto de Telecomunicações Porto, Portugal ABSTRACT URLs to identify web objects. Name-based Information Centric One of ICN’s main challenges is attaining forwarding table scala- Networks (ICNs) such as NDN [8] promise to be a good fit for such bility when confronted with a huge content space. This is specially applications, for two reasons: (1) no need for external name lookup true in flat ID architectures, which do not naturally support route (e.g., DNS or GNS [18]) by using name-based forwarding at the aggregation for hierarchical names. Previous work has proposed network layer; and (2) reduced forwarding table sizes as a result improving scalability by aggregating content names in a fixed-size of the aggregation enabled by the hierarchical structure of names. Bloom Filters (BF). However, the negative impact of false positive In contrast, ICNs based on flat IDs (defined as fixed-size bit strings (FPs) matches on forwarding correctness and performance has not in this paper), e.g., DONA [12], PURSUIT [6], do not natively have been studied thoroughly. In this paper, we study the end-to-end net- these benefits. work performance of BF-based forwarding. We devise an analytical Recently, a forwarding scheme based on Bloom Filters (BFs) [13, model that accurately models BF-based forwarding and the flow of 14] has been proposed to enable aggregation of content descriptors BF-based packets over inter-domain topologies.
    [Show full text]
  • Unicast Reverse Path Forwarding Configuration Guide, Cisco IOS XE 17 (Cisco ASR 900 Series)
    Unicast Reverse Path Forwarding Configuration Guide, Cisco IOS XE 17 (Cisco ASR 900 Series) First Published: 2020-01-10 Americas Headquarters Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA http://www.cisco.com Tel: 408 526-4000 800 553-NETS (6387) Fax: 408 527-0883 THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS. THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY. The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB's public domain version of the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California. NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS" WITH ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE. IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
    [Show full text]
  • Network Disaggregation at the Edge with the Open SD-Edge Platform
    Network Disaggregation at the Edge With the Open SD-Edge Platform November 11, 2020 Sponsored By: Information Classification: General Today’s Speakers Jennifer Clark, Robert Bays Principal Analyst – Assistant VP Heavy Reading ATT - Vyatta Srikanth Krishnamohan Elad Blatt Director of Product Marketing CSO IP Infusion Silicom Information Classification: General ©Page 2020 3 Omdia NFV in a Production Environment: Leading Use Cases Commercial NFV deployment expectation Information Classification: General Enterprises are Shifting to Managed Services Enterprises are shifting from DIY vCPE to managed services, supporting the same VFNs but with improved security, performance, reliability and cost Information Classification: General Edge deployment barriers • Today, operators are faced with three top challenges to deploying edge: – High costs – Unclear business case – Technical issues Information Classification: General Edge Investment: Everything is a Priority Information Classification: General Network Disaggregation at the Edge With the Open SD-Edge Platform Q&A Information Classification: General DANOS Vyatta Edition 2020-11-11.1 © 2020 AT&T Inc. What is DANOS Vyatta Edition? Gen 2 architecture >700 Subscription Multiple CSPs Vyatta sets vRouter Founded released customers Standardize on Vyatta speed record Domain 2.0 partner Acquires Vyatta Initial release Apr 2005 Oct 2007 Sep 2011 Jan 2013 Jun 2014 Dec 2014 July 2017 Nov 2019 First release 1M Downloads Gen 3 architecture Broadcom Tomahawk Gen 4 architecture EA Oct 2005 Jan 2011 Acquires
    [Show full text]
  • Insight MFR By
    Manufacturers, Publishers and Suppliers by Product Category 11/6/2017 10/100 Hubs & Switches ASCEND COMMUNICATIONS CIS SECURE COMPUTING INC DIGIUM GEAR HEAD 1 TRIPPLITE ASUS Cisco Press D‐LINK SYSTEMS GEFEN 1VISION SOFTWARE ATEN TECHNOLOGY CISCO SYSTEMS DUALCOMM TECHNOLOGY, INC. GEIST 3COM ATLAS SOUND CLEAR CUBE DYCONN GEOVISION INC. 4XEM CORP. ATLONA CLEARSOUNDS DYNEX PRODUCTS GIGAFAST 8E6 TECHNOLOGIES ATTO TECHNOLOGY CNET TECHNOLOGY EATON GIGAMON SYSTEMS LLC AAXEON TECHNOLOGIES LLC. AUDIOCODES, INC. CODE GREEN NETWORKS E‐CORPORATEGIFTS.COM, INC. GLOBAL MARKETING ACCELL AUDIOVOX CODI INC EDGECORE GOLDENRAM ACCELLION AVAYA COMMAND COMMUNICATIONS EDITSHARE LLC GREAT BAY SOFTWARE INC. ACER AMERICA AVENVIEW CORP COMMUNICATION DEVICES INC. EMC GRIFFIN TECHNOLOGY ACTI CORPORATION AVOCENT COMNET ENDACE USA H3C Technology ADAPTEC AVOCENT‐EMERSON COMPELLENT ENGENIUS HALL RESEARCH ADC KENTROX AVTECH CORPORATION COMPREHENSIVE CABLE ENTERASYS NETWORKS HAVIS SHIELD ADC TELECOMMUNICATIONS AXIOM MEMORY COMPU‐CALL, INC EPIPHAN SYSTEMS HAWKING TECHNOLOGY ADDERTECHNOLOGY AXIS COMMUNICATIONS COMPUTER LAB EQUINOX SYSTEMS HERITAGE TRAVELWARE ADD‐ON COMPUTER PERIPHERALS AZIO CORPORATION COMPUTERLINKS ETHERNET DIRECT HEWLETT PACKARD ENTERPRISE ADDON STORE B & B ELECTRONICS COMTROL ETHERWAN HIKVISION DIGITAL TECHNOLOGY CO. LT ADESSO BELDEN CONNECTGEAR EVANS CONSOLES HITACHI ADTRAN BELKIN COMPONENTS CONNECTPRO EVGA.COM HITACHI DATA SYSTEMS ADVANTECH AUTOMATION CORP. BIDUL & CO CONSTANT TECHNOLOGIES INC Exablaze HOO TOO INC AEROHIVE NETWORKS BLACK BOX COOL GEAR EXACQ TECHNOLOGIES INC HP AJA VIDEO SYSTEMS BLACKMAGIC DESIGN USA CP TECHNOLOGIES EXFO INC HP INC ALCATEL BLADE NETWORK TECHNOLOGIES CPS EXTREME NETWORKS HUAWEI ALCATEL LUCENT BLONDER TONGUE LABORATORIES CREATIVE LABS EXTRON HUAWEI SYMANTEC TECHNOLOGIES ALLIED TELESIS BLUE COAT SYSTEMS CRESTRON ELECTRONICS F5 NETWORKS IBM ALLOY COMPUTER PRODUCTS LLC BOSCH SECURITY CTC UNION TECHNOLOGIES CO FELLOWES ICOMTECH INC ALTINEX, INC.
    [Show full text]
  • A Scalable and Flexible Packet Forwarding Method for Future Internet Networks
    Globecom 2014 - Next Generation Networking Symposium A Scalable and Flexible Packet Forwarding Method for Future Internet Networks Andrzej Beben, Piotr Wiśniewski Jordi Mongay Batalla George Xilouris Warsaw University of Technology National Institute of Telecommunications NCSR Demokritos Warsaw, Poland Warsaw, Poland Athens, Greece {abeben, p.wisniewski}tele.pw.edu.pl [email protected] [email protected] Abstract—The paper proposes a novel flexible packet in the data plane while improving SDN scalability thanks to the forwarding (FPF) method designed for Future Internet networks. reduction of state information in SDN forwarders [4]. It follows the source routing principle at an inter-domain level and applies the list of domain customized identifiers to forward II. ANALYSIS OF RELATED WORKS packets on the end-to-end path. The main features are capability to introduce flexible routing path selection, native support for One of the main FI challenges is to design effective routing multipath and multicast packet transfer, ability for exploitation and forwarding methods that overcame limitations of the IP of advanced in-network packet processing as, e.g., content protocol. The key objectives are providing more flexible recoding and caching. The performance and scalability of FPF routing path selection and enabling innovative in-network approach were evaluated by experimentation on developed packet processing, while assuring scalability of the solution. prototype as well as by scalability studies assuming Internet-scale Many of recently proposed approaches are based on the source network scenario. routing principle, which is not really a new idea. The original studies on exploiting source routing in IP networks are Future Internet, source routing, packet forwarding, SDN presented in [5].
    [Show full text]