Browse Prior Art Database

Terminology for IP Multicast Benchmarking (RFC2432)

IP.com Disclosure Number: IPCOM000003010D
Original Publication Date: 1998-Oct-01
Included in the Prior Art Database: 2000-Sep-13
Document File: 13 page(s) / 27K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

K. Dubray: AUTHOR

Abstract

The purpose of this document is to define terminology specific to the benchmarking of multicast IP forwarding devices. It builds upon the tenets set forth in RFC 1242, RFC 2285, and other IETF Benchmarking Methodology Working Group (BMWG) efforts. This document seeks to extend these efforts to the multicast paradigm.

This text was extracted from a ASCII Text document.
This is the abbreviated version, containing approximately 11% of the total text.

Network Working Group K. Dubray

Request for Comments: 2432 IronBridge Networks

Category: Informational October 1998

Terminology for IP Multicast Benchmarking

Status of this Memo

This memo provides information for the Internet community. It does

not specify an Internet standard of any kind. Distribution of this

memo is unlimited.

Copyright Notice

Copyright (C) The Internet Society (1998). All Rights Reserved.

Abstract

The purpose of this document is to define terminology specific to the

benchmarking of multicast IP forwarding devices. It builds upon the

tenets set forth in RFC 1242, RFC 2285, 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.

1. Introduction

Network forwarding devices are being required to take a single frame

and support delivery to a number of destinations having membership to

a particular group. As such, multicast support may place a different

burden on the resources of these network forwarding devices than with

unicast or broadcast traffic types.

Such burdens may not be readily apparent at first glance - the IP

multicast packet's Class D address may be the only noticeable

difference from an IP unicast packet. However, there are many

factors that may impact the treatment of IP multicast packets.

Consider how a device's architecture may impact the handling of a

multicast frame. For example, is the multicast packet subject to the

same processing as its unicast analog? Or is the multicast packet

treated as an exeception and processed on a different data path?

Consider, too, how a shared memory architecture may demonstrate a

different performance profile than an architecture which explicitly

passes each individual packet between the processing entities.

In addition to forwarding device architecture, there are other

factors that may impact a device's or system's multicast related

performance. Protocol requirements may demand that routers and

switches consider destination and source addressing in its multicast

forwarding decisions. Capturing multicast source/destination

addressing information may impact forwarding table size and lengthen

lookups. Topological factors such as the degree of packet

replication, the number of multicast groups being supported by the

system, or the placement of multicast packets in unicast wrappers to

span non-multicast network paths may all potentially affect a

system's multicast related perfo...