This page includes all Drafts and RFCs which are related to IP-Multicast. The page is updated (Last Update: 13.02.2003 )on a regular basis. Please contact me if you encounter any problems. Drafts and RFCs which do not belong to one of the main Multicast related Working groups are listed at the end with a detailed description. Currently this list goes back until July 2002 (please have in mind, that drafts expire after six month). Old version of drafts are kept on this list.
BGPM, IDMR, MAGMA, MALLOC, MBONED, MOSPF, MSDP, MSEC, PIM, RMT, SSM
Title : Multicast Control Protocol (MCOP)
Author(s) : R. Lehtonen et al.
Filename : draft-lehtonen-magma-mcop-02.txt
Pages : 39
Date : 2003-2-12
This draft introduces Multicast Control Protocol (MCOP) that may be used as a tool for multicast network management. MCOP provides multicast network remote management with centralized information database located at Multicast Control Server (MCS). It allows gradual, group and network specific multicast network deployment. MCOP protocol is used between MCS and routers that have directly connected multicast sources or receivers. The actual control is done by MCOP enabled routers based on the information received from the MCS. MCOP router can filter IGMP/MLD reports and multicast packets before they reach the IGMP/MLD processing layer or multicast routing stack of the router. MCOP is independent of multicast routing protocols.
Title : An Effective Solution for Multicast Scalability:The
MPLS Multicast Tree (MMT)
Author(s) : A. Boudani, B. Cousin, J. Bonnin
Filename : draft-boudani-mpls-multicast-tree-03.txt
Pages : 10
Date : 2003-2-10
A multicast router should keep forwarding state for every multicast tree passing through it. The number of forwarding states grows with the number of groups. In this paper, we present a new approach, the MPLS multicast Tree (MMT), which utilizes MPLS LSPs between multicast tree branching node routers in order to reduce forwarding states and enhance scalability. In our approach only routers that are acting as multicast tree branching node routers for a group need to keep forwarding state for that group. All other non-branching node routers simply forward data packets by traffic engineered unicast routing using MPLS LSPs. We can deduce that our approach can be largely deployed because it uses for multicast traffic the same unicast MPLS forwarding scheme. We will briefly discuss the multicast scalability problem, related works and different techniques for forwarding state reduction. We discuss also the advantages of our approach, and conclude that it is feasible and promising. Finally, we analytically evaluate our approach.
Title : Framework of Overlay Multicast Control Protocol
Author(s) : S. Koh, J. Park
Filename : draft-sjkoh-overlay-multicast-framework-00.txt
Pages : 15
Date : 2003-2-7
This document describes Overlay Multicast Control Protocol (OMCP) used for realizing and managing Overlay Multicast, as also known as Application Layer Multicast. Overlay Multicast is a data delivery scheme for multicast applications, in which one or more intermediate relay agents are employed for relaying application data from a sender to many receivers along a pre-configured or automatically configured tree hierarchy. For standardization of Overlay Multicast, it needs to separate the data plane (for packet relaying) and the control plane (for tree configuration and session monitoring). We describe a control protocol for Overlay Multicast, named Overlay Multicast Control Protocol (OMCP). In OMCP, a special-purpose entity, called Session Manager, is used to manage and control the tree configuration and session monitoring. OMCP is designed to ensure that the multicast applications and services can be provided over current Internet environments in which IP multicast has not completely been deployed.
Title : Duplicate Address Detection Optimization using IPv6 Multicast Listener Discovery
Author(s) : G. Daley, R. Nelson
Filename : draft-daley-ipv6-mcast-dad-02.txt
Pages : 12
Date : 2003-2-3
This draft describes a possible optimization to Duplicate Address Detection (DAD) which can be used to successfully terminate DAD early, based on the presence of listeners on the link-scope solicited nodes multicast address.
Title : Anycast-RP using PIM
Author(s) : D. Farinacci, Y. Cai
Filename : draft-farinacci-pim-anycast-rp-00.txt
Pages : 7
Date : 2003-1-22
This proposal allows Anycast-RP to be used inside a domain which runs PIM only. There are no other multicast protocols required to support Anycast-RP, such as MSDP, which has been used traditionally to solve this problem.
Title : Explicit Multicast over Mobile IP (XMIP)
Author(s) : J. Lee
Filename : draft-lee-xcast-mobileip-01.txt
Pages : 17
Date : 2003-1-17
As a special kind of Internet multicast, Explicit multicast(Xcast)[1] encodes destination addresses of all the receivers into the packet. Not requiring membership management and routing information exchange in the intermediate routers in contrast to the legacy Internet multicast or Deering multicast, Xcast can effectively provide multicast service to Internet without those overheads. A node mobility supporting protocol, Mobile IP[2,3], requires to be modified to appropriately intercept, route and forward Xcast packets. This document specifies the protocol operations for the mobile agent, the mobile node and the correspondent node to support transmission and reception of Xcast datagram over Mobile IPv4 and Mobile IPv6.
Title : Explicit Multicast (Xcast) Basic Specification
Author(s) : R. Boivie et al.
Filename : draft-ooms-xcast-basic-spec-04.txt
Pages : 29
Date : 2003-1-17
Multicast has become increasingly important with the emergence of network-based applications such as IP telephony and video conferencing. The Internet community has done a significant amount of work on IP multicast over the last decade [1075, 2201, 2236, DEER, DEE2, FARI, HOLB, MBONE, PERL]. However, while today's multicast schemes are scalable in the sense that they can support very large multicast groups, there are scalability issues when a network needs to support a very large number of distinct multicast groups.
Title : Embedding the Address of RP in IPv6 Multicast Address
Author(s) : P. Savola, B. Haberman
Filename : draft-savola-mboned-mcast-rpaddr-01.txt
Pages : 11
Date : 2003-2-4
As has been noticed, there is exists a huge deployment problem with global, interdomain IPv6 multicast: PIM RPs have no way of communicating the information about multicast sources to other multicast domains, as there is no MSDP, and the whole interdomain Any Source Multicast model is rendered unusable; SSM avoids these
problems. This memo outlines a way to embed the address of the RP in the multicast address, solving the interdomain multicast problem. The problem is three-fold: specify an address format, adjust the operational procedures and configuration if necessary, and modify PIM implementations of those who want to join a group (DR's) or create one (RP's). In consequence, there would be no need for interdomain MSDP.
Title : Performing DNS queries via IP Multicast
Author(s) : S. Cheshire
Filename : draft-cheshire-dnsext-multicastdns-01.txt
Pages : 29
Date : 2002-12-23
As networked devices become smaller, more portable, and more ubiquitous, the ability to operate with less configured infrastructure is increasingly important. In particular, the ability to look up host names and similar DNS resource record data types, in the absence of a conventional managed DNS server, is becoming essential.
Title : Multicast Listener Discovery Version 2 (MLDv2) for IPv6
Author(s) : R. Vida, L. Costa
Filename : draft-vida-mld-v2-06.txt
Pages : 50
Date : 2002-12-2
This document specifies Version 2 of the Multicast Listener Discovery Protocol, MLDv2. MLD is the protocol used by an IPv6 router to discover the presence of multicast listeners (that is, nodes wishing
to receive multicast packets) on its directly attached links, and to discover specifically which multicast addresses are of interest to those neighboring nodes. MLDv2 is derived from version 3 of IPv4's Internet Group Management Protocol, IGMPv3. Compared to the previous version, MLDv2 adds
support for 'source filtering', that is, the ability for a node to report interest in listening to packets *only* from specific source addresses, or from *all but* specific source addresses, sent to a particular multicast address. This document obsoletes RFC 2710.
Title : MultiGRIP: Quality of Service Aware Multicasting over DiffServ
Author(s) : G. Bianchi et al.
Filename : draft-bianchi-qos-multicast-over-diffserv-00.txt
Pages : 19
Date : 2002-12-2
Efficient delivery of real-time multicast traffic imposes on the underlying network infrastructure the burden of supporting Quality of Service (QoS). This can be quite a complex issue in a Differentiated Services (DiffServ) IP network, especially if multicast users are allowed to dynamically join and leave the multicast tree. In fact, since DiffServ lacks of explicit reservation states, i) a replicating node cannot test whether a corresponding reservation exists on an output link, and ii) upon a dynamic join of a QoS multicast user, the DiffServ network lacks of control functions to verify whether resources are available along the new path. In this document, we present a solution to support dynamic multicast with QoS over a DiffServ network. Our solution combines two ideas. First, resource availability along a new QoS path is verified via a probe-based approach. Second, QoS is maintained by marking replicated packets with a special DSCP value, before forwarding them on the QoS path. We are fully aware that the possible application of the principles described in this draft in the Internet raises many issues, which we do not address. Our aim, then, is not proposing a fully-fledged solution, but contributing to the on-going discussions in the international arena on these matters, by means of what we may see also as a problem statement document.
Title : Methodology for IP Multicast Benchmarking
Author(s) : H. Soor, D. Stopp
Filename : draft-ietf-bmwg-mcastm-10.txt
Pages : 22
Date : 2002-12-2
The purpose of this draft is to describe methodology specific to the benchmarking of multicast IP forwarding devices. It builds upon the tenets set forth in RFC 2544, RFC 2432 and other IETF Benchmarking Methodology Working Group (BMWG) efforts. This document seeks to extend these efforts to the multicast paradigm. The BMWG produces two major classes of documents: Benchmarking Terminology documents and Benchmarking Methodology documents. The Terminology documents present the benchmarks and other related terms. The Methodology documents define the procedures required to collect the benchmarks cited in the corresponding Terminology documents.
Title : IP Multicast in Differentiated Services Networks
Author(s) : R. Bless, K. Wehrle
Filename : draft-bless-diffserv-multicast-05.txt
Pages : 33
Date : 2002-11-22
This document identifies problems which will arise when IP Multicast is used in Differentiated Services (DS) networks. Although the basic DS forwarding mechanisms also work with IP Multicast, some facts have to be considered which are related to the provisioning of multicast resources. The presented problems mainly lead to situations in which other service users are affected adversely in their experienced quality. An adequate solution is described in this document. It provides the necessary resource decoupling for protecting reserved resources until admission control is performed.
Title : RTCP Extensions for Single-Source Multicast Sessions with
Unicast Feedback
Author(s) : J. Chesterfield et al.
Filename : draft-ietf-avt-rtcpssm-02.txt
Pages : 28
Date : 2002-11-11
This document specifies a modification to the Real-time Transport Control Protocol (RTCP) to use unicast feedback. The proposed extension is useful for single source multicast sessions such as Source Specific Multicast (SSM) communication where the traditional model of many-to-many group communication is either not possible or not preferred. In addition, it can be applied to any group that might benefit from a sender controlled summarised reporting mechanism.
Title : On-Demand Multicast Routing Protocol (ODMRP) for Ad-Hoc Networks
Author(s) : Y. Yi, S. Lee
Filename : draft-ietf-manet-odmrp-04.txt
Pages : 29
Date : 2002-11-7
On-Demand Multicast Routing Protocol (ODMRP) is a multicast routing protocol designed for ad-hoc networks with mobile hosts. ODMRP is a mesh-based, rather than a conventional tree-based, multicast scheme and uses a Forwarding Group concept (only a subset of nodes forwards the multicast packets via scoped flooding). It applies on-demand procedures to dynamically set up routes and maintain multicast group membership. ODMRP is well suited for ad-hoc wireless networks with mobile hosts where bandwidth is limited, topology changes frequently and rapidly, and power is constrained.
Title : TCP-Friendly Multicast Congestion Control (TFMCC):Protocol Specification
Author(s) : J. Widmer, M. Handley
Filename : draft-ietf-rmt-bb-tfmcc-01.txt
Pages : 29
Date : 2002-11-4
This document specifies TCP-Friendly Multicast Congestion Control (TFMCC). TFMCC is a congestion control mechanism for multicast transmissions in a best-effort Internet environment. It is a single-rate congestion control scheme, where the sending rate is adapted to the receiver experiencing the worst network conditions. TFMCC is reasonably fair when competing for bandwidth with TCP flows and has a relatively low variation of throughput over time, making it suitable for applications such as streaming media where a relatively smooth
Title : Considerations for IGMP and MLD snooping switches
Author(s) : M. Christensen, K. Kimball
Filename : draft-ietf-magma-snoop-03.txt
Pages : 11
Date : 2002-11-4
This memo describes the requirements for IGMP and MLD snooping switches. The requirements for IGMPv2 snooping switches are based on best current practices. IGMPv3 and MLDv2 snooping are also covered in this draft although we are not aware of any such implementations at the time of writing. Note that IGMP snooping is related only to IPv4 multicast. Other multicast packets, such as IPv6, might be suppressed by the snooping functionality if additional care is not taken in the implementation. It is desired not to restrict the flow of non-IPv4 multicasts other than to the degree which would happen as a result of regular bridging functions. The same note can be made of MLD snooping switches with respect to suppression of IPv4.
Title : IPv6 Multicast Deployment Issues
Author(s) : P. Savola
Filename : draft-savola-v6ops-multicast-issues-01.txt
Pages : 8
Date : 2002-11-4
There are many issues concerning the deployment and implementation, and to a lesser degree, specification of IPv6 multicast. This memo describes known problems, trying to raise awareness. Currently, global IPv6 interdomain multicast is completely impossible except using SSM: there is no way to convey information about multicast sources between PIM RPs. Site-scoped multicast is also problematic when used alongside to global multicast because of that. A few possible solutions are outlined or referred to. In addition, an issue regarding link-local multicast-blocking Ethernet switches is brought up. Finally, a feature request for MLD snooping switches is noted.
Title : Extended RSVP-TE for Multicast LSP Tunnels
Author(s) : S. Yasukawa et al.
Filename : draft-yasukawa-mpls-rsvp-multicast-01.txt
Pages : 46
Date : 2002-11-4
Multicast technology will become increasingly important with the dissemination of new applications such as contents delivery services and video conferences, which require much more bandwidth and stricter QoS than conventional applications. From the service providers' perspective, traffic engineering (TE) functions will be needed to handle the large amount of multicast traffic.This document defines some protocol extensions to the existing RSVP-TE[1] in order to establish a multicast label switched path (LSP). The use of label switching routers (LSRs) with these protocol extensions defined in this document allows service providers to offer unicast and multicast multiprotocol label switching (MPLS) services in the same service network. This protocol assumes a variable LSP topology, e.g., point-to-multipoint, multipoint-to-multipoint, topologies. This document describes how to establish point-to-multipoint and multipoint-to-multipoint LSPs as the most basic multicast topology. It defines two ways of constructing a point-to-multipoint LSP: sender-initiated LSP setup and leaf-initiated LSP setup. Each method has an LSP modification function in order to adapt to dynamic changes in the LSP tree topology. This MPLS architecture[10] is very flexible and can be expanded to carry protocols other than IP multicasting, e.g., Ethernet, PPP, and SONET/SDH, but this document only defines IP multicasting (IPv4 and IPv6) as a forwarding equivalence class object (FEC).
Title : Cisco Systems Router-port Group Management Protocol
(RGMP)
Author(s) : I. Wu, T. Eckert
Filename : draft-wu-rgmp-03.txt
Pages : 16
Date : 2002-11-4
This draft documents RGMP, a protocol developed by Cisco Systems that is used between multicast routers and switches to restrict multicast packet forwarding in switches to those routers where the packets may be needed. RGMP is designed for backbone switched networks where multiple, high speed routers are interconnected.
Title : An Architecture of Overlay Multicast Control Protocol
Author(s) : S. Koh et al.
Filename : draft-koh-omcp-00.txt
Pages : 16
Date : 2002-11-4
This document describes Overlay Multicast Control Protocol (OMCP) used for realizing and managing Overlay Multicast, as also known as Application Layer Multicast. Overlay Multicast is a data delivery scheme for multicast applications, in which one or more intermediate relay agents are employed for relaying application data from a sender to many receivers along a pre-configured or automatically configured tree hierarchy. In OMCP, a special- purpose entity, called Session Manager, is used to manage and control the tree configuration and session monitoring. OMCP is designed to ensure that the multicast applications and services can be provided over current Internet environments in which IP multicast has not completely been deployed.
Title : Protocol Independent Multicast MIB
Author(s) : J. Nicholas et al.
Filename : draft-ietf-pim-mib-v2-01.txt
Pages : 31
Date : 2002-11-1
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing the Protocol Independent Multicast (PIM) protocol.
Title : Protocol Independent Multicast - Dense Mode (PIM-DM)Protocol Specification (Revised)
Author(s) : A. Adams, J. Nicholas, W. Siadak
Filename : draft-ietf-pim-dm-new-v2-02.txt
Pages : 54
Date : 2002-11-1
This document specifies Protocol Independent Multicast - Dense Mode (PIM-DM). PIM-DM is a multicast routing protocol that uses the underlying unicast routing information base to flood multicast datagrams to all multicast routers. Prune messages are used to prevent future messages from propagating to routers with no group membership information.
Title : Source Address Selection for Multicast Listener Discovery Protocol (RFC 2710)
Author(s) : B. Haberman
Filename : draft-ietf-magma-mld-source-03.txt
Pages : 4
Date : 2002-11-1
It has come to light that there is an issue with the selection of a suitable IPv6 source address for Multicast Listener Discovery messages when a node is performing stateless address autoconfiguration. This memo is intended to clarify the rules on selecting an IPv6 address to use for MLD messages.
Title : VPLS based on IP Multicast
Author(s) : A. Sajassi, H. Salama
Filename : draft-sajassi-mvpls-00.txt
Pages : 14
Date : 2002-11-1
Virtual Private LAN Service (VPLS) is a type of Layer-2 Provider Provisioned Virtual Private Network (L2 PPVPN) offered service, which has been described in [PPVPN-FRWK]. If the Service Provider network provides IP multicast functionality, then this network capability can be leveraged in providing very efficient VPLS service and yet simplifying the implementation of such service. This document describes a solution for providing VPLS service based on IP multicast feature referred to as Multicast Virtual Private LAN Service (MVPLS).
Title : Xcast+ Extension for Few-to-Few Mulitcast Communication
Author(s) : K. Kim et al.
Filename : draft-kim-xcast+-few-2-few-00.txt
Pages : 14
Date : 2002-10-31
Xcast+[2] is newly proposed multicast scheme to support IGMPv2/MLDv3 in Explicit Multicast(Xcast)[1]. Xcast+ is suitable for one-to-few multicast applications. In order to support few-to-few communication naturally, the control plane of existing Xcast+ should be extended. In this document, a new control plane for few-to-few communication for Xcast+ is specified. In order to acheive this, the concept of logical core (LC) is newly introduced.
Title : IGMP for user Authentication Protocol (IGAP)
Author(s) : T. Hayashi et al.
Filename : draft-hayashi-igap-00.txt
Pages : 22
Date : 2002-10-30
IP Multicast applications are becoming more common. Two key concerns raised by the providers of such applications are the lack of control on what users can get multicast traffic and a method for tracking user usage (such as how long these users are joined to a multicast group). This document introduces the IGMP for user Authentication Protocol (IGAP). IGAP extends the existing IGMPv2 protocol to add user authentication functionality. IGAP enables an IP multicast service provider to authenticate requests to join a specific multicast group based on user information.
Title : Selectively Reliable Multicast Protocol (SRMP)
Author(s) : M. Pullen et al.
Filename : draft-pullen-srmp-00.txt
Pages : 26
Date : 2002-10-29
The Selectively Reliable Multicast Protocol (SRMP) is a transport protocol, intended to deliver a mix of reliable and best-effort messages in an any-to-any multicast environment, where the best-effort traffic occurs in significantly greater volume than the best-effort traffic and therefore can be used to carry sequence numbers of reliable messages for loss detection. SRMP is intended for use in a distributed simulation application environment, where only the latest value of reliable transmission for any particular data identifier requires delivery. SRMP has two sublayers: a bundling sublayer that combines short messages, peforms NAK suppression, and incorporates the TCP-Friendly Multicast Congestion Control of Widmer and Handley, dropping best-effort traffic in order to achieve congestion control; and a selectively reliable transport (SRT) sublayer that formats best-effort and reliable transmissions and also creates negative acknowledgements when loss of reliable messages is detected.
Title : IP Version 6 Addressing Architecture
Author(s) : B. Hinden, S. Deering
Filename : draft-ietf-ipngwg-addr-arch-v3-11.txt
Pages : 26
Date : 2002-10-28
This specification defines the addressing architecture of the IP Version 6 protocol [IPV6]. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses. This document obsoletes RFC-2373 'IP Version 6 Addressing Architecture'.
Title : SDP Source-Filters
Author(s) : B. Quinn, R. Finlayson
Filename : draft-ietf-mmusic-sdp-srcfilter-02.txt
Pages : 10
Date : 2002-10-25
This document describes how to adapt the Session Description Protocol (SDP) to express one or more source addresses as a source filter for one or more destination 'connection' addresses. It defines the syntax and semantics for an SDP 'source-filter' attribute that may reference either IPv4 or IPv6 address(es) as either an inclusive or exclusive source list for either multicast or unicast destinations. In particular, an inclusive source-filter can be used to specify a Source-Specific Multicast ('SSM') session.
Receiver applications are expected use the SDP source-filter information to identify traffic from legitimate senders and discard traffic from illegitimate senders. Applications and hosts may also share the source-filter information with network elements (e.g., with routers using IGMPv3) so they can potentially perform the traffic filtering operation further 'upstream,' closer to the source(s).
Title : Analysis on RSVP Regarding Multicast
Author(s) : X. Fu, C. Kappler, H. Tschofenig
Filename : draft-fu-rsvp-multicast-analysis-01.txt
Pages : 14
Date : 2002-10-25
RSVP version 1 has been designed for optimum support multicast.However, in reality multicast is being used much less frequently than anticipated. Still, even for unicast (one sender, one receiver) full-fledged multicast-enabled RSVP signaling must be used. As pointed out in the NSIS requirement draft, multicast would not be necessarily required for an NSIS signaling protocol. This draft analyses ingredients of RSVP Version 1 which are affected by multicast, and derives how these ingredients may look like if multicast is not supported in the generic RSVP signaling protocol and adapt related functionalities accordingly - we call the resulting feature set 'RSVP Lite', a potentially more light-weight version of RSVP.
Title : Methodology for IP Multicast Benchmarking
Author(s) : H. Soor, D. Stopp
Filename : draft-ietf-bmwg-mcastm-09.txt
Pages : 21
Date : 2002-10-24
The purpose of this draft is to describe methodology specific to the benchmarking of multicast IP forwarding devices. It builds upon the tenets set forth in RFC 2544, RFC 2432 and other IETF Benchmarking Methodology Working Group (BMWG) efforts. This document seeks to extend these efforts to the multicast paradigm. The BMWG produces two major classes of documents: Benchmarking Terminology documents and Benchmarking Methodology documents. The Terminology documents present the benchmarks and other related terms. The Methodology documents define the procedures required to collect the benchmarks cited in the corresponding Terminology documents.
Title : Simple Explicit Multicast (SEM)
Author(s) : A. Boudani, B. Cousin
Filename : draft-boudani-simple-xcast-02.txt
Pages : 12
Date : 2002-10-23
In this document, we propose a new multicast protocol called SEM (Simple Explicit Multicast) or simple Xcast[1]. This protocol uses an efficient method to construct the multicast tree and deliver multicast packets. In order to construct the multicast tree, this protocol uses
the same mecanism as Xcast+[2].For the delivery of multicast packets it uses the mechanism of branching routers similar to the mechanism used in REUNITE I [3] and REUNITE II[4].
Title : Multicast Control Protocol (MCOP)
Author(s) : R. Lehtonen et al.
Filename : draft-lehtonen-magma-mcop-01.txt
Pages : 34
Date : 2002-10-18
In IP multicast all hosts that join a multicast group (*, G) or (S,G) can receive the multicast traffic. This draft introduces Multicast Control Protocol (MCOP) that makes it possible to selectively enable multicast receiving and sending. MCOP is used between Multicast Control Agent (MCA) and routers that have directly connected multicast sources or receivers. The receiver and source control is done by MCOP enabled routers based on the information received from the MCA. MCOP enabled routers filter IGMP/MLD reports and multicast packets before they reach the IGMP/MLD processing layer or multicast routing stack of the router. MCOP is independent of multicast routing protocols.
Title : Multicast Listener Discovery Version 2 (MLDv2) for IPv6
Author(s) : R. Vida et al.
Filename : draft-vida-mld-v2-05.txt
Pages : 52
Date : 2002-10-16
This document specifies Version 2 of the Multicast Listener Discovery protocol, MLDv2. MLD is the protocol used by an IPv6 router to discover the presence of multicast listeners (that is, nodes wishing to receive multicast packets) on its directly attached links, and to discover specifically which multicast addresses are of interest to those neighboring nodes. MLDv2 is derived from version 3 of IPv4's Internet Group ManagementProtocol, IGMPv3. Compared to the previous version, MLDv2 adds support for 'source filtering', that is, the ability for a node to report interest in listening to packets *only* from specific source addresses, or from *all but* specific source addresses, sent to a particular multicast address. That information may be used by multicast routing protocols to avoid delivering multicast packets from specific sources to links where there are no interested listeners. When compared to IGMPv3, one important difference to note is that MLDv2 uses ICMPv6 (IP Protocol 58) message types, rather than IGMP (IP Protocol 2) message types.
Title : An IPv6/IPv4 Multicast Translator based on IGMP/MLD Proxying (mtp)
Author(s) : K. Tsuchiya, H. Higuchi, S. Sawada, S. Nozaki
Filename : draft-ietf-ngtrans-mtp-03.txt
Pages : 14
Date : 2002-10-15
In the stage of the transition from IPv4 to IPv6 it is necessary that IPv4 nodes and IPv6 nodes can communicate directly. This memo proposes a mechanism which enables such direct communication for multicast, in addition to that for unicast defined in [SIIT] and [NAT-PT].
Title : Embedding the Address of RP in IPv6 Multicast Address
Author(s) : P. Savola, B. Haberman
Filename : draft-savola-mboned-mcast-rpaddr-00.txt
Pages : 10
Date : 2002-10-10
As has been noticed, there is exists a huge deployment problem with global, interdomain IPv6 multicast: PIM RPs have no way of communicating the information about multicast sources to other multicast domains, as there is no MSDP, and the whole interdomain Any Source Multicast model is rendered unusable; SSM avoids these problems. This memo outlines a way to embed the address of the RP in the multicast address, solving the interdomain multicast problem. The problem is three-fold: specify an address format, adjust the operational procedures and configuration if necessary, and modify receiver-side PIM implementations. In consequence, there would be no need for interdomain MSDP.
Title : Duplicate Address Detection Optimization using IPv6 Multicast Listener Discovery
Author(s) : G. Daley, R. Nelson
Filename : draft-daley-ipv6-mcast-dad-01.txt
Pages : 12
Date : 2002-10-8
This draft describes a possible optimization to Duplicate Address Detection (DAD) which can be used to successfully terminate DAD early, based on the presence of listeners on the link-scope solicited nodes multicast address.
Title : IPv6 Multicast Deployment Issues
Author(s) : P. Savola
Filename : draft-savola-v6ops-multicast-issues-00.txt
Pages : 7
Date : 2002-10-7
There are many issues concerning the deployment and implementation, and to a lesser degree, specification of IPv6 multicast. This memo describes known problems, trying to raise awareness. Currently, global IPv6 interdomain multicast is completely impossible except using SSM: there is no way to convey information about multicast sources between PIM RPs. Site-scoped multicast is also problematic when used alongside to global multicast because of that. A few possible solutions are outlined or referred to. In addition, an issue regarding link-local multicast-blocking Ethernet switches is brought up. Finally, a feature request for MLD snooping switches is noted.
Title : M-ISIS: Multi Topology (MT)Routing in IS-IS
Author(s) : T. Przygienda, N. Shen, N. Sheth
Filename : draft-ietf-isis-wg-multi-topology-05.txt
Pages : 11
Date : 2002-10-2
This draft describes an optional mechanism within ISIS used today by many ISPs for IGP routing within their clouds. This draft describes how to run within a single ISIS domain a set of independent IP topologies that we call Multi-Topologies (MTs). This MT extension can be used for variety of purposes such as an in-band management network ``on top'' of the original IGP topology, maintain separate IGP routing domains for isolated multicast or IPv6 islands within the backbone, or force a subset of an address space to follow a different topology.
Title : A MAPOS NSP (Node Switch Protocol) Multicast Expansion -
NSP+
Author(s) : T. Ogura et al.
Filename : draft-ogura-mapos-nsp-multiexp-00.txt
Pages : 13
Date : 2002-9-27
This document describes NSP+, an expansion of the MAPOS NSP (Node Switch Protocol). MAPOS is a multiple access protocol for transmission of network-protocol datagrams, encapsulated in High-Level Data Link Control (HDLC) frames, over SONET/SDH. NSP is a protocol for automatically assigning MAPOS node addresses. Other than the same function as NSP, NSP+ has an additional function to reduce unnecessary multicast frame transmission on MAPOS switches. In NSP+, a node can send a list of multicast HDLC addresses to a directly connected switch to notify that, in the case of multicasting, the code needs to receive only those frames whose destination addresses are included in the list. This enables the switch to forward only required multicast frames to directly connected nodes and reduce unnecessary bandwidth consumption.
Title : Requirements for Automatic Configuration of IP Hosts
Author(s) : A. Williams
Filename : draft-ietf-zeroconf-reqts-12.txt
Pages : 22
Date : 2002-9-25M
Many common TCP/IP protocols such as DHCP [RFC2131], DNS [RFC1034][RFC1035], MADCAP [RFC2730], and LDAP [RFC2251] must be configured and maintained by an administrative staff. This is unacceptable for emerging networks such as home networks, automobile networks, airplane networks, or ad hoc networks at conferences, emergency relief stations, and many others. Such networks may be nothing more than two isolated laptop PCs connected via a wireless LAN. For all these networks, an administrative staff will not exist and the users of these networks neither have the time nor inclination to learn network administration skills. Instead, these networks need protocols that require zero user configuration and administration.This document is part of an effort to define such zero configuration (zeroconf) protocols. Before embarking on defining zeroconf protocols, protocol requirements are needed. This document states the zeroconf protocol requirements for four protocol areas; they are: IP interface configuration, translation between host name and IP address, IP multicast address allocation, and service discovery. This document does not define specific protocols, just requirements. The requirements for these four areas result from examining everyday use or scenarios of these protocols.
Title : The UDP Multicast Tunneling Protocol
Author(s) : R. Finlayson
Filename : draft-finlayson-umtp-07.txt
Pages : 6
Date : 2002-9-23
Many Internet hosts - such as PCs - while capable of running multicast applications, cannot access the MBone (or other wide-area multicast network) because the router(s) that connect them to the Internet do not yet support IP multicast routing. The 'UDP Multicast Tunneling Protocol' (UMTP) enables such a host to establish an 'ad hoc' connection to the MBone by tunneling multicast UDP datagrams inside unicast UDP datagrams. By using UDP, this tunneling can be implemented as a 'user level' application, without requiring changes to the host's operating system.
Title : Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering and Virtual LAN
Extensions
Author(s) : V. Ngai, E. Bell et al.
Filename : draft-ietf-bridge-ext-v2-01.txt
Pages : 88
Date : 2002-9-23
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular, it defines two MIB modules for managing the new capabilities of MAC bridges defined by the IEEE 802.1D-1998 MAC Bridges and the IEEE 802.1Q-1998 Virtual LAN (VLAN) standards for bridging between Local Area Network (LAN) segments. One MIB module defines objects for managing the 'Traffic Classes' and 'Enhanced Multicast Filtering' components of IEEE 802.1D-1998 and P802.1t-2001. The other MIB module defines objects for managing VLANs, as specified in IEEE 802.1Q-1998, P802.1u and P802.1v. Provisions are made for support of transparent bridging. Provisions are also made so that these objects apply to bridges connected by subnetworks other than LAN segments. This memo also includes several MIB modules in a manner that is compliant to the SMIv2 [V2SMI]. This memo supplements RFC 1493 [BRIDGEMIB] and (to a lesser extent) RFC 1525 [SBRIDGEMIB].
Title : The MIDI Wire Protocol Packetization (MWPP)
Author(s) : J. Lazzaro, J. Wawrzynek
Filename : draft-ietf-avt-mwpp-midi-rtp-05.txt
Pages : 94
Date : 2002-9-23
The MIDI Wire Protocol Packetization (MWPP) is a general-purpose RTP packetization for the MIDI command language. MWPP is suitable for use in both interactive applications (such as the remote operation of musical instruments) and content-delivery applications (such as MIDI file streaming). MWPP is suitable for use over unicast and multicast UDP, and defines tools that support the graceful recovery from packet loss. MWPP may also be used over reliable transport such as TCP. The SDP parameters defined for MWPP support the customization of stream behavior (including the MIDI rendering method) during session setup. MWPP is compatible with the MPEG-4 generic RTP payload format, to support the MPEG 4 Audio object types for General MIDI, DLS2, and Structured Audio.
Title : Basic Socket Interface Extensions for IPv6
Author(s) : R. Gilligan, S. Thomson, J. Bound,
J. McCann, W. Stevens
Filename : draft-ietf-ipngwg-rfc2553bis-07.txt
Pages : 31
Date : 2002-9-19
The de facto standard application program interface (API) for TCP/IP applications is the 'sockets' interface. Although this API was developed for Unix in the early 1980s it has also been implemented on a wide variety of non-Unix systems. TCP/IP applications written using the sockets API have in the past enjoyed a high degree of portability and we would like the same portability with IPv6 applications. But changes are required to the sockets API to support IPv6 and this memo describes these changes. These include a new socket address structure to carry IPv6 addresses, new address conversion functions, and some new socket options. These extensions are designed to provide access to the basic IPv6 features required by TCP and UDP applications, including multicasting, while introducing a minimum of change into the system and providing complete compatibility for existing IPv4 applications. Additional extensions for advanced IPv6 features (raw sockets and access to the IPv6 extension headers) are defined in another document [4].
Title : MIPv6 Care of Address Option
Author(s) : A. O'Neill
Filename : draft-oneill-mipv6-cao-00.txt
Pages : 17
Date : 2002-9-19
IPv6 and MIPv6 has constrained the HoA to being used within forward and reverse tunnels via the HA. In the unicast case, the MN can then activate Route Optimisation to bypass the HA in both directions by securely installing a Binding Cache Entry into the CN. The MN then sends from the CCoA source address to the CN directly into the foreign multicast system, and includes the Home Address Option (HAO) so that the changing CCoA is masked from the transport layer. This draft defines the Care of Address Option, which carries the current CCoA of the MN. The CAO can be included in a Hop By Hop Header or Destination header and used instead of the packet source address for unicast ingress filtering and multicast RPF purposes. This enables a MN to potentially use the HoA as a source address on the foreign network, and to inform the CNs of the evolving MN location.
Title : A Quality-of-Service Resource Allocation Client for CASP
Author(s) : H. Schulzrinne et al.
Filename : draft-schulzrinne-nsis-casp-qos-00.txt
Pages : 12
Date : 2002-9-16
Signaling resource reservations is one of the possible applications of the Cross-Application Signaling Protocol (CASP). This document describes a client protocol that supports per-flow resource reservation for unicast and source-specific multicast flows, in both in-band and out-of-band modes, in sender- and receiver-directed operation.
Title : Aggregated Multicast: A Scheme to Reduce Multicast States
Author(s) : J. Cui et al.
Filename : draft-cui-multicast-aggregation-01.txt
Pages : 13
Date : 2002-9-9
In this document, we present a novel scheme, called aggregated multicast, to reduce multicast states ([FeiGI01] and [FeiNGC01]). The key idea is that multiple groups are forced to share one distribution tree, which we call aggregated tree. In our scheme, core routers need to keep states only per aggregated tree instead of per group. This can significantly reduce the total number of trees in the network and thus reduce forwarding states. We investigate the implementation issues of aggregated multicast in different network scenarios. We also discuss the effects of aggregated multicast on some important issues, such as QoS multicast provisioning, mobility support and fault tolerance. The scope of this paper is not to propose a detailed protocol, but present the idea of aggregated multicast at high level and show its merits.
Title : IPv6 Addressing Architecture Support for mobile ad hoc networks
Author(s) : G. Chelius, E. Fleury
Filename : draft-chelius-adhoc-ipv6-00.txt
Pages : 10
Date : 2002-9-5
The concept of node identifier, in practical terms an IP address, is crucial in ad hoc networks. Its use allows the setup of IP routing for ad hoc connectivity and the identification of several wireless devices as part of a unique ad hoc node. In this document, a new addressable object is defined: the ad hoc connector. It virtualizes several ad hoc network interfaces into a single addressable object. To locally address ad hoc connectors, a third IPv6 local-use unicast address (adhoc-local address) and the correlated use of the subnet multicast scope are defined.
Title : Multicast Announce and Control Protocol (MACP)
Author(s) : J. Helal
Filename : draft-helal-macp-00.txt
Pages : 49
Date : 2002-9-3
This memo describes the message and procedure related to the Multicast Announce and Control Protocol (MACP). This protocol is considered as one 'building blocks' of a reliable multicast transport framework. The Multicast Announce and Control Protocol (MACP) organizes the process by which a multicast sender node (Msender) manages transmissions to dynamic groups of receivers (Mreceivers) in the 'one-to-many' model. The prime objective of MACP is to work in conjunction with various data transport protocols in order to meet various network requirements. One other main objective is to provide a unified announce transport mechanism for both bulk data transfer and streamed data.
Title : Linklocal Multicast Name Resolution (LLMNR)
Author(s) : L. Esibov, B. Aboba, D. Thaler
Filename : draft-ietf-dnsext-mdns-12.txt
Pages : 20
Date : 2002-8-27
Today, with the rise of home networking, there are an increasing number of ad-hoc networks operating without a DNS server. In order to allow name resolution in such environments, Link-Local Multicast Name Resolution (LLMNR) is proposed. LLMNR supports all current and future DNS formats, types and classes, while operating on a separate port from DNS, and with a distinct resolver cache.
Title : Explicit multicast reachability test
Author(s) : J. Lee
Filename : draft-lee-xcast-reachability-00.txt
Pages : 11
Date : 13-Aug-02
It can be important to know which node has Explicit multicast receivability and routability before sending a large amount of data traffic in Explicit multicast. This document provides how to test the receivability and routability, in short, the reachability of Explicit multicast packets to a particular node.
Title : Explicit Multicast Tunneling
Author(s) : J. Lee
Filename : draft-lee-xcast-tunneling-01.txt
Pages : 21
Date : 09-Aug-02
Explicit multicast(Xcast)[1] is a new kind of Internet multicast, and encodes the list of destinations within its packet. This document specifies tunneling scheme of Xcast packets. Since a single Xcast tunnel has multiple egress-nodes, the original Xcast packet can be encapsulated either within a Xcast packet or within a unicast packet. When tunneled by Xcast-in-Xcast encapsulation, the bitmap of the original Xcast packet is overwritten by the bitmap of the tunnel Xcast packet at tunnel egress-nodes, in order to control the active destination set.
Title : Host Extensions to Protocol Independent Multicast
Author(s) : K. Patel, R. Perlman
Filename : draft-keyur-pim-host-extensions-00.txt
Pages :
Date : 06-Aug-02
This document defines host extensions to Protocol Independent Multicast - PIM protocol. These host extensions allows endnodes to join/leave any multicast (S/*,G) groups. This helps in easing SSM-style multicast deployment that does not have to depend on IGMP (v1/v2/v3), in either endnodes or the routers.
Title : L2TP Multicast Extension
Author(s) : G. Bourdon
Filename : draft-ietf-l2tpext-mcast-02.txt
Pages : 16
Date : 01-Aug-02
The Layer Two Tunneling Protocol (L2TP) [RFC2661] provides a standard method for tunneling PPP [RFC1661] packets. This document describes an extension to L2TP, in order to have an efficient use of L2TP tunnels within the context of deploying multicast services whose data will have to be conveyed by such tunnels.
Title : Mobility Management and IP Multicast
Author(s) : A. O'Neill
Filename : draft-oneill-mip-multicast-00.txt
Pages : 20
Date : 25-Jul-02
Mobile IP provides a mobile node, that visits a foreign subnet, the ability to continue to use an address from its home subnet (the home address) as a source address. This is achieved through the allocation of a Care of Address on the foreign subnet that is used as the end-point of a redirection tunnel from a home agent on the home subnet. Mobile IP in RFC 3220 states that when the mobile node originates multicast traffic intended for the foreign multicast system, it can only do so by first obtaining an IP address from the foreign subnet (a Collocated Care of Address) and then using this address as the multicast source address. This is to ensure that the source address will pass multicast routing reverse path forwarding checks. This foreign multicast model is however extremely restrictive, and still very problematic to multicast routing and applications when the mobile node regularly changes foreign subnets, as is common in wireless systems. This is because the source address continues to evolve which must be tracked by source specific multicast application and routing signalling. Using the home multicast system, again described above, is also non-optimal because the mobile node receiver is then serviced by packets that must be tunnelled from its home agent which, removes any multicast routing benefits (ie network based tree building). This draft therefore describes modifications to the foreign multicast interface between mobile IP and multicast routing that enable the mobile node to use its persistent home address as a multicast source address.
Title : The Bordercast Resolution Protocol (BRP) for Ad Hoc Networks
Author(s) : Z. Haas, M. Pearlman, P. Samar
Filename : draft-ietf-manet-zone-brp-02.txt
Pages : 13
Date : 05-Jul-02
The Bordercast Resolution Protocol (BRP) provides the bordercasting packet delivery service used to support network querying applications. The BRP uses a map of an extended routing zone, provided by the local proactive Intrazone Routing Protocol (IARP), to construct bordercast (multicast) trees, along which query packets are directed. Within the context of the hybrid ZRP, the BRP is used to guide the route requests of the global reactive Interzone Routing Protocol (IERP). The BRP employs special query control mechanisms to steer route requests away from areas of the network that have already been covered by the query. The combination of multicasting and zone based query control makes bordercasting an efficient and tunable service that is more suitable than flood searching for network probing applications like route discovery.
Title : Securing Group Management in IPv6 with Cryptographically Generated Addresses
Author(s) : C. Castelluccia, G. Montenegro
Filename : draft-irtf-gsec-sgmv6-01.txt
Pages : 32
Date : 05-Jul-02
Currently, group membership management in IP Multicast and Anycast can be abused in order to launch denial-of-service (DoS) attacks. The root of the problem is that routers cannot determine if a given host is authorized to join a group (sometimes referred to as the 'Proof-of-Membership Problem' [ECUMN00]). We propose a solution for IPv6 based on Group Cryptographically Generated Addresses (G-CGA). These addresses have characteristics of statistical uniqueness and cryptographic verifiability that lend themselves to severely limiting certain classes of DoS attacks. Our scheme is fully distributed and does not require any trusted third party or pre-established security association between the routers and the hosts. This is not only a huge gain in terms of scalability, reliability and overhead, but also in terms of privacy.
Title : IP Multicast in Differentiated Services Networks
Author(s) : R. Bless, K. Wehrle
Filename : draft-bless-diffserv-multicast-04.txt
Pages : 34
Date : 05-Jul-02
This document presents some of the problems which will arise when IP Multicast is used in DiffServ networks without taking special precautions into account for supplying multicast services. Although the basic DS forwarding mechanisms also work with IP Multicast, some facts have to be considered which are related to the provisioning of multicast resources. The presented problems mainly lead to situations in which other service users are affected adversely in their experienced quality. In order to retain the benefits of the DiffServ approach, a quite simple and scalable solution for those problems is required, not resulting in additional complexity or costs related to forwarding mechanisms in a DiffServ domain
Title : Link Scoped IPv6 Multicast Addresses
Author(s) : J. Park, M. Shin, Y. Kim
Filename : draft-ietf-ipv6-link-scoped-mcast-01.txt
Pages : 6
Date : 05-Jul-02
This document specifies an extension to the multicast addressing architecture of the IPv6 protocol. The extension allows for the use of interface-ID to allocate multicast addresses. When the link-local unicast address is configured at each interface of host, interface ID is uniquely determined. By delegating multicast addresses at the same time as interface ID, each host can identify their multicast addresses automatically at Layer 1 without running an intra- or inter-domain allocation protocol in the serverless environments.
Title : RTCP Extensions for Single-Source Multicast Sessions with Unicase Feedback
Author(s) : J. Chesterfield et al.
Filename : draft-ietf-avt-rtcpssm-01.txt
Pages : 28
Date : 05-Jul-02
This document specifies a modification to the Real-time Transport Control Protocol (RTCP) to use unicast feedback. The proposed extension is useful for single source multicast sessions such as Source Specific Multicast (SSM) communication where the traditional model of many-to-many group communication is either not possible or not preferred. In addition, it can be applied to any group that might benefit from a sender controlled summarised reporting mechanism.