idnits 2.17.1 draft-ietf-bmwg-mcast-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 6 longer pages, the longest (page 11) being 64 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 14 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 526: '...principal result MUST be reported in c...' RFC 2119 keyword, line 565: '...ncy measurements MUST be reported with...' RFC 2119 keyword, line 595: '...lay measurements MUST be reported with...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 10 has weird spacing: '...ment is an I...' == Line 11 has weird spacing: '...cuments of t...' == Line 12 has weird spacing: '...ups may also ...' == Line 16 has weird spacing: '... and may be...' == Line 17 has weird spacing: '...me. It is i...' == (38 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 1998) is 9416 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'Br91' is defined on line 620, but no explicit reference was found in the text == Unused Reference: 'Br96' is defined on line 623, but no explicit reference was found in the text == Unused Reference: 'Ma98' is defined on line 631, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1242 (ref. 'Br91') ** Obsolete normative reference: RFC 1944 (ref. 'Br96') (Obsoleted by RFC 2544) -- Possible downref: Non-RFC (?) normative reference: ref. 'Hu95' -- Possible downref: Non-RFC (?) normative reference: ref. 'Se98' ** Downref: Normative reference to an Informational RFC: RFC 2285 (ref. 'Ma98') -- Possible downref: Non-RFC (?) normative reference: ref. 'Mt98' Summary: 11 errors (**), 0 flaws (~~), 12 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group K. Dubray 2 INTERNET-DRAFT IronBridge Networks 3 Expiration Date: January 1999 July 1998 5 Terminology for IP Multicast Benchmarking 6 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet-Drafts as reference 18 material or to cite them other than as "work in progress." 20 To view the entire list of current Internet-Drafts, please check 21 the "1id-abstracts.txt" listing contained in the Internet-Drafts 22 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 23 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 24 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 25 (US West Coast). 27 This memo provides information for the Internet community. This memo 28 does not specify an Internet standard of any kind. Distribution of 29 this memo is unlimited. 31 Abstract 33 The purpose of this draft is to define terminology specific to the 34 benchmarking of multicast IP forwarding devices. It builds upon the 35 tenets set forth in RFC 1242, RFC 2285, and other IETF Benchmarking 36 Methodology Working Group (BMWG) efforts. This document seeks to 37 extend these efforts to the multicast paradigm. 39 1. Introduction 41 Network forwarding devices are being required to take a single frame 42 and support delivery to a number of destinations having membership to 43 a particular group. As such, multicast support may place a different 44 burden on the resources of these network forwarding devices than with 45 unicast or broadcast traffic types. 47 Such burdens may not be readily apparent at first glance - the IP 48 multicast packet's Class D address may be the only noticeable 49 difference from an IP unicast packet. However, there are many 50 factors that may impact the treatment of IP multicast packets. 52 Consider how a device's architecture may impact the handling of a 53 multicast frame. For example, is the multicast packet subject to the 54 same processing as its unicast analog? Or is the multicast packet 55 treated as an exeception and processed on a different data path? 56 Consider, too, how a shared memory architecture may demonstrate a 57 different performance profile than an architecture which explicitly 58 passes each individual packet between the processing entities. 60 In addition to forwarding device architecture, there are other 61 factors that may impact a device's or system's multicast related 62 performance. Protocol requirements may demand that routers and 63 switches consider destination and source addressing in its multicast 64 forwarding decisions. Capturing multicast source/destination 65 addressing information may impact forwarding table size and lengthen 66 lookups. Topological factors such as the degree of packet 67 replication, the number of multicast groups being supported by the 68 system, or the placement of multicast packets in unicast wrappers to 69 span non-multicast network paths may all potentially affect a 70 system's multicast related performance. For an overall understanding 71 of IP multicasting, the reader is directed to [Se98], [Hu95], and 72 [Mt98]. 74 By clearly identifying IP multicast benchmarks and related 75 terminology in this document, it is hoped that detailed methodologies 76 can be generated in subsequent documents. Taken in tandem, these two 77 efforts endeavor to assist the clinical, empirical, and consistent 78 characterization of certain aspects of multicast technologies and 79 their individual implementations. Understanding the operational 80 profile of multicast forwarding devices may assist the network 81 designer to better deploy multicast in his or her networking 82 environment. 84 This work is primarily directed towards intermediate IP multicast 85 forwarding devices (e.g., routers or switches) on LANs. Elements of 86 this text may or may not be applicable to other media as well. 87 Moreover, this document focuses on one source to many destinations 88 profiling. Elements of this document may require extension when 89 considering multiple source to multiple destination IP multicast 90 communication. 92 2. Definition Format 94 This section cites the template suggested by RFC 1242 in the 95 specification of a term to be defined. 97 Term to be defined. 99 Definition: 100 The specific definition for the term. 102 Discussion: 103 A brief discussion of the term, its application and any 104 restrictions on measurement procedures. 106 Measurement units: 107 Units used to record measurements of this term, if applicable. 109 [Issues:] 110 List of issues or conditions that effect this term. This 111 field is optional in this draft. 113 [See Also:] 114 List of other terms that are relevant to the discussion 115 of this term. This field is optional in this draft. 117 2.1 Existing Terminology 119 This document draws on existing terminology defined in other BMWG 120 work. Examples include, but are not limited to: 122 Throughput (RFC 1242, section 3.17) 123 Latency (RFC 1242, section 3.8) 124 Constant Load (RFC 1242, section 3.4) 125 Frame Loss Rate (RFC 1242, section 3.6) 126 Overhead behavior (RFC 1242, section 3.11) 127 Forwarding Rates (RFC 2285, section 3.6) 128 Loads (RFC 2285, section 3.5) 129 Devices (RFC 2285, section 3.1) 131 3. Table of Defined Terms 133 3.1 General Nomenclature 134 3.1.1 Traffic Class. 135 3.1.2 Group Class. 136 3.1.3 Service Class. 138 3.2 Forwarding and Throughput 139 3.2.1 Mixed Class Throughput (MCT). 140 3.2.2 Scaled Group Forwarding Matrix (SGFM). 141 3.2.3 Aggregated Multicast Throughput (AMT) 142 3.2.4 Encapsulation Throughput (ET) 143 3.2.5 Decapsulation Throughput (DT) 144 3.2.6 Re-encapsulation Throughput (RET) 146 3.3 Forwarding Latency 147 3.3.1 Multicast Latency 148 3.3.2 Min/Max Multicast Latency 150 3.4 Overhead 151 3.4.1 Group Join Delay. 152 3.4.2 Group Leave Delay. 154 3.5 Capacity 155 3.5.1 Multicast Group Capacity. 157 3.6 Interaction 158 3.6.1 Burdened Response 159 3.6.2 Forwarding Burdened Multicast Latency 160 3.6.3 Forwarding Burdened Join Delay 162 3.1 General Nomenclature 164 This section will present general terminology to be used in 165 this and other documents. 167 3.1.1 Traffic Class. 169 Definition: 170 An equivalence class of packets comprising one or more data 171 streams. 173 Discussion: 174 In the scope of this document, Traffic Class will be considered 175 a logical identifier used to discriminate between a set or sets 176 of packets offered the DUT. 178 For example, one Traffic Class may identify a set of unicast 179 packets 180 offered to the DUT. Another Traffic Class may differentiate the 181 multicast packets destined to multicast group X. Yet another 182 Class may distinguish the set of multicast packets destined to 183 multicast group Y. 185 Unless otherwise qualified, the usage of the word "Class" in this 186 document will refer simply to a Traffic Class. 188 Measurement units: 189 Not applicable. 191 3.1.2 Group Class. 193 Definition: 195 A specific type of Traffic Class where the packets comprising the 196 Class 197 are destined to a particular multicast group. 199 Discussion: 201 Measurement units: 202 Not applicable. 204 3.1.3 Service Class. 206 Definition: 207 A specific type of Traffic Class where the packets comprising the 208 Class 209 require particular treatment or treatments by the network 210 forwarding devices along the path to the packets' destination(s). 212 Discussion: 214 Measurement units: 215 Not applicable. 217 3.2 Forwarding and Throughput. 219 This section presents terminology related to the characterization of 220 the packet forwarding ability of a DUT/SUT in a multicast 221 environment. 222 Some metrics extend the concept of throughput presented in RFC 1242. 223 The notion of Forwarding Rate is cited in RFC 2285. 225 3.2.1 Mixed Class Throughput (MCT). 227 Definition: 228 The maximum rate at which none of the offered frames, comprised 229 from a unicast Class and a multicast Class, to be forwarded are 230 dropped by the device across a fixed number of ports. 232 Discussion: 233 Often times, throughput is collected on a homogenous traffic 234 class - the offered load to the DUT is either singularly unicast or 235 singularly multicast. In most networking environments, the traffic 236 mix is seldom so uniformly distributed. 238 Based on the RFC 1242 definition for throughput, the Mixed 239 Class Throughput benchmark attempts to characterize the DUT's 240 ability to process both unicast and multicast frames in the 241 same aggregated traffic stream. 243 Measurement units: 244 Frames per second 246 Issues: 247 Related methodology may have to address the ratio of unicast 248 packets 249 to multicast packets. 251 3.2.2 Scaled Group Forwarding Matrix (SGFM). 253 Definition: 254 A table that demonstrates Forwarding Rate as a function of 255 tested multicast groups for a fixed number of tested 256 DUT/SUT ports. 258 Discussion: 259 A desirable attribute of many Internet mechanisms is the ability 260 to "scale." This benchmark seeks to demonstrate the ability 261 of a SUT to forward as the number of multicast groups is scaled 262 upwards. 264 Measurement units: 265 Packets per second, with corresponding tested multicast group 266 and port configurations. 268 Issues: 269 The corresponding methodology may have to reflect the impact 270 that the pairing (source, group) has on many multicast routing 271 protocols. 273 3.2.3 Aggregated Multicast Throughput (AMT) 275 Definition: 276 The maximum rate at which none of the offered frames to be 277 forwarded through N destination interfaces of the same multicast 278 group are dropped. 280 Discussion: 281 Another "scaling" type of exercise, designed to identify the 282 DUT/SUT's ability to handle traffic as a function of the 283 multicast destination ports it is required to support. 285 Measurement units: 286 The ordered pair (N,t) where, 288 N = the number of destination ports of the multicast group. 289 t = the throughput, in frames per second, relative to the 290 source stream. 292 3.2.4 Encapsulation Throughput (ET) 293 Definition: 294 The maximum rate at which frames offered a DUT are encapsulated 295 and correctly forwarded by the DUT without loss. 297 Discussion: 298 A popular technique in presenting a frame to a device that may 299 not support a protocol feature is to encapsulate, or tunnel, 300 the packet containing the unsupported feature in a format that 301 is supported by that device. 303 More specifically, encapsulation refers to the act of taking a 304 frame or part of a frame and embedding it as a payload of another 305 frame. This benchmark attempts to characterize the overhead 306 behavior 307 associated with that translational process. 309 Consideration may need to be given with respect to the impact 310 of different frame formats on usable bandwidth. 312 Measurement units: 313 Frames per second. 315 3.2.5 Decapsulation Throughput (DT) 317 Definition: 318 The maximum rate at which frames offered a DUT are decapsulated 319 and correctly forwarded by the DUT without loss. 321 Discussion: 322 A popular technique in presenting a frame to a device that may 323 not support a protocol feature is to encapsulate, or tunnel, 324 the packet containing the unsupported feature in a format that 325 is supported by that device. At some point, the frame may be 326 required 327 to be returned its orginal format from its encapsulation wrapper 328 for 329 use by the frame's next destination. 331 More specifically, decapsulation refers to the act of taking a 332 frame or part of a frame embedded as a payload of another frame and 333 returning it to the payload's appropriate format. This benchmark 334 attempts to characterize the overhead behavior associated with that 335 translational process. 337 Consideration may need to be given with respect to the impact 338 of different frame formats on usable bandwidth. 340 Measurement units: 341 Frames per second. 343 3.2.6 Re-encapsulation Throughput (RET) 344 Definition: 345 The maximum rate at which frames of one encapsulated format offered 346 a DUT 347 are converted to another encapsulated format and correctly 348 forwarded 349 by the DUT without loss. 351 Discussion: 352 A popular technique in presenting a frame to a device that may 353 not support a protocol feature is to encapsulate, or tunnel, 354 the packet containing the unsupported feature in a format that 355 is supported by that device. At some point, the frame may be 356 required 357 to be converted from one encapsulation format to another 358 encapsulation 359 format. 361 More specifically, re-encapsulation refers to the act of taking an 362 encapsulated payload of one format and replacing it with another 363 encapsulated format - all the while preserving the original 364 payload's 365 contents. This benchmark attempts to characterize the overhead 366 behavior associated with that translational process. 368 Consideration may need to be given with respect to the impact 369 of different frame formats on usable bandwidth. 371 Measurement units: 372 Frames per second. 374 3.3 Forwarding Latency. 376 This section presents terminology relating to the characterization of 377 the forwarding latency of a DUT/SUT in a multicast environment. 378 It extends the concept of latency presented in RFC 1242. 380 3.3.1 Multicast Latency. 382 Definition: 383 The set of individual latencies from a single input port on 384 the DUT or SUT to all tested ports belonging to the destination 385 multicast group. 387 Discussion: 388 This benchmark is based on the RFC 1242 definition of latency. 389 While it is useful to collect latency between a pair of source 390 and destination multicast ports, it may be insightful to collect 391 the same type of measurements across a range of ports supporting 392 that Group Class. 394 A variety of statistical exercises can be applied to the set of 395 latencies measurements. 397 Measurement units: 398 Time units with enough precision to reflect a latency measurement. 400 3.3.2 Min/Max Multicast Latency. 402 Definition: 403 The difference between the maximum latency measurement and the 404 minimum latency measurement from the set of latencies produced by 405 the Multicast Latency benchmark. 407 Discussion: 408 This statistic may yield some insight into how a particular 409 implementation handles its multicast traffic. This may be useful 410 to users of multicast synchronization types of applications. 412 Measurement units: 413 Time units with enough precision to reflect latency measurement. 415 3.4 Overhead 417 This section presents terminology relating to the characterization of 418 the overhead delays associated with explicit operations found in 419 multicast environments. 421 3.4.1 Group Join Delay. 423 Definition: 424 The time duration it takes a DUT/SUT to start forwarding multicast 425 packets from the time a successful IGMP group membership report has 426 been issued to the DUT/SUT. 428 Discussion: 429 Many factors can contribute to different results, such as 430 the number or type of multicast-related protocols configured 431 on the system under test. Other factors are physical topology and 432 "tree" configuration. 434 Because of the number of variables that could impact this metric, 435 the metric may be a better characterization tool for a device or 436 system rather than a basis for comparisons with other devices. 438 A consideration for the related methodology: possible need to 439 differentiate a specifically-forwarded multicast frame from those 440 sprayed by protocols implementing a flooding tactic to solicit 441 prune 442 feedback. 444 Measurement units: 445 Microseconds. 447 3.4.2 Group Leave Delay. 449 Definition: 450 The time duration it takes a DUT/SUT to cease forwarding multicast 451 packets after a corresponding IGMP "Leave Group" message has been 452 successfully offered to the DUT/SUT. 454 Discussion: 455 While it is important to understand how quickly a system can 456 process multicast frames; it may be beneficial to understand 457 how quickly that same system can stop the process as well. 459 Because of the number of variables that could impact this metric, 460 the metric may be a better characterization tool for a device or 461 system rather than a basis for comparisons with other devices. 463 Measurement units: 464 Microseconds. 466 Issues: Methodology may need to consider protocol-specific timeout 467 values. 469 3.5 Capacity 471 This section offers terms relating to the identification of multicast 472 group limits of a DUT/SUT. 474 3.5.1 Multicast Group Capacity. 476 Definition: 477 The maximum number of multicast groups a SUT/DUT can support 478 while maintaining the ability to forward multicast frames 479 to all multicast groups registered to that SUT/DUT. 481 Discussion: 483 Measurement units: 484 Multicast groups. 486 Issues: 487 The related methodology may have to consider the impact of 488 multicast 489 sources per group on the ability of a SUT/DUT to "scale up" the 490 number of supportable multicast groups. 492 3.6 Interaction 494 Network forwarding devices are generally required to provide more 495 functionality than than the forwarding of traffic. Moreover, network 496 forwarding devices may be asked to provide those functions in a 497 variety of 498 environments. This section offers terms to assist in the 499 charaterization 500 of DUT/SUT behavior in consideration of potentially interacting 501 factors. 503 3.6.1 Burdened Response. 505 Definition: 506 A measured response collected from a DUT/SUT in light of 507 interacting, or potentially interacting, distinct stimulii. 509 Discussion: 510 Many metrics provide a one dimensional view into an operating 511 characteristic of a tested system. For example, the forwarding 512 rate 513 metric may yield information about the packet processing ability 514 of a device. Collecting that same metric in view of another 515 control variable can oftentimes be very insightful. Taking that 516 same 517 forwarding rate measurement, for instance, while the device's 518 address 519 table is injected with an additional 50,000 entries may yield a 520 different perspective. 522 Measurement units: 523 A burdened response is a type of metric. Metrics of this 524 this type must follow guidelines when reporting results. 526 The metric's principal result MUST be reported in conjunction with 527 the 528 contributing factors. 530 For example, in reporting a Forwarding Burdened Latency, the 531 latency measurement should be reported with respect to 532 corresponding Offered Load and Forwarding Rates. 534 Issues: 535 A Burdened response may be very illuminating when trying to 536 characterize a single device or system. Extreme care must 537 be exercised when attempting to use that characterization as 538 a basis of comparison with other devices or systems. Test agents 539 must ensure that the measured response is a function of the 540 controlled stimulii, and not secondary factors. An example of 541 of such an interfering factor would be configuration mismatch of 542 a timer impacting a response process. 544 3.6.2 Forwarding Burdened Multicast Latency. 546 Definition: 547 A multicast latency taken from a DUT/SUT in the presence of 548 a traffic forwarding requirement. 550 Discussion: 551 This burdened response metric builds on the Multicast Latency 552 definition 553 offered in section 3.3.1. It mandates that the DUT be subjected to 554 an additional measure of traffic not required by the non-burdened 555 metric. 557 This metric attempts to provide a means by which to evaluate 558 how traffic load may or may not impact a device's or system's 559 packet processing delay. 561 Measurement units: 562 Time units with enough precision to reflect the latencies 563 measurements. 565 Latency measurements MUST be reported with the corresponding 566 sustained 567 Forwarding Rate and associated Offered Load. 569 3.6.3 Forwarding Burdened Group Join Delay. 571 Definition: 572 A multicast Group Join Delay taken from a DUT/SUT in the presence 573 of 574 a traffic forwarding requirement. 576 Discussion: 577 This burdened response metric builds on the Group Join Delay 578 definition 579 offered in section 3.4.1. It mandates that the DUT be subjected to 580 an additional measure of traffic not required by the non-burdened 581 metric. 583 Many factors can contribute to different results, such as 584 the number or type of multicast-related protocols configured 585 on the system under test. Other factors could be physical topology 586 or the logical multicast "tree" configuration. 588 Because of the number of variables that could impact this metric, 589 the metric may be a better characterization tool for a device or 590 system rather than a basis for comparisons with other devices. 592 Measurement units: 593 Time units with enough precision to reflect the delay measurements. 595 Delay measurements MUST be reported with the corresponding 596 sustained 597 Forwarding Rate and associated Offered Load. 599 4. Security Considerations 601 This document addresses metrics and terminology relating to the 602 performance benchmarking of IP Multicast forwarding devices. 603 The information contained in this document does not impact the 604 security of the Internet. 606 Methodologies regarding the collection of the metrics described 607 within this document may need to cite security considerations. 608 This document does not address methodological issues. 610 5. Acknowledgments 612 The IETF BMWG participants have made several comments and suggestions 613 regarding this work. Particular thanks goes to Scott Bradner, Brad 614 Cain, Eric Crawley, Bob Mandeville, David Newman, Shuching Sheih, 615 Dave Thaler, Chuck Winter, Zhaohui Zhang, and John Galgay for their 616 insightful review and assistance. 618 6. References 620 [Br91] Bradner, S. Benchmarking Terminology for Network 621 Interconnection Devices. RFC 1242. July, 1991. 623 [Br96] Bradner, S., McQuaid, J. Benchmarking Methodology for Network 624 Interconnect Devices. RFC 1944. May, 1996. 626 [Hu95] Huitema, C. "Routing in the Internet." Prentice-Hall, 1995. 628 [Se98] Semeria, C. and Maufer, T. "Introduction to IP Multicast 629 Routing." http://www.3com.com/nsc/501303.html 3Com Corp., 1998. 631 [Ma98] Mandeville, R. Benchmarking Terminology for LAN Switching 632 Devices. 633 RFC 2285. February, 1998. 635 [Mt98] Maufer, T. "Deploying IP Multicast in the Enterprise." 636 Prentice- 637 Hall, 1998. 639 7. Author's Address 641 Kevin Dubray 642 IronBridge Networks 643 55 Hayden Avenue 644 Lexington, MA 02421 645 USA 647 Phone: 781 402 8018 648 EMail: kdubray@ironbridgenetworks.com