DOCSLIB.ORG

A Versatile UDP/IP Based PC ↔ FPGA Communication Platform

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
A Versatile UDP/IP Based PC ↔ FPGA Communication Platform A Versatile UDP/IP based PC ↔ FPGA Communication Platform Nikolaos Alachiotis, Simon A. Berger, Alexandros Stamatakis The Exelixis Lab, Scientific Computing Group Heidelberg Institute for Theoretical Studies Heidelberg, Germany Emails: {Nikolaos.Alachiotis,Simon.Berger,Alexandros.Stamatakis}@h-its.org Abstract—We present a substantially improved version of Nonetheless, this novel and more flexible UDP/IP core still our popular UDP/IP core for simple and fast PC ↔ FPGA outperforms all competing UDP/IP core implementations in communication over Gigabit Ethernet. We provide a novel terms of speed and resource requirements. feature to automatically configure (previously hard-coded) internal settings on the FPGA. Thereby, we substantially reduce Since February 2010, the proof-of-concept implementa- the installation overhead when a FPGA shall communicate with tion has been downloaded over 6,000 times from OpenCores. several different PCs. The UDP/IP core is designed to occupy org (http://opencores.org/project,udp ip core) and from a minimum amount of hardware resources on the FPGA. On our software page (http://www.exelixis-lab.org/countIPv4. the PC side, this new automatic configuration protocol can be php). Note that both Xilinx [2] and Altera [3] provide used and invoked via a C software interface which provides convenient functions for setting up the connection to the FPGA PCI Express-based solutions for PC ↔ FPGA communi- device and sending/retrieving arrays of common C data types cation. However, the interest our initial core has gener- to/from the UDP/IP core on the FPGA. The initial UDP/IP core ated underlines the apparent lack of a standardized, open- version is available under the LGPL license at http://opencores. source Ethernet-based communication mechanism. Thus, in org/project,udp ip core while the improved version of the addition to the improved UDP/IP core architecture, we core, including the C software interface (also under LGPL), is available at http://opencores.org/project,pc fpga com. also present an implementation of a comprehensive open- source PC ↔ FPGA communication platform that relies Keywords-FPGA; UDP/IP; PC-FPGA communication; on Gigabit Ethernet. This platform deploys the versatile version of the UDP/IP core and implements a simplified I. INTRODUCTION communication protocol that facilitates usage and integration FPGAs are commonly deployed as accelerator devices or of the send/receive paradigm for common C data types for verifying architectures. Irrespective of their particular and arrays. Our platform hides the complexity inherent to use, a machinery for moving data to/from the device is establishing a PC ↔ FPGA connection and to synchronizing required. Recently, we presented a proof-of-concept imple- data transmissions in both directions. The versatile UDP/IP mentation of a highly efficient UDP/IP core architecture that core and the communication platform are available for is optimized for point-to-point communication [1]. We found download at http://opencores.org/project,pc fpga com. that combining the IPv4 and UDP protocols represents an The remainder of this paper is organized as follows: efficient solution for establishing a connection between a Section II provides a short overview of related work on PC and a FPGA, with respect to reconfigurable hardware UDP/IP and TCP/IP cores as well as PC ↔ FPGA com- utilization. We achieve low resource utilization because the munication platforms. In Section III, we describe the design architecture employs a simplified method for calculating the of the novel and more versatile UDP/IP core. The PC ↔ IPv4 Header Checksum based on a pre-calculated template. FPGA communication platform is introduced in Section IV. Here, we present an improved UDP/IP core implemen- Section V covers implementation and verification details as tation and a comprehensive Ethernet-based communication well as a performance evaluation of the UDP/IP core and the platform. A key property of the UDP/IP core is that all PC ↔ FPGA platform. Section V also includes application static header fields required for point-to-point communica- examples to demonstrate the functionality of the proposed tion are stored in a lookup table. In the proof-of-concept solution. We conclude in Section VI and address directions implementation, this required the user to manually initialize of future work. the lookup table before configuring the device. The improved architecture we present here entails additional control logic II. RELATED WORK that retrieves all static fields of an incoming initialization In [4], L¨ofgren et al. present three different (commer- packet from the PC. This data is then stored in the respective cially available) stand-alone UDP/IP cores and denote them lookup table. This versatility of the new UDP/IP core as minimum, medium, and advanced implementations. The comes at a cost: the additional logic occupies approximately medium and advanced IP cores offer additional protocols 56% more hardware area than the proof-of-concept core. which are not necessary for establishing a direct PC ↔ to from user interface FPGA communication. Thus, we do not compare these EMAC TRANSMITTER HLUT wraddr,wren,din heavy-weight cores with our implementation because such reg a comparison would be unfair. The minimum IP core offers wren,value the same functionality as our Gigabit-speed UDP/IP core but RST_U IPv4 Header Checksum rst HLUT requires 2.8 times more hardware resources while operating Register CONTROL at 10/100 Mbps only. CONFIG_U from In [5], K¨uhn et al. used UDP/IP to implement PC ↔ EMAC config FPGA communication over Gigabit Ethernet. To implement RECEIVER to user interface the communication mechanism, the authors deployed an operating system (Linux) that was running on an embedded Figure 1. Top-level design of the advanced UDP/IP core. PowerPC processor. While using a processor that handles the communication represents an elegant and straightforward approach, not all reconfigurable devices contain such hard- coded processors. When such a processor is not required for of the 802.3 MAC frame are the Destination Address, the conducting additional computations, deploying a soft-coded Source Address, and the Ethernet Type. The IPv4 header sec- processor can lead to excessive hardware utilization on the tion contains the following fields: Version, Header Length, device. Our novel communication platform essentially offers Differentiated Services, Total Length, Identification, Flags, the same functionality but does not require an embedded Fragment Offset, Time to Live, Protocol, Header Checksum, processor. Source Address, and Destination Address [11]. The UDP Dollas et al. [6] presented an architecture for an open header section consists of the Source Port, the Destination TCP/IP core that supports all necessary protocols (ARP, Port, the Length, and the Checksum [12]. When only a ICMP, UDP) typically required for real-world applications. direct point-to-point connection between a PC and a FPGA The architectural complexity that is induced by the large is considered, all of the above header fields are constant number of supported protocols would yield a comparison to with the exception of the IPv4 Total Length and Header our light-weight design unfair. Note that a full TCP/IP core is Checksum fields as well as the UDP Length field. The idea not necessary for direct PC ↔ FPGA communication since of storing constant fields of UDP point-to-point connections this can be implemented using less complex protocols and in lookup tables has been used before [4]. However, the a lower amount of resources. required hardware resources are further reduced in our design because the calculation of the IPv4 checksum field In [7], Lin et al. presented a PC ↔ FPGA based commu- nication platform for verification and fast prototyping. The can be implemented by a single subtraction. platform communicates via a PCI interface and is intended During a transmission of an Ethernet packet from the to facilitate verification of multimedia applications. There FPGA to the PC, all static/constant fields are retrieved exist similar platforms as the one presented by Lin et al. that directly from the HLUT. The three variable fields (Total target specific application types [8], [9]. Our PC ↔ FPGA Length, Header Checksum, Length) can be calculated at communication platform offers a mechanism for integrating low cost using two additions and one subtraction. The communication routines into any kind of application and initial architecture contained three hard-coded values that allows for transferring arrays of the basic IEEE-754 data were used as the first operand of the two adders and the types (e.g., characters, short integers, integers, floats, long subtracter, while the second operand in all three operations integers, and doubles). was the length of the user data. The hard-coded values were Recently, Lieber and Hutchings [10] presented an open- set to the minimum IPv4 Total Length and UDP Length source PC ↔ FPGA communication framework for Xilinx values, that is, the offsets to the respective header sections FPGA boards achieving a maximum throughput of 504 and the IPv4 Header Checksum field of an Ethernet packet Mbps. Our PC ↔ FPGA communication platform provides without any user data attached to it. Based on the amount similar functionality and can operate at Gigabit speed (1000 of data (number of bytes) transferred with the packet, the Mbps) while requiring 50% less reconfigurable resources. corresponding length fields are calculated by two additions. The subtraction is used to calculate the correct IPv4 Header III. VERSATILE UDP/IP CORE ARCHITECTURE Checksum as a function of the IPv4 Total Length field. A In the following, we briefly review the basic concept of more detailed description of this procedure and a proof that the initial UDP/IP core and describe the enhancements in the a single subtraction is sufficient can be found in [1]. new version. As already mentioned, all static header fields Figure 1 illustrates the versatile UDP/IP core architecture.
Load more

Recommended publications
  • Network Layer
    Network Layer Rick Graziani Thanks to Brad Smith for his contributions Spring 2018 Next week in CE 151 • Sign up for Piazza (piazza.com) • Sunday - First lab due. - First lab section is half of the lab grade. - 85 points for the lab - 85 points for attending first lab section - VM Problems • Tuesday - Link layer lecture • Thursday - Read “End-to-End Argument” paper - IPv4/layer exercise - IPv4 quiz… review orange slides Today • Too many slides, but will go fast over some and slower on others • Evolution of TCP/IP - Overview Evoluon of TCP/IP (Overview) Internet Background • The ARPAnet was the first packet-switched network (1969) • It’s success led to the Internet • The ARPAnet architecture - Homogeneous (same) switches • Interface Message Processors (IMPs) – Honeywell 316/516 minicomputers (maps to "physical, data link and network layers") - Heterogeneous (different) hosts - The Network Control Protocol or Program (NCP) implemented conservative error, flow, and congestion control (early TCP) • Stop and wait • Hop by hop Evoluon of TCP/IP (Overview) • NCP provided the transport layer: - ARPANet Host-to-Host Protocol (AHHP) - Initial Connection Protocol (ICP) • Move from smart network to smart hosts … “End-to-end Principle” (Work done by Paul Baran and Donald Davies in the 1960s) • Reliable delivery a host-host issue • TCP split into TCP/IP (Early 1980s) - Internet Protocol (IP) • Best-effort routing • Internet level addressing - Transmission Control Protocol (TCP) • New, end-to-end error, flow, and congestion control Internet Background
    [Show full text]
  • Introduction to RAW-Sockets Jens Heuschkel, Tobias Hofmann, Thorsten Hollstein, Joel Kuepper
    Introduction to RAW-sockets Jens Heuschkel, Tobias Hofmann, Thorsten Hollstein, Joel Kuepper 16.05.2017 Technical Report No. TUD-CS-2017-0111 Technische Universität Darmstadt Telecooperation Report No. TR-19, The Technical Reports Series of the TK Research Division, TU Darmstadt ISSN 1864-0516 http://www.tk.informatik.tu-darmstadt.de/de/publications/ Introduction to RAW-sockets by Heuschkel, Jens Hofmann, Tobias Hollstein, Thorsten Kuepper, Joel May 17, 2017 Abstract This document is intended to give an introduction into the programming with RAW-sockets and the related PACKET-sockets. RAW-sockets are an additional type of Internet socket available in addition to the well known DATAGRAM- and STREAM-sockets. They do allow the user to see and manipulate the information used for transmitting the data instead of hiding these details, like it is the case with the usually used STREAM- or DATAGRAM sockets. To give the reader an introduction into the subject we will first give an overview about the different APIs provided by Windows, Linux and Unix (FreeBSD, Mac OS X) and additional libraries that can be used OS-independent. In the next section we show general problems that have to be addressed by the programmer when working with RAW-sockets. We will then provide an introduction into the steps necessary to use the APIs or libraries, which functionality the different concepts provide to the programmer and what they provide to simplify using RAW and PACKET-sockets. This section includes examples of how to use the different functions provided by the APIs. Finally in the additional material we will give some complete examples that show the concepts and can be used as a basis to write own programs.
    [Show full text]
  • Programmer's Guide
    Programmer’s Guide Release 18.02.2 June 15, 2018 CONTENTS 1 Introduction 1 1.1 Documentation Roadmap...............................1 1.2 Related Publications..................................2 2 Overview 3 2.1 Development Environment..............................3 2.2 Environment Abstraction Layer............................4 2.3 Core Components...................................4 2.4 Ethernet* Poll Mode Driver Architecture.......................6 2.5 Packet Forwarding Algorithm Support........................6 2.6 librte_net........................................6 3 Environment Abstraction Layer7 3.1 EAL in a Linux-userland Execution Environment..................7 3.2 Memory Segments and Memory Zones (memzone)................ 11 3.3 Multiple pthread.................................... 12 3.4 Malloc.......................................... 14 4 Service Cores 19 4.1 Service Core Initialization............................... 19 4.2 Enabling Services on Cores............................. 19 4.3 Service Core Statistics................................ 20 5 Ring Library 21 5.1 References for Ring Implementation in FreeBSD*................. 22 5.2 Lockless Ring Buffer in Linux*............................ 22 5.3 Additional Features.................................. 22 5.4 Use Cases....................................... 22 5.5 Anatomy of a Ring Buffer............................... 22 5.6 References....................................... 31 6 Mempool Library 33 6.1 Cookies......................................... 33 6.2 Stats.........................................
    [Show full text]
  • Efficient Pc-Fpga Communication Over Gigabit Ethernet
    EFFICIENT PC-FPGA COMMUNICATION OVER GIGABIT ETHERNET Nikolaos Alachiotis, Simon A. Berger, Alexandros Stamatakis∗ The Exelixis Lab Department of Computer Science Technische Universit¨at M¨unchen email: {alachiot,bergers,stamatak}@in.tum.de ABSTRACT As FPGAs become more powerful in terms of available reconfigurable hardware resources, they are increasingly used As FPGAs become larger and more powerful, they are in- as accelerator devices, for instance because of their inherent creasingly used as accelerator devices for compute-intensive ability to process more data in parallel. A common trend is functions. Input/Output (I/O) speeds can become a bottle- to connect a FPGA-based board to a general purpose proces- neck and directly affect the performance of a reconfigurable sor, usually a personal computer (PC), for offloading com- accelerator since the chip will idle when there are no data putationally intensive parts or functions of an application to available. While PCI Express represents the currently fastest the FPGA. Function offloading to the FPGA can thus sig- and most expensive solution to connect a FPGA to a general nificantly speed up the execution of scientific codes for in- purpose CPU, there exist several applications with I/O re- stance. To exploit the full acceleration potential of a recon- quirements for which Gigabit Ethernet is sufficient. figurable architecture, the time the FPGA idles because it is To this end, we present the design of an efficient UDP/IP waiting for an I/O operation should be minimized. core for PC-FPGA communication that has been designed to occupy a minimum amount of hardware resources on the The fastest and most expensive interconnect technology FPGA.
    [Show full text]
  • 2507 Lulea University of Technology/SICS Category: Standards Track B
    Network Working Group M. Degermark Request for Comments: 2507 Lulea University of Technology/SICS Category: Standards Track B. Nordgren Lulea University of Technology/Telia Research AB S. Pink Lulea University of Technology/SICS February 1999 IP Header Compression Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Abstract This document describes how to compress multiple IP headers and TCP and UDP headers per hop over point to point links. The methods can be applied to of IPv6 base and extension headers, IPv4 headers, TCP and UDP headers, and encapsulated IPv6 and IPv4 headers. Headers of typical UDP or TCP packets can be compressed down to 4-7 octets including the 2 octet UDP or TCP checksum. This largely removes the negative impact of large IP headers and allows efficient use of bandwidth on low and medium speed links. The compression algorithms are specifically designed to work well over links with nontrivial packet-loss rates. Several wireless and modem technologies result in such links. TABLE OF CONTENTS 1. Introduction..............................................3 2. Terminology...............................................5 3. Compression method........................................7 3.1. Packet types.......................................8 3.2. Lost packets in TCP packet streams.................9 3.3. Lost packets in UDP and non-TCP packet streams....10 4. Grouping packets into packet streams.....................14 Degermark, et.
    [Show full text]
  • Network Lecture # 8
    Faculty of Engineering Computer Engineering Department Islamic University of Gaza 201 2 Network Lecture # 8 CHAPTER 181818 : INTERNET PROTOCOLS Network LLLectureLectureecture## 888 CHAPTECHAPTERR 181818 : INTERNET PROTOCOLS Review Questions 18.1. Give some reasons for using fragmentation and reassembly. (1) The communications network may only accept blocks of data up to a certain size. (2) Error control may be more efficient with a smaller PDU size. With smaller PDUs, fewer bits need to be retransmitted when a PDU suffers an error. (3) More equitable access to shared transmission facilities, with shorter delay, can be provided. (4) A smaller PDU size may mean that receiving entities can allocate smaller buffers. (5) An entity may require that data transfer comes to some sort of "closure" from time to time, for checkpoint and restart/recovery operations. 18.2. List the requirements for an internetworking facility. (1) Provide a link between networks. At minimum, a physical and link control connection is needed. (2) Provide for the routing and delivery of data between processes on different networks. (3) Provide an accounting service that keeps track of the use of the various networks and routers and maintains status information. (4) Provide the services just listed in such a way as not to require modifications to the networking architecture of any of the constituent networks. This means that the internetworking facility must accommodate a number of differences among networks. 18.4. Explain the function of the three flags in the IPv4 header. The More bit is used for fragmentation and reassembly. If this bit is 0, then either there has been no fragmentation of this packet or this is the last fragment.
    [Show full text]
  • UDP Encapsulation in Linux
    UDP Encapsulation in Linux Tom Herbert Google USA [email protected] Abstract Basics of UDP encapsulation UDP encapsulation encompasses the techniques and protocols to Encapsulation is the technique of adding network headers encapsulate and decapsulate networking packets of various to a fully formed packet for the purposes of transit across a protocols inside UDP. UDP encapsulation has become prevalent network. UDP encapsulation includes the techniques and in data centers, and in fact nearly all the solutions for network protocols to encapsulate networking packets within User virtualization currently being proposed in IETF are based on UDP Datagram Protocol [1]. Packets are contained in the UDP encapsulation. payload, and are said to be encapsulated in UDP packets. In this paper we present much of the recent work done by the Tunneling, overlay networks, and network virtualization, Linux networking community to make UDP encapsulation a first are terms often associated with encapsulation. Tunneling class citizen. This cumulative work has resulted in greatly refers to the use of a high level transport service to carry improved performance, robustness, and scalability. We begin by packets or messages from another service. Encapsulation is describing the basic support and model for UDP encapsulation. often the lower level mechanism that implements a tunnel. Next, we look at performance enhancements in the areas of load An overlay network is a computer network which is built balancing, checksum offload, and segmentation offload. Finally, on the top of another network. An overlay network may we examine two generic methods of UDP encapsulation: Foo- be composed of links which are implemented by over-UDP and Generic UDP Encapsulation.
    [Show full text]
  • Ipv6 Is More Than Addresses
    IPv6 is More Than Addresses John W. McClain ICTN 6885 Spring 2014 1 Abstract Version 6 of the internet protocol (IPv6) is the designated successor for internet protocol version 4 (IPv4). The need for this new protocol version was driven by the depletion of IPv4 addresses. At this time there are no more IPv4 addresses available. The explosive growth of internet activity and mobile devices like smartphones created the perfect conditions to deplete the available IPv4 addresses. So, anyone designing a network must consider IPv6 during the discussion phase of the project. The explosive growth of internet activity and mobile devices created security issues for users and providers of computing services. The purpose of this paper is to discuss the reasons why IPv6’s security features are just as important as more addresses. This paper will go through a three phased approach to discussing IPv6 security. The first section of this paper will go through the planning process for implementing IPv6 on a network. It should be noted that most devices have IPv6 capabilities built into the devices now. The latest Windows systems have IPv6 capabilities. The second section of this paper will discuss the differences between IPv4 and IPv6. At some point during an upgrade IPv4 and IPv6 will need to exist together so knowing the differences is important. The last section of the paper will look at ways to exploit IPv6’s vulnerabilities. The hackers aren’t going let better security features stop their assault plans. Overall, IPv6 is more than additional addresses, the security features are extremely important.
    [Show full text]
  • Checksum Coverage and Delivery of Errored Content
    Checksum Coverage and Delivery of Errored Content Lloyd Wood, Wesley M. Eddy, Jim McKim and Will Ivancic Abstract —We examine how the overall reliability of network application protocol stacks is affected by the use of error-detecting checksums and Cyclic Redundancy Checks at each protocol transport layer. How these checksums cover their frames and payloads can affect the reliability of the rest of the stack, particularly higher layers, and the resulting delivery of data. We then apply insights network gained to a comparison of new protocols promising delivery of packets with payload errors, to determine how well those data link/MAC protocols achieve that goal when used in realistic stacks. Index Terms physical —checksum, CRC, partial checksum, partial reliability, Internet, IP, TCP, UDP, DCCP, UDP-Lite, Saratoga, a. Minimal reliability with an end-to-end checksum. Licklider, LTP, DTN, delay-tolerant networking, bundles. I. INTRODUCTION application Reliability in the processing and delivery of received data is transport fundamental to packet networking. By this, we mean being able to trust the data in the payloads of the packets that you network receive, and being able to trust the structure of the very packets and frames so that you can decode them correctly and data link/MAC get at the payload data they hold. This is distinct from (although supplemental to and a prerequisite for) the notion of physical delivery reliability from acknowledgement and retransmission protocols. Even when applications can tolerate errors in the b. Still end-to-end, but redundancy in checking may be payload data they receive, delivered by the protocols discussed unnecessary.
    [Show full text]
  • Ipv6 for Ipv4 Experts
    IPv6 for IPv4 Experts Yar Tikhiy December 31, 2013 DRAFT License cbnd This draft is licensed under the Creative Commons Attribution-NonCommercial- NoDerivs license. DRAFT 1 Contents Preface 9 1 Defining the Problem 11 2 IPv6 Address 19 2.1 TheIPv6AddressLengthIssue . 19 2.2 TextRepresentationofanIPv6Address . 29 2.3 IPv6AddressTypes ....................... 38 2.4 IPv6AddressScopeandZone . 42 2.5 Well-known Applications of IPv6 Link-local Addresses . 59 2.6 IPv6UnicastAddressStructure . 61 2.7 IPv6InterfaceIDsandEUI-64. 66 2.8 IPv6MulticastAddressStructure . 72 2.9 IPv6 Multicast Addressing Extensions Based on Unicast Ad- dresses . 78 2.10 Site-Local Address Problem and Its Solution . 85 2.11 IPv6AddressesinDNS. 89 3IPv6Packet 92 3.1 IPv6 Packet Layout . 92 3.2 IPv6Header............................ 96 3.3 ExtensionHeaders ........................ 104 3.3.1 A Header That Isn’t There: No Next Header . 104 3.3.2 IPv6DRAFT Options . 105 3.3.3 RoutingHeader ..................... 111 3.3.4 Fragment Header. IPv6 Fragmentation and Reassembly 119 3.3.5 IPSecurityHeaders. 134 3.3.6 ExtensionHeaderOrdering . 142 3.3.7 UnsupportedHeaderHandling. 144 2 CONTENTS 3 4 IPv6 in the Protocol Stack 147 4.1 Link-Level Encapsulation . 147 4.1.1 Ethernet . 148 4.1.2 PPP . 151 4.2 InteractionwithUpper-LayerProtocols . 158 4.3 Control . 162 5 Neighbor Discovery Protocol 172 5.1 Neighbor Discovery and IPv6 Address Resolution . 172 5.2 TheHost,theLink,andtheSubnetinIPv6 . 207 5.3 IPv6AddressingModesRevised. Anycast . 239 5.4 IPv6Autoconfiguration. 247 5.4.1 Interface ID Selection and Duplicate Address Detection 247 5.4.2 Prefix and Router Discovery . 255 6 Advanced IPv6 277 6.1 AnycastingtotheRoutersoftheSubnet . 277 6.2 PrivacyExtensionsforSLAAC .
    [Show full text]
  • Sample Content from Understanding Ipv6, Second Edition
    To learn more about this book, visit Microsoft Learning at http://www.microsoft.com/MSPress/books/11607aspx © A05T624467.fm Page vii Tuesday, December 4, 2007 5:28 PM Table of Contents Foreword . xxxi Preface. .xxxiii Acknowledgments . xxxv Introduction . xxxvii Who Should Read This Book. .xxxviii What You Should Know Before Reading This Book . .xxxviii Organization of This Book. .xxxix Appendices of This Book . .xxxix About the Companion CD-ROM . xl System Requirements. xli IPv6 Protocol and Windows Product Versions . xli A Special Note to Teachers and Instructors . xli Disclaimers and Support . xlii Technical Support . xlii 1 Introduction to IPv6 . .1 Limitations of IPv4. 1 Consequences of the Limited IPv4 Address Space. 2 Features of IPv6 . 6 New Header Format . 6 Large Address Space . 6 Stateless and Stateful Address Configuration . 6 IPsec Header Support Required . 7 Better Support for Prioritized Delivery. 7 New Protocol for Neighboring Node Interaction . 7 Extensibility. .7 Comparison of IPv4 and IPv6 . 8 IPv6 Terminology. 9 What do you think of this book? We want to hear from you! Microsoft is interested in hearing your feedback so we can continually improve our books and learning resources for you. To participate in a brief online survey, please visit: www.microsoft.com/learning/booksurvey/ vii A05T624467.fm Page viii Tuesday, December 4, 2007 5:28 PM viii Table of Contents The Case for IPv6 Deployment . 11 IPv6 Solves the Address Depletion Problem. 12 IPv6 Solves the Disjoint Address Space Problem . 12 IPv6 Solves the International Address Allocation Problem . 12 IPv6 Restores End-to-End Communication. 13 IPv6 Uses Scoped Addresses and Address Selection .
    [Show full text]
  • Ts 102 361-3 V1.2.1 (2013-07)
    ETSI TS 102 361-3 V1.2.1 (2013-07) Technical Specification Electromagnetic compatibility and Radio spectrum Matters (ERM); Digital Mobile Radio (DMR) Systems; Part 3: DMR data protocol 2 ETSI TS 102 361-3 V1.2.1 (2013-07) Reference RTS/ERM-TGDMR-312-3 Keywords air interface, data, digital, PMR, protocol, radio ETSI 650 Route des Lucioles F-06921 Sophia Antipolis Cedex - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 Siret N° 348 623 562 00017 - NAF 742 C Association à but non lucratif enregistrée à la Sous-Préfecture de Grasse (06) N° 7803/88 Important notice Individual copies of the present document can be downloaded from: http://www.etsi.org The present document may be made available in more than one electronic version or in print. In any case of existing or perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive within ETSI Secretariat. Users of the present document should be aware that the document may be subject to revision or change of status. Information on the current status of this and other ETSI documents is available at http://portal.etsi.org/tb/status/status.asp If you find errors in the present document, please send your comment to one of the following services: http://portal.etsi.org/chaircor/ETSI_support.asp Copyright Notification No part may be reproduced except as authorized by written permission.
    [Show full text]