idnits 2.17.1 draft-ietf-bmwg-reset-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC2544, updated by this document, for RFC5378 checks: 1999-03-01) -- 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 (October 10, 2010) is 4947 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-23) exists of draft-ietf-bmwg-igp-dataplane-conv-meth-21 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Benchmarking Methodology WG Rajiv Asati 2 Internet Draft Cisco 3 Updates: 2544 (if approved) Carlos Pignataro 4 Intended status: Informational Cisco 5 Expires: April 2011 Fernando Calabria 6 Cisco 7 Cesar Olvera 8 Consulintel 10 October 10, 2010 12 Device Reset Characterization 13 draft-ietf-bmwg-reset-02 15 Abstract 17 An operational forwarding device may need to be re-started 18 (automatically or manually) for a variety of reasons, an event that 19 we call a "reset" in this document. Since there may be an 20 interruption in the forwarding operation during a reset, it is 21 useful to know how long a device takes to resume the forwarding 22 operation. 24 This document specifies a methodology for characterizing reset (and 25 recovery time) during benchmarking of forwarding devices, and 26 provides clarity and consistency in reset test procedures beyond 27 what's specified in RFC2544. It therefore updates RFC2544. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF), its areas, and its working groups. Note that 36 other groups may also distribute working documents as Internet- 37 Drafts. 39 Internet-Drafts are draft documents valid for a maximum of six 40 months and may be updated, replaced, or obsoleted by other documents 41 at any time. It is inappropriate to use Internet-Drafts as 42 reference material or to cite them other than as "work in progress." 43 The list of current Internet-Drafts can be accessed at 44 http://www.ietf.org/ietf/1id-abstracts.txt 46 The list of Internet-Draft Shadow Directories can be accessed at 47 http://www.ietf.org/shadow.html 49 This Internet-Draft will expire on April 10, 2011. 51 Copyright Notice 53 Copyright (c) 2010 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with 61 respect to this document. Code Components extracted from this 62 document must include Simplified BSD License text as described in 63 Section 4.e of the Trust Legal Provisions and are provided without 64 warranty as described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction...................................................4 69 1.1. Scope.....................................................4 70 1.2. Recovery Time Measurement Methods.........................4 71 1.3. Reporting Format..........................................5 72 2. Key Words to Reflect Requirements..............................7 73 3. Test Requirements..............................................7 74 4. Reset Test.....................................................8 75 4.1. Hardware Reset............................................8 76 4.1.1. Routing Processor (RP) / Routing Engine reset........9 77 4.1.1.1. RP Reset for a single-RP device (REQUIRED)......9 78 4.1.1.2. RP Switchover for a multiple-RP device (OPTIONAL) 79 ........................................................10 80 4.1.2. Line Card (LC) Removal and Insertion (REQUIRED).....11 81 4.2. Software Reset...........................................12 82 4.2.1. Operating System (OS) reset (REQUIRED)..............12 83 4.2.2. Process reset (OPTIONAL)............................13 84 4.3. Power interruption.......................................14 85 4.3.1. Power Interruption (REQUIRED).......................14 86 5. Security Considerations.......................................15 87 6. IANA Considerations...........................................16 88 7. Acknowledgments...............................................16 89 8. References....................................................17 90 8.1. Normative References.....................................17 91 8.2. Informative References...................................17 92 Authors' Addresses...............................................18 94 1. Introduction 96 An operational forwarding device (or one of its components) may need 97 to be re-started for a variety of reasons, an event that we call a 98 "reset" in this draft. Since there may be an interruption in the 99 forwarding operation during a reset, it is useful to know how long a 100 device takes to resume the forwarding operation. In other words, it 101 is desired to know how long the recovery time after the reset is. 103 However, the answer to this question is no longer simple and 104 straight-forward as the modern forwarding devices employ many 105 hardware advancements (distributed forwarding, etc.) and software 106 advancements (graceful restart, etc.) that influence the recovery 107 time after the reset. 109 1.1. Scope 111 This document specifies a methodology for characterizing reset (and 112 recovery time) during benchmarking of forwarding devices, and 113 provides clarity and consistency in reset procedures beyond what is 114 specified in [RFC2544]. Software upgrades incur additional 115 benchmarking complexities and are outside the scope of this 116 document. 118 These procedures may be used by other benchmarking documents such as 119 [RFC2544], [RFC5180], [RFC5695], etc., and is expected that other 120 protocol-specific benchmarking documents would reference this 121 document for reset recovery time characterization. 123 This document updates Section 26.6 of [RFC2544]. 125 This document focuses on only the reset criterion of benchmarking, 126 and presumes that it would be beneficial to [RFC5180], [RFC5695], 127 and other BMWG benchmarking efforts. 129 1.2. Recovery Time Measurement Methods 131 The 'recovery time' is the time during which the traffic forwarding 132 is temporarily interrupted following a reset event. Strictly 133 speaking, this is the time over which one or more frames are lost. 134 This definition is similar to that of 'Loss of connectivity period' 135 defined in [IGPConv] section 4. 137 There are two accepted methods to measure the 'recovery time': 139 1. Frame-Loss Method - This method requires testtool capability to 140 monitor the number of lost frames. In this method, the offered 141 stream rate (frames per second) must be known. The recovery 142 time is calculated per the below equation: 144 Recovery_time = Frames_lost (packets) / Offered_rate 145 (packets per second) 147 2. Time-Stamp Method - This method requires testtool capability to 148 timestamp each frame. In this method, the testtool timestamps 149 each transmitted frame and monitors the received frame's 150 timestamp. During the test, the test tool would record the 151 timestamp (Timestamp A) of the frame that was last received 152 prior to the reset interruption and the timestamp (Timestamp 153 B) of the first frame after the interruption stopped. The 154 difference between Timestamp B and Timestamp A is the recovery 155 time. 157 The tester/operator MAY use either method for recovery time 158 measurement depending on the testtool capability. However, the 159 Frame-loss method SHOULD be used if the test tool is capable of (a) 160 counting the number of lost frames per stream, and (b) transmitting 161 test frame despite the physical link status, whereas Time-stamp 162 method SHOULD be used if the test tool is capable of (a) time- 163 stamping each frame, (b) monitoring received frame's timestamp, and 164 (c) transmitting frames only if the physical link status is UP. 166 1.3. Reporting Format 168 All reset results are reported in a simple statement including the 169 frame loss and recovery times. 171 For each test case, it is RECOMMENDED that the following parameters 172 be reported in these units: 174 Parameter Units or Examples 176 Throughput Frames per second and bits per 177 second 179 Loss (average) Frames 181 Recovery Time (average) Milliseconds 183 Number of trials Integer count 185 Protocol IPv4, IPv6, MPLS, etc. 187 Frame Size Octets 189 Port Media Ethernet, GigE (Gigabit Ethernet), 190 POS (Packet over SONET), etc. 192 Port Speed 10 Gbps, 1 Gbps, 100 Mbps, etc. 194 Interface Encap. Ethernet, Ethernet VLAN, 195 PPP, HDLC, etc. 197 For mixed protocol environments, frames SHOULD be distributed 198 between all the different protocols. The distribution MAY 199 approximate the network conditions of deployment. IN all cases the 200 details of the mixed protocol distribution MUST be included in the 201 reporting. 203 Additionally, the DUT and test bed provisioning, configuration, and 204 deployed methodologies that may influence the overall recovery time 205 MUST be listed. (Refer to the additional factors listed in Section 206 3). 208 The reporting of results MUST regard repeatability considerations 209 from Section 4 of [RFC2544]. It is RECOMMENDED to perform multiple 210 trials and report average results. 212 2. Key Words to Reflect Requirements 214 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 215 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 216 document are to be interpreted as described in BCP 14, RFC 2119 217 [RFC2119]. RFC 2119 defines the use of these key words to help make 218 the intent of standards track documents as clear as possible. While 219 this document uses these keywords, this document is not a standards 220 track document. 222 3. Test Requirements 224 In order to provide consistent and fairness while benchmarking a set 225 of different DUTs, the Network tester / Operator MUST (a) use 226 identical control and data plane information during testing, (b) 227 document & report any factors that may influence the overall time 228 after reset / convergence. 230 Some of these factors include: 232 1. Type of reset - Hardware (line-card crash, etc.) vs. Software 233 (protocol reset, process crash, etc.) or even complete power 234 failures 236 2. Manual vs. Automatic reset 238 3. Scheduled vs. non-scheduled reset 240 4. Local vs. Remote reset 242 5. Scale - Number of line cards present vs. in-use 244 6. Scale - Number of physical and logical interfaces 246 7. Scale - Number of routing protocol instances 248 8. Scale - Number of Routing Table entries 250 9. Scale - Number of Route Processors available 252 10. Performance - Redundancy strategy deployed for route 253 processors and line cards 255 11. Performance - Interface encapsulation as well as achievable 256 Throughput [RFC2544] 258 12. Any other internal or external factor that may influence 259 recovery time after a hardware or software reset 261 The recovery time is one of the key characterization results 262 reported after each test run. While the recovery time during a reset 263 test event may be zero, there may still be effects on traffic, such 264 as transient delay variation or increased latency. However, that is 265 not covered and deemed outside the scope of this document. In this 266 case, only "no loss" is reported. 268 4. Reset Test 270 This section contains the description of the tests that are related 271 to the characterization of the time needed for DUTs (Device Under 272 Test) / SUTs (System Under Test) to recover from a reset. There are 273 three types of reset considered in this document: 275 1. Hardware resets 277 2. Software resets 279 3. Power interruption 281 Different types of reset have potentially different impact on the 282 forwarding behavior of the device. As an example, a software reset 283 (of a routing process) might not result in forwarding interruption, 284 whereas a hardware reset (of a line card) most likely will. 286 Section 4.1 describes various hardware resets, whereas Section 4.2 287 describes various software resets. Additionally, Section 4.3 288 describes power interruption tests. These sections define and 289 characterize these resets. 291 Additionally, since device specific implementations may vary for 292 hardware and software type resets, it is desirable to classify each 293 test case as "REQUIRED" or "OPTIONAL". 295 4.1. Hardware Reset 297 A test designed to characterize the time it takes a DUT to recover 298 from the hardware reset. 300 A "hardware reset" generally involves the re-initialization of one 301 or more physical components in the DUT, but not the entire DUT. 303 A hardware reset is executed by the operator for example by physical 304 removal of a physical component, by pressing on a "reset" button for 305 the component, or could even be triggered from the command line 306 interface. 308 For routers that do not contain separate Routing Processor and Line 309 Card modules, the hardware reset tests are not performed since they 310 are not relevant; instead, the power interruption tests MUST be 311 performed (see Section 4.3) in these cases. 313 4.1.1. Routing Processor (RP) / Routing Engine reset 315 The Routing Processor (RP) is the DUT module that is primarily 316 concerned with Control Plane functions. 318 4.1.1.1. RP Reset for a single-RP device (REQUIRED) 320 Objective 322 To characterize time needed for a DUT to recover from a Route 323 processor hardware reset in a single RP environment. 325 Procedure 327 First, ensure that the RP is in a permanent state to which it will 328 return to after the reset, by performing some or all of the 329 following operational tasks: save the current DUT configuration, 330 specify boot parameters, ensure the appropriate software files are 331 available, or perform additional Operating System or hardware 332 related task. 334 Second, ensure that the DUT is able to forward the traffic for at 335 least 15 seconds before any test activities are performed. The 336 traffic should use the minimum frame size possible on the media 337 used in the testing and rate should be sufficient for the DUT to 338 attain the maximum forwarding throughput. This enables a finer 339 granularity in the recovery time measurement. 341 Third, perform the Route Processor (RP) hardware reset at this 342 point. This entails for example physically removing the RP to 343 later re-insert it, or triggering a hardware reset by other means 344 (e.g., command line interface, physical switch, etc.) 345 Finally, the characterization is completed by recording the frame 346 loss (as reported by the test tool) and calculating the recovery 347 time (by following the section 1.2). 349 Reporting format 351 The reporting format is defined in Section 1.3. 353 4.1.1.2. RP Switchover for a multiple-RP device (OPTIONAL) 355 Objective 357 To characterize time needed for "secondary" Route Processor 358 (sometimes referred to as "backup" RP) of a DUT to become active 359 after a "primary" (or "active") Route Processor hardware reset. 360 This process is often referred to as "RP Switchover". The 361 characterization in this test should be done for the default DUT 362 behavior as well as a DUT's non-default configuration that 363 minimizes frame loss, if exists. 365 Procedure 367 This test characterizes "RP Switchover". Many implementations 368 allow for optimized switchover capabilities that minimize the 369 downtime during the actual switchover. This test consists of two 370 sub-cases from a switchover characteristics standpoint: First, a 371 default behavior (with no switchover-specific configurations); and 372 potentially second, a non-default behavior with switchover 373 configuration to minimize frame loss. Therefore, the procedures 374 hereby described are executed twice, and reported separately. 376 First, ensure that the RPs are in a permanent state such that the 377 secondary will be activated to the same state as the active is, by 378 performing some or all of the following operational tasks: save 379 the current DUT configuration, specify boot parameters, ensure the 380 appropriate software files are available, or perform additional 381 Operating System or hardware related task. 383 Second, ensure that the DUT is able to forward the traffic for at 384 least 15 seconds before any test activities are performed. The 385 traffic should use the minimum frame size possible on the media 386 used in the testing and rate should be sufficient for the DUT to 387 attain the maximum forwarding throughput. This enables a finer 388 granularity in the recovery time measurement. 390 Third, perform the primary Route Processor (RP) hardware reset at 391 this point. This entails for example physically removing the RP, 392 or triggering a hardware reset by other means (e.g., command line 393 interface, physical switch, etc.) It is up to the Operator to 394 decide if the primary RP needs to be re-inserted after a grace 395 period or not. 397 Finally, the characterization is completed by recording the frame 398 loss (as reported by the test tool) and calculating the recovery 399 time (by following the section 1.2). 401 Reporting format 403 The reset results are potentially reported twice, one for the 404 default switchover behavior (i.e., the DUT without any switchover- 405 specific enhanced configuration) and the other for the switchover- 406 specific behavior if it exists (i.e., the DUT configured for 407 optimized switchover capabilities that minimize the downtime 408 during the actual switchover). 410 The reporting format is defined in Section 1.3, and also includes 411 any specific redundancy scheme in place. 413 4.1.2. Line Card (LC) Removal and Insertion (REQUIRED) 415 The Line Card (LC) is the DUT component that is responsible with 416 packet forwarding. 418 Objective 420 To characterize time needed for a DUT to recover from a Line Card 421 removal and insertion event. 423 Procedure 425 For this test, the Line Card that is being hardware-reset MUST be 426 on the forwarding path and all destinations MUST be directly 427 connected. 429 First, complete some or all of the following operational tasks: 430 save the current DUT configuration, specify boot parameters, 431 ensure the appropriate software files are available, or perform 432 additional Operating System or hardware related task. 434 Second, ensure that the DUT is able to forward the traffic for at 435 least 15 seconds before any test activities are performed. The 436 traffic should use the minimum frame size possible on the media 437 used in the testing and rate should be sufficient for the DUT to 438 attain the maximum forwarding throughput. This enables a finer 439 granularity in the recovery time measurement. 441 Third, perform the Line Card (LC) hardware reset at this point. 442 This entails for example physically removing the LC to later re- 443 insert it, or triggering a hardware reset by other means (e.g., 444 command line interface (CLI), physical switch, etc.). However, 445 most accurate results will be obtained using the CLI or a physical 446 switch, and therefore these are RECOMMENDED. Otherwise, the time 447 spent trying to physically seat the LC will get mixed into the 448 results. 450 Finally, the characterization is completed by recording the frame 451 loss (as reported by the test tool) and calculating the recovery 452 time (by following the section 1.2). 454 Reporting Format 456 The reporting format is defined in Section 1.3. 458 4.2. Software Reset 460 To characterize time needed for a DUT to recover from the software 461 reset. 463 In contrast to a "hardware reset", a "software reset" involves only 464 the re-initialization of the execution, data structures, and partial 465 state within the software running on the DUT module(s). 467 A software reset is initiated for example from the DUT's Command 468 Line Interface (CLI). 470 4.2.1. Operating System (OS) reset (REQUIRED) 472 Objective 474 To characterize time needed for a DUT to recover from an Operating 475 System (OS) software reset. 477 Procedure 478 First, complete some or all of the following operational tasks: 479 save the current DUT configuration, specify software boot 480 parameters, ensure the appropriate software files are available, 481 or perform additional Operating System task. 483 Second, ensure that the DUT is able to forward the traffic for at 484 least 15 seconds before any test activities are performed. The 485 traffic should use the minimum frame size possible on the media 486 used in the testing and rate should be sufficient for the DUT to 487 attain the maximum forwarding throughput. This enables a finer 488 granularity in the recovery time measurement. 490 Third, trigger an Operating System re-initialization in the DUT, 491 by operational means such as use of the DUT's Command Line 492 Interface (CLI) or other management interface. 494 Finally, the characterization is completed by recording the frame 495 loss (as reported by the test tool) and calculating the recovery 496 time (by following the section 1.2). 498 Reporting format 500 The reporting format is defined in Section 1.3. 502 4.2.2. Process reset (OPTIONAL) 504 Objective 506 To characterize time needed for a DUT to recover from a software 507 process reset. 509 Such time period may depend upon the number and types of process 510 running in the DUT and which ones are tested. Different 511 implementations of forwarding devices include various common 512 processes. A process reset should be performed only in the 513 processes most relevant to the tester and most impactful to 514 forwarding. 516 Procedure 518 First, complete some or all of the following operational tasks: 519 save the current DUT configuration, specify software parameters or 520 environmental variables, or perform additional Operating System 521 task. 523 Second, ensure that the DUT is able to forward the traffic for at 524 least 15 seconds before any test activities are performed. The 525 traffic should use the minimum frame size possible on the media 526 used in the testing and rate should be sufficient for the DUT to 527 attain the maximum forwarding throughput. This enables a finer 528 granularity in the recovery time measurement. 530 Third, trigger a process reset for each process running in the DUT 531 and considered for testing from a management interface (e.g., by 532 means of the Command Line Interface (CLI), etc.) 534 Finally, the characterization is completed by recording the frame 535 loss (as reported by the test tool) and calculating the recovery 536 time (by following the section 1.2). 538 Reporting format 540 The reporting format is defined in Section 1.3, and is used for 541 each process running in the DUT and tested. Given the 542 implementation nature of this test, details of the actual process 543 tested should be included along with the statement. 545 4.3. Power interruption 547 "Power interruption" refers to the complete loss of power on the 548 DUT. It can be viewed as a special case of a hardware reset, 549 triggered by the loss of the power supply to the DUT or its 550 components, and is characterized by the re-initialization of all 551 hardware and software in the DUT. 553 4.3.1. Power Interruption (REQUIRED) 555 Objective 557 To characterize time needed for a DUT to recover efrom a complete 558 loss of electric power or complete power interruption. This test 559 simulates a complete power failure or outage, and should be 560 indicative of the DUT/SUTs behavior during such event. 562 Procedure 564 First, ensure that the entire DUT is at a permanent state to which 565 it will return to after the power interruption, by performing some 566 or all of the following operational tasks: save the current DUT 567 configuration, specify boot parameters, ensure the appropriate 568 software files are available, or perform additional Operating 569 System or hardware related task. 571 Second, ensure that the DUT is able to forward the traffic for at 572 least 15 seconds before any test activities are performed. The 573 traffic should use the minimum frame size possible on the media 574 used in the testing and rate should be sufficient for the DUT to 575 attain the maximum forwarding throughput. This enables a finer 576 granularity in the recovery time measurement. 578 Third, interrupt the power (AC or DC) that feeds the corresponding 579 DUTs power supplies at this point. This entails for example 580 physically removing the power supplies in the DUT to later re- 581 insert them, or simply disconnecting or switching off their power 582 feeds (AC or DC as applicable). The actual power interruption 583 should last at least 15 seconds. 585 Finally, the characterization is completed by recording the frame 586 loss (as reported by the test tool) and calculating the recovery 587 time (by following the section 1.2). 589 For easier comparison with other testing, the 15 seconds are 590 removed from the reported recovery time. 592 Reporting format 594 The reporting format is defined in Section 1.3. 596 5. Security Considerations 598 Benchmarking activities, as described in this memo, are limited to 599 technology characterization using controlled stimuli in a laboratory 600 environment, with dedicated address space and the constraints 601 specified in the sections above. 603 The benchmarking network topology will be an independent test setup 604 and MUST NOT be connected to devices that may forward the test 605 traffic into a production network or misroute traffic to the test 606 management network. 608 Furthermore, benchmarking is performed on a "black-box" basis, 609 relying solely on measurements observable external to the DUT/SUT. 611 Special capabilities SHOULD NOT exist in the DUT/SUT specifically 612 for benchmarking purposes. Any implications for network security 613 arising from the DUT/SUT SHOULD be identical in the lab and in 614 production networks. 616 There are no specific security considerations within the scope of 617 this document. 619 6. IANA Considerations 621 There is no IANA consideration for this document. 623 7. Acknowledgments 625 The authors would like to thank Ron Bonica, who motivated us to 626 write this document. The authors would also like to thank Al Morton, 627 Andrew Yourtchenko, David Newman, John E. Dawson, Timmons C. Player, 628 Jan Novak, Steve Maxwell, and Ilya Varlashkin for providing thorough 629 review, useful suggestions, and valuable input. 631 This document was prepared using 2-Word-v2.0.template.dot. 633 8. References 635 8.1. Normative References 637 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 638 Requirement Levels", BCP 14, RFC 2119, March 1997. 640 [RFC2544] Bradner, S. and McQuaid, J., "Benchmarking Methodology for 641 Network Interconnect Devices", RFC 2544, March 1999. 643 8.2. Informative References 645 [IGPConv] Poretsky, S., Imhoff, B., and K. Michielsen, "Benchmarking 646 Methodology for Link-State IGP Data Plane Route 647 Convergence", draft-ietf-bmwg-igp-dataplane-conv-meth-21 648 (work in progress), May 2010. 650 [RFC5180] Popoviciu, C., et al, "IPv6 Benchmarking Methodology for 651 Network Interconnect Devices", RFC 5180, May 2008. 653 [RFC5695] Akhter, A., Asati, R., and C. Pignataro, "MPLS Forwarding 654 Benchmarking Methodology for IP Flows", RFC 5695, November 655 2009. 657 Authors' Addresses 659 Rajiv Asati 660 Cisco Systems 661 7025-6 Kit Creek Road 662 RTP, NC 27709 663 USA 665 Email: rajiva@cisco.com 667 Carlos Pignataro 668 Cisco Systems 669 7200-12 Kit Creek Road 670 RTP, NC 27709 671 USA 673 Email: cpignata@cisco.com 675 Fernando Calabria 676 Cisco Systems 677 7200-12 Kit Creek Road 678 RTP, NC 27709 679 USA 681 Email: fcalabri@cisco.com 683 Cesar Olvera 684 Consulintel 685 Joaquin Turina, 2 686 Pozuelo de Alarcon, Madrid, E-28224 687 Spain 689 Phone: +34 91 151 81 99 690 Email: cesar.olvera@consulintel.es