idnits 2.17.1 draft-schulzrinne-lmap-requirements-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 : ---------------------------------------------------------------------------- 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 (September 21, 2012) is 4235 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 2679 (ref. '5') (Obsoleted by RFC 7679) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LMAP H. Schulzrinne 3 Internet-Draft W. Johnston 4 Intended status: Informational J. Miller 5 Expires: March 25, 2013 FCC 6 September 21, 2012 8 Large-Scale Measurement of Broadband Performance: Use Cases, 9 Architecture and Protocol Requirements 10 draft-schulzrinne-lmap-requirements-00 12 Abstract 14 Measuring broadband performance on a large scale is important for 15 network diagnostics by providers and users, as well for as public 16 policy. To conduct such measurements, user networks gather data, 17 either on their own initiative or instructed by a measurement 18 controller, and then upload the measurement results to a designated 19 measurement server. This document describes a logical architecture 20 and summarizes key requirements for protocols to connect the 21 components. The system is designed to support residential and small- 22 enterprise networks, using either wired or wireless networks. The 23 architecture supports an extensible set of active and passive 24 measurements, but the details of the metrics themselves are beyond 25 the scope of this document. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on March 25, 2013. 44 Copyright Notice 46 Copyright (c) 2012 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 3. Architecture Overview . . . . . . . . . . . . . . . . . . . . 8 64 3.1. Measurement client . . . . . . . . . . . . . . . . . . . . 8 65 3.2. Measurement server . . . . . . . . . . . . . . . . . . . . 8 66 3.3. Measurement controller . . . . . . . . . . . . . . . . . . 8 67 3.4. Data collector . . . . . . . . . . . . . . . . . . . . . . 8 68 3.5. Network parameter server . . . . . . . . . . . . . . . . . 9 69 4. Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 5. Initiation of Measurements . . . . . . . . . . . . . . . . . . 12 71 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 13 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 74 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 75 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 76 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19 77 10.2. Informative References . . . . . . . . . . . . . . . . . . 19 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 80 1. Introduction 82 Measuring actual network performance is crucial to managing consumer 83 and enterprise networks, but, when performed at scale, it also allows 84 third parties to gain insight into the actual performance of such 85 networks, facilitating consumer choice and allowing to evaluate the 86 state of broadband performance in a country, among other public 87 policy goals. A number of network performance metrics have been 88 defined, such as [2], but there is no overall architecture and set of 89 protocols that facilitates gathering such measurements in a 90 coordinated way, at scales drawing on thousands or millions of nodes. 92 Large-scale measurement efforts (e.g., [3]) use proprietary, custom- 93 designed mechanisms to coordinate the measurement clients. They 94 require that the organization running the measurements deploy 95 thousands of dedicated hardware components or rely on end-system 96 software modules that are subject to exogeneous factors, such as home 97 networks, that may distort the results. Thus, this document proposes 98 an overall architecture, with emphasis on the functional and security 99 requirements for the protocols connecting the elements of the 100 architecture, that will make it possible to build measurement 101 capabilities into home and enterprise edge routers, personal 102 computers, mobile devices and other edge devices. 104 Any usage and implementation will likely impose a number of 105 additional operational requirements and a statistical sampling 106 methodology. For example, the Measurement Broadband America project 107 [3] within the US Federal Communications Commission (FCC) has 108 established specific operational guidelines on data validity and 109 commits to specific requirements for open access to measurement data, 110 software tools and documentation of measurement methodology and 111 statistical approaches. While crucial for deployment, these are 112 beyond the scope of this protocol requirements document. Also, as is 113 customary for IETF-managed protocols, this document does not mandate 114 a specific hardware or operating system platform for implementation. 116 We suggest that the IETF IP Performance Metrics (IPPM) working group 117 take on defining any additional performance metrics as needed. Such 118 an effort should be undertaken as a collaborative effort with the 119 Broadband Forum (BBF) [4]; other SDOs may also take on aspects of 120 this problem area. 122 In some applications, such as data gathering by local regulatory 123 entities, extensive logging at various levels, from packet arrival 124 times to events, will be used to assure all parties of the validity 125 of the data gathered. However, logging is beyond the scope of this 126 document. 128 Both active and passive measurement techniques have been widely 129 accepted in practice. In active measurements, the end systems emits 130 traffic and observes a performance metric, or has another end point 131 do so. Examples of active measurements include round-trip delay [2], 132 one-way delay [5] and throughput [6] metrics, service availability, 133 as well as a range of measurements that try to emulate application 134 behavior, such as VoIP, HTTP retrievals or media streaming. Passive 135 measurements observe existing user traffic flows. We note that there 136 is some overlap between NetFlow [7] measurements and passive 137 measurements described here. The delineation between the two and 138 possible re-use of functionality are left to further discussion. 140 For both active and passive measurements, a measurement client sends 141 or observes traffic, respectively. For active measurements, the 142 measurement client may need a measurement server as serve as 143 recipient of the measurement traffic. (In some cases, such as 144 measurements modeling user access to network services, such as web 145 page retrieval performance, the measurement traffic is exchanged with 146 a production server, such as a web server, but this requires careful 147 design to avoid overloading that server with measurement traffic.) 148 Since we are interested in large-scale measurements, we assume that a 149 measurement controller provides the measurement client with 150 information on what to measure and when to perform the measurements. 151 Finally, in some cases, a measurement data collector gathers data, 152 typically samples rather than aggregate data, collected by the 153 measurement clients for later analysis. The data models and file 154 formats for supporting the exchange of the test parameters as well as 155 test results require standardization. 157 As noted above, it appears likely that metrics will evolve and new 158 ones will be added over time. Components of the platform may be 159 designed and operated by different, independent entities, or, at 160 minimum, data gathered by the platform may be used by different 161 parties for different purposes. For example, a regulator or ISP 162 might contract with third parties to manage various components of a 163 measurement effort, and all data communications must securely support 164 the delegation and authentication of rights and responsibilities to 165 perform any operational parameter supported by the measurement 166 architecture. Thus, it will be important to agree to on a set of 167 metrics and associated metric-specific protocol parameters. For 168 example, the TCP throughput metric defined in [6] depends on the TCP 169 congestion avoidance algorithm. Each measurement run generates one 170 or more data samples, e.g., a set of throughput values. The 171 controller needs to convey those parameters to the measurement client 172 and the data collector needs to be able to determine unambiguously 173 which parameters were used for a specific set of data samples. 175 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 176 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 177 document are to be interpreted as described in [1]. Although RFC 178 2119 was written with protocols in mind, the key words are used in 179 this document to indicate the strength of a requirement. 181 2. Use Cases 183 Large-scale, automated measurements are helpful in a number of use 184 cases. We illustrate the scope with three examples: 186 Provider network measurements: Internet service providers have an 187 interest in knowing how well their networks are performing, as 188 viewed from their customers' perspective. Such performance 189 information allows them to identify bottlenecks and observe the 190 impact of changes in user behavior, e.g., the emergence of new 191 network applications or time-of-day patterns. Here, the provider 192 is not interested in the performance of an individual edge network 193 or device, but rather wants to get a statistically-valid sample of 194 performance across their network. Service providers may be 195 interested in both the end device performance, i.e., the 196 performance as seen by edge devices in home and enterprise 197 networks, as well as the edge performance, i.e., as seen by the 198 network device directly attached to their network, such as a cable 199 modem, DSL modem or enterprise edge router. To reduce the network 200 load, providers are unlikely to gather measurements from all 201 clients all the time, but rather sample randomly across both time 202 and their user population. The measurement controller directs the 203 measurement client what measurements are to be performed, what 204 measurement servers to use, when to measure and at which data 205 collector it should deposit the measurement data. 207 User network diagnostics: End users may want to determine whether 208 their network is performing according to the specifications (e.g., 209 service level agreements) offered by the Internet service 210 provider, or they may want to diagnose whether components of their 211 network path are impaired. End users may perform measurements on 212 their own, using the measurement infrastructure they provide or 213 infrastructure offered by a third party, or they may work directly 214 with their network or application provider to diagnose a specific 215 performance problem. Depending on the circumstances, measurements 216 may occur at specific pre-defined intervals, or may be triggered 217 manually. A system administrator may perform such measurements on 218 behalf of the user. 220 Multi-provider network measurements: As an extension of the first 221 use case, multiple network providers and third parties, such as a 222 regulatory body, may collaborate to gather network performance 223 data on a one-time or recurring basis, using a subset of customers 224 of the service providers. The form of collaboration is beyond the 225 scope of this paper, however it should be understood that a data 226 collection platform must serve multiple stakeholder interests. 228 In the description above, the network provider can either be a 229 commercial or not-for-profit entity distinct from the network edge 230 users, or it can be the information technology department in a local 231 area network. Particularly for the user diagnostics use case, it may 232 be helpful for the measurement client to obtain parameters of their 233 connectivity, such as the nominal uplink and downlink speed. In 234 other cases, only the entity performing the data analysis may need to 235 know the nominal performance parameters. 237 3. Architecture Overview 239 We define a measurement platform to consist of one or more 240 measurement clients, measurement controllers and data collection 241 servers. Based on the use cases above, we summarize their functions 242 below. 244 3.1. Measurement client 246 The measurement client is the reference point for measurements. For 247 active measurements, it sends measurement traffic to the measurement 248 server or other network elements. For passive measurements, it 249 observes network performance metrics. Client measurement 250 functionality must be implementable in a variety of user contexts and 251 provide for communications within different network segments, such as 252 the access link between a broadband subscribers modem and an ISP 253 network, as well as consumer electronic device communicating to 254 measurement server features in a wireless LAN device. 256 3.2. Measurement server 258 The measurement server is only needed for active measurements that 259 require two network nodes. The measurement server typically operates 260 as a traffic source or sink. To allow scaling, different clients 261 within a measurement platform may use different measurement servers. 262 Clients may also select, for example, the closest measurement server 263 if the influence of wide-area connectivity on measurement results is 264 to be minimized. 266 3.3. Measurement controller 268 The measurement controller provides the measurement client with 269 instructions on when and how to conduct what measurements, i.e., the 270 measurement schedule. For example, it might instruct the client to 271 conduct a particular kind of throughput measurement every ten 272 minutes, and to deposit the throughput samples into a particular data 273 collector. Measurement controllers may be capable of accepting 274 inputs from other controllers, scaling up the scope of the 275 measurement system. As one example, an ISP operating a testing 276 platform for its own network may accept test requests from an 277 external controller as part of a nationwide testing program that it 278 is participating in. 280 3.4. Data collector 282 The data collector collects time-stamped measurement samples from 283 measurement clients. It generally makes these measurement samples 284 available only to authorized users. The data collector may store 285 measurement samples in a database or as files and may make them 286 available via download or SQL query. Access control, internal data 287 storage and access methods to data are beyond the scope of this 288 document. 290 We logically separate the data collector from the measurement server 291 for both functional and performance reasons. In general, data 292 collected should not be transferred to the collector while a 293 measurement is in progress. Also, a measurement client on a mobile 294 host may decide to delay transferring measurement data until a low- 295 cost or high-speed connection to the server becomes available. 297 3.5. Network parameter server 299 In some of the use cases, it is necessary for the analysis to compare 300 the measured against the nominal network performance, or correlate 301 measured parameters with the type and key parameters of the userOs 302 network connection. For example, for evaluating network delay 303 measurements, it is helpful to know what kind of access technology 304 (e.g., FTTP, DSL, cable, cellular data or satellite) and nominal 305 speed the network connection offers. 307 4. Protocols 309 With the description of the elements above and the relationships 310 between them, a set of protocols needs to be defined. The key 311 functions of the protocols are described briefly below. 313 Measurement client to measurement server: Each metric will have its 314 own set of measurement protocols, and these are beyond the scope 315 of this document. For example, a VoIP metric may use a defined 316 set of UDP packets to estimate performance. 318 Measurement client to measurement controller: The measurement client 319 queries the measurement controller to obtain an updated 320 measurement schedule. The measurement schedule returned by the 321 controller indicates the type of measurements the measurement 322 client should perform, the measurement servers and on what 323 schedule to conduct the measurements. For example, it might 324 indicate to run a VoIP emulation test every day for ten minutes to 325 a specific server, spanning a one-week measurement campaign. The 326 collector also indicates one or more addresses of data collectors 327 to the client. 329 Measurement controller to measurement controller: A measurement 330 controller can request that another controller undertake a 331 specific testing program and could indicate specific tests, 332 schedules and sample parameters appropriate to the intended 333 objectives. Other data could include the identity and identity 334 verification of the requester, a specific test identifier, e.g. 335 Nationwide Test XX, and information necessary for the data 336 collector so that data is accessible to authorized parties. 338 Measurement client to data collector: The measurement client will 339 typically perform one or more measurements, and then, during the 340 pause between measurements, transmit the collected samples to the 341 data collector. The samples must be tagged with identifying 342 information, such as when they were collected, edge device 343 information (e.g., the mobile device or cable modem) and which 344 measurement host was used. For mobile measurements, the sample 345 data is likely to contain location data, possibly of reduced 346 spatial resolution to protect user privacy. 348 Measurement client to network parameter server: The measurement 349 client may query the network parameter server, typically located 350 in the service providers network, for information about its 351 nominal service parameters, based on its network address, link 352 layer address, or hardware identifiers such as the IMEI for mobile 353 nodes. The data returned may include information such as nominal 354 uplink and downlink speeds, data quotas and physical and data link 355 layer technology. (Data quotas may be important for deciding 356 which data-intensive measurements a client wishes to run.) 358 While basic network connection information is unlikely to change 359 rapidly, it may change at unpredictable instants. For example, a 360 network provider may upgrade the connection speed of subsets of 361 their customers, customers may change their subscription or 362 provider may adjust the monthly data transfer quota. 364 We assume that the measurement server, controller and data 365 collector cooperate in configuring appropriate parameters. For 366 example, the controller needs to be able to determine which 367 measurement servers and data collectors are currently available 368 and the client is authorized to use. Discovery of suitable data 369 collectors is considered beyond the scope of this effort. 371 5. Initiation of Measurements 373 Either the client or the measurement controller could in principle 374 initiate measurements. For periodic measurements or one-off user- 375 triggered diagnostics, it is sufficient for the end system to contact 376 the controller, e.g., periodically every week. Client-initiated 377 measurements have a number of advantages. In particular, they make 378 it less likely that measurement hosts can be abused to generate 379 denial-of-service traffic. They also avoid problems allowing inbound 380 requests through network address translators (NATs) and firewalls. 382 However, there may be cases where the network provider wishes to 383 initiate a one-time measurement or change the measurement parameters 384 before the client next contacts the controller. For such cases, a 385 publish-subscribe mechanism may be considered, where the measurement 386 client subscribes to measurement schedule updates with the 387 measurement controller. 389 6. Requirements 391 We distinguish requirements for the different component by a prefix: 392 Requirements labeled A-* describe the overall platform architecture, 393 M-* indicate requirements primarily affecting the measurement client, 394 C-* those for the controller, D-* for the data collector and N-* for 395 the functions necessary to obtain network parameter. In many cases, 396 a single requirement governs more than one entity or protocol, so the 397 labeling should be considered rough. 399 A-1: The architecture MUST allow for one-time measurements initiated 400 by end users, sampled measurements initiated by network providers 401 and measurements by one or more third parties. 403 A-2: Measurement clients and servers MUST support an extensible set 404 of performance metrics. 406 A-3: Measurement clients, measurement servers and data collectors 407 MAY be operated by different administrative entities, including 408 entities other than the Internet service provider. 410 A-4: Measurement clients MUST be able perform both active and 411 passive measurements. 413 A-6: All entities MUST be able to authenticate the entities they 414 communicate with. 416 A-7: Each measurement sample MUST be unambiguously associated with 417 the measurement parameters, either by reference or by value. 419 A-8: To ensure availability and scaling, implementations MUST be 420 able to implement multiple measurement controllers, measurement 421 servers and data collectors with appropriate load balancing and 422 failover. 424 M-1: The architecture MUST allow a single measurement client to 425 participate in one or more independent measurement platforms. 427 M-2: A measurement client SHOULD be able to automatically switch 428 from a non-responsive to an alternate measurement server. 430 M-3: A measurement client MUST be able to register with the data 431 collection platform automatically, announcing its availability and 432 relevant system parameters. (For example, a cable or DSL modem 433 may indicate its make and model number.) 435 M-4: A measurement client MUST be able to declare what kind of 436 measurements it can perform, e.g., by enumerating a set of 437 measurement identifiers. 439 C-1: The measurement system MUST support measurements that are 440 scheduled according to a pre-defined calendar. 442 C-2: The measurement controller MUST be able to specify the interval 443 on how often it wishes to be contacted for updated measurement 444 schedules. 446 C-3: A measurement client SHOULD be able to automatically discover 447 controllers provided by their Internet service provider. 449 C-4: A measurement client MUST be able to authenticate and authorize 450 the measurement controller. 452 C-5: The data exchange between the client and controller MUST allow 453 for optional encryption and integrity protection. 455 D-1: The protocol messages for measurement samples MUST allow new 456 measurement types and parameters. 458 D-2: It MUST be possible to protect the integrity and 459 confidentiality of the measurement data exchanged between the 460 measurement client and the data collector. 462 D-3: The data exchange protocol between measurement server and data 463 collector SHOULD allow the definition of common data elements, 464 e.g., for network addresses and timestamps. 466 D-4: The measurement client SHOULD be able to automatically fail 467 over to alternate data collectors. 469 D-5: Clients MUST be able to either send data immediate or delay 470 sending measurement data to the collector, e.g., to use a low- 471 traffic period or a low-cost network. 473 D-6: Clients MUST be able to interleave data samples from different 474 measurement metrics to the data collector. 476 D-7: The data collector SHOULD be able to ascertain whether the 477 measurement client clock is at least approximately synchronized to 478 its own. 480 D-8: The data exchange between measurement client and data collector 481 MUST be subject to flow and congestion control. 483 D-9: The measurement client MUST be able to ascertain that it is 484 initiating a session with the desired data collector rather than 485 an impostor. 487 N-1: Measurement clients SHOULD be able to obtain nominal network 488 service parameters in a machine-readable format, such as 489 advertised speed and typical latency. (This may not be necessary 490 in all measurement use cases.) 492 N-2: The set of network parameters MUST be extensible in a backward- 493 compatible manner. 495 N-3: The measurement client SHOULD be able to determine the network 496 parameter server without manual configuration. 498 N-4: The protocol between measurement client and network parameter 499 server SHOULD support a variety of client identifiers, such as 500 network addresses, link-layer addresses, AAA identifiers or 501 hardware identifiers. 503 N-5: The data exchanged between the network parameter server and the 504 measurement client SHOULD ensure its confidentiality and 505 integrity. 507 N-6: The protocol SHOULD support suitable authentication 508 functionality to restrict access to network parameters to 509 authorized nodes. Authorized nodes may include third parties, 510 such as data collectors. 512 N-7: The entity querying the network parameter server MUST be able 513 to assure itself that it is communicating with an authentic 514 server. 516 N-8: Clients of the network parameter server SHOULD be able to be 517 automatically informed of changes in parameters. 519 7. Security Considerations 521 The large-scale measurement architecture has to prevent third 522 parties' use of the measurement clients in bot-nets or for other 523 nefarious or malicious purposes. A malicious third party could cause 524 a measurement client to initiate probe traffic to victim hosts rather 525 than measurement servers. We rely on user-initiated requests, 526 secured with transport-layer security and server certificates, to 527 ensure that only user-authorized entities issue control commands. 528 Users may also authenticate themselves via local shared secrets. We 529 note that there are similarities in approach with M2M data 530 communications and we suggest that reference of ongoing work on the 531 M2M signaling gateway framework or other models may be useful. 533 Measurements may also inadvertently expose information that the owner 534 of the measurement client considers privacy-sensitive. Privacy 535 considerations may differ depending on whether the measurement 536 client, measurement server or data collector are operated by the same 537 entity or not, and what trust relationships these entities have with 538 each other. It must be possible to protect the confidentiality of 539 the measurement data exchanged between the measurement client and the 540 data collector. For mobile measurements, location information is 541 likely to be crucial to interpreting measurement results. A 542 measurement client may want to substitute rough location [8] to 543 reduce the ability of a third party to track its movements and 544 whereabouts. 546 8. IANA Considerations 548 This document does not request any IANA actions. 550 9. Acknowledgements 552 The document is based on discussion within the FCC Measuring 553 Broadband America project. 555 DISCLAIMER: The opinions expressed are those of the author and do not 556 necessarily represent the views of the Federal Communications 557 Commission or the United States Government 559 10. References 561 10.1. Normative References 563 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 564 Levels", RFC 2119, March 1997. 566 10.2. Informative References 568 [2] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay 569 Metric for IPPM", RFC 2681, September 1999. 571 [3] Federal Communications Commission, "Measuring Broadband 572 America", September 2012. 574 [4] Broadband Forum, "Liaison Statement: New Project - Broadband 575 Access Service Attributes and Performance Measures", 576 August 2012. 578 [5] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay 579 Metric for IPPM", RFC 2679, September 1999. 581 [6] Mathis, M. and M. Allman, "A Framework for Defining Empirical 582 Bulk Transfer Capacity Metrics", RFC 3148, July 2001. 584 [7] Claise, B., "Cisco Systems NetFlow Services Export Version 9", 585 RFC 3954, October 2004. 587 [8] Barnes, R. and M. Lepinski, "Using Imprecise Location for 588 Emergency Context Resolution", Internet 589 draft draft-ietf-ecrit-rough-loc-05, July 2012. 591 Authors' Addresses 593 Henning Schulzrinne 594 Federal Communications Commission - See Disclaimer 595 445 12th Street SW 596 Washington, DC 20554 597 USA 599 Phone: +1 202 418 1544 600 Email: henning.schulzrinne@fcc.gov 602 Walter Johnston 603 Federal Communications - See Disclaimer 604 445 12th Street SW 605 Washington, DC 20554 606 USA 608 Phone: +1 202 418 0807 609 Email: walter.johnston@fcc.gov 611 James Miller 612 Federal Communications Commission - See Disclaimer 613 445 12th Street SW 614 Washington, DC 20554 615 USA 617 Phone: +1 202 418 7351 618 Email: James.Miller@fcc.gov