RFC 2432 (rfc2432) - Page 1 of 16


Terminology for IP Multicast Benchmarking



Alternative Format: Original Text Document



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?



Dubray                       Informational