"Automatic IP Multicast Without Explicit Tunnels (AMT)", Dave Thaler, Mohit Talwar, Amit Aggarwal, Lorenzo Vicisano, Tom Pusateri, 27-Jun-08. ( bytes)

Automatic Multicast Tunneling (AMT) allows multicast communication amongst isolated multicast-enabled sites or hosts, attached to a network which has no native multicast support. It also enables them to exchange multicast traffic with the native multicast infrastructure and does not require any manual configuration. AMT uses an encapsulation interface so that no changes to a host stack or applications are required, all protocols (not just UDP) are handled, and there is no additional overhead in core routers.

"IANA Guidelines for IPv4 Multicast Address Assignments", Michelle Cotton, Dave Meyer, 3-Nov-08. ( bytes)

This document obsoletes RFC 3171. It provides guidance for the Internet Assigned Numbers Authority (IANA) in assigning IPv4 multicast addresses.

"Requirements for Multicast AAA coordinated between Content Provider(s) and Network Service Provider(s)", Haixiang He, 20-Jun-08. ( bytes)

This memo presents requirements in the area of accounting and access control for IP multicasting. The scope of the requirements is limited to cases that Authentication, Accounting and Authorization (AAA) functions are coordinated between Content Provider(s) and Network Service Provider(s). General requirements for accounting and admission control capabilities including quality-of-service (QoS) related issues are listed. This memo assumes that these capabilities can be realized by functions implemented at edges of a network based on IGMP or MLD. Finally, cases for Content Delivery Services (CDS) are described as application examples which could benefit from multicasting accounting and access control capabilities as described in this memo. This memo defines requirements related to AAA issues for multi- entity provider models in which the network service provider and content provider cooperate to provide CDS and various related AAA functions for purposes such as protecting and accounting for the access to content and network resources. The requirements are generally not relevant to cases in which there is not a reason to share AAA functions between separate entities.

"AAA and Admission Control Framework for Multicasting", Hiroaki Satou, 2-Jul-08. ( bytes)

IP multicast-based services, such as TV broadcasting or videoconferencing raise the issue of making sure that potential customers are fully entitled to access the corresponding contents. There is indeed a need for service and content providers to identify users (if not authenticate, especially within the context of enforcing electronic payment schemes) and to retrieve statistical information for accounting purposes, as far as content and network usage are concerned. This memo describes the framework for specifying the Authorization, Authentication and Accounting (AAA) capabilities that could be activated within the context of the deployment and the operation of IP multicast-based services. This framework addresses the requirements presented in "Requirements for Accounting, Authentication and Authorization in Well Managed IP Multicasting Services" [I-D.mboned-maccnt-req]. The memo provides a basic AAA enabled model as well as an extended fully enabled model with resource and admission control coordination.

"Lightweight IGMPv3 and MLDv2 Protocols", Hui Liu, Wei Cao, Hitoshi Asaeda, 6-Sep-08. ( bytes)

This document describes lightweight IGMPv3 and MLDv2 protocols (LW- IGMPv3 and LW-MLDv2), which simplify the standard (full) versions of IGMPv3 and MLDv2. The interoperability with the full versions and the previous versions of IGMP and MLD is also taken into account.

"Multicast Ping Protocol", Stig Venaas, 3-Nov-08. ( bytes)

The Multicast Ping Protocol specified in this document allows for checking whether an endpoint can receive multicast, both Source- Specific Multicast (SSM) and Any-Source Multicast (ASM). It can also be used to obtain additional multicast related information like multicast tree setup time etc. This protocol is based on an implementation of tools called ssmping and asmping.

"Mtrace Version 2: Traceroute Facility for IP Multicast", Hitoshi Asaeda, Tatuya Jinmei, Bill Fenner, Stephen Casner, 3-Nov-08. ( bytes)

This document describes the IP multicast traceroute facility. Unlike unicast traceroute, multicast traceroute requires special implementations on the part of routers. This specification describes the required functionality in multicast routers, as well as how management applications can use the router functionality.

"Requirements for IP Multicast Session Announcement in the Internet", Hitoshi Asaeda, Vincent Roca, 27-Oct-08. ( bytes)

The Session Announcement Protocol (SAP) [3] was used to announce information for all available multicast sessions to the prospective receiver in an experimental network. It is useful and easy to use, but difficult to control the SAP message transmission in a wide area network. This document describes the several major limitations SAP has and the requirements for multicast session announcement in the global Internet.

Return to Internet-Draft directory.

Return to IETF home page.