High-speed, in-band performance measurement instrumentation for next generation IP networks

Facilitating always-on instrumentation of Internet traffic for the purposes of performance measurement is crucial in order to enable accountability of resource usage and automated network control, management and optimisation. This has proven infeasible to date due to the lack of native measurement mechanisms that can form an integral part of the network‟s main forwarding operation. However, Internet Protocol version 6 (IPv6) specification enables the efficient encoding and processing of optional per-packet information as a native part of the network layer, and this constitutes a strong reason for IPv6 to be adopted as the ubiquitous next generation Internet transport. In this paper we present a very high-speed hardware implementation of in-line measurement, a truly native traffic instrumentation mechanism for the next generation Internet, which facilitates performance measurement of the actual data-carrying traffic at small timescales between two points in the network. This system is designed to operate as part of the routers' fast path and to incur an absolutely minimal impact on the network operation even while instrumenting traffic between the edges of very high capacity links. Our results show that the implementation can be easily accommodated by current FPGA technology, and real Internet traffic traces verify that the overhead incurred by instrumenting every packet over a 10 Gb/s operational backbone link carrying a typical workload is indeed negligible

Multicast Mobility in Mobile IP Version 6 (MIPv6) : Problem Statement and Brief Survey

Publisher PD

User-space Multipath UDP in Mosh

In many network topologies, hosts have multiple IP addresses, and may choose among multiple network paths by selecting the source and destination addresses of the packets that they send. This can happen with multihomed hosts (hosts connected to multiple networks), or in multihomed networks using source-specific routing. A number of efforts have been made to dynamically choose between multiple addresses in order to improve the reliability or the performance of network applications, at the network layer, as in Shim6, or at the transport layer, as in MPTCP. In this paper, we describe our experience of implementing dynamic address selection at the application layer within the Mobile Shell. While our work is specific to Mosh, we hope that it is generic enough to serve as a basis for designing UDP-based multipath applications or even more general APIs

Connecting the World of Embedded Mobiles: The RIOT Approach to Ubiquitous Networking for the Internet of Things

The Internet of Things (IoT) is rapidly evolving based on low-power compliant protocol standards that extend the Internet into the embedded world. Pioneering implementations have proven it is feasible to inter-network very constrained devices, but had to rely on peculiar cross-layered designs and offer a minimalistic set of features. In the long run, however, professional use and massive deployment of IoT devices require full-featured, cleanly composed, and flexible network stacks. This paper introduces the networking architecture that turns RIOT into a powerful IoT system, to enable low-power wireless scenarios. RIOT networking offers (i) a modular architecture with generic interfaces for plugging in drivers, protocols, or entire stacks, (ii) support for multiple heterogeneous interfaces and stacks that can concurrently operate, and (iii) GNRC, its cleanly layered, recursively composed default network stack. We contribute an in-depth analysis of the communication performance and resource efficiency of RIOT, both on a micro-benchmarking level as well as by comparing IoT communication across different platforms. Our findings show that, though it is based on significantly different design trade-offs, the networking subsystem of RIOT achieves a performance equivalent to that of Contiki and TinyOS, the two operating systems which pioneered IoT software platforms

A Study on Techniques for Handling Transmission Error of IPV6 Packets over Fmer Optic Links

Problem identification of the existing error control mechanism is very important to find out a new suitable design to solve the problem of ineffective error control.The identification results become main basic of designing a new mechanism.Hence, the design obtained truly solves the problem accurately

Internet-wide geo-networking problem statement

This document describes the need of specifying Internet-wide location-aware forwarding protocol solutions that provide packet routing using geographical positions for packet transport

Performance comparison of transmitting jumbo frame on Windows and Linux System

IPv6 is the successor of IPv4, the current Internet Protocol that runs out its address. It offers some improvements including simpler header format and extension header resulting in faster transmission of IP packets. However, IPv6 is a network layer protocol that requires lower layer services. IP packets from the network layer pass to data link layer to be encapsulated by layer 2 headers and trailer to become frames. Ethernet is the most widely used data link layer protocol in the current network devices. The technology is always improved to support high speed transmission. However, from standard Ethernet until ten gigabit Ethernet, the size of MTU remains unchanged at 1500 Bytes. This prevents the network from gaining an optimum performance on transmitting IP packets and operating systems cannot take full advantage of the high-speed performance of Gigabit Ethernet. This research aims to implement the transmission of IPv6 packets using jumbo frame on a test-bed environment. The implementation can be used to justify the impact of jumbo frame on the network as well as operating systems performance. The results prove that the OS used on implementation of jumbo frame affects on the network performance. The highest percentage of increasing throughput is 33.6% when both sender and receiver are running Windows. The decreasing delay by 54.36% was happened when using Linux in sender and Windows in receiver