DOCSLIB.ORG

COM-5503SOFT IP Protocol Stack for 10Gbe, VHDL Source Code Overview

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
COM-5503SOFT IP Protocol Stack for 10Gbe, VHDL Source Code Overview COM-5503SOFT IP/TCP CLIENTS/UDP/ARP/PING STACK for 10GbE VHDL SOURCE CODE OVERVIEW Overview simple enough to interface with any Ethernet MAC component with minimum glue logic. 10Gigabit-speed IP protocols like TCP/IP and UDP/IP can demand a high level of computation on Wireshark Libpcap network capture files can be processors. The trend has been to move the used as receiver input for simulation purposes. implementation of these fast but highly repetitive tasks to a TCP offload engine (TOE) to free the application processor from frequent interrupts. Block Diagram DHCP The COM-5503SOFT is a generic Internet protocol CLIENT stack (including the VHDL source code) designed to support near 10Gbps throughputs on any low- IGMP cost FPGAs running at 156.25 MHz. APPLICATION NEIGHBOR INTERFACE The modular architecture of VHDL components DISCOVERY reflects the various internet protocols implemented STREAMS TO 1 ARP PACKETS within: TCP clients , UDP transmit, UDP receive, REPLY ARP, NDP, PING, IGMP (for multicast UDP) and MAC INTERFACE DHCP client. Ancillary components are also PING UDP_TX included for streaming. These components can be 10Gb MAC REPLY Receive easily enabled or disabled as needed by the user's Interface application. ROUTING TABLE PACKET PARSING The VHDL source code is fully portable to a variety ARP/NDP of FPGA platforms. REQUEST The maximum number of concurrent TCP PACKETS TO UDP_RX connections can be adjusted prior to VHDL STREAMS synthesis depending on the available FPGA resources. TCP_RXBUF TCP CLIENTS The code is written specifically for IEEE 802.3 Ethernet packet encapsulation (RFC 894). It TCP_TXBUF supports IPv4, IPv6, jumbo frames. TCP_TX The code interfaces seamlessly with the COM-5501SOFT 10Gbps Ethernet MAC for the 10Gb MAC Arbitration MAC / PHY layers implementation or the Transmit COM-5401SOFT 10/100/1000 Mbps Ethernet Interface MAC. However, the MAC interface is generic and 190010 1 See COM-5502SOFT for TCP servers. MSS • 845 Quince Orchard Boulevard Ste N • Gaithersburg, Maryland 20878-1676 • U.S.A. Telephone: (240) 631-1111 Facsimile: (240) 631-1676 www.ComBlock.com © MSS 2021 Issued 1/23/2021 Target Hardware The code is written in generic VHDL so that it can be ported to a variety of FPGAs capable of running at 156.25 MHz or above. It was developed and tested on Xilinx 7-series FPGAs. Device Utilization Summary (Excludes 10G Ethernet MAC and XAUI) Device: Xilinx Artix-7 UDP-only: 1 UDP rx, 1 UDP tx, 0 TCP client, ARP, Ping, routing table, IPv4 only, 8KB UDP tx buffer Flip Flops 3125 LUTs 2737 36Kb block RAM 7.5 DSP48 0 TCP IPv4 only: 0 UDP rx, 0 UDP tx, 1 TCP client, ARP, Ping, routing table, IPv4 only, 32KB TCP buffers Flip Flops 2224 LUTs 2381 36Kb block RAM 9.5 DSP48 0 TCP IPv4 only: 0 UDP rx, 0 UDP tx, 2 TCP clients, ARP, Ping, routing table, IPv4 only, 32KB TCP buffers Flip Flops 2735 LUTs 2563 36Kb block RAM 17 DSP48 1 UDP rx, 1 UDP tx, 1 TCP client, ARP, Ping, NDP, routing table, IPv4. IPv6, 32KB TCP buffers Flip Flops 7208 LUTs 9120 36Kb block RAM 32.5 DSP48 0 2 TCP Throughput The TCP throughput is primarily a function of the tx/rx buffers sizes and of the two-way delay. For example, if the two way delay (NIC + FPGA) is 90us Buffers sizes TCP throughput 2kB 133 Mbits/s 8kB 673 Mbits/s 32kB 2.8 Gbits/s 64kB 5.56 Gbits/s 128kB 9.3 Gbits/s 256kB 9.3 Gbits/s If the two-way delay is only 45us, the same TCP throughput can be achieved with half-sized buffers. The buffer size is determined prior to synthesis by the generic parameters TCP_TX/RX_WINDOW_SIZE Throughput Performance Examples UDP IPv4 UDP throughput using 512-Byte data frames: 8.64 Gbits/s IPv4 UDP throughput using 2048-Byte data frames: 9.62 Gbits/s TCP IPv4 TCP single server, uni-directional stream, MTU = 1500 Bytes, equal length maximum size IP frames: 9.38 Gbits/s TCP IPv6 TCP single server, uni-directional stream, MTU = 1500 Bytes, equal length maximum size IP frames: 9.23 Gbits/s IPv4 TCP single server, bi-directional streams, MTU = 1500 Bytes 8.82 Gbits/s in each direction IPv4 TCP single server, uni-directional stream, MTU = 8252 Bytes, equal length maximum size IP frames, buffer size = 32K Bytes: 9.88 Gbits/s IPv6 TCP single server, uni-directional stream, MTU = 8252 Bytes, equal length maximum size IP frames, buffer size = 32K Bytes: 9.86 Gbits/s 3 TCP Latency Performance Examples Interfaces The transmit and receive latency depend on the MAC INTERFACE APP INTERFACE frame length. For a maximum frame length of 1460 CLK UDP_RX_DATA(63:0) SYNC_RESET UDP_RX_DATA_VALID(7:0) bytes, FPGA 156.25 MHz processing clock: MAC_TX_DATA(63:0) UDP RX UDP_RX_SOF MAC_TX_DATA_VALID(7:0) Transmit latency (from the 1st byte of DATA UDP_RX_EOF MAC_TX_SOF MAC TX UDP_RX_FRAME_VALID payload data input to the 1st byte of MAC_TX_EOF DATA payload data output to the Ethernet MAC): MAC_TX_CTS UDP_RX_DEST_PORT_NO_IN(15:0) 23.9µs MAC_TX_RTS CHECK_UDP_RX_DEST_PORT_NO UDP_RX_DEST_PORT_NO_OUT(15:0) Receive latency (from the 1st byte of MAC_RX_DATA(63:0) Ethernet MAC input to the 1st byte of MAC_RX_DATA_VALID(7:0) UDP_TX_DATA(63:0) MAC_RX_SOF MAC RX UDP_TX_DATA_VALID(7:0) payload data output): 12.2µs MAC_RX_EOF DATA UDP_TX_SOF MAC_RX_FRAME_VALID If latency is more important than throughput, the UDP TX UDP_TX_EOF DATA UDP_TX_CTS transmit segmentation threshold can be reduced to UDP_TX_ACK X payload bytes. In this more general case, UDP_TX_NAK UDP_TX_DEST_IP_ADDR(127:0) Transmit latency (from the 1st byte of UDP_TX_DEST_IPv4_6n payload data input to the 1st byte of UDP_TX_DEST_PORTS payload data output to the Ethernet MAC): UDP_TX_SRC_PORT 0.5 + 2X/125 µs TCP_RX_DATA (63:0) The receive latency (from the 1st byte of Ethernet REPLICATED NTCPSTREAMS TCP_RX_DATA_VALID(7:0) MAC input to the 1st byte of payload data TIMES TCP_RX_RTS output): 0.5 + X/125 µs TCP RX TCP_RX_CTS DATA TCP_RX_CTS_ACK TCP_LOCAL_PORTS TCP_TX_DATA(63:0) REPLICATED TCP_TX_DATA_VALID(7:0) NTCPSTREAMS TCP_TX_DATA_FLUSH TIMES TCP TX TCP_TX_CTS CONTROLS DATA TCP_CONNECTED_FLAG MAC_ADDR(47:0) IPv4_ADDR(31:0) TCP_DEST_IP_ADDR IPv4_MULTICAST_ADDR(31:0) TCP_DEST_IPv4_6n IPv4_SUBNET_MASK(31:0) TCP_DEST_PORTS IPv4_GATEWAY_ADDR(31:0) TCP_STATE_REQUESTED IPv6_ADDR(127:0) TCP_STATE_STATUS IPv6_SUBNET_PREFIX_LENGTH(7:0) TCP_KEEPALIVE_EN IPv6_GATEWAY_ADDR(127:0) 180017 Component Interface This interface comprises three primary signal groups: MAC interface (direct connection to COM- 5501SOFT Ethernet MAC or equivalent) TCP streams UDP frames or UDP streams to/from the user application. All signals are clock synchronous. See the clock/timing section. 4 Configuration TCP buffers TCP_TX_WINDOW_SIZE sizes TCP_RX_WINDOW_SIZE The key configuration parameters are brought to the Window size is expressed as interface so that the user can change them 2**n Bytes. Thus a value of 15 dynamically at run-time. Other, more arcane, indicates a window size of parameters are fixed at the time of VHDL synthesis. 32KB. This generic parameter determines how much memory is Pre-synthesis configuration parameters allocated to buffer tcp streams. It applies equally to all concurrent The following configuration parameters are set streams (no individualization). prior to synthesis in the com5503pkg.vhd package Purpose: tradeoff memory or at the top level component com5503.vhd. utilization vs throughput. Configuration Description Memory size ranges from 2KB parameters in (multiple streams/lower com5503pkg.vhd individual throughput) to 1MB Maximum number NTCPSTREAMS_MAX. (single stream/maximum of concurrent TCP This applies to all COM5503 throughput) streams components instantiated in a The window scale option is project. It primarily affects the data recommended on the client side width of the TCP interface. when this server's buffers are Configuration Description larger than 64KB. parameters in DHCP client DHCP_CLIENT_EN com5503.vhd instantiation ‘1’ to instantiate a DHCP client within. DHCP is a protocol used Number of NTCPSTREAMS to dynamically assign IP concurrent TCP This applies to a given COM5503 addresses at power up from streams for a given instance. remote DHCP servers, like a COM5503 Each additional TCP stream gateway. instance. requires additional resources ’0’ when a fixed (static) IP (RAM block, logic). address is defined by the user. IGMP IGMP_EN UDP transmit NUDPTX instantiation instantiated (1) / disabled (0) instantiation instantiated (1) / disabled (0) Enable when using UDP Note: a component handles multicast addresses multiple ports. Inactive input TX_IDLE_TIMEOUT When UDP receive NUDPRX stream timeout segmenting a TCP transmit instantiation instantiated (1) / disabled (0) stream, a packet will be sent out Note: a component handles with pending data if no new data multiple ports was received within the specified Enable IPv6 IPv6_ENABLED timeout. protocols '1' to allow IPv6 protocols in Expressed as integer multiple of addition to the baseline IPv4. 4s. '0' to ignore IPv6 messages. TCP keep- TCP_KEEPALIVE_ MTU size MTU alive period PERIOD Maximum Transmission Unit: IP period in seconds for sending no frame maximum byte size. data keepalive frames. -- Typically 1500 for standard frames, 9000 for jumbo frames. "Typically TCP Keepalives are -- A frame will be deemed invalid sent every 45 or 60 seconds on if its payload size exceeds this an idle TCP connection, and the MTU value. connection is dropped after 3 -- Should match the values in sequential ACKs are missed" MAC layer) -- elastic buffers at the user CLK CLK_FREQUENCY frequency CLK frequency in MHz. Needed interface should be sized to contain at least 4 IP frames payload. See to compute actual delays. ADDR_WIDTH generic parameter. 5 Configuration Description Configuration Description parameters in parameters in ping_10g.vhd stream_2_packets_10g Maximum ping size MAX_PING_SIZE . maximum IP/ICMP size vhd (excluding Ethernet/MAC, Maximum packet size MAX_PACKET_SIZE but including the IP/ICMP when segmenting a When segmenting a header) in 64-bit words. stream to packets transmit stream, a packet Larger echo requests will be will be sent out as soon as ignored.
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]