MULTICAST OPERATIONS, ADMINISTRATION, AND MANAGEMENT (OAM) TECHNIQUES UTILIZING PROTOCOL INDEPENDENT MULTICAST (PIM) FLOODING MECHANISMS

Multicast networks are often complex and to provide a visualization of traffic flows within a multicast network often involves the full knowledge of a distribution tree for the network. Further, isolating problems within a multicast network can involve tracing of multiple nodes across the distribution tree. Techniques presented provide efficient multicast tree discovery through Protocol Independent Multicast (PIM) flooding mechanisms, which can be further used to facilitate network visualizations and fault isolation within a network

A Common API for Transparent Hybrid Multicast

Group communication services exist in a large variety of flavors and technical implementations at different protocol layers. Multicast data distribution is most efficiently performed on the lowest available layer, but a heterogeneous deployment status of multicast technologies throughout the Internet requires an adaptive service binding at runtime. Today, it is difficult to write an application that runs everywhere and at the same time makes use of the most efficient multicast service available in the network. Facing robustness requirements, developers are frequently forced to use a stable upper-layer protocol provided by the application itself. This document describes a common multicast API that is suitable for transparent communication in underlay and overlay and that grants access to the different flavors of multicast. It proposes an abstract naming scheme that uses multicast URIs, and it discusses mapping mechanisms between different namespaces and distribution technologies. Additionally, this document describes the application of this API for building gateways that interconnect current Multicast Domains throughout the Internet. It reports on an implementation of the programming Interface, including service middleware. This document is a product of the Scalable Adaptive Multicast (SAM) Research Group

HITLESS GRACEFUL INSERTION AND REMOVAL OF A ROUTER/SWITCH IN HIGHLY RELIABLE MULTICAST NETWORKS

Currently, the support for graceful insertion and removal (GIR) within a Protocol-Independent Multicast (PIM) environment is limited. As a result, there is no mechanism today that allows for a soft migration of flows when, for example, planning for a maintenance window. Techniques are presented herein that support a hitless upgrade capability that avoids impacting any flow during the upgrade and reload of a spine switch. This is the most difficult task today for customer networks, where multicast flows run all of the time and no disruption is acceptable. Aspects of the presented techniques include a new PIM hello message type-length-value (TLV) option. Such an option may be referred to herein as a progressive graceful insertion and removal (PGIR) capability option

D3.6.1: Cookbook for IPv6 Renumbering in SOHO and Backbone Networks

In this text we present the results of a set of experiments that are designed to be a first step in the process of analysing how effective network renumbering procedures may be in the context of IPv6. An IPv6 site will need to get provider assigned (PA) address space from its upstream ISP. Because provider independent (PI) address space is not available for IPv6, a site wishing to change provider will need to renumber from its old network prefix to the new one. We look at the scenarios, issues and enablers for such renumbering, and present results and initial conclusions and recommendations in the context of SOHO and backbone networking. A subsequent deliverable (D3.6.2) will refine these findings, adding additional results and context from enterprise and ISP renumbering scenarios

RFC 6104: rogue IPv6 Router Advertisement problem statement

When deploying IPv6, whether IPv6-only or dual-stack, routers are configured to send IPv6 Router Advertisements (RAs) to convey information to nodes that enable them to autoconfigure on the network. This information includes the implied default router address taken from the observed source address of the RA message, as well as on-link prefix information. However, unintended misconfigurations by users or administrators, or possibly malicious attacks on the network, may lead to bogus RAs being present, which in turn can cause operational problems for hosts on the network. In this document, we summarise the scenarios in which rogue RAs may be observed and present a list of possible solutions to the problem. We focus on the unintended causes of rogue RAs in the text. The goal of this text is to be Informational, and as such to present a framework around which solutions can be proposed and discussed

A Common API for Transparent Hybrid Multicast

Group communication services exist in a large variety of flavors, and technical implementations at different protocol layers. Multicast data distribution is most efficiently performed on the lowest available layer, but a heterogeneous deployment status of multicast technologies throughout the Internet requires an adaptive service binding at runtime. Today, it is difficult to write an application that runs everywhere and at the same time makes use of the most efficient multicast service available in the network. Facing robustness requirements, developers are frequently forced to use a stable, upper layer protocol provided by the application itself. This document describes a common multicast API that is suitable for transparent communication in underlay and overlay, and grants access to the different multicast flavors. It proposes an abstract naming by multicast URIs and discusses mapping mechanisms between different namespaces and distribution technologies. Additionally, it describes the application of this API for building gateways that interconnect current multicast domains throughout the Internet, and reports on an implementation of the programming interface including a service middleware. This document is a product of the Scalable Adaptive Multicast Research Group (SAM) Research Group