idnits 2.17.1 draft-ietf-bmwg-lanswitch-02.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-26) 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 1 longer page, the longest (page 1) being 713 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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.) ** There are 116 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** There are 2 instances of lines with control characters in the document. ** 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 140: '...ectional traffic MUST be offered when ...' RFC 2119 keyword, line 343: '...evice under test MUST NOT be counted a...' RFC 2119 keyword, line 369: '... inhibited, they MUST be left out of f...' RFC 2119 keyword, line 462: '...stinations. Flooded frames MUST NOT be...' RFC 2119 keyword, line 639: '...ncy measurements SHOULD be bit oriente...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (Jan 1997) is 9963 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) No issues found here. Summary: 10 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Mandeville 3 INTERNET-DRAFT European Network Laboratories 4 Expiration Date: Jun 1997 Jan 1997 6 Benchmarking Terminology for LAN Switching Devices 7 < draft-ietf-bmwg-lanswitch-02.txt > 9 Status of this Document 11 This document is an Internet-Draft. Internet-Drafts are working documents of 12 the Internet Engineering Task Force (IETF), its areas, and its working 13 groups. Note that other groups may also distribute working documents as 14 Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months and 17 may be updated, replaced, or obsoleted by other documents at any time. It is 18 inappropriate to use Internet- Drafts as reference material or to cite them 19 other than as ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 23 Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 24 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 26 Distribution of this document is unlimited. Please send comments to 27 bmwg@harvard.edu or to the editor. 29 Abstract 31 The purpose of this draft is to define and discuss benchmarking terminology 32 for local area switching devices. It is meant to extend the terminology 33 already defined for network interconnect devices in RFCs 1242 and 1944 by 34 the Benchmarking Methodology Working Group (BMWG) of the Internet 35 Engineering Task Force (IETF) and prepare the way for a discussion on 36 benchmarking methodology for local area switches. 38 LAN switches are one of the principal sources of new bandwidth in the local 39 area. The multiplicity of products brought to market makes it desirable to 40 define a set of terms to be used when evaluating the performance 41 characteristics of local area switching devices. Well-defined terminology 42 will help in providing the user community with complete, reliable and 43 comparable data on LAN switches. 45 1. Introduction 47 The purpose of this draft is to discuss and define terminology for the 48 benchmarking of local area network switches. Although it might be found 49 useful to apply some of the terms defined here to a broader range of network 50 interconnect devices, this draft primarily deals with devices which switch 51 frames at the Medium Access Control (MAC) layer. It defines terms in 52 relation to throughput, latency, address handling and filtering. 54 2. Term definitions 56 A previous document, "Benchmarking Terminology for Network Interconnect 57 Devices" (RFC 1242), defined many of the terms that are used in this 58 document. The terminology document should be consulted before attempting to 59 make use of this document. A more recent document, "Benchmarking Methodology 60 for Network Interconnect Devices" (RFC 1944), defined a number of test 61 procedures which are directly applicable to switches. Since it discusses a 62 number of terms relevant to benchmarking switches it should also be consulted. 63 A number of new terms applicable to benchmarking switches are defined below 64 using the format for definitions set out in Section 2 of RFC 1242. RFCs 1242 65 and 1944 already contain discussions of some of these terms. 67 2. 1. Reminder of RFC 1242 definition format 69 Term to be defined. (e.g., Latency) 71 Definition: 72 The specific definition for the term. 74 Discussion: 75 A brief discussion about the term, it's application 76 and any restrictions on measurement procedures. 78 Measurement units: 79 The units used to report measurements of this 80 term, if applicable. 82 Issues: 83 List of issues or conditions that effect this term. 85 See Also: 86 List of other terms that are relevant to the discussion 87 of this term. 89 2.2. Unidirectional traffic 91 Definition: 93 Single or multiple streams of frames forwarded in one direction only from 94 one or more ports of a switching device designated as input ports to one or 95 more other ports of the device designated as output ports. 97 Discussion: 98 This definition conforms to the discussion in section 16 of RFC 1944 on 99 multi-port testing which describes how unidirectional traffic can be offered 100 to ports of a device to measure throughput. 101 Unidirectional traffic is also appropriate for: 102 - the measurement of the minimum inter-frame gap 103 - the creation of many-to-one or one-to-many port overload 104 - the detection of head of line blocking 105 - the measurement of throughput when congestion control mechanisms are active 107 Unidirectional traffic can be used to load the ports of a switching device 108 in different ways. For example unidirectional traffic can be sent to two or 109 more input ports from an external source and switched by the device under 110 test to a single output port (n-to-1) or such traffic can be sent to a 111 single input port and switched by the device under test to two or more 112 output ports (1-to-n). Such patterns can be combined to test for head of 113 line blocking or to measure throughput when congestion control mechanisms 114 are active. 115 When devices are equipped with ports running at different media rates the 116 number of input streams required to load or overload an output port or ports 117 will vary. 118 The measurement of the minimum inter-frame gap serves to detect violations 119 of the IEEE 802.3 standard. 121 Issues: 122 half duplex / full duplex 124 Measurement units: 125 n/a 127 See Also: 128 bidirectional traffic (2.3) 129 meshed traffic (2.4) 131 2.3. Bidirectional traffic 133 Definition: 134 Two or more streams of frames forwarded in opposite directions between at 135 least two or more ports of a switching device. 137 Discussion: 138 This definition conforms to the discussions in sections 14 and 16 of RFC 139 1944 on bidirectional traffic and multi-port testing. 140 Bidirectional traffic MUST be offered when measuring throughput on full 141 duplex ports of a switching device. 143 Issues: 144 truncated binary exponential back-off algorithm 146 Measurement units: 147 n/a 149 See Also: 150 unidirectional traffic (2.2) 151 meshed traffic (2.4) 153 2.4. Meshed traffic 155 Definition: 156 Multiple streams of frames switched simultaneously between all of a 157 designated number of ports of a switching device such that each of the ports 158 under test will both send frames to and receive frames from all of the other 159 ports under test. 161 Discussion: 162 This definition follows from the discussions in sections 14 and 16 of RFC 163 1944 on bidirectional traffic and multi-port testing and readily extends to 164 configurations with multiple switching devices linked together over backbone 165 connections. 166 As with bidirectional multi-port traffic, meshed traffic exercises both the 167 transmission and reception sides of the ports of a switching device. Since 168 ports are not divided into two groups every port forwards frames to and 169 receives frames from every other port. The total number of individual 170 streams when traffic is meshed over n switched ports equals n x (n - 1). 171 This compares with n x (n / 2) such streams in a bidirectional multi-port 172 test. It should be noted that bidirectional multiport traffic can load 173 backbone connections linking together two switching devices more than meshed 174 traffic. 175 Meshed traffic on half duplex ports is inherently bursty since ports must 176 interrupt transmission whenever they receive frames. Bursty meshed traffic 177 which is characteristic of real network traffic simultaneously exercises 178 many of the component parts of a switching device such as input and output 179 buffers, buffer allocation mechanisms, aggregate switching capacity, 180 processing speed and behavior of the medium access controller. 181 When offering bursty meshed traffic to a device under test a number of 182 variables have to be considered. These include frame size, the number of 183 frames within bursts as well as the interval between bursts. The terms 184 burst, burst size and inter-burst gap are defined in sections 2.5, 2.6 and 185 2.7 below. 187 Measurement units: 188 n/a 190 Issues: 191 half duplex / full duplex 193 See Also: 194 unidirectional traffic (2.2) 195 bidirectional traffic (2.3) 196 burst (2.5) 197 burst size (2.6) 198 inter-burst gap (2.7) 200 2.5 Burst 202 Definition: 203 A sequence of frames transmitted with the minimum inter-frame gap allowed by 204 the medium. 206 Discussion: 207 This definition follows from discussions in section 3.16 of RFC 1242 and 208 section 21 of RFC 1944 which describes cases where it is useful to consider 209 isolated frames as single frame bursts. 211 Measurement units: 212 n/a 214 Issues: 216 See Also: 217 burst size (2.6) 219 2.6 Burst size 221 Definition: 222 The number of frames in a burst. 224 Discussion: 225 Burst size can range from one to infinity. In unidirectional streams there 226 is no theoretical limit to burst length. When traffic is bidirectional or 227 meshed bursts on half duplex media are finite since ports interrupt 228 transmission intermittently to receive frames. 229 On real networks burst size will normally increase with window size. This 230 makes it desirable to test devices with small as well as large burst sizes. 232 Measurement units: 233 number of N-octet frames 235 Issues: 237 See Also: 238 burst (2.5) 240 2.7 Inter-burst gap (IBG) 242 Definition: 243 The interval between two bursts. 245 Discussion: 246 This definition conforms to the discussion in section 20 of RFC 1944 on 247 bursty traffic. 248 Bidirectional and meshed streams of traffic are inherently bursty since 249 ports share their time between receiving and transmitting frames. External 250 sources offering bursty traffic for a given frame size and burst size must 251 adjust the inter-burst gap to achieve a specified rate of transmission. 253 Measurement units: 254 nanoseconds 255 microseconds 256 milliseconds 257 seconds 259 Issues: 261 See Also: 262 burst size (2.6) 264 2.8 Port load 266 Definition: 267 The number of frames per second that a switched port transmits and receives. 269 Discussion: 270 Port load can be expressed in a number of ways: bits per second, frames per 271 second with the frame size specified or as a percentage of the maximum frame 272 rate allowed by the medium for a given frame size. In the case of 273 bidirectional or meshed traffic port load is the sum of the frames 274 transmitted and received on a port per second. The load on an Ethernet port 275 which is transmitting and receiving a total of 7440 64-byte frames per 276 second equals 50% given that the maximum rate of transmission on an Ethernet 277 is 14880 64-byte frames per second. 278 There is room for varying the balance between incoming and outgoing traffic 279 when loading ports with bidirectional and meshed traffic. When offering 280 meshed traffic to a device the equal distribution of load over all ports 281 will help avoid unwanted or inadvertent port overloading in throughput tests. 283 Measurement units: 284 bits per second 285 frames per second with the frame size specified 286 as a percentage of the maximum frame rate allowed by the medium for a given 287 frame size. 289 Issues: 291 See Also: 292 bidirectional traffic (2.3) 293 meshed traffic (2.4) 294 overload (2.9) 296 2.9 Overload 298 Definition: 299 Loading a port or ports in excess of the maximum rate of transmission 300 allowed by the medium. 302 Discussion: 303 Overloading can serve to exercise input and output buffers, buffer 304 allocation algorithms and congestion control mechanisms. 305 Port overloading with unidirectional traffic requires a minimum of two input 306 and one output ports when the medium rate of all ports is the same. The 307 number of input ports will vary according to the media rates of the output 308 port or ports under test. 309 Port overloading with bidirectional and meshed traffic requires the sum of 310 the traffic transmitted and received on each port to exceed the maximum rate 311 of transmission allowed by the medium. To distribute port overload equally, 312 the external source of traffic must transmit at the same rate situated 313 between more than 50% and a 100% of the maximum medium rate to each of the 314 ports under test. 316 Measurement units: 317 N-octet frames per second 319 Issues: 321 See Also: 322 bidirectional traffic (2.3) 323 meshed traffic (2.4) 324 port load (2.8) 326 2.10 Intended rate 328 Definition: 329 The number of frames per second that an external source attempts to send to 330 a port of a device under test. 332 Discussion: 333 An external source may not transmit frames to a device under test at the 334 intended rate due to collisions on CSMA/CD links or the action of congestion 335 control mechanisms. This makes it useful to distinguish between intended 336 rate and the rate at which the source can be observed to send frames to a 337 device under test. 338 An external source should have sufficient internal resources to transmit 339 frames at the intended rate and in the case of Ethernet must implement the 340 truncated binary exponential back-off algorithm when executing bidirectional 341 and meshed performance tests to ensure that it is accessing the medium legally. 342 Frames which are not successfully transmitted by the external source of 343 traffic to the device under test MUST NOT be counted as transmitted frames 344 in performance benchmarks. 346 Measurement units: 347 bits per second 348 N-octets per second 349 (N-octets per second / media_maximum-octets per second) x 100 351 Issues: 352 token ring 354 See also: 355 offered rate (2.11) 357 2.11 Offered rate 359 Definition: 360 The number of frames per second that an external source can be observed to 361 send to a port of a device under test. 363 Discussion: 364 Offered rate may differ from intended rate due to collisions on half duplex 365 media or congestion control mechanisms. 366 The frame count on a port of a device under test may exceed the rate at 367 which an external device offers frames due to the presence of spanning tree 368 BPDUs (Bridge Protocol Data Units) on 802.1D-compliant switches or SNMP 369 frames. If such frames cannot be inhibited, they MUST be left out of frame 370 counts in performance benchmarks. 372 Measurement units: 373 bits per second 374 N-octets per second 375 (N-octets per second / media_maximum-octets per second) x 100 377 Issues: 378 token ring 380 See also: 381 intended rate (2.10) 383 2.12 Maximum load 385 Definition: 386 The load which results on a port when traffic is transmitted or addressed to 387 it at the maximum rate allowed by the medium. 389 Discussion: 390 Maximum port load may be less than the maximum rate allowed by the medium 391 when the offered rate of the external sources sending traffic to the device 392 or system under test is less than the intended rate. 394 Measurement units: 395 bits per second 396 frames per second with the frame size specified 397 as a percentage of the maximum frame rate allowed by the medium for a given 398 frame size. 400 Issues: 402 See Also: 403 bidirectional traffic (2.3) 404 meshed traffic (2.4) 405 port load (2.8) 406 intended rate (2.10) 407 offered rate (2.11) 408 forwarding rate (2.13) 409 forwarding rate at maximum load (2.14) 411 2.13 Forwarding rate 413 Definition: 414 The number of frames per second that a device is observed to deliver to the 415 correct output port in response to a known intended rate. 417 Discussion: 418 Forwarding rate does not take frame loss into account and must only be 419 sampled on the output side of the ports under test. It can be measured on 420 devices offered unidirectional, bidirectional or meshed traffic. 421 The forwarding rates of switching devices which exhibit no frame loss may be 422 reduced through the action of congestion control mechanisms. 424 Measurement units: 425 N-octet frames per second 427 Issues: 429 See Also: 430 port load (2.8) 431 intended rate (2.10) 432 offered rate (2.11) 433 forwarding rate at maximum load (2.14) 435 2.14 Forwarding rate at maximum load 437 Definition: 438 The number of frames per second that a device is observed to successfully 439 deliver to the correct output port at maximum load. 441 Discussion: 442 Forwarding rate at maximum load may be less than the maximum rate at which a 443 device might be observed to successfully forward traffic. 445 Measurement units: 446 N-octet frames per second 448 Issues: 450 See Also: 451 maximum load (2.12) 452 forwarding rate (2.13) 454 2.15 Flooding 456 Definition: 457 Frames received on ports which do not correspond to the destination MAC 458 address information. 460 Discussion: 461 When recording throughput statistics it is important to check that frames 462 have been forwarded to their proper destinations. Flooded frames MUST NOT be 463 counted as received frames. Both known and unknown unicast frames can be 464 flooded. 466 Measurement units: 467 N-octet valid frames per second 469 Issues: 470 Spanning tree BPDUs. 472 See Also: 474 2.16 Backpressure 476 Definition: 477 Techniques whereby switching devices avoid frame loss by impeding external 478 sources of traffic from transmitting frames to congested ports. 480 Discussion: 481 Some switches send jam signals, for example preamble bits, back to traffic 482 sources when their transmit and/or receive buffers start to overfill. 483 Switches implementing full duplex Ethernet links may use IEEE 802.3x Flow 484 Control for the same purpose. Such devices may incur no frame loss when 485 external sources attempt to offer traffic to congested or overloaded ports. 486 Jamming and flow control normally slow all traffic transmitted to congested 487 input ports including traffic intended for uncongested output ports. 489 Measurement units: 490 frame loss on congested port or ports 491 N--octet frames per second between the port applying backpressure and an 492 uncongested 493 destination port 495 Issues: 496 jamming not explicitly described in standards 498 See Also: 499 forward pressure (2.17) 501 2.17 Forward pressure 503 Definition: 504 An illegal technique whereby a device retransmits buffered frames without 505 waiting for the interval calculated by the normal operation of the back-off 506 algorithm. 508 Discussion: 509 Some switches illegally inhibit or abort the truncated binary exponential 510 backoff algorithm and force access to the medium to avoid frame loss. 511 The backoff algorithm should be fair whether the device under test is in a 512 congested or an uncongested state. 514 Measurement units: 515 intervals in microseconds between transmission retries during 16 successive 516 collisions. 518 Issues: 519 truncated binary exponential backoff algorithm 521 See also: 522 backpressure (2.16) 524 2.18 Head of line blocking 526 Definition: 527 Frame loss observed on an uncongested output port whenever frames are 528 received from an input port which is also attempting to forward frames to a 529 congested output port. 531 Discussion: 532 It is important to verify that a switch does not slow transmission or drop 533 frames on ports which are not congested whenever overloading on one of its 534 other ports occurs. 536 Measurement units: 537 frame loss recorded on an uncongested port when receiving frames from a port 538 which is also forwarding frames to a congested port. 540 Issues: 541 input buffers 543 See Also: 544 unidirectional traffic (2.2) 546 2.19 Address handling 548 Definition: 549 The number of MAC addresses per n ports, per module or per device which a 550 switch can cache and successfully forward frames to without flooding or 551 dropping frames. 553 Discussion: 555 Users building networks will want to know how many nodes they can connect to 556 a switch. This makes it necessary to verify the number of MAC addresses that 557 can be assigned per n ports, per module and per chassis before a switch 558 begins flooding frames. 560 Measurement units: 561 number of MAC addresses 563 Issues: 565 See Also: 566 Address learning rate (2.20) 568 2.20 Address learning rate 570 Definition: 571 The maximum rate at which a switch can learn new MAC addresses before 572 starting to flood or drop frames. 574 Discussion: 575 Users may want to know how long it takes a switch to build its address 576 tables. This information is useful to have when considering how long it 577 takes a network to come up when many users log on in the morning or after a 578 network crash. 580 Measurement units: 581 frames per second with each successive frame sent to the switch containing a 582 different source address. 584 Issues: 586 See Also: address handling (2.19) 588 2.21 Illegal frames 590 Definition: 591 Frames which are over-sized, under-sized, misaligned or with an errored 592 Frame Check Sequence. 594 Discussion: 595 Switches, unlike IEEE 802.1d compliant brdiges, do not necessarily filter 596 all types of illegal frames. Some switches, for example, which do not store 597 frames before forwarding them to their destination ports may not filter 598 over-sized frames (jabbers) or verify the validity of the Frame Check 599 Sequence field. Other illegal frames are under-sized frames (runts) and 600 misaligned frames. 602 Measurement units: 603 N-octet frames filtered or not filtered 605 Issues: 607 See Also: 609 2.22 Maximum broadcast forwarding rate 611 Definition: 612 The number of broadcast frames per second that a switch can deliver to all 613 ports at maximum load. 615 Discussion: 616 There is no standard forwarding mechanism used by switches to forward 617 broadcast frames. It is useful to determine the broadcast forwarding rate 618 for frames switched between ports on the same card, ports on different cards 619 in the same chassis and ports on different chassis linked together over 620 backbone connections. 622 Measurement units: 623 N-octet frames per second 625 Issues: 627 See Also: 628 broadcast latency (2.23) 630 2.23 Broadcast latency 632 Definition: 633 The time required by a switch to forward a broadcast frame to each port 634 located within a broadcast domain. 636 Discussion: 637 Since there is no standard way for switches to process broadcast frames, 638 broadcast latency may not be the same on all receiving ports of a switching 639 device. The latency measurements SHOULD be bit oriented as described in 3.8 640 of RFC 1242. It is useful to determine broadcast latency for frames 641 forwarded between ports on the same card, ports on different cards in the 642 same chassis and ports on different chassis linked together over backbone 643 connections. 645 Measurement units: 646 nanoseconds 647 microseconds 648 milliseconds 649 seconds 651 Issues: 653 See Also: 654 broadcast forwarding rate (2.20) 656 3. Index of definitions 658 2.1 Reminder of RFC 1242 definition format 659 2.2 Unidirectional traffic 660 2.3 Bidirectional traffic 661 2.4 Meshed traffic 662 2.5 Burst 663 2.6 Burst size 664 2.7 Inter-burst gap (IBG) 665 2.8 Port load 666 2.9 Overload 667 2.10 Intended rate 668 2.11 Offered rate 669 2.12 Maximum load 670 2.13 Forwarding rate 671 2.14 Forwarding rate at maximum load 672 2.15 Flooding 673 2.16 Backpressure 674 2.17 Forward pressure 675 2.18 Head of line blocking 676 2.19 Address handling 677 2.20 Address learning rate 678 2.21 Illegal frames 679 2.22 Maximum broadcast forwarding rate 680 2.23 Broadcast latency 682 4. Acknowledgments 684 In order of appearance Jean-Christophe Bestaux of European Network 685 Laboratories, Ajay Shah of Wandel & Goltermann, Henry Hamon of Netcom 686 Systems, Stan Kopek of Digital Equipment Corporation, Kevin Dubray of Bay 687 Networks, and Doug Ruby of Prominet were all instrumental in getting this 688 draft done. 689 A special thanks goes to the IETF BenchMark WorkGroup for the many 690 suggestions it collectively made to help shape this draft. 692 The editor 693 Bob Mandeville 695 5. Editor's Address 697 Robert Mandeville 698 ENL (European Network Laboratories) 699 35, rue Beaubourg 700 75003 Paris 701 France 702 mobile phone: +33 6 07 47 67 10 703 phone: +33 1 39 44 12 05 704 fax: + 33 1 39 44 12 06 705 email: bob.mandeville@eunet.fr