idnits 2.17.1 draft-hou-pim-drlb-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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 15, 2011) is 4576 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: 'RFC3973' is defined on line 506, but no explicit reference was found in the text == Unused Reference: 'RFC5015' is defined on line 510, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) -- Duplicate reference: RFC4601, mentioned in 'HELLO-OPT', was also mentioned in 'RFC4601'. -- Obsolete informational reference (is this intentional?): RFC 4601 (ref. 'HELLO-OPT') (Obsoleted by RFC 7761) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Yiqun Cai 3 Internet-Draft Sri Vallepalli 4 Intended status: Standards Track Heidi Ou 5 Expires: April 17, 2012 Cisco Systems, Inc. 6 Andy Green 7 British Telecom 8 October 15, 2011 10 Protocol Independent Multicast DR Load Balancing 11 draft-hou-pim-drlb-00.txt 13 Abstract 15 On a multi-access network such as an Ethernet, one of the PIM routers 16 is elected as a Designated Routers (DR). The PIM DR has two roles in 17 the PIM protocol. On the first hop network, the PIM DR is 18 responsible for registering an active source to the RP if the group 19 is operated in PIM SM. On the last hop network, the PIM DR is 20 responsible for tracking local multicast listeners and forwarding 21 traffic to these listeners if the group is operated in PIM SM/SSM/DM. 22 In this document, we propose a modification to the PIM protocol that 23 allows multiple of these last hop routers to be selected so that the 24 forwarding load can be distributed to and handled among these 25 routers. A router responsible for forwarding for a particular group 26 is called a Group Designated Router (GDR). 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on April 17, 2012. 45 Copyright Notice 47 Copyright (c) 2011 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 6 65 4. Functional Overview . . . . . . . . . . . . . . . . . . . . . 6 66 4.1. GDR Candidates . . . . . . . . . . . . . . . . . . . . . . 7 67 4.2. Hash Mask . . . . . . . . . . . . . . . . . . . . . . . . 7 68 4.3. PIM Hello Options . . . . . . . . . . . . . . . . . . . . 8 69 5. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 8 70 5.1. PIM DR Load Balancing GDR (LBGDR) Hello TLV . . . . . . . 8 71 5.2. PIM DR Load Balancing Hash Masks (LBM) Hello TLV . . . . . 9 72 6. Protocol Specification . . . . . . . . . . . . . . . . . . . . 9 73 6.1. PIM DR Operation . . . . . . . . . . . . . . . . . . . . . 10 74 6.2. PIM GDR Candidate Operation . . . . . . . . . . . . . . . 10 75 6.3. PIM Assert Modification . . . . . . . . . . . . . . . . . 11 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 77 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 78 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 12 79 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 10.1. Normative Reference . . . . . . . . . . . . . . . . . . . 12 81 10.2. Informative References . . . . . . . . . . . . . . . . . . 12 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 84 1. Terminologies 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in [RFC2119]. 90 With respect to PIM, this document follows the terminology that has 91 been defined in [RFC4601]. 93 This document also introduces the following new acronyms: 95 o GDR: GDR stands for "Group Designated Router". For each multicast 96 group, a hash algorithm (described below) is used to select one of 97 the routers as GDR. The GDR is responsible for initiating the 98 forwarding tree building for the corresponding group. 100 o GDR Candidate: a last hop router that has potential to become a 101 GDR. A GDR Candidate must have the same DR priority as the DR 102 router. It must send and process received new PIM Hello Options 103 as defined in this document. There might be more than one GDR 104 candidate on a LAN. But only one can become GDR for a specific 105 multicast group. 107 2. Introduction 109 On a multi-access network such as an Ethernet, one of the PIM routers 110 is elected as a Designated Routers (DR). The PIM DR has two roles in 111 the PIM protocol. On the first hop network, the PIM DR is 112 responsible for registering an active source to the RP if the group 113 is operated in PIM SM. On the last hop network, the PIM DR is 114 responsible for tracking local multicast listeners and forwarding to 115 these listeners if the group is operated in PIM SM/SSM/DM. 117 Considering the following last hop network in Figure 1. 119 ( core networks ) 120 | | | 121 | | | 122 R1 R2 R3 123 | | | 124 --(last hop LAN)-- 125 | 126 | 127 (many receivers) 129 Figure 1: Last Hop Network 131 Assuming R1 is elected as the Designated Router. According to 132 [RFC4601], R1 will be responsible for forwarding to the last hop LAN. 133 In addition to keeping track of IGMP and MLD membership reports, R1 134 is also responsible for initiating the creation of source and/or 135 shared trees towards the senders or the RPs. 137 Forcing sole data plane forwarding responsibility on the PIM DR 138 proves a limitation in the protocol. In comparison, even though an 139 OSPF DR, or an IS-IS DIS, handles additional duties while running the 140 OSPF or IS-IS protocols, they are not required to be solely 141 responsible for forwarding packets for the network. On the other 142 hand, on a last hop LAN, only the PIM DR is asked to forward packets 143 while the other routers handle only control traffic (and perhaps 144 dropping packets due to RPF failures). The forwarding load of a last 145 hop LAN is concentrated on a single router. 147 This leads to several issues. One of the issues is that the 148 aggregated bandwidth will be limited to what R1 can handle towards 149 this particular interface. These days, it is very common that the 150 last hop LAN usually consists of switches that run IGMP/MLD or PIM 151 snooping. This allows the forwarding of multicast packets to be 152 restricted only to segments leading to receivers who have indicated 153 their interest in multicast groups using either IGMP or MLD. The 154 emergence of the switched Ethernet allows the aggregated bandwidth to 155 exceed, some times by a large number, that of a single link. For 156 example, let us modify Figure 1 and introduce an Ethernet switch in 157 Figure 2. 159 ( core networks ) 160 | | | 161 | | | 162 R1 R2 R3 163 | | | 164 +=gi0===gi1===gi2=+ 165 + + 166 + switch + 167 + + 168 +=gi4===gi5===gi6=+ 169 | | | 170 H1 H2 H3 172 Figure 2: Last Hop Network with Ethernet Switch 174 Let us assume that each individual link is a Gigabit Ethernet. Each 175 router, R1, R2 and R3, and the switch have enough forwarding capacity 176 that can handle hundreds of Gigabits of data. 178 Let us further assume that each of the hosts requests 500 mbps of 179 data and different traffic is requested by each host. This 180 represents a total 1.5 gbps of data, which is under what each switch 181 or the combined uplink bandwidth across the routers can handle, even 182 under failure of a single router. 184 On the other hand, the link between R1 and switch, via port gi0, can 185 only handle a throughput of 1gbps. And if R1 is the only router, the 186 PIM DR elected using the procedure defined by RFC 4601, at least 500 187 mbps worth of data will be lost because the only link that can be 188 used to draw the traffic from the routers to the switch is via gi0. 189 In other words, the entire network's throughput is limited by the 190 single connection between the PIM DR and the switch (or the last hop 191 LAN as in Figure 1). 193 The problem may also manifest itself in a different way. For 194 example, R1 happens to forward 500 mbps worth of unicast data to H1, 195 and at the same time, H2 and H3 each requests 300 mbps of different 196 multicast data. Once again packet drop happens on R1 while in the 197 mean time, there is sufficient forwarding capacity left on R2 and R3 198 and link capacity between the switch and R2/R3. 200 Another important issue is related to failover. If R1 is the only 201 forwarder on the last hop network, in the event of a failure when R1 202 goes out of service, multicast forwarding for the entire network has 203 to be rebuilt by the newly elected PIM DR. However, if there was a 204 way that allowed multiple routers to forward to the network for 205 different groups, failure to one of the routers would only lead to 206 disruption to a subset of the flows, therefore improving the overall 207 resilience of the network. 209 In this document, we propose a modification to the PIM protocol that 210 allows multiple of these routers, called Group Designated Router 211 (GDR) to be selected so that the forwarding load can be distributed 212 to and handled by a number of routers. 214 3. Applicability 216 The proposed change described in this draft applies to PIM last hop 217 routers only. 219 It doesn't alter the behavior of a PIM DR on the first hop network. 220 This is because the source tree is built using the IP address of the 221 sender, not the IP address of the PIM DR that sends the registers 222 towards the RP. The load balancing between first hop routers can be 223 achieved naturally if an IGP provides equal cost multiple paths 224 (which it usually does in practice). And distributing the load to do 225 registering doesn't justify the additional complexity required to 226 support it. 228 4. Functional Overview 230 In existing PIM DR election, when multiple last hop routers are 231 connected to a multi-access network (for example, an Ethernet), one 232 of them is selected to act as PIM DR. The PIM DR is responsible for 233 sending Join/Prune messages to the RP or source. To elect the PIM 234 DR, each PIM router on the network examines the received PIM Hello 235 messages and compares its DR priority and IP address with those of 236 its neighbors. The router with the highest DR priority is the PIM 237 DR. If there are multiple such routers, IP address is used as the 238 tie breaker, as described in [RFC4601]. 240 In order to share forwarding load among last hop routers, besides the 241 normal PIM DR election, the GDR is also elected on the last hop 242 multi-access network. There is only one PIM DR on the multi-access 243 network, but there might be multiple GDR candidates. 245 For each multicast group, a hash algorithm is used to select one of 246 the routers to be the GDR. Hash Masks are defined for Source, Group 247 and RP separately, in order to handle different PIM modes. The masks 248 are announced in PIM Hello as a new Load Balancing Hash Mask TLV (LBM 249 TLV). Last hop routers with this new TLV and with the same DR 250 priority as the PIM DR are GDR candidates. 252 A simple hash algorithm based on the announced Source, Group or RP 253 masks allow one GDR to be assigned to a corresponding multicast 254 group, and that GDR is responsible for initiating the creation of 255 multicast forwarding tree for the group. 257 4.1. GDR Candidates 259 GDR is the new concept introduced by this draft. To become a 260 candidate GDR, a router must have the same DR priority as the DR. 261 For example, if there are 4 routers on the LAN: R1, R2, R3 and R4. 262 R1, R2 and R3 have the same DR priority while R4's DR priority is 263 less preferred. In this example, only R1, R2 and R3 will be eligible 264 for GDR election. R4 is not because R4 will not become a PIM DR 265 unless all of R1, R2 and R3 go out of service. 267 Further assuming router R1 wins the PIM DR election. In its Hello 268 packet, R1 will include the identity of R1, R2 and R3 (the GDR 269 candidates) besides its own Load Balancing Hash Mask TLV. The order 270 of the GDR candidates is converted to the ordinal number associated 271 with each GDR candidate. For example, addresses advertised by R1 is 272 R1, R2, R3, the ordinal number assigned to R1 is 0, to R2 is 1 and to 273 R3 is 2. 275 4.2. Hash Mask 277 A Hash Mask is used to extract a number of bits from the 278 corresponding IP address field (32 for v4, 128 for v6), and calculate 279 a hash value. A hash value is used to select GDR from GDR Candidates 280 advertised in order by PIM DR. For example, 0.255.0.0 defines a Hash 281 Mask for an IPv4 address that masks the first, the third and the 282 fourth octets. 284 There are three Hash Masks defined, 286 o RP Hash Mask 287 o Source Hash Mask 288 o Group Hash Mask 290 The Hash Masks must be configured on the PIM routers that can 291 potentially become a PIM DR. 293 For ASM groups, a hash value is calculated using the following 294 formula: 296 o hashvalue_RP = ((RP_address & RP_hashmask) >> N ) % M 298 RP_address is the address of the RP defined for the group. N is the 299 number of bits that are 0 from the right. M is the number of GDR 300 candidates as described above. 302 If RP_hashmask is 0, a hash value is also calculated using the group 303 Hash Mask in a similar fashion 305 o hashvalue_Group = ((Group_address & Group_hashmask) >> N) % M 307 For SSM groups, a hash value is calculated using both the source and 308 group Hash Mask 310 o hashvalue_SG = (((Source_address & Source_hashmask) >> N_S) ^ 311 ((Group_address & Group_hashmask) >> N_G)) % M 313 4.3. PIM Hello Options 315 When a non-DR PIM router that supports this draft sends a PIM Hello, 316 it includes a new option, called "Load Balancing Hash Masks TLV (LBM 317 TLV)". The LBM TLV consists of three Hash Masks as defined above. 319 Besides this new LBM TLV, the elected PIM DR router also includes a 320 "Load Balancing GDR TLV (LBGDR TLV)" in its PIM Hello. The LBGDR TLV 321 consists of the sorted addresses of all GDR candidates on the last 322 hop network. 324 The elected PIM DR router uses LBM TLV to calculate its LBGDR TLV. 325 The GDR candidates use LBM TLV and LBGDR TLV advertised by DR PIM 326 router to calculate hash value. 328 5. Packet Format 330 5.1. PIM DR Load Balancing GDR (LBGDR) Hello TLV 332 0 1 2 3 333 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 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | Type = TBD | Length | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | GDR Address(es) | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 Figure 3: GDR Hello TLV 342 Type: TBD 343 Length: 344 GDR Address (32/128 bits): Address(es) of GDR candidates. All 345 addresses must be in the same address family. The addresses are 346 sorted from high to low. The order is used as the ordinal number, 347 starting from 0, in hash value calculation. 349 This LBGDR TLV should only be advertised by the elected PIM DR 350 router. 352 5.2. PIM DR Load Balancing Hash Masks (LBM) Hello TLV 354 0 1 2 3 355 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 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | Type = TBD | Length | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | Group Mask | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | Source Mask | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | RP Mask | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 Figure 4: Hash Masks Hello TLV 368 Type: TBD. 369 Length: 370 Group Mask (32/128 bits): Mask 371 Source Mask (32/128 bits): Mask 372 RP Mask (32/128 bits): Mask 374 All masks must be in the same address family, with the same length. 376 This LBM TLV should be advertised by last hop routers, which support 377 this draft. 379 6. Protocol Specification 380 6.1. PIM DR Operation 382 The DR elect process is still the same as defined in [RFC4601]. A DR 383 supports this draft advertises a new Hello Option LBGRD TLV to 384 includes all GDR candidates. Moreover, same as non-DR routers, DR 385 also advertises LBM TLV Hello Option to indicate its capability of 386 supporting this draft. 388 LBGRD TLV is composed by sorting the addresses of all GDR candidates. 389 LBM TLV on PIM DR contains value of masks from user configuration. 391 If a PIM DR receives a neighbor Hello with LBGRD TLV, the PIM DR 392 should ignore the TLV. 394 If a PIM DR receives a neighbor Hello with LBM TLV, and the neighbor 395 has the same DR priority as PIM DR itself, the PIM DR should consider 396 the neighbor as a GDR candidate and insert the neighbor's address 397 into the sorted list of LBGRD TLV. 399 6.2. PIM GDR Candidate Operation 401 When an IGMP join is received, without this proposal, router R1 (the 402 PIM DR) will handle the join and potentially run into the issues 403 described earlier. Using this proposal, a simple algorithm is used 404 to determine which router is going to be responsible for building 405 forwarding trees on behalf of the host. 407 The algorithm works as follows, assuming the router in question is X 408 and a GDR Candidate: 410 o If the group is ASM, and if the RP Hash Mask announced by the PIM 411 DR is not 0.0.0.0, calculate the value of hashvalue_RP. If 412 hashvalue_RP is the same as the ordinal number assigned implicitly 413 to X by PIM DR, X becomes the GDR. 414 o If the group is ASM and if the RP Hash Mask announced by the PIM 415 DR is 0, obtain the value of hashvalue_Group. And compare that to 416 the ordinal value of X assigned by the PIM DR to decide if X is 417 the GDR 418 o If the group is SSM, then use hashvalue_SG to determine if X is 419 the GDR. 421 If X is the GDR for the group, X will be responsible for building the 422 forwarding tree. 424 A router that supports this draft advertises LBM TLV in its Hello, 425 even the router may not be a GDR candidate. 427 A GDR candidate may receive a LBM TLV from PIM DR router, with a 428 different Hash Masks as advertised in its own Hello LBM TLV. The GDR 429 candidate must use the Hash Masks advertised by the PIM DR Hello to 430 calculate the hash value. 432 A GDR candidate may receive a LBGDR TLV from a non-DR PIM router. 433 The GDR candidate must ignore such LBGDR TLV. 435 A GDR candidate may receive Hello from the elected PIM DR, and the 436 PIM DR doesn't support this draft. The GDR election described by 437 this draft will not take place, that is only the PIM DR joins the 438 multicast tree. 440 6.3. PIM Assert Modification 442 When routers restart, GDR may change for a specific group, which 443 might cause packet drops. 445 For example, if there are two streams G1 and G2, and R1 is the GDR 446 for G1 and R2 is the GDR for G2. When R3 comes up online, it is 447 possible that R2 becomes GDR for G1 and R3 becomes GDR for G2, and 448 rebuilding of the forwarding trees for G1 and G2 will lead to 449 potential packet loss. 451 This is not a typical deployment scenario but it still might happen. 452 Here we describe a mechanism to minimize the impact. 454 When the role of GDR changes as above, instead of immediately 455 stopping forwarding, R1 and R2 continue forwarding to G1 and G2 456 respectively, while in the same time, R2 and R3 build forwarding 457 trees for G1 and G2 respectively. This will lead to PIM Asserts. 459 The same tie breakers are used to select an Assert winner with one 460 modification. That is, instead of comparing IP addresses as the last 461 resort, a router considers whether the sender of an Assert is a GDR. 462 In this example, R1 will let R2 be the assert winner for G1, and R2 463 will do the same for R3 for G2. This will cause some duplicates in 464 the network while minimizing packet loss. 466 If a router on the LAN doesn't support this draft, the Assert 467 modification described above will not take place, that is only the IP 468 address of an Assert sender is used as the tie breaker. Fore 469 example, if R4, with preferred IP address, doesn't understand GDR and 470 sends Assert for G1, R2, the GDR for G1, will grant R4 as the Assert 471 winner, clear OIF on R2. 473 7. IANA Considerations 475 Two new PIM Hello Option Types are required to assign to the DR Load 476 Balancing messages. According to [HELLO-OPT], this document 477 recommends 32(0x20) as the new "PIM DR Load Balancing GDR Hello 478 Option", and 33(0x21) as the new "PIM DR Load Balancing Hash Masks 479 Hello Option" . 481 8. Security Considerations 483 Security of the PIM DR Load Balancing Hello message is only 484 guaranteed by the security of PIM Hello packet, so the security 485 considerations for PIM Hello packets as described in PIM-SM [RFC4601] 486 apply here. 488 9. Acknowledgement 490 The authors would like to thank Steve Simlo, Taki Millonis for 491 helping with the original idea, ??? for their review comments. 493 10. References 495 10.1. Normative Reference 497 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 498 Requirement Levels", BCP 14, RFC 2119, March 1997. 500 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 501 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 502 Protocol Specification (Revised)", RFC 4601, August 2006. 504 10.2. Informative References 506 [RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol 507 Independent Multicast - Dense Mode (PIM-DM): Protocol 508 Specification (Revised)", RFC 3973, January 2005. 510 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 511 "Bidirectional Protocol Independent Multicast (BIDIR- 512 PIM)", RFC 5015, October 2007. 514 [HELLO-OPT] 515 IANA, "PIM Hello Options", PIM-HELLO-OPTIONS per 516 RFC4601 http://www.iana.org/assignments/pim-hello-options, 517 March 2007. 519 Authors' Addresses 521 Yiqun Cai 522 Cisco Systems, Inc. 523 Tasman Drive 524 San Jose, CA 95134 525 USA 527 Email: ycai@cisco.com 529 Sri Vallepalli 530 Cisco Systems, Inc. 531 Tasman Drive 532 San Jose, CA 95134 533 USA 535 Email: svallepa@cisco.com 537 Heidi Ou 538 Cisco Systems, Inc. 539 Tasman Drive 540 San Jose, CA 95134 541 USA 543 Email: hou@cisco.com 545 Andy Green 546 British Telecom 547 Adastral Park 548 Ipswich IP5 2RE 549 United Kingdom 551 Email: andy.da.green@bt.com