idnits 2.17.00 (12 Aug 2021) /tmp/idnits20686/draft-bhandari-dhc-class-based-prefix-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 (March 12, 2012) is 3721 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) == Unused Reference: 'RFC2629' is defined on line 516, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 519, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Bhandari 3 Internet-Draft G. Halwasia 4 Intended status: Standards Track S. Bandi 5 Expires: September 13, 2012 S. Gundavelli 6 Cisco Systems 7 H. Deng 8 China Mobile 9 March 12, 2012 11 DHCPv6 class based prefix 12 draft-bhandari-dhc-class-based-prefix-01 14 Abstract 16 DHCPv6 defines class based allocation of IA_NA and IA_TA IPv6 17 addresses. This document extends DHCPv6 prefix delegation with class 18 based prefix allocation. It defines a new prefix class option to 19 classify a prefix. It defines the behavior of a DHCPv6 client 20 requesting a prefix to include the class of the prefix to be 21 allocated and the DHCPv6 server behavior to select and offer a prefix 22 from a given class. It discusses how IA_NA can be requested and 23 assigned from a specific prefix class. 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 September 13, 2012. 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 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 62 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 4 63 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2.1. Prefix Class Option in IA_PD . . . . . . . . . . . . . . . 4 65 2.2. Consideration for different DHCPv6 entities . . . . . . . 5 66 2.2.1. Requesting Router Behavior . . . . . . . . . . . . . . 5 67 2.2.2. Delegating Router Behavior . . . . . . . . . . . . . . 6 68 2.2.3. DHCPv6 Client Behavior for IA_NA allocation . . . . . 7 69 2.3. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 2.3.1. Class based prefix and IA_NA allocation . . . . . . . 7 71 2.3.2. Class based prefix and IA_PD allocation . . . . . . . 8 72 2.3.3. Class based prefix and SLAAC . . . . . . . . . . . . . 8 73 3. Example Application . . . . . . . . . . . . . . . . . . . . . 8 74 3.1. Class based prefix delegation . . . . . . . . . . . . . . 11 75 3.2. IPv6 address assignment from class based prefix . . . . . 11 76 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 77 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 79 7. Change History (to be removed prior to publication as an 80 RFC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 82 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 83 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 86 1. Introduction 88 DHCPv6 based prefix delegation as defined in [RFC3633] is a mechanism 89 for the delegation of IPv6 prefixes using DHCPv6 options. Through 90 these options, a delegating router can delegate prefixes to 91 authorized requesting routers. If the requesting router has to 92 function as a DHCPv6 server there needs to be additional information 93 in the delegated prefix that helps the requesting router to select 94 the address allocation for the DHCPv6 client it serves, from one of 95 the available delegated prefixes. 97 One way to select an address or longer prefix (from a delegated 98 prefix) to be allocated by a requesting router playing the role of a 99 DHCPv6 server is by introducing additional options in IA_PD to be 100 matched with options for address selection in the DHCPv6 SOLICIT 101 message. [RFC3315] defines the OPTION_USER_CLASS option which is 102 used for selecting address for assignment. This document introduces 103 OPTION_PREFIX_CLASS option in IA_PD option for the purpose of 104 selecting a prefix for further delegation either via IA_NA or IA_PD 105 DHCPv6 request. It defines the behavior of the DHCPv6 server, the 106 DHCPv6 prefix requesting router and the DHCPv6 client to use this 107 option. 109 1.1. Motivation 111 In this section motivation for class based prefix delegation that 112 qualifies the delegated prefix with additional class information is 113 described in the context of mobile networks. The class information 114 attached to a delegated prefix helps to distinguish property of a 115 delegated IPv6 prefix and selection of the prefix by different 116 applications using it. 118 In the mobile network architecture, there is a mobile router which 119 functions as a IP network gateway and provides IP connectivity to 120 mobile nodes. Mobile router can be the requesting router requesting 121 delegated IPv6 prefix using DHCPv6. Mobile router can assume the 122 role of DHCPv6 server for mobile nodes(DHCPv6 clients) attached to 123 it. A mobile node in mobile network architecture can be associated 124 with multiple IPv6 prefixes belonging to different domains for e.g. 125 home address prefix, care of address prefix as specified in 126 [RFC3775]. 128 The delegated prefixes when seen from the mobile router perspective 129 appear to be like any other prefix, but each prefixes have different 130 properties referred to as "Prefix Color" in the mobile networks. 131 Some delegated prefixes may be topologically local and some may be 132 remote prefixes anchored on a global anchor, but available to the 133 local anchor by means of tunnel setup in the network between the 134 local and global anchor. Some may be local with low latency 135 characteristics suitable for voice call break-out, some may have 136 global mobility support. So, the prefixes have different properties 137 and it is required for the application using the prefix to learn 138 about this property in order to use it intelligently. There is 139 currently no semantics in DHCPv6 prefix delegation that can carry 140 this information to specify properties of a delegated prefix. In 141 this scenario, the mobile router is unable to further delegate a 142 longer prefix intelligently based on properties of the prefix learnt. 144 1.2. Terminology 146 This document uses the terminology defined in [RFC2460], [RFC3315] 147 and [RFC3633]. 149 1.3. Requirements Language 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 153 document are to be interpreted as described in RFC 2119 [RFC2119]. 155 2. Overview 157 This section defines Prefix Class option in IA_PD and IA_NA to aid 158 class based prefix delegation and address assignment. This section 159 defines the behavior of the delegating router, the requesting router 160 and the DHCPv6 client. 162 2.1. Prefix Class Option in IA_PD 163 The format of the DHCPv6 Prefix Class option is shown below. 164 0 1 2 3 165 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | OPTION_PREFIX_CLASS | option-length | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | prefix-class | 170 | (variable length) | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 option-code: OPTION_PREFIX_CLASS (TBD) 174 option-length: length of prefix-class 175 prefix-class: Prefix class (binary string). 177 2.2. Consideration for different DHCPv6 entities 179 The model of operation of communicating prefixes to be used by a 180 DHCPv6 server is as follows. A requesting router requests prefix(es) 181 from the delegating router, as described in Section 2.2.1. A 182 delegating router is provided IPv6 prefixes to be delegated to the 183 requesting router. Examples of ways in which the delegating router 184 is provided these prefixes are: 186 o Configuration 188 o Prefix delegated via a DHCPv6 request to another DHCPv6 server 190 o Using a Authentication Authorization Accounting (AAA) protocol 191 like RADIUS [RFC2865] 193 The delegating router chooses prefix(es) for delegation, and responds 194 with prefix(es) to the requesting router along with additional 195 options in the allocated prefix as described in Section 2.2.2. The 196 requesting router is then responsible for the delegated prefix(es) 197 after the DHCPv6 REQUEST message exchange. For example, the 198 requesting router may create DHCPv6 server configuration pools from 199 the delegated prefix, and function as a DHCPv6 Server. When the 200 requesting router then receives a DHCPv6 IA_NA requests it can select 201 the address to be allocated based on the OPTION_USER_CLASS or 202 OPTION_PREFIX_CLASS options received in IA_NA request or any of the 203 other methods as described in Section 2.3.1. 205 2.2.1. Requesting Router Behavior 207 DHCPv6 requesting router can request for prefixes in the following 208 ways: 210 o In the SOLICIT message within the IA_PD Prefix option, it MAY 211 include OPTION_PREFIX_CLASS requesting prefix delegation for the 212 specific class indicated in the OPTION_PREFIX_CLASS option. It 213 can include multiple IA_PD Prefix options to indicate it's 214 preference for more than one prefix class. 216 o In the SOLICIT message include an OPTION_ORO option with the 217 OPTION_PREFIX_CLASS option code to request prefixes from all the 218 classes that the DHCPv6 server can provide to this requesting 219 Router. 221 The requesting router parses the OPTION_PREFIX_CLASS option in 222 theOPTION_IAPREFIX option area of the corresponding IA_PD Prefix 223 option in the ADVERTISE message. The Requesting router MUST then 224 include all or subset of the received class based prefix(es) in the 225 REQUEST message so that it will be responsible for the prefixes 226 selected. 228 2.2.2. Delegating Router Behavior 230 If the Delegating router supports class based prefix allocation by 231 supporting the OPTION_PREFIX_CLASS option and it is configured to 232 assign prefixes from different classes, it selects prefixes for class 233 based prefix allocation in the following way: 235 o If requesting router includes OPTION_PREFIX_CLASS within the IA_PD 236 Prefix option, it selects prefixes to be offered from that 237 specific class. 239 o If requesting router includes OPTION_PREFIX_CLASS within 240 OPTION_ORO, then based on its configuration and policy it MAY 241 offer prefixes from multiple classes available. 243 The delegating router responds with an ADVERTISE message after 244 populating the IP_PD option with prefixes from different prefix 245 classes. Along with including the IA_PD prefix options in the IA_PD 246 option, it also includes the OPTION_PREFIX_CLASS option in the 247 OPTION_IAPREFIX option area of the corresponding IA_PD prefix option. 249 If neither the OPTION_ORO nor the IA_PD option in the SOLICIT message 250 include the OPTION_PREFIX_CLASS option, then the delegating router 251 MAY allocate the prefix as specified in [RFC3633] without including 252 the class option in the IA_PD prefix option in the response. 254 If OPTION_ORO option in the Solicit message includes the 255 OPTION_PREFIX_CLASS option code but the delegating router does not 256 support the solution described in this specification, then the 257 delegating router acts as specified in [RFC3633]. The requesting 258 router MUST in this case also fall back to the behavior specified in 259 [RFC3633]. 261 If both delegating and requesting routers support class-based prefix 262 allocation, but the delegating router cannot offer prefixes for any 263 other reason, it MUST respond to requesting router with appropriate 264 status code as specified in [RFC3633]. For e.g., if no prefixes are 265 available in the specified class then the delegating router MUST 266 include the status code NoPrefixAvail in the response message. 268 2.2.3. DHCPv6 Client Behavior for IA_NA allocation 270 DHCPv6 client MAY request for an IA_NA address allocation from a 271 specific prefix class in the following way: 273 o In the SOLICIT message within the IA_NA option, it MAY include the 274 OPTION_PREFIX_CLASS requesting address to be allocated from a 275 specific prefix class indicated in that option. 277 The DHCPv6 server parses OPTION_PREFIX_CLASS option received and 278 includes it in option area of corresponding OPTION_IA_NA in ADVERTISE 279 message. 281 2.3. Usage 283 Class based prefix delegation can be used by the requesting router to 284 configure itself as a DHCPv6 server to serve its DHCPv6 clients. It 285 can allocate longer prefixes from a delegated shorter prefix it 286 received, for serving IA_NA and IA_PD requests. 288 2.3.1. Class based prefix and IA_NA allocation 290 The requesting router can use the delegated prefix(es) from different 291 classes (for example "video", "guest", "voice" etc), for assigning 292 the IPv6 addresses to the end hosts through DHCPv6 IA_NA based on a 293 preconfigured mapping with OPTION_PREFIX_CLASS option, the following 294 conditions MAY be observed: 296 o It MAY have a pre-configured mapping between the prefix class and 297 OPTION_USER_CLASS option received in IA_NA. 299 o It MAY match the OPTION_PREFIX_CLASS if the IA_NA request received 300 contains OPTION_PREFIX_CLASS. 302 o It MAY map OPTION_PREFIX_CLASS option to the OPTION_USER_CLASS 303 option by string matching of both these option values. 305 o It MAY have a pre-configured mapping between the prefix class and 306 the client DUID received in DHCPv6 message. 308 o It MAY have a pre-configured mapping between the prefix class and 309 its network interface on which the IA_NA request was received. 311 The requesting router playing the role of a DHCPv6 server can 312 ADVERTISE IA_NA from a class of prefix(es) thus selected. 314 2.3.2. Class based prefix and IA_PD allocation 316 If the requesting router, receives prefix(es) for different classes 317 (for example "video", "guest", "voice" etc), it can use these 318 prefix(es) for assigning the longer IPv6 prefixes to requesting 319 routers it serves through DHCPv6 IA_PD by assuming the role of 320 delegating router, its behavior is explained in Section 2.2.2. 322 2.3.3. Class based prefix and SLAAC 324 DHCPv6 IA_NA and IPv6 Stateless Address Autoconfiguration (SLAAC as 325 defined in [RFC4862]) are two ways by IPv6 addresses can be 326 dynamically assigned to end hosts. Making SLAAC class aware is 327 outside the scope of this document. 329 3. Example Application 331 The following sub-sections provide examples of class based prefix 332 delegation and how it is used in a mobile network. Each of the 333 examples will refer to the below network: 335 The example network consists of : 337 Mobile Gateway It is network entity anchoring IP traffic in the 338 mobile core network. This entity allocates an IP address which is 339 topologically valid in the mobile network and may act as a mobility 340 anchor if handover between mobile and Wi-Fi is supported. 342 Mobile Nodes (MN) A host or router that changes its point of 343 attachment from one network or subnetwork to another. A mobile node 344 may change its location without changing its IP address; it may 345 continue to communicate with other Internet nodes at any location 346 using its (constant) IP address, assuming link-layer connectivity to 347 a point of attachment is available. 349 Access Point (AP) A wireless access point, identified by a MAC 350 address, providing service to the wired network for wireless nodes. 352 Access Router (AR) An IP router residing in an access network and 353 connected to one or more Acess Point(AP)s. An AR offers IP 354 connectivity to MNs. 356 WLAN controller (WLC) The entity that provides the centralized 357 forwarding, routing function for the user traffic. 359 Example mobile network 360 _----_ _----_ _----_ 361 _( )_ _( )_ _( )_ 362 (Operator-1) (Operator-2) (Operator-3) 363 (_ _) (_ _) (_ _) 364 -+-- -+-- '-+--' 365 +--------+ +--------+ +--------+ 366 | Mobile | | Mobile | | Mobile | 367 |gateway | |gateway | |gateway | 368 +--------+ +--------+ +--------+ 369 | | | 370 +-------------. | .-------------+ 371 | | | 372 | | | 373 | | |P1:"global-anchor" 374 | | | 375 +--------+ _----_ 376 +---+ | |P2:"local-breakout"_( )_ 377 |AAA|. . . . . . . | Access |------------------( Internet ) 378 +---+ | Aggreg |-----------+ (_ _) 379 | Gateway| P3:"guest"| '----' 380 +--------+ | 381 | | +----- Guest Access 382 | | Network 383 | +-------------+ 384 | | 385 | +-----+ 386 | | AR | 387 +-----+ +-----+ 388 | WLC | * ---------* 389 | | ( LAN ) 390 +-----+ * ---------* 391 / \ / \ 392 +----+ +----+ +----+ +----+ 393 |WiFi| |WiFi| |WiFi| |WiFi| 394 | AP | | AP | | AP | | AP | 395 +----+ +----+ +----+ +----+ 396 . . 397 / \ / \ 398 MN1 MN2 MN3 MN4(guest) 400 Figure 1 402 3.1. Class based prefix delegation 404 The Access Aggregation Gateway requests for Prefix delegation from 405 Mobile gateway and associates the prefix received with prefix class 406 "global-anchor". The Access Aggregation Gateway is preconfigured to 407 provide prefixes from the following classes: "global-anchor", "local- 408 breakout", "guest". It has a preconfigured policy to advertise 409 prefixes to requesting routers and mobile nodes based on the service 410 class supported by the service provider for the requesting device. 411 In the example mobile network, the Access Router(AR) requests class 412 based prefix allocation by sending a DHCPv6 SOLICIT message and 413 include OPTION_PREFIX_CLASS in the OPTION_ORO. 415 The Access Router (AR) receives an advertise with following prefixes 416 in the IA_PD option: 418 1. P1: IA_PD Prefix option with a prefix 3001::1::/64 containing 419 OPTION_PREFIX_CLASS set to "global-anchor" 421 2. P2: IA_PD Prefix option with a prefix 3001::2::/64 containing 422 OPTION_PREFIX_CLASS set to "local-breakout" 424 3. P3: IA_PD Prefix option with a prefix 3001::3::/64 containing 425 OPTION_PREFIX_CLASS set to "guest" 427 It sends a REQUEST message with all of above prefixes and receives a 428 REPLY message with prefixes allocated for each of the requested 429 class. 431 3.2. IPv6 address assignment from class based prefix 433 When the Access Router(AR) receives a DHCPv6 SOLICIT requesting IA_NA 434 from the mobile node that has mobility service enabled, it offers an 435 IPv6 address from the prefix class "global-anchor". For MN3 it 436 advertises 3001::1::1 as the IPv6 address in OPTION_IAADDR in 437 response to the IA_NA request. 439 The Mobile Node(MN4) Figure 1 sends a DHCPv6 SOLICIT message 440 requesting IA_NA address assignment with OPTION_USER_CLASS option 441 containing the value "guest" towards the CPE. The Access Router(AR) 442 assumes the role of the DHCPv6 server and sends an ADVERTISE to the 443 MN with OPTION_IA_NA containing an IPv6 address in OPTION_IAADDR from 444 the "guest" prefix class. The IPv6 address in the OPTION_IAADDR is 445 set to 3001::3::1. The "guest" class can also be distinguished based 446 on a preconfigured interface or SSID advertised for MNs connecting to 447 it. 449 When the Access Aggregation Gateway receives a DHCPv6 SOLICIT 450 requesting IA_NA from MNs through WLC and it has a preconfigured 451 profile to provide both local-breakout internet access and global- 452 anchor, it offers an IPv6 address from the prefix class "local- 453 breakout" and "global-anchor". For MN1 it advertises 3001::2::1 and 454 3001::1::2 as the IPv6 address in OPTION_IAADDR in response to the 455 IA_NA request. Applications within MN1 can choose to use the 456 appropriate prefix based on the mobility enabled or local-breakout 457 property. 459 4. Acknowledgements 461 The authors would like to acknowledge review and guidance received 462 from Frank Brockners, Wojciech Dec, Richard Johnson, Erik Nordmark, 463 Hemant Singh, Mark Townsley, Ole Troan, Bernie Volz 465 5. IANA Considerations 467 IANA is requested to assign an option code to OPTION_PREFIX_CLASS 468 from the "DHCPv6 and DHCPv6 options" registry (http://www.iana.org/ 469 assignments/dhcpv6-parameters/dhcpv6-parameters.xml). 471 6. Security Considerations 473 Security issues related to DHCPv6 which are described in section 23 474 of [RFC3315] and [RFC3633] apply for scenarios mentioned in this 475 draft as well. 477 7. Change History (to be removed prior to publication as an RFC) 479 Changes from -00 to -01 481 a. Modified motivation section to focus on mobile networks 483 b. Modified example with a mobile network and class based prefix 484 delegation in it 486 8. References 488 8.1. Normative References 490 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 491 Requirement Levels", BCP 14, RFC 2119, March 1997. 493 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 494 (IPv6) Specification", RFC 2460, December 1998. 496 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 497 "Remote Authentication Dial In User Service (RADIUS)", 498 RFC 2865, June 2000. 500 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 501 and M. Carney, "Dynamic Host Configuration Protocol for 502 IPv6 (DHCPv6)", RFC 3315, July 2003. 504 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 505 Host Configuration Protocol (DHCP) version 6", RFC 3633, 506 December 2003. 508 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 509 in IPv6", RFC 3775, June 2004. 511 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 512 Address Autoconfiguration", RFC 4862, September 2007. 514 8.2. Informative References 516 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 517 June 1999. 519 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 520 Text on Security Considerations", BCP 72, RFC 3552, 521 July 2003. 523 Authors' Addresses 525 Shwetha Bhandari 526 Cisco Systems 527 Cessna Business Park, Sarjapura Marathalli Outer Ring Road 528 Bangalore, KARNATAKA 560 087 529 India 531 Phone: 532 Email: shwethab@cisco.com 533 Gaurav Halwasia 534 Cisco Systems 535 Cessna Business Park, Sarjapura Marathalli Outer Ring Road 536 Bangalore, KARNATAKA 560 087 537 India 539 Phone: +91 80 4426 1321 540 Email: ghalwasi@cisco.com 542 Sindhura Bandi 543 Cisco Systems 544 Cessna Business Park, Sarjapura Marathalli Outer Ring Road 545 Bangalore, KARNATAKA 560 087 546 India 548 Phone: +91 80 4426 2347 549 Email: sinb@cisco.com 551 Sri Gundavelli 552 Cisco Systems 553 170 West Tasman Drive 554 San Jose, CA 95134 555 USA 557 Email: sgundave@cisco.com 559 Hui Deng 560 China Mobile 561 53A, Xibianmennei Ave., Xuanwu District 562 Beijing 100053 563 China 565 Email: denghui02@gmail.com