Search

Because it is very bursty, the microsecond-scale temporal behaviour of network traffic in data-centres is challenging to measure and understand. To bring observability into data-centre networks, this paper introduces the Open Platform for Programmable Precise Packet Timestamping (OP4T), a hardware architecture, targeting Field-Programmable Gateway Arrays (FPGAs), integrated into data-centre servers as a Smart Network Interface Card (SmartNIC), and flexible enough to enable advanced latency diagnosis.In this paper, OP4T is specified, and an open-source implementation of that architecture is proposed, targeting the NetFPGA SUME prototyping board. By leveraging the P4 programming language, and partial reconfiguration, that opensource implementation is experimentally shown to enable in-band, precise packet timestamping, without sacrificing the achievable throughput. As an illustration, OP4T is shown to be usable to measure fine-grained properties of a software packet forwarder, e.g., packet batching.

This document analyzes common security threats to the Optimized Link State Routing Protocol version 2 (OLSRv2) and describes their potential impacts on Mobile Ad Hoc Network (MANET) operations. It also analyzes which of these security vulnerabilities can be mitigated when using the mandatory-to-implement security mechanisms for OLSRv2 and how the vulnerabilities are mitigated. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8116. Clausen, et al.

This document analyzes security threats to Simplified Multicast Forwarding (SMF), including vulnerabilities of duplicate packet detection and relay set selection mechanisms. This document is not intended to propose solutions to the threats described. In addition, this document updates RFC 7186 regarding threats to the relay set selection mechanisms using the Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP) (RFC 6130). Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7985. Yi, et al.

This document replaces RFC 6779; it contains revisions and extensions to the original document. It defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring parameters of the Neighborhood Discovery Protocol (NHDP) process on a router. The extensions described in this document add objects and values to support the NHDP optimization specified in RFC 7466. The MIB module defined in this document, denoted NHDP-MIB, also reports state, performance information, and notifications about NHDP. This additional state and performance information is useful to troubleshoot problems and performance issues during neighbor discovery.

This specification describes an extension to the Optimized Link State Routing Protocol version 2 (OLSRv2) to support multiple routing topologies, while retaining interoperability with OLSRv2 routers that do not implement this extension. This specification updates RFCs 7188 and 7631 by modifying and extending TLV registries and descriptions. Status of This Memo This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation. This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7722.

This document reorganizes the naming of already-allocated TLV (typelength-value) types and type extensions in the "Mobile Ad hoc NETwork (MANET) Parameters" registries defined by RFC 5444 to use names appropriately. It has no consequences in terms of any protocol implementation. This document also updates the Expert Review guidelines in RFC 5444, so as to establish a policy for consistent naming of future TLV type and type extension allocations. It makes no other changes to RFC 5444. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7631.

The link quality mechanism of the Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP) enables "ignoring" some 1-hop neighbors if the measured link quality from that 1-hop neighbor is below an acceptable threshold while still retaining the corresponding link information as acquired from the HELLO message exchange. This allows immediate reinstatement of the 1-hop neighbor if the link quality later improves sufficiently.

The mechanism in this specification can also be used for other protocols that use the generalized packet/message format described in RFC 5444. This document updates RFC 6130 and RFC 7181 by mandating the implementation of this integrity and replay protection in NHDP and OLSRv2. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

The Optimized Link State Routing Protocol version 2 (OLSRv2) includes the ability to assign metrics to links and to use those metrics to allow routing by other than minimum hop count routes. This document provides a historic record of the rationale for, and design considerations behind, how link metrics were included in OLSRv2. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7185.

This document analyzes common security threats of the Neighborhood Discovery Protocol (NHDP) and describes their potential impacts on Mobile Ad Hoc Network (MANET) routing protocols using NHDP. This document is not intended to propose solutions to the threats described. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7186. Yi, et al.

This specification updates the Optimized Link State Routing Protocol version 2 (OLSRv2) with an optimization to improve the selection of routing multipoint relays. The optimization retains full interoperability between implementations of OLSRv2 with and without this optimization. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7187.

This specification describes extensions to definitions of TLVs used by the Optimized Link State Routing Protocol version 2 (OLSRv2) and the MANET Neighborhood Discovery Protocol (NHDP) to increase their abilities to accommodate protocol extensions. This document updates RFC 7181 (OLSRv2) and RFC 6130 (NHDP). Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7188.

This document revises, extends, and replaces RFC 6622. It describes general and flexible TLVs for representing cryptographic Integrity Check Values (ICVs) and timestamps, using the generalized Mobile Ad Hoc Network (MANET) packet/message format defined in RFC 5444. It defines two Packet TLVs, two Message TLVs, and two Address Block TLVs for affixing ICVs and timestamps to a packet, a message, and one or more addresses, respectively. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

This specification describes version 2 of the Optimized Link State Routing Protocol (OLSRv2) for Mobile Ad Hoc Networks (MANETs). Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7181.

This document describes general and flexible TLVs for representing cryptographic Integrity Check Values (ICVs) (i.e., digital signatures or Message Authentication Codes (MACs)) as well as timestamps, using the generalized Mobile Ad Hoc Network (MANET) packet/message format defined in RFC 5444. It defines two Packet TLVs, two Message TLVs, and two Address Block TLVs for affixing ICVs and timestamps to a packet, a message, and an address, respectively. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6622.

International audience; Qu'est-ce que la communication ? Vaste question. Ce chapitre ne prétend pas y répondre dans son intégralité, mais présente les principes qui régissent de nos jours la communication entre ordinateurs, et notamment Internet.

Jitter is a small, random variation of timing before message emission that is widely used in non-synchronized wireless communication. It is employed to avoid collisions caused by simultaneous transmissions by adjacent nodes over the same channel. In reactive (on-demand) routing protocols, such as AODV and LOADng, it is recommended to use jitter during the flooding of Route Request messages. This paper analyzes the cost of jitter mechanisms in route discovery of on-demand routing protocols, and examines the drawbacks of the standard and commonly used uniformly distributed jitter. The main studied drawback is denominated delay inversion effect. Two variations on the jitter mechanism-window jitter and adaptive jitter-are proposed to address this effect, which take the presence and the quality of traversed links into consideration to determine the per-hop forwarding delay. These variations allow to effectively reduce the routing overhead, and increase the quality of the computed paths with respect to the standard uniform jitter mechanism. Simulations are also performed to compare the performance of different jitter settings in various network scenarios.

International audience; LOADng is an on-demand routing protocol, derived from AODV, simplified for use in lossy, low-power and constrained environments, where the ability for devices to communicate is a commodity to their primary function, and where therefore not only the communications channel offers limited capacity, but also the resources available to the device's communications subsystem are limted. LOADng simplifies AODV in a number of ways, notably the route discovery process by removing intermediate/gratuitous Route Replies-sacrificing that functionality in order to attain smaller control messages and less router state and processing. Alas, this comes at an expense: in some situations, LOADng produces increased control traffic overhead (as compared to AODV), and more control messages transmissions means tapping into the device's limited resources. This paper presents a simple mechanism by which to integrate Expanding Ring flooding into LOADng. The mechanism is described, and the result of simulation studies are presented, showing that both in scenarios with "point-to-point" (any-to-any) traffic and in scenarios with "multipoint-to-point" (all traffic sent to the same destination, as in a data acquisition sensor network) traffic, considerable savings in control traffic overhead can be achieved-without loss in data delivery ratios.

With more and more cellular phone handsets being introduced wifi interfaces, an alternative to using the purely cell-based mobile phone networks infrastructure can be envisioned: mobile phone cells can be extended via ad-hoc relaying of traffic from out-of-coverage handsets towards in-coverage handsets, and mobile phones might be able to establish communication paths between them without passing through the cellular infrastructure. This presents a number of challenges including billing, security, multi-fabric routing, hand-over and quality of service. One task of this project is thus to look at the necessity of providing brokering network access, addressing variables influencing its success. The other task for this project is to construct the necessary mechanisms for establishing the ad-hoc part of an extension to cellular networks. This involves analysing ad-hoc networking and implementing OLSRv2, one of several experimental solutions for ad-hoc networking that exist within the Internet Engineering Task Force (IETF). To emulate such a system, but also for debugging and evaluating the implementation, a test-bed is required to be constructed.

Beyond the transport of uncompressed video over IP networks, defined in standards such as ST2022-6, the ability to build software-based Video Processing Functions (VPF) on commodity hardware and using general purpose Operating Systems is the next logical step in the evolution of the media industry towards an "all-IP" world. In that context, understanding the jitter induced on an ST2022-6 stream by a commodity platform is essential. This paper describes a general methodology to enumerate jitter sources on commodity platforms and to quantify their relative contribution to the overall system jitter. The methodology is applied to the Linux kernel, producing a classification of the different sources of jitter, and a quantification of their impact.

Commonly, duplicate address detection is performed when configuring network interfaces in order to ensure that unique addresses are assigned to each interface in the network. Such mechanisms commonly operate with the premises that a node "intelligently" selects an address which it supposes to be unique, followed by a duplicate address detection cycle, through which it verifies that no other active interfaces on the same network has been or is in the process of being configured with the same address. Even assuming that such a mechanism is present in a MANET, allowing MANET nodes to initially configure their interfaces with addresses unique within the network, additional complications arise: two or more MANETs may merge to form a single network, and a formerly connected MANET may partition. Thus, unless it is ensured that all MANET interfaces are assigned globally unique addresses, addressing conflicts may at any point-not just during initial network configuration. In this paper, we investigate the task of performing duplicate address detection when otherwise independent OLSR networks merge. We benefit from the information already exchanged by OLSR, and identify a number of mechanisms through which a node may detect a conflict between the address assigned to one of its interfaces, and an address assigned to an interface on another node. The mechanisms proposed are, thus, entirely passive, creating no additional information exchange on the network.

This document describes the LLN Ad hoc On-Demand (LOAD) distance vector routing protocol - Next Generation, a reactive routing protocol intended for use in Low power Lossy Networks (LLN). The protocol is derived from AODV and extended for use in LLNs., Ce document décrit le protocole de routage "distance vector" LOAD - Next Generation (LLN Ad hoc On-Demand). Il s'agit d'un protocole réactif qui s'adresse aux réseaux á faible puissance et fort taux de perte (Low power and Lossy Networks, LLNs). Il est dérivé d'AODV et a été modifié de maniére à répondre aux besoin de tels réseaux.

With the development of large-scale data centers, Virtual Machine (VM) migration is a key component for resource optimization, cost reduction, and maintenance. From a network perspective, traditional VM migration mechanisms rely on the hypervisor running at the destination host advertising the new location of the VM once migration is complete. However, this creates a period of time during which the VM is not reachable, yielding packet loss. This paper introduces a method to perform zero-loss VM migration by using IPv6 Segment Routing (SR). Rather than letting the hypervisor update a locator mapping after VM migration is complete, a logical path consisting of the source and destination hosts is pre-provisioned. Packets destined to the migrating VM are sent through this path using SR, shortly before, during, and shortly after migration-the virtual router on the source host being in charge of forwarding packets locally if the VM migration has not completed yet, or to the destination host otherwise. The proposed mechanism is implemented as a VPP plugin, and feasibility of zero-loss VM migration is demonstrated with various workloads. Evaluation shows that this yields benefits in terms of session opening latency and TCP throughput.