idnits 2.17.1 draft-tarapore-mboned-multicast-cdni-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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** 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.) (A line matching the expected section header was found, but with an unexpected indentation: ' 7. IANA Considerations' ) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 22, 2012) is 4197 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-18) exists of draft-ietf-mboned-auto-multicast-13 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MBONED Working Group Percy S. Tarapore 2 Internet Draft Robert Sayko 3 Intended status: BCP AT&T 4 Expires: January 21, 2013 Ram Krishnan 5 Brocade 6 October 22, 2012 8 Multicast Considerations in Support of CDN-I 9 draft-tarapore-mboned-multicast-cdni-01.txt 11 Status of this Memo 13 This Internet-Draft is submitted in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 This Internet-Draft will expire on January 22, 2013. 34 Copyright Notice 36 Copyright (c) 2012 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 47 Internet-Draft Multicast Considerations in Support of CDN-I October 48 2012 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Abstract 55 This document examines the current capabilities of multicast to 56 support content distribution in an environment involving multiple 57 Service Providers joining together to form a Content Distribution 58 Network Interconnection (CDN-I) Federation. 60 Table of Contents 62 1. Introduction...................................................2 63 2. CDN Nomenclature and High Level Overview.......................3 64 3. Multicast Use Cases for a CDN-I Federation.....................5 65 3.1. Native Multicast Use Case.................................5 66 3.2. Automatic Multicast Tunneling Use Cases...................6 67 3.2.1. AMT Interconnection Between P-CDN and S-CDN..........6 68 3.2.2. AMT Tunnel Connecting S-CDN and EU...................7 69 3.2.3. AMT Tunnel Connecting EU to P-CDN Through Non-Multicast 70 S-CDN.......................................................7 71 4. Content Types Suitable for Multicast-based CDN.................8 72 4.1. Live Content...................Error! Bookmark not defined. 73 4.2. "Delayed-Play" Download........Error! Bookmark not defined. 74 4.3. "Instant-Play" Download........Error! Bookmark not defined. 75 5. Evaluation of Native Multicast for CDN.........................8 76 6. Evaluation of AMT for CDN......................................9 77 7. Security Considerations.......................................14 78 8. IANA Considerations...........................................14 79 TBD..............................................................14 80 9. Conclusions...................................................14 81 10. References...................................................14 82 10.1. Normative References....................................14 83 10.2. Informative References..................................15 84 11. Acknowledgments..............................................15 86 1. Introduction 88 Content Providers (CP) are experiencing significant growth in demand 89 for all types of internet-based content. A single "over-the-top" CP 90 would require significant resources to deliver content that could be 91 requested from anywhere in the world. Service Providers (SP) are 92 taking advantage of this situation by forming Content Distribution 93 Network (CDN) Federations for the purpose of distributing content on 95 Internet-Draft Multicast Considerations in Support of CDN-I October 96 2012 98 behalf of Content Providers (CP). There are several advantages to 99 such CDN Federations: 101 o CPs can simply contract with one or more SPs in a CDN Federation 102 for delivery of their content. This enables CPs to concentrate on 103 their main objective - creation of content. 105 o SPs can expand their geographic reach via distribution agreements 106 with Federation members without developing costly resources 107 outside their local territories. 109 Multicast-based delivery mechanisms are a natural fit for content 110 distribution in the proposed CDN Federations. The scope of this 111 document is strictly focused on the interactions between CDN 112 Federation members to support multicast-based content distribution. 113 The purpose of this document is the detailed examination of 114 applicable multicast techniques and the identification of detailed 115 data/metadata/parameters that will have to be exchanged by CDN 116 Federation members to enable multicast-based content distribution. 118 2. CDN Nomenclature and High Level Overview 120 Terminology utilized to describe end-to-end user requests is 121 described as follows. 123 There are many entities involved in distribution of the content from 124 the CP all the way to the End User (EU). Figure 1 is a diagram 125 depicting the basic logical relationships among the various roles 126 involved in content delivery. Besides the CP and EU, the two 127 remaining major entities are the two members of a CDN Federation - 128 the Primary CDN Provider (P-CDN) and the Supporting CDN Provider (S- 129 CDN) [A-0200003]. The relationships between these entities are as 130 follows - see Figure 1. 132 1. The Content Provider owns the content and specifies conditions of 133 delivery and use. The End User interacts with the CP (link 1 in 134 the figure) for authentication and authorization, and to reach an 135 agreement to obtain specific content (content selection, content 136 purchase, acknowledgement of conditions of use). The CP has the 137 legal right to distribute content and specify conditions for 138 distribution. 140 2. The CP has an agreement and interacts with the P-CDN for deploying 141 content (link 2). The content is assumed to be retrieved by the P- 142 CDN from the CP Origin server. 144 Internet-Draft Multicast Considerations in Support of CDN-I October 145 2012 147 3. The P-CDN in turn has an agreement with an S-CDN for deploying and 148 distributing content (link 3). 150 4. The End User is attached to S-CDN for access and obtains the 151 content from the S-CDN (link 4). The End User also interacts with 152 the CP (link 1) as indicated above. 154 ----------------------------------------------- 155 | (1) | 156 v | 157 +---------+ +---------+ +---------+ +---------+ 158 | | | | | | | | 159 | Content | | Primary | | Suppor- | | End | 160 | Provider| --> | CDN | --> | -ting | --> | User | 161 | | (2) | | (3) | CDN | (4) | | 162 | | | | | | | | 163 +---------+ +---------+ +---------+ +---------+ 165 Figure 1 - Relationships in a CDN Federation 167 Note that all SPs in the CDN Federation can play the role of P-CDN 168 (active relationship with a CP) as well as an S-CDN (attach EUs and 169 distribute content from P-CDN to EUs). 171 Using the above nomenclature, a CDN Federation is assumed to comprise 172 multiple SPs that agree to function as CDN Providers and distribute 173 content to End Users on behalf of CPs. The term 'SP' in this context 174 is synonymous with the term 'CDN Provider' for the purpose of this 175 document. A CP is assumed to have a contract with one or more SPs for 176 the purpose of content delivery. A high level content request flow is 177 described as follows: 179 o An End User discovers a specific content on a CP website and 180 requests delivery of the same. The CP selects one CDN Provider 181 with whom it has contracts for content delivery. The rules for 182 CDN Provider selection are part of the CP . CDN Provider 183 contract and are out of scope for this document. The selected 184 CDN Provider functions as the P-CDN. 186 Internet-Draft Multicast Considerations in Support of CDN-I October 187 2012 189 o The P-CDN then determines the mode of content delivery - either 190 cache/unicast or multicast depending on the type of content and 191 its own capabilities and resources. It then determines whether 192 to deliver the content directly to the End User or utilize 193 another CDN Provider based on rules such as proximity, available 194 resources, common delivery methods (e.g., multicast), etc. These 195 selection rules are out of scope of this document. In case 196 another CDN Provider is selected, then that entity assumes the 197 role of the S-CDN. 199 o The P-CDN then initiates the delivery process via the S-CDN's 200 domain - the S-CDN acts as the "point of delivery" to the End 201 User. 203 The simple scenario described here is common to both delivery 204 mechanisms - cache/unicast as well as multicast. The purpose of this 205 document is to address all multicast related aspects in support of 206 multicast-based content delivery. 208 3. Multicast Use Cases for a CDN-I Federation 210 Use cases involving multicast methods for distributing content in a 211 CDN Federation have been described in [A-0200004]. 213 3.1. Native Multicast Architectural Use Case 215 ------------------- ------------------- 216 / P-CDN \ / S-CDN \ 217 / (Multicast Enabled) \ / (Multicast Enabled) \ 218 / \ / \ 219 | +----+ | | | 220 | | | +------+ | | +------+ | +----+ 221 | | CS |------>| BR |-|---------|->| BR |-------------|--->| EU | 222 | | | +------+ | I1 | +------+ | I2 +----+ 223 \ +----+ / \ / 224 \ / \ / 225 \ / \ / 226 ------------------- ------------------- 228 CS = Content Multicast Source (assumes that the Content Source 229 retrieves content from CP Origin) 230 BR = Border Router 231 I1 = P-CDN and S-CDN Multicast Interconnection (MBGP or BGMP) 232 I2 = S-CDN and EU Multicast Connection 234 Figure 1 - Content Distribution via End to End Native Multicast 236 Internet-Draft Multicast Considerations in Support of CDN-I October 237 2012 239 This case assumes that both CDN Providers as well as the 240 interconnection between them and the connection between the EU and S- 241 CDN are all multicast enabled. 243 3.2. A variation of this "pure" Native Multicast case is when the 244 interconnection I1 between the CDNs is multicast enabled via a 245 Generic Routing Encapsulation Tunnel (GRE) [RFC2784] and 246 encapsulating the multicast protocols across the interface. 247 Automatic Multicast Tunneling Architectural Use Cases 249 In reality, the initial introduction of multicast may not be fully 250 multicast enabled resulting in "Multicast Islands" requiring 251 Automatic Multicast Tunnels (AMT) for enabling multicast connections 252 between them [IETF-ID-AMT]. 254 3.2.1. AMT Interconnection Between P-CDN and S-CDN 256 ------------------- ------------------- 257 / P-CDN \ / S-CDN \ 258 / (Multicast Enabled) \ / (Multicast Enabled) \ 259 / \ / \ 260 | +----+ | | | 261 | | | +------+ | | +------+ | +----+ 262 | | CS |------>| AR |-|---------|->| AG |-------------|--->| EU | 263 | | | +------+ | I1 | +------+ | I2 +----+ 264 \ +----+ / \ / 265 \ / \ / 266 \ / \ / 267 ------------------- ------------------- 269 AR = AMT Relay 270 AG = AMT Gateway 271 I1 = AMT Interconnection between P-CDN and S-CDN 272 I2 = S-CDN and EU Multicast Connection 274 Figure 3 - AMT Interconnection between P-CDN and S-CDN 276 This configuration assumes both CDN Providers are multicast enabled. 277 Only the interconnection between them is not multicast enabled and 278 hence, an AMT tunnel is established between them as shown in Figure 279 3. 281 Internet-Draft Multicast Considerations in Support of CDN-I October 282 2012 284 3.2.2. AMT Tunnel Connecting S-CDN and EU 286 ------------------- ------------------- 287 / P-CDN \ / S-CDN \ 288 / (Multicast Enabled) \ / (Multicast Enabled) \ 289 / \ / \ 290 | +----+ | | | 291 | | | +------+ | | +------+ +------+ | +----+ 292 | | CS |------>| BR |-|---------|->| BR |--->| AR |-|--->| EU | 293 | | | +------+ | I1 | +------+ +------+ | I2 +----+ 294 \ +----+ / \ / 295 \ / \ / 296 \ / \ / 297 ------------------- ------------------- 299 CS = Content Server 300 BR = Border Router 301 AR = AMT Relay 302 I1 = P-CDN and S-CDN Multicast Interconnection (MBGP or BGMP) 303 I2 = AMT Connection between S-CDN and EU 305 Figure 4 - AMT Tunnel Connecting S-CDN and EU 307 This case involves EU devices that are not multicast enabled. Hence 308 an AMT Tunnel is established between the S-CDN AMT Relay and the EU 309 device. This implies one tunnel per EU - potentially several AMT 310 tunnels may need to be setup. 311 Note that there could be configurations involving both situations 312 described in 3.2.1 and 3.2.2. 314 3.2.3. AMT Tunnel Connecting EU to P-CDN Through Non-Multicast S-CDN 316 This Use Case assumes that EU attached to the non-multicast enabled 317 S-CDN has a device populated with a client that establishes an AMT 318 tunnel to the AMT Relay in the P-CDN. 320 This configuration is needed when the S-CDN is not multicast-enabled. 321 This is the most "extreme" AMT case as the length of the tunnels as 322 well as the number of tunnels can be large. 324 Internet-Draft Multicast Considerations in Support of CDN-I October 325 2012 327 ------------------- ------------------- 328 / P-CDN \ / S-CDN \ 329 / (Multicast Enabled) \ / (Non-Multicast \ 330 / \ / Enabled) \ 331 | +----+ | | | 332 | | | +------+ | | | +----+ 333 | | CS |------>| AR |-|---------|-----------------------|--->| EU | 334 | | | +------+ | | | I2 +----+ 335 \ +----+ / \ / 336 \ / \ / 337 \ / \ / 338 ------------------- ------------------- 340 CS = Content Source 341 AR = AMT Relay 342 I2 = AMT Tunnel Connecting EU to P-CDN Relay through Non-Multicast 343 Enabled S-CDN. 345 Figure 5 - AMT Tunnel Connecting P-CDN AMT Relay and EU 347 4. Content Types Suitable for Multicast-based CDN 349 This section highlights applications and content types that are 350 suitable for multicast-based delivery in a CDN Federation. Any unique 351 aspects of specific applications/content types that require special 352 attention are duly noted. 354 Note: Suggest we put in content types in tabular form followed by 355 this text: 357 For the purpose of this document, live streaming is chosen as a 358 typical multicast application for content distribution via a CDN 359 Federation. Note that a definition of live streaming needs to be 360 provided. 362 5. Evaluation of Existing Multicast Protocols to Support CDN-I 364 Use Case 3.1 describes Native Multicast configurations. This is the 365 "simplest" multicast case in that a single standard set of protocols 366 supports end-to-end content delivery from the CP to EU via two or 367 more fully multicast-enabled CDN Providers. It also provides for 368 efficient use of bandwidth and resources. 370 Internet-Draft Multicast Considerations in Support of CDN-I October 371 2012 373 Use Case 3.2.1 does deploy an AMT Tunnel for interconnecting two CDN 374 Providers; the rest of the configuration is Native Multicast - this 375 assumes that the EU devices are also multicast-enabled. 377 Thus existing Multicast capabilities need to be examined to determine 378 their ability to fully support content distribution in a CDN 379 Federation. A list of issues requiring examination is as follows: 381 o Delivery - Identification and communication of {Source, Group} 382 information and DNS information for provisioning across CDNs. 383 Details to be provided. 385 o Routing/Peering - Identification and acknowledgement of external 386 IP addresses particularly when utilizing a GRE Tunnel for 387 interconnecting CDNs. Details to be provided. 389 o Back-Office Functions - Identification of appropriate 390 data/metadata collected by Native Multicast to support usage of 391 content for billing, settlements, logging, etc. Details to be 392 provided. 394 o Security - Determine ability of Native Multicast to deal with 395 security risks such as bot attacks, denial of service, etc. 396 Details to be provided. Also, EU authentication and 397 authorization 399 o Others - To Be Determined 401 5.1. Use Case 3.1 403 In this Use Case, with E-T-E multicast connectivity, the P-CDN 404 provides source, routing and reporting functionality. The S-CDN 405 provides routing and reporting functions. 407 Though the CP is the origin the interface between the origin and the 408 MC source is out of scope. 410 Issues: 412 -what about performance and reliability "tricks" that may be employed 413 do we address here? 415 -Moving from network to network? Addressed in separate RFC 417 Internet-Draft Multicast Considerations in Support of CDN-I October 418 2012 420 -IPv4 to IPv6 (assumption) not addressed or in scope - need to 421 reference a standard if there is one 423 -expand definition of S-CDN??? 425 5.1.1. Delivery 427 1) If there exists end to end multicast between the EU and the MC 428 Source, then IGMP/MLD, PIM and MBGP protocols will ensure the 429 content stream is delivered to the requesting EU. 431 2) The (S,G) and in fact all parameters required by the application 432 related to the requested stream can be obtained by the client 433 application in a number of ways. None of which affects the MC 434 protocols and generally neither are the delivery mechanisms of the 435 parameters mutually exclusive. Examples are: 437 a. Upon selecting (clicking a link) on a web page for MC 438 content a file (Manifest file) is delivered via unicast to 439 the EU from the web page 441 b. An HTTP reply from the web page to the EU request may 442 contain the required parameters 444 c. An application may be "programmed" with the (S,G) and other 445 parameters. This method would require that the parameters 446 remain fairly static/stable. 448 d. An application may even require an EU to enter the (S,G) and 449 other parameters manually 451 3) There are a number of ways to control and communicate parameters 452 to the EU that direct the EU to the appropriate MC source. Eg. 454 a. The (S,G) can be FQDNs in which case DNS can be used to 455 select specific (S,G) address set. 457 b. When the EU selects the stream from the web page the 458 parameters forwarded back to to the EU can be selected based 459 on criteria related to the EU such as source IP, EU SP. 460 Decisions are driven by 462 i. Business relationship to the EU and/or EU CDN 464 Internet-Draft Multicast Considerations in Support of CDN-I October 465 2012 467 ii. Geographic location of SP 469 iii. On-net or off-net EU 471 iv. MC network conditions 473 v. TOD 475 vi. Etc 477 c. In ETE MC any intervening (transit) network or SP should not 478 make any attempt to change parameters forwarded to the EU 479 from the serving CDN. 481 i. Only a selected and participating S-CDN SP should, if 482 required, intercept and change any MC parameters 483 forwarded to the EU. There should be agreement between 484 the participating CDNs that this is permissible. 486 ii. If the S-CDN changes parameters this should be recorded 487 and reported to the upstream (P-CDN) CDN. 489 1. Generally reporting to the P-CDN will not be 490 required in real time 492 2. TBD = situations where it should be Real Time or 493 near RT 495 iii. An S-CDN should generally avoid unilaterally intercepting 496 and changing parameters values sent from an upstream 497 participating CDN (e.g. P-CDN)because this may cause 498 problems such as the following examples: 500 1. Performance issues in delivery to the EU 502 2. Conflicting/erroneous parameter values 504 3. Conflicting/erroneous authentication, authorization 505 or accounting 507 4) The MC Source application, which in the case of ETE is the P-CDN, 508 should employ techniques to ensure reliable deliver of the content 509 to the UE. The methodology or combination of methodologies will 510 often depend on the content type being delivered. There are 512 Internet-Draft Multicast Considerations in Support of CDN-I October 513 2012 515 several effective methods currently available, of which a few 516 examples are described below: 518 a. Carrouselling 520 b. FEC 522 c. Parallel streaming 524 d. Grid or burst severs 526 e. Unicast fallback 528 5.1.2. Routing and Peering 530 1) Routing between CDNi federation participants should be on a pair- 531 wise agreement and implementation 533 2) Route/peering preferences of the S-CDN should be communicated to 534 the P-CDN - how can this be done?????? How necessary is it? 536 a. Allow S-CDN to have some ability to balance peering traffic 538 b. Route around congestion. 540 3) CDNi participants must ensure that advertisement of the Source IP 541 address is provided across the peering interface. 543 a. If an Anycast address is to be used for the Source, then 544 participants must coordinate use of the Anycast address 545 space. 547 b. Coordination of the address space should be spelled out in 548 the participating members business arrangement/agreement 550 c. Coordination can occur in a pair-wise manner, but each CDN 551 with multiple arrangements must ensure that there are no 552 conflicts introduced into any individual arrangement. 554 4) If the peering interface is not multicast enabled a GRE tunnel 555 should be provisioned between the CDNi participants 557 a. Source IP must be advertised across the GRE tunnel 559 Internet-Draft Multicast Considerations in Support of CDN-I October 560 2012 562 b. The GRE tunnel may be provisioned to be terminated on 563 participants border routers 565 c. Alternatively, the P-CDN may desire to terminate the GRE 566 directly to the Source. This will allow the P-CDN to have a 567 separate IP address for external and internal EUs. 569 5) Is there a way a P-CDN can instruct a S-CDN router to not 570 broadcast its IGMP group memberships across its subnet????? 572 a. How is that communicated to the router 574 b. Is it a provisioning only option 576 c. Or can it be interactively done via some protocol message? 578 5.1.3. Back Office Functions 580 5.1.4. Security 582 5.2. Use Case 3.2.1 (AMT only across the peering interface) 584 5.2.1. Delivery 586 All the recommended practices of 5.1.1 are applicable, plus the 587 following additional: 589 1) The P-CDN and S-CDN should each deploy and provision an AMT Relay 590 at their respective peering interface(s) 592 2) These AMT Relay must also include and AMT Gateway (GW) function 594 3) The P-CDN and S-CDN must have an agreement that allows the S-CDN 595 to advertise the Source IP address across the S-CDN multicast 596 enabled network. 598 4) If the AMT interface fails or is out of service the P-CDN and S- 599 CDN interface agreement should include provision for unicast 600 failover. 602 Internet-Draft Multicast Considerations in Support of CDN-I October 603 2012 605 5.2.2. Routing and Peering 607 1) The GW function in the S-CDN AMT Relay can be provisioned with the 608 proper address (this may be an Anycast address) of the P-CDN AMT 609 Relay with connectivity to the source. Alternatively, if the MC 610 source IP (or Anycast address) is not provisioned then a mechanism 611 for the GW function to find the P-CDN Relay with connectivity to 612 the source must be available 614 a. A recommended mechanism for the GW to find the correct Relay 615 is documented in "the RFC draft being constructed" 617 b. The P-CDN and S-CDN agreements should cover the methodology 618 used 620 c. The agreement should specify how notification of MC Source 621 IP is communicated (including timing) 623 5.2.3. 625 5.2.4. 627 6. Security Considerations 629 TBD 631 7. IANA Considerations 633 TBD 635 8. Conclusions 637 TBD 639 9. References 641 9.1. Normative References 643 [RFC2784] D. Farinacci, T. Li, S. Hanks, D. Meyer, P. Traina, 644 "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000 646 [IETF-ID-AMT] G. Bumgardner, "Automatic Multicast Tunneling", draft- 647 ietf-mboned-auto-multicast-13, April 2012, Work in progress 649 Internet-Draft Multicast Considerations in Support of CDN-I October 650 2012 652 9.2. Informative References 654 [A-0200003] P. Tarapore, "CDN Interconnection Use Case Specifications 655 and High Level Requirements", ATIS Standard A-0200003, June 2011 656 (contact Nicole Butler at nbutler@atis.org using code IETF12 to 657 receive a free copy before September 30, 2012) 659 [A-0200004] P. Tarapore and R. Sayko, "CDN Interconnection Use Cases 660 and Requirements for Multicast-Based Content Distribution", ATIS 661 Standard A-0200004, January 2012 (contact Nicole Butler at 662 nbutler@atis.org using code IETF12 to receive a free copy before 663 September 30, 2012) 665 10. Acknowledgments 667 Internet-Draft Multicast Considerations in Support of CDN-I October 668 2012 670 Authors' Addresses 672 Percy S. Tarapore 673 AT&T 674 Phone: 1-732-420-4172 675 Email: tarapore@att.com 677 Robert Sayko 678 AT&T 679 Phone: 1-732-420-3292 680 Email: rs1983@att.com 682 Ram Krishnan 683 Brocade 684 Phone: 685 Email: ramk@brocade.com