idnits 2.17.00 (12 Aug 2021) /tmp/idnits35724/draft-svshah-lln-diffserv-recommendations-00.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 : ---------------------------------------------------------------------------- ** 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 422 has weird spacing: '... |Alert signa...' == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 3, 2012) is 3609 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 515, but no explicit reference was found in the text == Unused Reference: 'RFC5127' is defined on line 522, but no explicit reference was found in the text == Unused Reference: 'RFC5548' is defined on line 525, but no explicit reference was found in the text == Unused Reference: 'RFC5826' is defined on line 533, but no explicit reference was found in the text == Unused Reference: 'RFC5867' is defined on line 537, but no explicit reference was found in the text == Unused Reference: 'RFC2474' is defined on line 548, but no explicit reference was found in the text == Unused Reference: 'RFC2475' is defined on line 553, but no explicit reference was found in the text == Unused Reference: 'RFC6272' is defined on line 557, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Shah 3 Internet-Draft P. Thubert 4 Intended status: Informational Cisco Systems 5 Expires: January 4, 2013 July 3, 2012 7 Differentiated Service Class Recommendations for LLN Traffic 8 draft-svshah-lln-diffserv-recommendations-00 10 Abstract 12 Differentiated services architecture is widely deployed in 13 traditional networks. There exist well defined recommendations for 14 the use of appropriate differentiated service classes for different 15 types of traffic (eg. audio, video) in these networks. Per-Hop 16 Behaviors are typically defined based on this recommendations. With 17 emerging Low-power and Lossy Networks (LLNs), traffic originated in a 18 LLN, such as metering, command and control, may transit over a 19 converged campus IP network, or even a Wide Area Network, and will 20 share resources with traditional classes of traffic such as voice, 21 video and data. It is important to have defined differentiated 22 services recommendations for LLN traffic to co-exist with traditional 23 class of traffic. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 4, 2013. 42 Copyright Notice 44 Copyright (c) 2012 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 This document may contain material from IETF Documents or IETF 58 Contributions published or made publicly available before November 59 10, 2008. The person(s) controlling the copyright in some of this 60 material may not have granted the IETF Trust the right to allow 61 modifications of such material outside the IETF Standards Process. 62 Without obtaining an adequate license from the person(s) controlling 63 the copyright in such materials, this document may not be modified 64 outside the IETF Standards Process, and derivative works of it may 65 not be created outside the IETF Standards Process, except to format 66 it for publication as an RFC or to translate it into languages other 67 than English. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 73 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 3. Application Types and Traffic Patterns . . . . . . . . . . . . 5 75 3.1. Alert signals . . . . . . . . . . . . . . . . . . . . . . 6 76 3.2. Control signals . . . . . . . . . . . . . . . . . . . . . 6 77 3.3. Monitoring data . . . . . . . . . . . . . . . . . . . . . 7 78 3.3.1. Video data . . . . . . . . . . . . . . . . . . . . . . 7 79 3.3.2. Query based data . . . . . . . . . . . . . . . . . . . 8 80 3.3.3. Periodic reporting/logging, Software downloads . . . . 8 81 3.4. Traffic Class Characteristics Table . . . . . . . . . . . 9 82 4. Differentiated Service recommendations for LLN traffic . . . . 9 83 4.1. Alert signals . . . . . . . . . . . . . . . . . . . . . . 9 84 4.2. Control signals . . . . . . . . . . . . . . . . . . . . . 10 85 4.3. Monitoring Data . . . . . . . . . . . . . . . . . . . . . 10 86 4.3.1. Video Data . . . . . . . . . . . . . . . . . . . . . . 10 87 4.3.2. Query based data . . . . . . . . . . . . . . . . . . . 10 88 4.3.3. Periodic reporting/logging, Software downloads . . . . 10 89 4.4. Summary of Differentiated Code-points and QoS 90 Mechanics for them . . . . . . . . . . . . . . . . . . . . 11 91 5. Deployment Scenario . . . . . . . . . . . . . . . . . . . . . 11 92 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 93 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 94 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 95 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 96 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 99 1. Introduction 101 With emerged LLNs, it is anticipated that more and more such networks 102 will be connected to existing Campus, WANs, Provider core networks. 103 As deployments of LLNs grow, traffic out of such Networks will also 104 grow which is to co-exist with traditional types of traffic. Per-Hop 105 Behaviors (PHB) and Inter-domain Service Level Agreements (SLAs), not 106 only at the LLN Border but also in the managed IP networks, will have 107 to be defined considering all types of traffic. 109 We will first categorize different types of LLN traffic into service 110 classes and then provide recommendations for Differentiated Service 111 Code-Point(DSCP) for those service classes. Mechanisms to be used, 112 like Traffic Conditioning and Active Queue Management, for 113 differentiated services is well defined in RFC4594. This document 114 does not focus to re-call them again here but the document will call 115 out any specific mechanism that requires particular consideration. 116 Though nodes inside LLNs MAY use code-points recommended here. 118 This document focuses on Diffserv recommendations for LLN class of 119 traffic in managed IP networks outside of LLNs that is for the 120 traffic from LLN to the Campus, WAN, Provider Core as well as for the 121 traffic in the reverse direction. It does not focus on Diffserv 122 architecture or any other QoS recommendations within the LLNs. Given 123 constraints of LLNs and their unique requirements, it is expected of 124 a focus within a separate efforts. 126 In Section 3 we categorize different types of traffic from Different 127 LLNs. Section 4 recommends differentiated services, including DSCPs 128 and QoS mechanics, for categorized classes of traffic. Section 5 129 evaluates one of the deployment scenario. 131 1.1. Definitions 133 DSCP: Differentiated Service Code Point. It is a 6-bits value in the 134 TOS and Traffic Class field of the IPv4 and IPv6 header 135 respectively. This 6-bits numerical value defines standard set 136 of behavior to be performed by Differentiated Services capable 137 hops. 139 Diffserv 140 Class: Diffser Class in this document is used to refer to DSCP code- 141 point(s) and associated Per-hop Behaviors for it. 143 LLN: Low-power and lossy Network. Network constructed with sensors, 144 actuators, routers that are low-power and with higher loss/ 145 success transmission ratio, due to transmission medium and 146 nature of dynamics of changing topology, compare to wired and 147 other traditional networks. 149 SLA: Service Level Agreement. It is a collection of Traffic 150 classification rules and set of services associated with each 151 Traffic Class. Traffic classification may be defined based 152 on just DSCP code-points or additionally (or otherwise) 153 based on some other packet attributes. 155 WAN: Wide Area Network. Broader area of network that connects 156 multiple LANs, LLNs to each other including LAN, LLN networks 157 from different sites across regions. 159 2. Terminology 161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 163 document are to be interpreted as described in RFC2119. 165 3. Application Types and Traffic Patterns 167 Different types of traffic can be collapsed into following network 168 service classes. 170 - Alert signals 171 - Critical control signals 172 - Monitoring data 173 - Video data 174 - Query-based response data 175 - Periodic reporting/logging, Software downloads 177 3.1. Alert signals 179 Alerts/alarms reporting fall in this category where such signal is 180 triggered in a rare un-usual circumstances. An alert may be 181 triggered for an example when environmental hazard level goes beyond 182 certain threshold. Such alerts require to be reported with in the 183 human tolerable time. Note that certain critical alert reporting in 184 certain automation systems may be reported via very closely and 185 tightly managed method that is not implemented within LLNs, due to 186 the nature of transmission media of LLNs and due to the stringent 187 latency requirement for those alerts. Such types of signals are not 188 considered here since they are not within the scope of LLN or any 189 other IP networks. 191 Examples : 192 - Environmental hazard level goes beyond certain threshold 193 - Measured blood pressure exceeds the threshold or a person falls to 194 the ground 195 - Instructional triggers like start/stop traffic lights during 196 certain critical event 198 Traffic Pattern: 200 Typically size of such packets is very small. any specific device of 201 LLN is expected to trigger only handful of packets (may be only 1 202 packet). That too only during an event which is not a common 203 occurrence. 205 In an affected vicinity, only a designated device or each affected 206 devices may send alerts. In certain type of sensor networks, it is 207 predictable and expected to have only a designated device to trigger 208 such an alert while in certain other types scale number of alert 209 flows may be expected. 211 Latency required for such traffic is not stringent but is to be 212 within human tolerable time bound. 214 3.2. Control signals 216 Besides alerts, LLNs also trigger and/or receive different types of 217 control signals, to/from control applications outside of LLNs. These 218 control signals are important enough for the operation of sensors, 219 actuators and underneath network. Administrator controlling 220 applications, outside of LLN network, may trigger a control signal in 221 response to alerts/data received from LLN (in some cases control 222 signal trigger may be automated without explicit human interaction in 223 the loop) or administrator may trigger an explicit control signal for 224 a specific function. 226 Examples: 227 - auto [demand] response (e.g. manage peak load, service 228 disconnect, start/stop street lights) 229 - manual remote service disconnect, remote demand reset 231 - open-loop regulatory control 232 - non-critical close-loop regulatory control 233 - trigger to start Video surveillance 235 Traffic Pattern: 237 Variable size packets but typically size of such packets is small. 238 Certain control signals may be regular and so with number of devices 239 in a particular LLN, it is predictable on average, how many such 240 signals to expect. However, certain other control signals are 241 irregular or on-demand. 243 Typically most of the open-loop, that requires manual interaction, 244 signals are tolerant to latency above 1 second. Certain close-loop 245 control signals require low jitter and low latency, latency in the 246 order of 100s of ms. 248 Some of the tightly coupled closed loop control signals are very 249 sensitive to latency and jitter. However they today, just like 250 critical alerts, are implemented via other management methods outside 251 of LLN. 253 3.3. Monitoring data 255 Reaction to control signals may initiate flow of data-traffic in 256 either direction. Sensors/Actuators in LLNs may also trigger 257 periodic data (eg. monitoring, reporting data). All different types 258 of data may be categorized in following classes. 260 3.3.1. Video data 262 A very common example of this type of monitoring data is Video 263 surveillance or Video feed, triggered thru control signals. This 264 Video feed is typically from LLN towards an application outside of 265 LLN. 267 Traffic Pattern: 269 Video frame size is expected to be big with a flow of variable rate. 271 3.3.2. Query based data 273 Application at the controller, outside the LLN, or user explicitly 274 may launch query for the data. For example, query for an urban 275 environmental data, query for health report etc. Since this data is 276 query based data, it is important to report data with reasonable 277 latency though not stringent. In addition, some periodic logging 278 data also may require timely reporting and so may expect same type of 279 service (eg. at-home health reporting). 281 Traffic Pattern: 283 Size of packets can vary from small to big. While rate may be 284 predictable in some cases, in most of the cases traffic rate for such 285 data is variable. The traffic is bursty in the nature. 287 3.3.3. Periodic reporting/logging, Software downloads 289 Many sensors/actuator in different LLNs report data periodically. 290 With some exceptions, as mentioned above for healthcare monitoring 291 logs, most of such data do not have any latency requirement and can 292 be forwarded either thru lower priority assured forwarding or with 293 service of store and forward or even best effort. 295 Sensors/actuators may require software/firmware upgrades where 296 software/ firmware may be downloaded on demand bases. These upgrades 297 and so downloads do not have stringent requirement of timely delivery 298 to the accuracy of seconds. This data also can be forwarded thru 299 lower priority assured forwarding. 301 Traffic Pattern: 303 Periodic reporting/logging typically can be predicated as constant 304 rate. Data may be bursty in the nature. Software download data also 305 may be bursty in nature. Such traffic is tolerant to jitter and 306 latency. 308 3.4. Traffic Class Characteristics Table 310 ------------------------------------------------------------------- 311 |Traffic Class | | Tolerance to | 312 | Name | Traffic Characteristics | Loss |Delay |Jitter| 313 |===============+==============================+======+======+======| 314 | Alerts/ |Packet size = small | Low |Low | N/A | 315 | alarms |Rate = typically 1-few packets| | | | 316 | |Short lived flow | | | | 317 | |Burst = not bursty | | | | 318 |---------------+------------------------------+------+------+------| 319 | Control |Packet size = variable, | Yes |Low | Yes | 320 | Signals | typically small | | | | 321 | |Rate = few packets | | | | 322 | |Short lived flow | | | | 323 | |Burst = none to some-what | | | | 324 |---------------+------------------------------+------+------+------| 325 | Very low |Packet size = variable, | Low |Very | Low | 326 | latency | typically small | |Low | | 327 | close-loop |Rate = few packets | | | | 328 | Control |Short lived flow | | | | 329 | Signals |Burst = none to some-what | | | | 330 |---------------+------------------------------+------+------+------| 331 | Video |Packet size = big | Low |Low - | Low | 332 |Monitoring/feed|Rate = variable | |Medium| | 333 | |Long lived flow | | | | 334 | |Burst = non-bursty | | | | 335 |---------------+------------------------------+------+------+------| 336 | Query-based |Packet size = variable | Low |Medium| Yes | 337 | Data |Rate = variable | | | | 338 | |Short lived elastic flow | | | | 339 | |Burst = bursty | | | | 340 |---------------+------------------------------+------+------+------| 341 | Periodic |variable packet size, rate | Yes |Medium| Yes | 342 |Reporting/log, |bursty | |- High| | 343 | Software | | | | | 344 | downloads | | | | | 345 ------------------------------------------------------------------- 347 4. Differentiated Service recommendations for LLN traffic 349 4.1. Alert signals 351 Alerts/alarms signaling service requires transmission of few packets 352 with low delay, tolerable to human. This requirement is very similar 353 to signaling traffic in the traditional networks. Alert signals MAY 354 use Diffserv code-point CS5. 356 4.2. Control signals 358 As described in earlier section, control signals over IP are divided 359 in two categories. Control signals that require very low latency, 360 service inline with EF PHB, and control signals that require low 361 delay but do not mandate lowest latency. Service requirement for 362 later class of control signals is very similar to service for 363 signaling traffic in the traditional networks. Recommendation for 364 this class of control signals is to use Diffserv code-point CS5. 366 Control signals, like some of the closed-loop signals, that require 367 lower delay and jitter compare to CS5 class of control signals, are 368 recommended to use EF Diffserv class. These control signals are 369 expected to be of the small packet size and short-lived flows. 370 Specifically while sharing EF class with voice traffic, any big 371 control packets can cause additional latency to voice packets and so 372 care MUST be taken either to use a different Diffserv class for them 373 or compress such packets to smaller size. 375 4.3. Monitoring Data 377 4.3.1. Video Data 379 RFC4594 has well documented recommendations for different types of 380 Video traffic. If there is any Video traffic from/to LLNs to/from 381 outside of LLNs, they should use same recommended dscp from RFC4594. 382 For example, surveillance video feed is recommended to use dscp CS3. 384 4.3.2. Query based data 386 Low latency data, like query based report and non-critical signals, 387 is recommended to use AF2 assured forwarding service. Also, certain 388 periodic reporting/logging data that are critical to be reported with 389 regular interval with relatively low jitter is recommended to use 390 AF2x service. 392 4.3.3. Periodic reporting/logging, Software downloads 394 Non-critical periodic reporting/logging and rest all other data MAY 395 use AF1x or BE service class. 397 4.4. Summary of Differentiated Code-points and QoS Mechanics for them 399 - Alert Signals CS5 401 - Control Signaling CS5 403 - Lower latency control-signals EF 405 - Video broadcast/feed CS3 407 - Query-based data AF2x 409 - Assured monitoring data AF1x 410 high throughput 412 - Best Effort monitoring data BE 413 Reporting (periodic reporting.certain types of periodic monitoring 414 MAY require assured forwarding) 415 ------------------------------------------------------------------ 416 | Service | DSCP | Conditioning at | PHB | Queuing| AQM| 417 | Class | | DS Edge | Used | | | 418 |===============+======+===================+=========+========+====| 419 | lower latency | EF |Police using sr+bs | RFC3246 |Priority| No | 420 |control signals| |Police using sr+bs | | | | 421 |---------------+------+-------------------+---------+--------+----| 422 |Alert signals/| | | | | | 423 |Control signals| CS5 |Police using sr+bs | RFC2474 | Rate | No | 424 |---------------+------+-------------------+---------+--------+----| 425 | Video feed | CS3 |Police using sr+bs | RFC2474 | Rate | No | 426 |---------------+------+-------------------+---------+--------+----| 427 | Query- | AF21 | Using single-rate,| | | Yes| 428 | based | AF22 |three-color marker | RFC2597 | Rate | per| 429 | Data | AF23 | (such as RFC 2697)| | |DSCP| 430 |---------------+------+-------------------+---------+--------+----| 431 | Periodic | AF11 | Using two-rate, | | | Yes| 432 | Reporting/ | AF12 |three-color marker | RFC2597 | Rate | per| 433 | logging | AF13 | (such as RFC 2698)| | |DSCP| 434 ------------------------------------------------------------------ 435 * "sr+bs" represents a policing mechanism that provides single rate 436 with burst size control [RFC4594] 438 5. Deployment Scenario 440 Industrial Automation, as described in [RFC5673] and [ISA100.11a], 441 classifies different types of traffic in following six classes 442 ranging in complexity from Class 5 to Class 0 where Class 0 is the 443 most time sensitive class. 445 o Safety 447 * Class 0: Emergency action - Always a critical function 449 o Control 451 * Class 1: Closed-loop regulatory control - Often a critical 452 function 454 * Class 2: Closed-loop supervisory control - Usually a non- 455 critical function 457 * Class 3: Open-loop control - Operator takes action and controls 458 the actuator (human in the loop) 460 o Monitoring 462 * Class 4: Alerting - Short-term operational effect (for example, 463 event-based maintenance) 465 * Class 5: Logging and downloading / uploading - No immediate 466 operational consequence (e.g., history collection, sequence-of- 467 events, preventive maintenance) 469 It might not be appropriate to transport Class 0 traffic over a 470 wireless network or a multihop network, unless tight mechanisms are 471 put in place such as TDM and frequency hopping. Today this class of 472 traffic is expected to use other tightly managed method outside of 473 IP networks. Excluding class 0 traffic, following table maps Class 1 474 thru Class 5 service classes to Diffserv code-point. 476 ------------------------- 477 | Service | DSCP | 478 | Class | | 479 |===============+=========| 480 | Class 1* | EF | 481 +-------------------------+ 482 | Class 2 | CS5 | 483 +-------------------------+ 484 | Class 3 | CS5 | 485 +-------------------------+ 486 | Class 4 | AF2x | 487 +-------------------------+ 488 | class 5 | AF1x/BE | 489 +-------------------------+ 491 * Any Class 1 traffic that requires very tight control over latency 492 and jitter falls in the same category as Class 0 traffic. 494 6. Security Considerations 496 A typical trust model, as much is applicable in traditional networks, 497 is applicable with LLN traffic as well. At the border of the LLN, a 498 trust model needs to be established for any traffic coming out of 499 LLN. Without appropriate trust model to accept/mark dscp code-point 500 for LLN traffic, misbehaving flow may attack a specific Diffserv 501 class disrupting expected service for other traffic from the same 502 Diffserv class. Trust models are typically established at the border 503 router by employing rate-limiting and even marking down dscp code- 504 point to Best Effort for non-trusted flows or dropping them as 505 required. 507 7. Acknowledgements 509 Thanks to Fred Baker for his valuable comments and suggestions. 511 8. References 513 8.1. Normative References 515 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 516 Requirement Levels", BCP 14, RFC 2119, March 1997. 518 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 519 Guidelines for DiffServ Service Classes", RFC 4594, 520 August 2006. 522 [RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of 523 Diffserv Service Classes", RFC 5127, February 2008. 525 [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, 526 "Routing Requirements for Urban Low-Power and Lossy 527 Networks", RFC 5548, May 2009. 529 [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, 530 "Industrial Routing Requirements in Low-Power and Lossy 531 Networks", RFC 5673, October 2009. 533 [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation 534 Routing Requirements in Low-Power and Lossy Networks", 535 RFC 5826, April 2010. 537 [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, 538 "Building Automation Routing Requirements in Low-Power and 539 Lossy Networks", RFC 5867, June 2010. 541 8.2. Informative References 543 [ISA100.11a] 544 ISA, "ISA-100.11a-2011 - Wireless systems for industrial 545 automation: Process control and related applications", 546 May 2011. 548 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 549 "Definition of the Differentiated Services Field (DS 550 Field) in the IPv4 and IPv6 Headers", RFC 2474, 551 December 1998. 553 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 554 and W. Weiss, "An Architecture for Differentiated 555 Services", RFC 2475, December 1998. 557 [RFC6272] Baker, F. and D. Meyer, "Internet Protocols for the Smart 558 Grid", RFC 6272, June 2011. 560 Authors' Addresses 562 Shitanshu Shah 563 Cisco Systems 564 170 W. Tasman Drive 565 San Jose, CA 95134 566 US 568 Email: svshah@cisco.com 570 Pascal Thubert 571 Cisco Systems 572 Village d'Entreprises Green Side 573 400, Avenue de Roumanille 574 Batiment T3 575 Biot - Sophia Antipolis 06410 576 FRANCE 578 Email: pthubert@cisco.com