idnits 2.17.1 draft-irtf-nmrg-autonomic-sla-violation-detection-07.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 -- The document date (March 2, 2017) is 2611 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'LMAP' is mentioned on line 419, but not defined == Missing Reference: 'IPFIX' is mentioned on line 426, but not defined == Missing Reference: 'ALTO' is mentioned on line 432, but not defined == Outdated reference: A later version (-30) exists of draft-ietf-anima-autonomic-control-plane-05 -- Obsolete informational reference (is this intentional?): RFC 4148 (Obsoleted by RFC 6248) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Management Research Group J. Nobre 3 Internet-Draft University of Vale do Rio dos Sinos 4 Intended status: Informational L. Granville 5 Expires: September 3, 2017 Federal University of Rio Grande do Sul 6 A. Clemm 7 Huawei 8 A. Gonzalez Prieto 9 Cisco Systems 10 March 2, 2017 12 Autonomic Networking Use Case for Distributed Detection of SLA 13 Violations 14 draft-irtf-nmrg-autonomic-sla-violation-detection-07 16 Abstract 18 This document describes a use case for autonomic networking in 19 distributed detection of Service Level Agreement (SLA) violations. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on September 3, 2017. 38 Copyright Notice 40 Copyright (c) 2017 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 5 57 3. Current Approaches . . . . . . . . . . . . . . . . . . . . . 5 58 4. Use Case Description . . . . . . . . . . . . . . . . . . . . 6 59 5. A Distributed Autonomic Solution . . . . . . . . . . . . . . 7 60 6. Intended User and Administrator Experience . . . . . . . . . 8 61 7. Analysis of Parameters and Information Involved . . . . . . . 8 62 7.1. Device Based Self-Knowledge and Decisions . . . . . . . . 8 63 7.2. Interaction with other devices . . . . . . . . . . . . . 9 64 8. Comparison with current solutions . . . . . . . . . . . . . . 9 65 9. Related IETF Work . . . . . . . . . . . . . . . . . . . . . . 9 66 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 67 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 68 12. Security Considerations . . . . . . . . . . . . . . . . . . . 10 69 13. Informative References . . . . . . . . . . . . . . . . . . . 10 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 72 1. Introduction 74 The Internet has been growing dramatically in terms of size and 75 capacity, and accessibility in the last years. Communication 76 requirements of distributed services and applications running on top 77 of the Internet have become increasingly demanding. Some examples 78 are real-time interactive video or financial trading. Providing such 79 services involves stringent requirements in terms of acceptable 80 latency, loss, or jitter. 82 Performance requirements lead to the articulation of Service Level 83 Objectives (SLOs) which must be met. Those SLOs are part of Service 84 Level Agreements (SLAs) that define a contract between the provider 85 and the consumer of a service. SLOs, in effect, constitute a service 86 level guarantee that the consumer of the service can expect to 87 receive (and often has to pay for). Likewise, the provider of a 88 service needs to ensure that the service level guarantee and 89 associated SLOs are met. Some examples of clauses that relate to 90 service level objectives can be found in [RFC7297]). 92 Violations of SLOs can be associated with significant financial loss, 93 which can by divided into two categories. For one, there is the loss 94 that can be incurred by the user of a service when the agreed service 95 levels are not provided. For example, a financial brokerage's stock 96 orders might suffer losses when it is unable to execute stock 97 transactions in a timely manner. An electronic retailer may lose 98 customers when their online presence is perceived by customers as 99 sluggish. An online gaming provider may not be able to provide fair 100 access to online players, resulting in frustrated players who are 101 lost as customers. In each case, the failure of a service provider 102 to meet promised service level guarantees can have a substantial 103 financial impact on users of the service. By the same token, there 104 is the loss that is incurred by the provider of a service who is 105 unable to meet promised service level objectives. Those losses can 106 take several forms, such as penalties for not meeting the service 107 and, in many cases more important, loss of revenue due to reduced 108 customer satisfaction. Hence, service level objectives are a key 109 concern for the service provider. In order to ensure that SLOs are 110 not being violated, service levels need to be continuously monitored 111 at the network infrastructure layer in order to know, for example, 112 when mitigating actions need to be taken. To that end, service level 113 measurements must take place. 115 Network measurements can be performed using active or passive 116 measurement techniques. In passive measurements, production traffic 117 is observed, and no monitoring traffic is created by the measurement 118 process itself. That is, network conditions are checked in a non 119 intrusive way. In the context of IP Flow Information EXport (IPFIX) 120 WG, several documents were produced to define passive measurement 121 mechanisms (e.g., flow records specification [RFC3954]). Active 122 measurements, on the other hand, are intrusive in the sense that it 123 involves injecting synthetic test traffic into the network to measure 124 network service levels. The IP Performance Metrics (IPPM) WG 125 produced documents that describe active measurement mechanisms, such 126 as: One-Way Active Measurement Protocol (OWAMP) [RFC4656], Two-Way 127 Active Measurement Protocol (TWAMP) [RFC5357], and Cisco Service 128 Level Assurance Protocol (SLA) [RFC6812]. In addition, there are 129 some mechanisms that do not fit into either active or passive 130 categories, such as Performance and Diagnostic Metrics Destination 131 Option (PDM) techniques [draft-ietf-ippm-6man-pdm-option]. 133 Active measurement mechanisms offer a high level of control of what 134 and how to measure. They do not require inspecting production 135 traffic. Because of this, active measurements usually offer better 136 accuracy and privacy than passive measurement mechanisms. Traffic 137 encryption and regulations that limit the amount of payload 138 inspection that can occur are non-issues. Furthermore, active 139 measurement mechanisms are able to detect end-to-end network 140 performance problems in a fine-grained way (e.g., simulating the 141 traffic that must be handled considering specific Service Level 142 Objectives - SLOs). As a result, active measurements are often 143 preferred over passive measurement for SLA monitoring. Measurement 144 probes must be hosted in network devices and measurement sessions 145 must be activated to compute the current network metrics (e.g., 146 considering those described in [RFC4148]). This activation should be 147 dynamic in order to follow changes in network conditions, such as 148 those related with routes being added or new customer demands. 150 While offering many advantages, active measurements are expensive in 151 terms of network resource consumption. Active measurements generally 152 involve measurement probes that generate synthetic test traffic that 153 is directed at a responder. The responder needs to timestamp test 154 traffic it receives and reflect it back to the originating 155 measurement probe. The measurement probe subsequently processes the 156 returned packets along with time stamping information in order to 157 compute service levels. Accordingly, active measurements consume 158 substantial CPU cycles as well as memory of network devices to 159 generate and process test traffic. In addition, synthetic traffic 160 increases network load. Active measurements thus compete for 161 resources with other functions, including routing and switching. 163 The resources required and traffic generated by the active 164 measurement sessions are to a large part a function of the number of 165 measured network destinations. (In addition, the amount of traffic 166 generated for each measurement plays a role, which in turn influences 167 the accuracy of the measurement.) The more destinations are being 168 measured, the larger the amount of resources consumed and traffic 169 needed to perform the measurements. Thus, to have a better 170 monitoring coverage it is necessary to deploy more sessions which 171 consequently turns increases consumed resources. Otherwise, enabling 172 the observation of just a small subset of all network flows can lead 173 to an insufficient coverage. 175 Furthermore, while some end-to-end service levels can be determined 176 by adding up the service levels observed across different path 177 segments, the same is not true for all service levels. For example, 178 the end-to-end delay or packet loss from a node A to a node C routed 179 via a node B can often be computed simply by adding delays (or loss) 180 from A to B, and B to C. This allows to decompose a large set of 181 end-to-end measurements into a much smaller set of segment 182 measurements. However, end-to-end jitter and (for example) Mean 183 Opinion Scores cannot be decomposed as easily and, for higher 184 accuracy, must be measured end-to-end. 186 Hence, the decision how to place measurement probes becomes an 187 important management activity. The goal is to obtain maximum 188 benefits of service level monitoring with a limited amount of 189 measurement overhead. Specifically, the goal is to maximize the 190 number of service level violations that are detected with a limited 191 amount of resources. 193 2. Definitions and Acronyms 195 Active Measurements: Techniques to measure service levels that 196 involve generating and observing synthetic test traffic 198 Passive Measurements: Techniques used to measure service levels based 199 on observation of production traffic 201 AN: Autonomic Network 203 Measurement Session: A communications association between a Probe and 204 a Responder used to send and reflect synthetic test traffic for 205 active measurements 207 Probe: The source of synthetic test traffic in an active measurement 209 Responder: The destination for synthetic test traffic in an active 210 measurement 212 SLA: Service Level Agreement 214 SLO: Service Level Objective 216 P2P: Peer-to-Peer 218 3. Current Approaches 220 The current best practice in feasible deployments of active 221 measurement solutions to distribute the available measurement 222 sessions along the network consists in relying entirely on the human 223 administrator expertise to infer which would be the best location to 224 activate such sessions. This is done through several steps. First, 225 it is necessary to collect traffic information in order to grasp the 226 traffic matrix. Then, the administrator uses this information to 227 infer which are the best destinations for measurement sessions. 228 After that, the administrator activates sessions on the chosen subset 229 of destinations considering the available resources. This practice, 230 however, does not scale well because it is still labor intensive and 231 error-prone for the administrator to determine which sessions should 232 be activated given the set of critical flows that needs to be 233 measured. Even worse, this practice completely fails in networks 234 whose critical flows are too short in time and dynamic in terms of 235 traversing network path, like in modern cloud environments. That is 236 so because fast reactions are necessary to reconfigure the sessions 237 and administrators are not just enough in computing and activating 238 the new set of required sessions every time the network traffic 239 pattern changes. Finally, the current active measurements practice 240 usually covers only a fraction of the network flows that should be 241 observed, which invariably leads to the damaging consequence of 242 undetected SLA violations. 244 4. Use Case Description 246 The use case involves a service level provider who needs to monitor 247 the network to detect service level violations using active service 248 level measurements, and wants to be able to do so with minimal human 249 intervention. The goal is to conduct the measurements in an 250 effective manner maximizing the percentage of detected service level 251 violations. The service level provider has a bounded resource budget 252 with regards to measurements that can be performed, specifically, 253 with regards to the number of measurements that can be conducted 254 concurrently from any one network device. However, while at any one 255 point in time the number of measurements conducted is limited, it is 256 possible for a device to change which destinations to measure over 257 time. This can be exploited to achieve a balance of eventually 258 covering all possible destinations using a reasonable amount of 259 "sampling" where measurement coverage of a destination cannot be 260 continuous. The solution needs to be dynamic and be able to cope 261 with network conditions which may change over time. The solution 262 should also be embeddable inside network devices that control the 263 deployment of active measurement mechanisms. 265 The goal is to conduct the measurements in a smart manner that 266 ensures that the network is broadly covered and the likelihood of 267 detecting service level violations is maximized. In order to 268 maximize that likelihood, it is reasonable to focus measurement 269 resources on destinations that are more likely to incur a violation, 270 while spending less resources on destinations that are more likely to 271 be in compliance. In order to do so, there are various aspects that 272 can be exploited, including past measurements (destinations close to 273 a service level threshold requiring more focus than destinations 274 further from it), complementation with passive measurements such as 275 flow data (to identify network destinations that are currently 276 popular and critical), an observations from other parts of the 277 network. In addition, measurements can be coordinated among 278 different network devices to avoid hitting the same destination at 279 the same time and to be able to share results that may be useful in 280 future probe placement. 282 Clearly, static solutions will have severe limitations. At the same 283 time, human administrators cannot be in the loop for continuous 284 dynamic measurement probe reconfigurations. Accordingly, an 285 automated or, ideally, autonomic solution is needed in which network 286 measurements are automatically orchestrated and dynamically 287 reconfigured from within the network. 289 5. A Distributed Autonomic Solution 291 The use of Autonomic Networking (AN) can help such detection through 292 an efficient activation of measurement sessions [P2PBNM-Nobre-2012]. 293 The problem to be solved by AN in the present use case is how to 294 steer the process of measurement session activation by a complete 295 solution that sets all necessary parameters for this activation to 296 operate efficiently, reliably and securely, with no required human 297 intervention other than setting overall policy. 299 We advocate for embedding Peer-to-Peer (P2P) technology in network 300 devices in order to conduct the measurement session activation 301 decisions using autonomic control loops. This requires the use of a 302 P2P overlay. A P2P overlay is important for several reasons: 304 o It makes it possible for nodes in the network to autonomically set 305 up Measurement Sessions, without having to rely on central 306 management system or controller to perform configuration 307 operations associated with configuring measurement probes and 308 responders. 310 o It facilitates the exchange local data between different devices 311 that is used to coordinate measurements and to share measurement 312 results to refine measurement strategy. 314 The provisioning of the P2P overlay should be transparent for the 315 network administrator. An Autonomic Control Plane such as defined in 316 [I-D.anima-autonomic-control-plane] provides an ideal candidate for 317 the P2P overlay's underlay. 319 An autonomic solution for the distributed detection of SLA violations 320 provide several benefits. First, efficiency: this solution should 321 optimize the resource consumption and avoid resource starvation on 322 the network devices. A device that is "self-aware" of its available 323 resources will be able to adjust measurement activities rapidly as 324 needed, without requiring a separate control loop involving resource 325 monitoring by an external system. Secondly, placing logic where to 326 conduct measurements in the node enables rapid control loops in which 327 devices are able to react instantly to observations and adjust their 328 measurement strategy. For example, a device could decide to adjust 329 the amount of synthetic test traffic being sent during the 330 measurement itself depending on results observed so far on this and 331 on other concurrent measurement sessions. As a result, the solution 332 could decrease the time necessary to detect SLA violations. 333 Adaptivity features of an autonomic loop could capture faster the 334 network dynamics than an human administrator and even a central 335 controller. Finally, the solution could help to reduce the workload 336 of human administrator, or, at least, to avoid their need to perform 337 operational tasks. 339 In practice, these factors combine to maximize the likelihood of SLA 340 violations being detected while operating within a given resource 341 budget, allowing to conduct a continuous measurement strategy that 342 takes into account past measurement results, observations of other 343 measures such as link utilization or flow data, sharing of 344 measurement results between network devices, and coordinating future 345 measurement activities among nodes. Combined this can result in 346 efficient measurement decisions that achieve a golden balance between 347 broad network coverage and honing in on service level "hot spots". 349 6. Intended User and Administrator Experience 351 The autonomic solution should not require human intervention in the 352 distributed detection of SLA violations. This also enables SLA 353 monitoring of a network by less experienced human administrators. 354 However, some information may be provided from the human 355 administrator. For example, the human administrator may set a policy 356 regarding the resource budget that is assigned to network devices for 357 measurement operations, or set a target for the number or percentage 358 of SLO violations that must be detected allowing the solution to 359 minimize the resources required to achieve that target. 361 7. Analysis of Parameters and Information Involved 363 The active measurement model assumes that a typical infrastructure 364 will have multiple network segments and Autonomous Systems (ASs), and 365 a reasonably large number of several of routers and hosts. It also 366 considers that multiple SLOs can be in place at a given time. Since 367 interoperability in a heterogenous network is a goal, features found 368 on different active measurement mechanisms (e.g. OWAMP, TWAMP, and 369 IPSLA) and device programability interfaces (such as Juniper's Junos 370 API or Cisco's Embedded Event Manager) could be used for the 371 implementation. The autonomic solution should include and/or 372 reference specific algorithms, protocols, metrics and technologies 373 for the implementation of distributed detection of SLA violations as 374 a whole. 376 7.1. Device Based Self-Knowledge and Decisions 378 Each device has self-knowledge about the local SLA monitoring. This 379 could be in the form of historical measurement data and SLOs. 380 Besides that, the devices would have algorithms that could decide 381 which probes should be activated in a given time. The choice of 382 which algorithm is better for a specific situation would be also 383 autonomic. 385 7.2. Interaction with other devices 387 Network devices should share information about service level 388 measurement results. This information can speed up the detection of 389 SLA violations and increase the number of detected SLA violations. 390 For example, if one device detects that a remote destination is 391 danger of violating an SLO, other devices may conduct additional 392 measurements to the same destination or other destinations in its 393 proximity. For any given network device, the exchange of data may be 394 more important with some devices (for example, devices in the same 395 network neighborhood, or devices that are "correlated" by some other 396 means) than with others. The definition of network devices that 397 exchange measurement data, i.e., management peers, creates a new 398 topology. Different approaches could be used to define this topology 399 (e.g., correlated peers [P2PBNM-Nobre-2012]). To bootstrap peer 400 selection, each device should use its known endpoints neighbors 401 (e.g., FIB and RIB tables) as the initial seed to get possible peers. 403 8. Comparison with current solutions 405 There is no standardized solution for distributed autonomic detection 406 of SLA violations. Current solutions are restricted to ad hoc 407 scripts running on a per node fashion to automate some 408 administrator's actions. There some proposals for passive probe 409 activation (e.g., DECON and CSAMP), but without the focus on 410 autonomic features. It is also mentioning a proposal from Barford et 411 al. to detect and localize links which cause anomalies along a 412 network path. 414 9. Related IETF Work 416 The following paragraphs discuss related IETF work and are provided 417 for reference. This section is not exhaustive, rather it provides an 418 overview of the various initiatives and how they relate to autonomic 419 distributed detection of SLA violations. 1. [LMAP]: The Large-Scale 420 Measurement of Broadband Performance Working Group aims at the 421 standards for performance management. Since their mechanisms also 422 consist in deploying measurement probes the autonomic solution could 423 be relevant for LMAP specially considering SLA violation screening. 424 Besides that, a solution to decrease the workload of human 425 administrators in service providers is probably highly desirable. 2. 426 [IPFIX]: IP Flow Information EXport (IPFIX) aims at the process of 427 standardization of IP flows (i.e., netflows). IPFIX uses measurement 428 probes (i.e., metering exporters) to gather flow data. In this 429 context, the autonomic solution for the activation of active 430 measurement probes could be possibly extended to address also passive 431 measurement probes. Besides that, flow information could be used in 432 the decision making of probe activation. 3. [ALTO]: The Application 433 Layer Traffic Optimization Working Group aims to provide topological 434 information at a higher abstraction layer, which can be based upon 435 network policy, and with application-relevant service functions 436 located in it. Their work could be leveraged for the definition of 437 the topology regarding the network devices which exchange measurement 438 data. 440 10. Acknowledgements 442 We wish to acknowledge the helpful contributions, comments, and 443 suggestions that were received from Mohamed Boucadair, Bruno Klauser, 444 Eric Voit, and Hanlin Fang. 446 11. IANA Considerations 448 This memo includes no request to IANA. 450 12. Security Considerations 452 The bootstrapping of a new device follows the approach proposed on 453 anima wg [draft-anima-boot], thus in order to exchange data a device 454 should register first. This registration could be performed by a 455 "Registrar" device or a cloud service provided by the organization to 456 facilitate autonomic mechanisms. The new device sends its own 457 credentials to the Registrar, and after successful authentication, 458 receives domain information, to enable subsequent enrollment to the 459 domain. The Registrar sends all required information: a device name, 460 domain name, plus some parameters for the operation. Measurement 461 data should be exchanged signed and encrypted among devices since 462 these data could carry sensible information about network 463 infrastructures. Some attacks should be considering when analyzing 464 the security of the autonomic solution. Denial of service (DoS) 465 attacks could be performed if the solution be tempered to active more 466 local probe than the available resources allow. Besides that, 467 results could be forged by a device (attacker) in order to this 468 device be considered peer of a specific device (target). This could 469 be done to gain information about a network. 471 13. Informative References 473 [draft-anima-boot] 474 Pritikin, M., Richardson, M., Behringer, M., and S. 475 Bjarnason, "draft-ietf-anima-bootstrapping-keyinfra", 476 draft-ietf-anima-bootstrapping-keyinfra-04 (work in 477 progress), January 2017. 479 [draft-ietf-ippm-6man-pdm-option] 480 Elkins, N., Hamilton, R., and M. Ackermann, "draft-ietf- 481 ippm-6man-pdm-option", draft-ietf-ippm-6man-pdm-option-08 482 (work in progress), February 2017. 484 [I-D.anima-autonomic-control-plane] 485 Behringer, M., Eckert, T., and S. Bjarnason, "An Autonomic 486 Control Plane", draft-ietf-anima-autonomic-control- 487 plane-05 (work in progress), January 2017. 489 [P2PBNM-Nobre-2012] 490 Nobre, J., Granville, L., Clemm, A., and A. Gonzalez 491 Prieto, "Decentralized Detection of SLA Violations Using 492 P2P Technology, 8th International Conference Network and 493 Service Management (CNSM)", 2012, 494 . 497 [RFC3954] Claise, B., Ed., "Cisco Systems NetFlow Services Export 498 Version 9", RFC 3954, DOI 10.17487/RFC3954, October 2004, 499 . 501 [RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics 502 Registry", BCP 108, RFC 4148, DOI 10.17487/RFC4148, August 503 2005, . 505 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 506 Zekauskas, "A One-way Active Measurement Protocol 507 (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, 508 . 510 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 511 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 512 RFC 5357, DOI 10.17487/RFC5357, October 2008, 513 . 515 [RFC6812] Chiba, M., Clemm, A., Medley, S., Salowey, J., Thombare, 516 S., and E. Yedavalli, "Cisco Service-Level Assurance 517 Protocol", RFC 6812, DOI 10.17487/RFC6812, January 2013, 518 . 520 [RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP 521 Connectivity Provisioning Profile (CPP)", RFC 7297, 522 DOI 10.17487/RFC7297, July 2014, 523 . 525 Authors' Addresses 527 Jeferson Campos Nobre 528 University of Vale do Rio dos Sinos 529 Porto Alegre 530 Brazil 532 Email: jcnobre@unisinos.br 534 Lisandro Zambenedetti Granvile 535 Federal University of Rio Grande do Sul 536 Porto Alegre 537 Brazil 539 Email: granville@inf.ufrgs.br 541 Alexander Clemm 542 Huawei 543 Santa Clara, California 544 USA 546 Email: ludwig@clemm.org 548 Alberto Gonzalez Prieto 549 Cisco Systems 550 San Jose 551 USA 553 Email: albertgo@cisco.com