The range of user requirements on multicast protocols is so wide that no single protocol will ever satisfy them. The set of multicast protocols can be classified using the user requirements, and the architectures, mechanisms, communications patterns, and policies used to satisfy these requirements. We provide such a classification, and illustrate it with several example protocols chosen to cover the range of features described.

A Classification of

In the IP multicast model, a set of hosts can be aggregated into a group of hosts with one address, to which any host can send. However, Internet TV, distance learning, file distribution and other emerging large-scale multicast applications strain the current realization of this model, which lacks a basis for charging, lacks access control, and is difficult to scale.This paper proposes an extension to IP multicast to support the channel model of multicast and describes a specific realization called EXPlicitly REquested Single-Source (EXPRESS) multicast. In this model, a multicast channel has exactly one explicitly designated source, and zero or more channel subscribers. A single protocol supports both channel subscription and efficient collection of channel information such as subscriber count. We argue that EXPRESS addresses the aforementioned problems, justifying this multicast service model in the Internet.

/pdf/ip-multicast-channels-express-support-for-large-scale-single-as750ixs2q.pdf

IP multicast channels: EXPRESS support for large-scale single-source applications

Utility companies (electricity, gas, and water suppliers), governments, and researchers have been urging to deploy communication-based systems to read meters, known as automatic meter reading (AMR) An AMR system is envisaged to bring on benefits to customers, utilities, and governments The advantages include reducing peak demand for energy, supporting the time-of-use concept for billing, enabling customers to make informed decisions, and reducing the cost of meter reading, to name a few A key element in an AMR system is communications between meters and utility servers Though several communication technologies have been proposed and implemented at a small scale, with the wide proliferation of wireless communication, it is the right time to critique the old proposals and explore new possibilities for the next generation AMR We provide a comprehensive review of the AMR technologies proposed so far Next, we present how future AMRs will benefit from third generation (3G) communication systems, the DLMS/COSEM (Data Language Messaging Specification/Companion Specification for Energy Metering) standard and Internet Protocol-based SIP (Session Initiation Protocol) signaling at the application level The DLMS/COSEM standard provides a framework for meters to report application data (ie meter readings) to a utility server in a reliable manner The SIP protocol is envisaged to be used as the signaling protocol between application entities running on meters and servers The DLMS/COSEM standard and the SIP protocol are expected to provide an application level communication abstraction to achieve reliability and scalability Finally, we identify the challenges at the application level that need to be tackled The challenges include handling failure, gathering meter data under different time constraints (ranging from real-time to delay-tolerance), disseminating (ie, unicasting, multicasting, broadcasting, and geocasting) control data to the meters, and achieving secure communication

A Survey of Communication Protocols for Automatic Meter Reading Applications

Congestion and flow control is an integral part of any Internet data transport protocol. It is widely accepted that the congestion avoidance mechanisms of TCP have been one of the key contributors to the success of the Internet. However, TCP is ill-suited to real-time multimedia streaming applications. Its bursty transmission, and abrupt and frequent wide rate fluctuations cause high delay jitters and sudden quality degradation of multimedia applications. For asymmetric networks such as wireless networks, cable modems, ADSL, and satellite networks, transmitting feedback for (almost) every packet received as it is done in TCP causes congestion in the reverse path. In this environment, TCP may severely underutilize the forward path throughput. Use of multicast further complicates the problem; TCP-like frequent feedback from each receiver to the sender in a large scale multicast session cause well-known scalability limitations (e.g. acknowledgment implosion). We have developed a new flow control approach for multimedia streaming, called TCP emulation at receivers (TEAR). TEAR shifts most of flow control mechanisms to receivers. In TEAR, a receiver does not send to the sender the congestion signals detected in its forward path but rather processes them immediately to determine its own appropriate receiving rate. TEAR can determine this rate using congestion signals observed at the receiver. These signals are used to emulate the TCP sender’s flow control functions at receivers.The emulation allows receivers to estimate a TCP-friendly rate for the congestion conditions observed in their forward paths. TEAR also allows receivers to adjust their receiving rates to a TCP-friendly rate without actually modulating the rates to probe for spare bandwidth, or to react to packet losses directly. Thus, the perceived rate fluctuations at the application are much more smooth than in TCP. A unicast version of TEAR is implemented. This report describes the implementation of TEAR, examine the performance of this TEAR implementation from the NS simulation and Internet experiments, and compare it with that of other TCP-friendly flow control techniques. Our preliminary tests indicate that TEAR shows superior fairness to TCP with significantly lower rate fluctuations than TCP. TEAR’s sensitivity to feedback interval is very low, so that even under high feedback latency, TEAR flows exhibit acceptable performance in terms of fairness, TCP-friendliness, and rate fluctuations. Finally, I will discuss the future extension of TEAR for multicast environments. This work is supported in part by NSF CAREER ANI-9875651.

TEAR: TCP emulation at receivers – flow control for multimedia streaming

In recent years, much of the discussion involving “smart grids” has implicitly involved only the distribution side, notably advanced metering. However, today's electric systems have many challenges that also involve the rest of the system. An enabling technology for improving the power system, which has emerged in recent years, is the ability to measure coherent, real-time data. In this paper, we describe major challenges facing electrical generation and transmission today that availability of these measurements can help address. We overview applications using coherent, real-time measurements that are in use today or proposed by researchers. Specifically, we describe, normalize, and then quantitatively compare key factors for these power applications that influence how the delivery system should be planned, implemented, and managed. These factors include whether a person or computer is in the loop and (for both inputs and outputs) latency, rate, criticality, quantity, and geographic scope. From this, we abstract the baseline communications requirements of a data delivery system supporting these applications and suggest implementation guidelines to achieve them. Finally, we overview the state of the art in the supporting computer science areas of overlay networking and distributed computing (including middleware) and analyze gaps in commercial middleware products, utility standards, and issues that limit low-level network protocols from meeting these requirements when used in isolation.

/pdf/smart-generation-and-transmission-with-coherent-real-time-1dvkfznh62.pdf

Smart Generation and Transmission With Coherent, Real-Time Data

Pragmatic General Multicast (PGM) is a reliable multicast transport protocol for applications that require ordered or unordered, duplicate-free, multicast data delivery from multiple sources to multiple receivers. PGM guarantees that a receiver in the group either receives all data packets from transmissions and repairs, or is able to detect unrecoverable data packet loss. PGM is

D. Farinacci

Papers

PGM Reliable Transport Protocol Specification

RFC3208: PGM Reliable Transport Protocol Specification