idnits 2.17.1 draft-thubert-savi-ra-throttler-01.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 (June 4, 2012) is 4315 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) == Outdated reference: A later version (-02) exists of draft-phinney-roll-rpl-industrial-applicability-00 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SAVI P. Thubert, Ed. 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track June 4, 2012 5 Expires: December 6, 2012 7 Throttling RAs on constrained interfaces 8 draft-thubert-savi-ra-throttler-01 10 Abstract 12 In a large switched topology with either many routers or routers that 13 transmit a high rate of multicast advertisements per router, as 14 suggested to support mobile nodes, the cost of distributing the many 15 resulting multicast messages to certain classes of devices might be 16 prohibitive. This is the case of a device that runs on batteries, or 17 a device that is reachable over a wireless interface. For this 18 device, it can be beneficial to filter a certain amount of multicast 19 messages such as the Router Advertisement while preserving the 20 functionality expected in the IPv6 Neighbor Discovery Protocol. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 26 "OPTIONAL" in this document are to be interpreted as described in RFC 27 2119 [RFC2119]. 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). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on December 6, 2012. 46 Copyright Notice 48 Copyright (c) 2012 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. Problem statement . . . . . . . . . . . . . . . . . . . . . . 5 66 3.1. Routers behavior . . . . . . . . . . . . . . . . . . . . . 5 67 3.2. Wireless Mobility domain . . . . . . . . . . . . . . . . . 5 68 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 4.1. Throttling scope and period . . . . . . . . . . . . . . . 7 70 4.2. Pending Hosts List . . . . . . . . . . . . . . . . . . . . 7 71 4.3. Advertising Routers List . . . . . . . . . . . . . . . . . 8 72 4.4. RA with an Advertisement Interval Option . . . . . . . . . 8 73 4.5. Final RA . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 4.6. Throttling Policy . . . . . . . . . . . . . . . . . . . . 10 75 5. Manageability . . . . . . . . . . . . . . . . . . . . . . . . 11 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 78 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 80 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 81 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 84 1. Introduction 86 The protection of the network is not necessarily a security function 87 such as the defense against a specific attack. It might also have to 88 do with other activities that include the control of multicast 89 storms, as provided to some extent by Multicast Listener Discovery 90 (MLD) Snooping [RFC4541], or of the overuse of the network that might 91 degrade the service for all users as provided for instance by Call 92 Admission Control [RFC5865]. 94 In particular, the wireless edge of a large Layer 2 topology will 95 require some special protections to conserve the limited bandwidth 96 that is available over the radio medium, such protections certainly 97 involving the reduction of multicast operations. 99 MLD Snooping helps control the impact of multicast messages but: 101 It does not apply to the all-nodes link-scoped multicast address 102 (FF02::1) as defined in the IP Version 6 Addressing Architecture 103 [RFC4291]. 105 MLD snooping is generally not implemented for link scope multicast 106 messages anyway. 108 If MLD snooping runs in instance as opposed to the Access Point 109 (AP) and if there is at least one listener associated to the AP 110 then the AP will still get the multicast and transmit it to all 111 the devices that are associated to the AP. 113 MLD snooping has the granularity of a group as opposed to a 114 binding table that has the granularity of a target - a host. 116 This document focusses on the protection against an excessive 117 bandwidth consumption by multicast IPv6 Neighbor Discovery (ND) 118 [RFC4861] Protocol (NDP) Router Advertisement (RA) messages over the 119 wireless edge of a switched network. 121 RA messages are link-scoped messages that provide the recipient node 122 with link information such as availability and characteristics of 123 routers that are present on the link and a list of prefixes that are 124 usable for IPv6 NDP Stateless Address Autoconfiguration (SLAAC) 125 [RFC4862]. 127 RA messages coming from different routers may carry different 128 information, including information about the router itself, but also 129 different prefix lists and other information such as the period of 130 transmission [RFC6275]. 132 In a number of cases, the fact that a node misses an RA does not 133 impact the node operation in a notable fashion, either because the 134 information is fully redundant with information that the node already 135 has (e.g. multiple RAs of a same content from a same router in rapid 136 sequence) or because the information is not critical to the node 137 (e.g. yet another router that is not preferable as default gateway). 138 In other cases, the loss of an RA is eventually recovered, but the 139 node will not operate optimally in the meantime and such a loss 140 should be avoided. 142 This document studies situations when an Ethernet Switch, an IEEE 143 802.11 Access Point, or a Control And Provisioning of Wireless Access 144 Points (CAPWAP) Access Controller (AC) [RFC5415] can, with no notable 145 effect, make the decision not to copy an RA message onto a port or a 146 set of ports, typically one or more ports that connect to an IEEE 147 802.11 wireless domain, the consequences of doing so and the eventual 148 recovery. In the remainder of this document, the term throttling 149 will refer to the decision not to copy a message over such ports, and 150 the layer 2 device in charge of making that decision will simply be 151 referred to as switch, whether it is a classical Ethernet switch or 152 any one of the sorts of devices listed above. 154 2. Terminology 156 The draft uses the following terminology: 158 Switch: A layer 2 device that distributes packets over one or more 159 ports. This broad definition includes but is not limited to 160 Ethernet and IEEE802.3 switches, CAPWAP Access Controllers and 161 IEEE 802.11 Access Points. 163 Throttling: The decision not to copy a given multicast message onto 164 a given port or a set of ports after the determination that the RA 165 would be redundant for most hosts across the port(s). A multicast 166 packet that is throttled over a given port might still be copied 167 for unicast delivery to selected hosts on a that port if it is 168 determined that they will benefit from receiving the RA. The 169 packet might still be passed on to other ports such as trunk 170 ports, for further switching along a VLAN for instance. 172 Throttled port: A port on the switch where throttling is active. 173 The port might be an access port that is directly connected to a 174 host, but it might also be a multipoint port, for instance if it 175 is connected to another switch such as an Access Point. 177 3. Problem statement 179 3.1. Routers behavior 181 Assuming that the solicitor's source address is not the unspecified 182 address, a router may choose to respond to an ND Router solicitation 183 (RS) with a unicast RA message directly to the soliciting host's 184 address. But it is common that the router aggregates multiple 185 requests and sends a single multicast response to the all-nodes 186 group. This RA is received by all the nodes on link, though a host 187 that did not issue an RS is probably not very interested in receiving 188 the solicited RA response message. Yet, in a wireless environment, a 189 host will usually issue an RS each time it reassociates, which can be 190 quite often if the host is as mobile as a smartphone. 192 A traditional (wireline) router will typically not rate limit its RA 193 emissions based on consistent RA messages received from other 194 routers, though such a behavior is required in the Routing Protocol 195 for Low Power and Lossy Networks (RPL) [I-D.ietf-roll-rpl] that is 196 specifically designed for constrained environments such as wireless 197 mesh networks. As a result, the number of RAs on a switched topology 198 increase roughly linearly with the number of deployed routers. 200 As it goes, the whole RA operation denotes an implicit expectation 201 that the cost for a multicast operation is not substantially 202 different from that of a unicast transmission and that the cost is 203 roughly similar on all segments of the link. Sadly, this is not true 204 in the case of a composite network with a switched Ethernet backbone 205 and an IEEE 802.11 Extended Service Set (ESS) wireless edge. The 206 situation is even worse if the edge is a mesh network, e.g. an IEEE 207 802.11S or a Low Power Lossy Network as described in 208 [I-D.phinney-roll-rpl-industrial-applicability] and 209 [I-D.thubert-lowpan-backbone-router]. In any case, a rate of RAs 210 that might appear acceptable on the backbone can rapidly become 211 excessive on the wireless edge. 213 3.2. Wireless Mobility domain 215 A number of (layer 3) Network-Based Localized Mobility Management 216 (NetLMM) techniques have been deployed that enable IP mobility 217 transparently to the host, that is without requiring the active 218 participation of the host in any mobility-related signaling. This is 219 achieved by hiding its mobility to the host and more specifically by 220 presenting the host with a consistent link appearance as it roams at 221 layer 3, in particular through tailored RA messages. An example of 222 such NetLMM solutions would be the adaption of Proxy Mobile IPv6 223 (PMIPv6) [RFC5213] within a proprietary mobility framework. 225 As a result, within a same radio environment (say an IEEE 802.11 226 Service Set Identification or SSID), some of the associated nodes may 227 be local nodes and some other nodes may be roaming devices that are 228 virtually part of some other link or VLAN in a remote location. If 229 all the associated nodes received a local RA announcing an local IPv6 230 prefix, roaming devices would detect their movement, form new 231 addresses and defeat the mobility functionality to the point that the 232 entire mobility domain would appear as one flat single IPv6 link. 234 To avoid that problem, a dedicated RA is unicast to each of the 235 associated devices as opposed to sent once as a layer 2 broadcast to 236 all devices in a single shot. A very common method consists in 237 rewriting the link layer multicast address in a frame that carries 238 the layer 3 multicast message onto a layer 2 unicast address. This 239 isolates which L3 multicast packet gets to which host, and more 240 importantly which multicast packet will not get to a given host for 241 whih it is not destined. 243 When a multicast packet is converted into multiple unicast frames by 244 a siwtch such as an Access Point or an Access Controller, a single 245 packet that is sent to the all-nodes group can consume a large amount 246 of bandwidth that is roughly a factor of the number of associated 247 devices, and disrupt sensitive applications such as voice over IEEE 248 802.11. The NDP assumption that a multicast does not cost more than 249 a unicast is severely broken. It results that the ND Protocol is not 250 really suited for the wireless medium, and that some tailoring is 251 required in instance to reduce the impact of the multicast messages, 252 in particular RA messages. 254 4. Operation 256 The NDP messages Router Advertisements are scoped to a link. They 257 are sent on a given IPv6 link (e.g. a Virtual Local Area Network) and 258 should be delivered only to IPv6 nodes that reside on that link. An 259 RA message can be transmitted over the medium either as unicast 260 response or as a multicast message that is sent to the link-scoped 261 all-nodes multicast address (FF02::1) as defined in [RFC4291], which 262 all IPv6 nodes on the link listen to. 264 If a Router Advertisement is sent to a unicast destination address, 265 instance MUST forward the packet to the destination device. But as 266 opposed to other ND Protocol operations such as the Duplicate Address 267 Detection (DAD) that occurs only when a node obtains or forms a new 268 address, multicast RAs are sent periodically and might be quite 269 frequent for the duration of the network activity. In that case, 270 instance MAY drop the multicast RA if it is redundant. The question 271 becomes to determine whether a multicast RA is redundant. 273 A switch might connect ports of different natures. Some ports may 274 need throttling of the RA messages, and some node. It is expected 275 that some mechanism is in place to determine which ports require 276 throttling, for instance a configured policy or an automatic 277 discovery. 279 4.1. Throttling scope and period 281 The scope of a throttling activity is a link (a VLAN). Within that 282 scope, some ports on instance are determined to be throttled, while 283 others are not. A throttling period is associated to that scope. A 284 policy dictates how many and under which conditions multicast RAs are 285 throttled. The policy is based on counters that count RAs per router 286 and counters that aggregate the numbers to the throttling scope (the 287 VLAN). The counters are reset at each throttling period. 289 NDP does not mandate that routers on a link expose the same prefixes. 290 It is possible that a router advertises a prefix that none of the 291 other routers does for instance. Or a router might advertise a 292 better preference for a given destination [RFC4291]. It is this 293 important that the throttling mechanism does not starve any given 294 router. instance SHOULD attempt to distribute fairly the amount of 295 RAs per source router, and to serve at least once any given router on 296 the link (VLAN) within a given period of time. 298 4.2. Pending Hosts List 300 A multicast RA that is the response to an RS is probably redundant 301 for all nodes that did not solicit the RA in the first place. But it 302 is certainly useful to nodes that issued an RS over a throttled port 303 since the last multicast RA happened. instance needs to keep track of 304 all those hosts as discovered through their RS messages, in an 305 abstract list referred to as the Pending Hosts List (PHL). There is 306 one PHL per link (that is, typically, per VLAN). 308 A host is anchored to a port on instance, a link layer address, and 309 eventually one or more VLAN identifier(s) depending on the 310 deployment. An IPv6 Link Local Address [RFC4291] might be available 311 to qualify the host. A PHL entry SHOULD contain all the anchor 312 parameter and MAY indicate additional information such as the host 313 Link Local Address. 315 instance SHOULD add a host to the PHL when it receives an RS from 316 that host over a throttled port, and upon a layer 2 trigger that 317 indicates that the port has flapped, typically an association or a 318 reassociation event in an Access Point or an Accesss Controller. 319 instance MAY remove a host from the PHL when a RA is forwarded to the 320 host, either as a unicast, a multicast, or a unicast copy of a 321 throttled multicast, and SHOULD remove the entry after a number or 322 RAs are forwarded, depending on the policy that applies to the host. 324 4.3. Advertising Routers List 326 The primary cause of RA redundancies is a router that sends multiple 327 identical RAs in a short sequence, for instance as stimulated by 328 hosts joining the link. instance identifies such redundancies by 329 keeping track of all the routers as discovered through RA messages, 330 and eventually of the content of those RA messages, in an abstract 331 list referred to as the Advertising Routers List (ARL). There is one 332 ARL per link (VLAN). 334 A router is anchored to a port on instance, a link layer address, and 335 eventually one or more VLAN identifier(s) depending on the 336 deployment. The router Link Local Address is found as the source 337 address of the RA. A ARL entry SHOULD contain all the anchor 338 parameters, the router Link Local Address, and a number of counters 339 that indicate the router activity over the last period and MAY 340 contain additional information from the RA such as a prefix list or 341 the router preferences [RFC4191]. The entry MUST also contain 342 counters that are necessary for the throttling operation, typically 343 the number of multicast RAs that where copied and the number that 344 were throttled during the current throttling period. 346 instance SHOULD add a router to the ARL when it receives an RA from 347 that router on any port that belong to that link (VLAN). instance 348 SHOULD remove the router from the ARL when the throttle period 349 elapses. instance MAY maintain a list of routers that were part of 350 the ARL for the previous period in an alternate list to keep 351 additional history and improve runtime performances. 353 4.4. RA with an Advertisement Interval Option 355 The Mobility Support in IPv6 (MIPv6) [RFC4191] section 7.3 introduces 356 the Advertisement Interval Option (AIO), used in RA messages to 357 advertise the interval at which the advertising router sends 358 unsolicited multicast Router Advertisements. When this option is 359 present, a switch SHOULD NOT interfere with a routers attempt to live 360 up to its claim that at least one RA message will be posted every 361 advertisement interval. 363 There is more than one way for instance to comply with this 364 requirement, as controlled by a policy that applies to the throttling 365 operation: 367 instance MAY never copy RAs from a given router that carry the AIO 368 over throttled ports. 370 Or instance MAY copy all RAs from a given router that carry the 371 AIO over throttled ports. 373 Alternatively, instance MAY monitor the timing of RA emissions 374 from a given router and refrain from throttling at least one RA 375 per advertisement interval from that router. It might then happen 376 that the router arms its timer on a message that instance 377 throttles later. In that case, the next RA that is not throttled 378 can be separated by substantially more time than one advertisement 379 interval though less than 2 intervals. This should not impact the 380 MIPv6 operation that does not take action until no RA is received 381 within two and a half advertisement intervals. 383 It can be noted that the advertisement interval that is used to 384 support mobility can be very short and load the radio medium quite 385 dramatically, depending on the available bandwidth on that medium. 386 The policy in place SHOULD probably make it so that RAs with too 387 short intervals are not copied on throttled ports unless no other 388 option is available. If mobile devices are expected on the wireless 389 link, then it might be preferred to block all routers advertising AIO 390 but one or two that would preferably use an acceptable interval. 392 4.5. Final RA 394 Section 6.2.5 of the Neighbor Discovery specification [RFC4861] 395 describe the router operation when it ceases to advertise on a given 396 interface. In particular, the router needs to transmit one or more 397 final (multicast) RA messages on the interface with a Router Lifetime 398 field of zero. 400 This information is critical to any host that utilizes the router 401 either as default gateway or more preferred gateway for a given 402 destination prefix since filtering out a final RA might leave such 403 host without connectivity till the host discovers that the router is 404 gone. A switch SHOULD NOT take actions that would prevent such a 405 host from receiving at least one final RA that indicates that a given 406 router ceases to be a available as a IPv6 gateway on the link (VLAN) 407 where throttling applies. 409 There is more than one way for instance to comply with that 410 requirement, as controlled by a policy that applies to the throttling 411 operation: 413 instance MAY never throttle an RA with a Router Lifetime field set 414 to zero. 416 Alternatively, instance MAY throttle further multicast final RAs 417 arrive immediately after a first final RA from a same router. 419 It can be noted that the advertisement interval that is used to 420 support mobility can be very short and load the system quite 421 dramatically. The policy in place should probably make it so that 422 RAs with short intervals are not copied on throttled ports unless no 423 other option is available. 425 4.6. Throttling Policy 427 An implementation SHOULD allow to configure a policy whereby the RA 428 throttling operation is based on the history of received RAs during 429 the current throttling period. 431 Suggested policy parameters per link (VLAN) include: 433 throttle-period: This is the duration of the throttling period. A 434 suggestion is to keep this value under the highest 435 MaxRtrAdvInterval used in the network. MaxRtrAdvInterval is 436 defined in [RFC4861] with a default of 600 seconds. The policy 437 that provides that parameter MAY apply to the link (VLAN) or 438 instance. 440 max-through: This is a maximum number of RAs that may pass before 441 for all routers during a throttling period. rAdvInterval is 442 defined in [RFC4861] with a default of 600 seconds. The policy 443 that provides that parameter MAY apply to the link (VLAN) or 444 instance. A suggested default is 1. 446 at-least: This is the minimum guaranteed number of RAs that pass 447 before the first RA is throttled for a given router. The policy 448 that provides that parameter MAY apply to an individual router, a 449 port, the link (VLAN) or instance. A suggested default is 1. 450 This parameter takes precedence over the max-through parameter 451 that is defined at the link (VLAN) level so as not to starve any 452 router. 454 at-most: This is a maximum number of RAs that may pass before for a 455 given router during a throttling period. The policy that provides 456 that parameter MAY apply to the router, the port, the link (VLAN) 457 or instance. A suggested default is 1. 459 interval-option: This parameter indicates the behaviour upon RAs 460 with the IAO as discussed in Section 4.4. The policy that 461 provides that parameter MAY apply to the router, the port, the 462 link (VLAN) or instance. A suggested default is never to copy RAs 463 with IAO on a throttled port. 465 5. Manageability 467 An implementation SHOULD allow the administrator to define one or 468 more throttling policies and to apply them on the relevant targets 469 (routers, ports, links and switch). The implementation should count 470 the number of RAs that passed and RAs that are throttled per target. 472 6. IANA Considerations 474 This specification does not require IANA action. 476 7. Security Considerations 478 This specification is not found to introduce new security threat. 480 8. Acknowledgements 482 The author wishes to thank Eric Levy-Abegnoli for his kind mentorship 483 all along this project. 485 9. References 487 9.1. Normative References 489 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 490 Requirement Levels", BCP 14, RFC 2119, March 1997. 492 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 493 Architecture", RFC 4291, February 2006. 495 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 496 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 497 September 2007. 499 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 500 Address Autoconfiguration", RFC 4862, September 2007. 502 9.2. Informative References 504 [I-D.ietf-roll-rpl] 505 Brandt, A., Vasseur, J., Hui, J., Pister, K., Thubert, P., 506 Levis, P., Struik, R., Kelsey, R., Clausen, T., and T. 507 Winter, "RPL: IPv6 Routing Protocol for Low power and 508 Lossy Networks", draft-ietf-roll-rpl-19 (work in 509 progress), March 2011. 511 [I-D.phinney-roll-rpl-industrial-applicability] 512 Phinney, T., Thubert, P., and R. Assimiti, "RPL 513 applicability in industrial networks", 514 draft-phinney-roll-rpl-industrial-applicability-00 (work 515 in progress), October 2011. 517 [I-D.thubert-lowpan-backbone-router] 518 Thubert, P., "LoWPAN Backbone Router", 519 draft-thubert-lowpan-backbone-router-00 (work in 520 progress), November 2007. 522 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 523 More-Specific Routes", RFC 4191, November 2005. 525 [RFC4541] Christensen, M., Kimball, K., and F. Solensky, 526 "Considerations for Internet Group Management Protocol 527 (IGMP) and Multicast Listener Discovery (MLD) Snooping 528 Switches", RFC 4541, May 2006. 530 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 531 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 533 [RFC5415] Calhoun, P., Montemurro, M., and D. Stanley, "Control And 534 Provisioning of Wireless Access Points (CAPWAP) Protocol 535 Specification", RFC 5415, March 2009. 537 [RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated 538 Services Code Point (DSCP) for Capacity-Admitted Traffic", 539 RFC 5865, May 2010. 541 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 542 in IPv6", RFC 6275, July 2011. 544 Author's Address 546 Pascal Thubert (editor) 547 Cisco Systems 548 Village d'Entreprises Green Side 549 400, Avenue de Roumanille 550 Batiment T3 551 Biot - Sophia Antipolis 06410 552 FRANCE 554 Phone: +33 497 23 26 34 555 Email: pthubert@cisco.com