idnits 2.17.1 draft-ietf-bmwg-lanswitch-03.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-20) 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 727 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 311: '...evice under test MUST NOT be counted a...' RFC 2119 keyword, line 316: '... inhibited, they MUST be left out of f...' RFC 2119 keyword, line 574: '...stinations. Flooded frames MUST NOT be...' RFC 2119 keyword, line 637: '...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 (Feb 1997) is 9926 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. -------------------------------------------------------------------------------- 1 Network Working Group R. Mandeville 2 INTERNET-DRAFT European Network Laboratories 3 Expiration Date: Jul 1997 Feb 1997 5 Benchmarking Terminology for LAN Switching Devices 7 < draft-ietf-bmwg-lanswitch-03.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, the interval between bursts as well as the 184 distribution of load between incoming and outgoing traffic. The terms burst, 185 burst size and inter-burst gap are defined in sections 2.5, 2.6 and 2.7 186 below. Load and balanced load are defined in sections 2.8 and 2.10 below. 188 Measurement units: 189 n/a 191 Issues: 192 half duplex / full duplex 194 See Also: 195 unidirectional traffic (2.2) 196 bidirectional traffic (2.3) 197 burst (2.5) 198 burst size (2.6) 199 inter-burst gap (2.7) 200 load (2.8) 201 balanced load (2.10) 203 2.5 Burst 205 Definition: 206 A sequence of frames transmitted with the minimum inter-frame gap allowed by 207 the medium. 209 Discussion: 210 This definition follows from discussions in section 3.16 of RFC 1242 and 211 section 21 of RFC 1944 which describes cases where it is useful to consider 212 isolated frames as single frame bursts. 214 Measurement units: 215 n/a 217 Issues: 219 See Also: 220 burst size (2.6) 222 2.6 Burst size 224 Definition: 225 The number of frames in a burst. 227 Discussion: 228 Burst size can range from one to infinity. In unidirectional streams there 229 is no theoretical limit to burst length. When traffic is bidirectional or 230 meshed bursts on half duplex media are finite since ports interrupt 231 transmission intermittently to receive frames. 232 On real networks burst size will normally increase with window size. This 233 makes it desirable to test devices with small as well as large burst sizes. 235 Measurement units: 236 number of N-octet frames 238 Issues: 240 See Also: 241 burst (2.5) 243 2.7 Inter-burst gap (IBG) 245 Definition: 246 The interval between two bursts. 248 Discussion: 249 This definition conforms to the discussion in section 20 of RFC 1944 on 250 bursty traffic. 251 Bidirectional and meshed streams of traffic are inherently bursty since 252 ports share their time between receiving and transmitting frames. External 253 sources offering bursty traffic for a given frame size and burst size must 254 adjust the inter-burst gap to achieve a specified rate of transmission. 256 Measurement units: 257 nanoseconds 258 microseconds 259 milliseconds 260 seconds 262 Issues: 264 See Also: 265 burst size (2.6) 267 2.8 Port load 269 Definition: 270 The total number of frames per second that a switched port can be observed 271 to transmit and receive in response to an offered load. 273 Discussion: 274 Port load can be expressed in a number of ways: bits per second, frames per 275 second with the frame size specified or as a percentage of the maximum frame 276 rate allowed by the medium for a given frame size. In the case of 277 bidirectional or meshed traffic port load is the sum of the frames 278 transmitted and received on a port per second. The load on an Ethernet port 279 which is transmitting and receiving a total of 7440 64-byte frames per 280 second equals 50% given that the maximum rate of transmission on an Ethernet 281 is 14880 64-byte frames per second. 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 offered load (2.9) 295 overload (2.12) 297 2.9 Offered load 298 The total number of frames per second that an external source attempts to 299 transmit or address to a port of a device under test. 301 Discussion: 302 Collisions on CSMA/CD links or the action of congestion control mechanisms 303 can reduce the rate of transmission of external sources sending or 304 addressing traffic to a port under test. This makes it useful to distinguish 305 port load, the load that can be observed on a port, from the load that an 306 external source offers, that is, attempts to send or address to the port. 307 In the case of Ethernet an external source of traffic must implement the 308 truncated binary exponential back-off algorithm when executing bidirectional 309 and meshed performance tests to ensure that it is accessing the medium legally. 310 Frames which are not successfully transmitted by an external source of 311 traffic to the device under test MUST NOT be counted as transmitted frames 312 in performance benchmarks. 313 The frame count on a port of a device under test may exceed the rate at 314 which an external device offers frames due to the presence of spanning tree 315 BPDUs (Bridge Protocol Data Units) on 802.1D-compliant switches or SNMP 316 frames. If such frames cannot be inhibited, they MUST be left out of frame 317 counts in performance benchmarks. 319 Measurement units: 320 bits per second 321 N-octets per second 322 (N-octets per second / media_maximum-octets per second) x 100 324 Issues: 325 token ring 327 See also: 328 port load (2.8) 330 2.10 Balanced load 332 Definition: 333 Port load when the total number of frames per second that an external source 334 attempts to transmit to a port of a device under test equals the total 335 number of frames per second that the external source attempts to address to 336 the same port. 338 Discussion: 339 There is room for varying the balance between incoming and outgoing traffic 340 when loading ports with bidirectional and meshed traffic. A balanced load on 341 all ports will help avoid unwanted or inadvertent port overloading in 342 throughput tests. 344 Measurement units: 345 bits per second 346 N-octets per second 347 (N-octets per second / media_maximum-octets per second) x 100 349 Issues: 351 See also: 352 port load (2.8) 353 offered load (2.9) 355 2.11 Maximum load 357 Definition: 358 Port load when the offered load equals the maximum rate allowed by the medium. 360 Discussion: 361 Maximum load in balanced bidirectional and meshed traffic tests requires the 362 number of frames per second an external source attempts to transmit to a 363 port and the number of frames per second the source attempts to address to 364 the same port to be equally divided and total to the maximum rate of 365 transmission allowed by the medium. 367 Measurement units: 368 bits per second 369 frames per second with the frame size specified 370 as a percentage of the maximum frame rate allowed by the medium for a given 371 frame size. 373 Issues: 375 See Also: 376 bidirectional traffic (2.3) 377 meshed traffic (2.4) 378 port load (2.8) 379 offered load (2.9) 381 2.12 Overload 383 Definition: 384 Loading a port or ports in excess of the maximum rate of transmission 385 allowed by the medium. 387 Discussion: 388 Overloading can serve to exercise input and output buffers, buffer 389 allocation algorithms and congestion control mechanisms. 390 Port overloading with unidirectional traffic requires a minimum of two input 391 and one output ports when the medium rate of all ports is the same. The 392 number of input ports will vary according to the media rates of the output 393 port or ports under test. 394 Port overloading with bidirectional and meshed traffic requires the offered 395 load on each port to exceed the maximum rate of transmission allowed by the 396 medium. 398 Measurement units: 399 N-octet frames per second 401 Issues: 403 See Also: 404 bidirectional traffic (2.3) 405 meshed traffic (2.4) 406 port load (2.8) 408 2.13 Forwarding rate 410 Definition: 411 The number of frames per second that a device can be observed to deliver to 412 the correct output port in response to an offered load. 414 Discussion: 415 Forwarding rate does not take frame loss into account and must only be 416 sampled on the output side of the ports under test. It can be measured on 417 devices offered unidirectional, bidirectional or meshed traffic with 418 balanced loads to help avoid unwanted or inadvertent port overloading in 419 throughput tests. 420 The forwarding rates of switching devices which exhibit no frame loss may 421 decrease when congestion control mechanisms are active. 423 Measurement units: 424 N-octet frames per second 426 Issues: 428 See Also: 429 port load (2.8) 430 offered load (2.9) 431 forwarding rate at maximum load (2.14) 433 2.14 Forwarding rate at maximum load 435 Definition: 436 Forwarding rate when the offered load equals the maximum rate allowed by the 437 medium. 439 Discussion: 440 Forwarding rate at maximum load may be less than the maximum rate at which a 441 device can be observed to successfully forward traffic. 443 Measurement units: 444 N-octet frames per second 446 Issues: 448 See Also: 449 maximum load (2.11) 450 forwarding rate (2.13) 452 2.15 Backpressure 454 Definition: 455 Techniques whereby switching devices attempt to avoid frame loss by impeding 456 external sources of traffic from transmitting frames to congested ports. 458 Discussion: 459 Some switches send jam signals, for example preamble bits, back to traffic 460 sources when their transmit and/or receive buffers start to overfill. 461 Switches implementing full duplex Ethernet links may use IEEE 802.3x Flow 462 Control for the same purpose. Such devices may incur no frame loss when 463 external sources attempt to offer traffic to congested or overloaded ports. 464 Jamming and flow control normally slow all traffic transmitted to congested 465 input ports including traffic intended for uncongested output ports. 467 Measurement units: 468 frame loss on congested port or ports 469 N--octet frames per second between the port applying backpressure and an 470 uncongested 471 destination port 473 Issues: 474 jamming not explicitly described in standards 476 See Also: 477 forward pressure (2.16) 479 2.16 Forward pressure 481 Definition: 482 An illegal technique whereby a device retransmits buffered frames without 483 waiting for the interval calculated by the normal operation of the back-off 484 algorithm. 486 Discussion: 487 Some switches illegally inhibit or abort the truncated binary exponential 488 backoff algorithm and force access to the medium to avoid frame loss. 489 The backoff algorithm should be fair whether the device under test is in a 490 congested or an uncongested state. 492 Measurement units: 493 intervals in microseconds between transmission retries during 16 successive 494 collisions. 496 Issues: 497 truncated binary exponential backoff algorithm 499 See also: 500 backpressure (2.15) 502 2.17 Head of line blocking 504 Definition: 505 Frame loss observed on an uncongested output port whenever frames are 506 received from an input port which is also attempting to forward frames to a 507 congested output port. 509 Discussion: 510 It is important to verify that a switch does not slow transmission or drop 511 frames on ports which are not congested whenever overloading on one of its 512 other ports occurs. 514 Measurement units: 515 frame loss recorded on an uncongested port when receiving frames from a port 516 which is also forwarding frames to a congested port. 518 Issues: 519 input buffers 521 See Also: 522 unidirectional traffic (2.2) 524 2.18 Address handling 526 Definition: 527 The number of MAC addresses per n ports, per module or per device which a 528 switch can cache and successfully forward frames to without flooding or 529 dropping frames. 531 Discussion: 533 Users building networks will want to know how many nodes they can connect to 534 a switch. This makes it necessary to verify the number of MAC addresses that 535 can be assigned per n ports, per module and per chassis before a switch 536 begins flooding frames. 538 Measurement units: 539 number of MAC addresses 541 Issues: 543 See Also: 544 Address learning rate (2.19) 546 2.19 Address learning rate 548 Definition: 549 The maximum rate at which a switch can learn new MAC addresses before 550 starting to flood or drop frames. 552 Discussion: 553 Users may want to know how long it takes a switch to build its address 554 tables. This information is useful to have when considering how long it 555 takes a network to come up when many users log on in the morning or after a 556 network crash. 558 Measurement units: 559 frames per second with each successive frame sent to the switch containing a 560 different source address. 562 Issues: 564 See Also: address handling (2.18) 566 2.20 Flooding 568 Definition: 569 Frames received on ports which do not correspond to the destination MAC 570 address information. 572 Discussion: 573 When recording throughput statistics it is important to check that frames 574 have been forwarded to their proper destinations. Flooded frames MUST NOT be 575 counted as received frames. Both known and unknown unicast frames can be 576 flooded. 578 Measurement units: 579 N-octet valid frames per second 581 Issues: 582 Spanning tree BPDUs. 584 See Also: 586 2.21 Illegal frames 588 Definition: 589 Frames which are over-sized, under-sized, misaligned or with an errored 590 Frame Check Sequence. 592 Discussion: 593 Switches, unlike IEEE 802.1d compliant brdiges, do not necessarily filter 594 all types of illegal frames. Some switches, for example, which do not store 595 frames before forwarding them to their destination ports may not filter 596 over-sized frames (jabbers) or verify the validity of the Frame Check 597 Sequence field. Other illegal frames are under-sized frames (runts) and 598 misaligned frames. 600 Measurement units: 601 N-octet frames filtered or not filtered 603 Issues: 605 See Also: 607 2.22 Maximum broadcast forwarding rate 609 Definition: 610 The number of broadcast frames per second that a switch can be observed to 611 deliver to all ports at maximum load. 613 Discussion: 614 There is no standard forwarding mechanism used by switches to forward 615 broadcast frames. It is useful to determine the broadcast forwarding rate 616 for frames switched between ports on the same card, ports on different cards 617 in the same chassis and ports on different chassis linked together over 618 backbone connections. 620 Measurement units: 621 N-octet frames per second 623 Issues: 625 See Also: 626 broadcast latency (2.23) 628 2.23 Broadcast latency 630 Definition: 631 The time required by a switch to forward a broadcast frame to each port 632 located within a broadcast domain. 634 Discussion: 635 Since there is no standard way for switches to process broadcast frames, 636 broadcast latency may not be the same on all receiving ports of a switching 637 device. The latency measurements SHOULD be bit oriented as described in 3.8 638 of RFC 1242. It is useful to determine broadcast latency for frames 639 forwarded between ports on the same card, ports on different cards in the 640 same chassis and ports on different chassis linked together over backbone 641 connections. 643 Measurement units: 644 nanoseconds 645 microseconds 646 milliseconds 647 seconds 649 Issues: 651 See Also: 652 broadcast forwarding rate (2.20) 654 3. Index of definitions 656 2.1 Reminder of RFC 1242 definition format 658 Traffic patterns 659 2.2 Unidirectional traffic 660 2.3 Bidirectional traffic 661 2.4 Meshed traffic 663 Bursts 664 2.5 Burst 665 2.6 Burst size 666 2.7 Inter-burst gap (IBG) 668 Port loads 669 2.8 Port load 670 2.9 Offered load 671 2.10 Balanced load 672 2.11 Maximum load 673 2.12 Overload 675 Forwarding rates 676 2.13 Forwarding rate 677 2.14 Forwarding rate at maximum load 679 Congestion control 680 2.15 Backpressure 681 2.16 Forward pressure 682 2.17 Head of line blocking 684 Address handling 685 2.18 Address handling 686 2.19 Address learning rate 687 2.20 Flooding 689 Filtering 690 2.21 Illegal frames 692 Broadcasts 693 2.22 Maximum broadcast forwarding rate 694 2.23 Broadcast latency 696 4. Acknowledgments 698 In order of appearance Jean-Christophe Bestaux of European Network 699 Laboratories, Ajay Shah of Wandel & Goltermann, Henry Hamon of Netcom 700 Systems, Stan Kopek of Digital Equipment Corporation, Kevin Dubray of Bay 701 Networks, and Doug Ruby of Prominet were all instrumental in getting this 702 draft done. 703 A special thanks goes to the IETF BenchMark WorkGroup for the many 704 suggestions it collectively made to help shape this draft. 706 The editor 707 Bob Mandeville 709 5. Editor's Address 711 Robert Mandeville, ENL 712 European Network Laboratories 713 6 Parc Ariane, le Mercure 714 Blvd des Chenes 715 78284 Guyancourt 716 France 717 email: bob.mandeville@eunet.fr 718 Phone/voice mail: +33 1 39 44 12 05 719 Fax: +33 1 39 44 12 06 720 Mobile phone: +33 6 07 47 67 10