Network Working Group G. Chen Internet-Draft China Mobile Intended status: Informational T. Tsou Expires: August 17, 2014 Huawei Technologies (USA) C. Donley CableLabs T. Taylor Huawei Technologies February 13, 2014 Analysis of NAT64 Port Allocation Method draft-chen-sunset4-cgn-port-allocation-03 Abstract The document enumerated methods of port assignment in CGN contexts, more focused on NAT64 environments. The analysis categorized the different methods with several key features. The uses of existing protocols are described corresponding to those features. The document also shared the port-usage experiences, relevant findings, evaluations and workarounds. It's expected the document could provide a informative base line to help operators choosing a proper method. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on August 17, 2014. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. Chen, et al. Expires August 17, 2014 [Page 1] Internet-Draft cgn-port February 2014 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Port Consumption on NAT64 . . . . . . . . . . . . . . . . . . 3 3. Port Allocation Category . . . . . . . . . . . . . . . . . . 4 3.1. NAT vs NAPT . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Dynamic vs Static . . . . . . . . . . . . . . . . . . . . 5 3.3. Centralized vs Distributed . . . . . . . . . . . . . . . 6 4. Port Allocation Solutions . . . . . . . . . . . . . . . . . . 6 4.1. Deterministic CGN . . . . . . . . . . . . . . . . . . . . 6 4.2. MAP-T and 4rd . . . . . . . . . . . . . . . . . . . . . . 7 4.3. PCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.4. Dynamic Port Allocation . . . . . . . . . . . . . . . . . 8 5. Specific Considerations . . . . . . . . . . . . . . . . . . . 8 5.1. Log Volume Optimization . . . . . . . . . . . . . . . . . 9 5.2. Connectivity State Optimization . . . . . . . . . . . . . 10 5.3. Port Randomization . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 1. Introduction With the depletion of IPv4 address, CGN has been adopted by ISPs to expand IPv4 spaces. Relying upon the mechanism of multiplexing multiple subscribers' connections over a smaller number of shared IPv4 addresses, CGN mapped IP addresses from one address realm to another, providing transparent routing to end hosts. [I-D.ietf-behave-lsn-requirements] defined the term of CGN. Several proposals including DS-Lite[RFC6333], NAT64[RFC6145], [RFC6146], NAT444 would likely fall into the scope. Focusing on the topic of IPv6 migration, the memo elaborate the considerations in NAT64 environment, where there IPv6-only nodes are connected. Chen, et al. Expires August 17, 2014 [Page 2] Internet-Draft cgn-port February 2014 In regards to port allocations on NAT64, several aspects may have to consider in order to deploy a suitable method. The below enumerates the potential considerations. o Specific features of port-usage in a NAT64 environment o The category of different port-allocations methods o The port allocation method to improve connectivity o The port allocation method to optimize log volume o The port allocation method to enhance security The document trying to detail the analysis and relevant experiences. 2. Port Consumption on NAT64 With the merits of simplicity and efficiency, NAT64 will be likely deployed. In those cases, NAT64 would enable internal IPv6-only hosts to connect to external dual-stack networks. Compared with NAT44, fewer ports consumed on NAT64. The reason for the fewer port consumption is NAT64 are deployed to provide connectivity from one address family to another. Only flows between different address families require ports to be assigned. That is, a NAT44 might be deployed in an IPv4-only environment. Since all traffic will have to traverse the NAT, all flows will need ports. Conversely, NAT64 only requires a port when one end is IPv4-only. Therefore, the more hosts support IPv6, the fewer ports are needed on the NAT64. There was a testing on the comparison of port consumption on NAT64 and NAT44. Top100 websites (referring to Alexa statistics) were being assessed to evaluate status of port usage on NAT44 and NAT64 respectively. It's observed that the port consumption on NAT64 is roughly only half on NAT44. 43 percent of top100 websites have AAAA records, therefore the NAT64 didn't have to assign ports to the traffic going to those websites. The results may be different if more services (e.g. game, web-mail, etc) are considered. Whereas, it's apparent the effects of port saving on NAT64 could be amplified by increasing native IPv6 supports. Apart from above, the port allocation can be tuned corresponding to the phase of IPv6 migration. The use of NAT64 would advance IPv6, because it provides everyone incentives to use IPv6, and eventually the result is an end-to-end IPv6-only networks with no needs for port allocations. As more content providers and service are available over IPv6, the utilization on NAT64 goes down since fewer destinations require translation progressing. In the trend of IPv6 Chen, et al. Expires August 17, 2014 [Page 3] Internet-Draft cgn-port February 2014 migration, NAT64 may relax the multiplexing ratio of shared IPv4 address by either a delivered message or a centralized control. 3. Port Allocation Category This section lists several methods to allocate the port information in NAT64 equipments. It also described exemplified cases for each allocation model. 3.1. NAT vs NAPT NAT64 may not do Network Address Port Translation (NAPT), but only Network Address Translation (NAT). In those cases, there is no concern about port assignment. Some existing practices are listed below from two aspects. o Stateful The stateful NAT can be implemented either by static address translation or dynamic address translation. In the case of static address assignment, one-to-one address mapping for hosts between a IPv6 network address and an IPv4 network address would be pre-configured on the NAT operation. Those cases normally occurred when a server deployed in a IPv6 domain. The static configuration ensure the stable inbound connectivity. Dynamic address assignment would periodically free the binding so that the global address could be recycled for later uses. Addresses could be more efficiently used by a time-division manner. o Stateless The stateless NAT is performed in compliant with [RFC6145]. Public IPv4 address is required to be inserted in IPv6 address. Therefore, NAT64 could directly extract the address and no need to record mapping states. A promising usage of stateless could be appeared in IDC environment where there is IPv6 servers pools to receive inbound connections from IPv4 users externally[I-D.anderson-siit-dc]. The uses in other cases may be controversial. First off, the static one- to-one mapping may didn't address the issue of IPv4 depletion. Secondly, it introduced the dependency of IPv4/IPv6. That would create new limitations since the change of IPv4 address would cause renumbering of IPv6 addresses. Chen, et al. Expires August 17, 2014 [Page 4] Internet-Draft cgn-port February 2014 3.2. Dynamic vs Static When the cases come to port assignment, there are two methods on port allocations. o Dynamic assignment NAT64 normally do the dynamic assignment, since maximum port utilizations could be achieved. In respect to port allocations, it could be allocated with the granularity of per-session or per- customer. Per-session assignment basically configured on NAT64 by default for efficient port utilizations. However, a heavy log volume may have to be recorded for lawful interception system. In order to mitigate the concerns, NAT64 could dynamically allocate a port range for each connected subscriber on-demand. It would significantly reduce log volume. A proper port-range configuration may have to consider two-folds. a. The number of session initiations for each subscriber. A subscriber normally uses multiple applications simultaneously, e.g. map, online video or game. The number of concurrent sessions are essential to determine the space of port range. It has been learned from subscriber's behaviors that the average session's number of a user's device is around 200~300 ports. Several devices maybe appeared behind a CPE. Administors may configure a range with 1000 ports to each CPE in fixed networks. b. Impacts to NAT64 capacity. The preassigned port ranges occupy the memory even there are unused ports. Therefore, it should be cautious the impacts of port-range reservation to the capacity of attempted concurrent sessions, especially in the case of NAT64 CGN served a centralized point to numerous subscribes. o Static assignment The static assignment makes a bulk of port reservations for each internal address before subscriber's connection. The bulk of ports could be either a contiguous or non-contiguous port range for the sake of attack defense. [I-D.donley-behave-deterministic-cgn]has described a deterministic NAT to assign a port range for internal IP address pool in a sequence. The difference of the static method with dynamic port-range is address/ports mappings have been established before subscriber's connectivity attempts. Log recording may not be necessary due to the stable mapping relations. The considerations of port-range allocation and capacity impacts could also be applied to the case of static assignment. Chen, et al. Expires August 17, 2014 [Page 5] Internet-Draft cgn-port February 2014 3.3. Centralized vs Distributed There are increasing needs to connect NAT64 with downstream NAT46-capable devices to support IPv4 users/applications on a IPv6-only path. Several solutions have been proposed in this area, e.g. 464xlat[RFC6877], MAP-T[I-D.ietf-softwire-map-t] and 4rd[I-D.ietf-softwire-4rd]. With the feature of double-translation, the port allocation can be categorized as a centralized assignment on NAT64 or a port delegation distributed to downstream devices (e.g, CE connected with NAT64) . o Centralized Assignment A centralized method would make port assignments once IP flows come to NAT64. The allocation policy is enforced on a centralized point. Either a dynamic or static port assignment is made for received sessions. o Distributed Assignment NAT64 could also delegate the pre-allocated port range to customer edge devices. That can be achieved through additional out-band provisioning signals(e.g. ,[I-D.ietf-pcp-port-set][I-D.ietf-softwire-map-dhcp]). The distributed model normally performed A+P style for static port assignment. NAT64 should hold the corresponding mapping in accordance with assigned ports. Those methods could shift NAT64 port computations/states into downstream devices. The detailed benefits was documented in [I-D.ietf-softwire-stateless-4v6-motivation]. 4. Port Allocation Solutions 4.1. Deterministic CGN The deterministic port allocation has been described in [I-D.donley-behave-deterministic-cgn].This algorithm allows an operator to identify a subscriber internal IP address when provided the public side IP and port number without having to examine the CGN translation logs. Specific port allocation is determined by the algorithm configured on the CGN. The following variables are required to be configured: o Inside IPv4/IPv6 address range (I); o Outside IPv4 address range (O); o Compression ratio (e.g. inside IP addresses I/outside IP addresses O) (C); Chen, et al. Expires August 17, 2014 [Page 6] Internet-Draft cgn-port February 2014 o Dynamic address pool factor (D), to be added to the compression ratio in order to create an overflow address pool; o Maximum ports per user (M); o Address assignment algorithm (A); o Reserved TCP/UDP port list (R). The reserved ports (R) from the port candidate list (e.g., 0-1023 for TCP and UDP) can't be allocated to users. Deterministic port allocation uses the compression ratio (C) to tune the available port number allocated to per user. It also provides a method to allocate the ports in a dynamic approach. The CGN calculates the total compression ratio (C+D), and allocates 1/(C+D) of the available ports to each internal IP address. Specific port allocation is determined by the algorithm (A) configured on the CGN. Any remaining ports are allocated to the dynamic pool, which offers a possibility to allocate the extra ports when port resource is overused. The log information generated from the dynamic pool must be recorded. Address assignment algorithms are configured to regulate the port assignment method to each subscriber. Subscribers could be restricted to ports from a single IPv4 address, or could be allocated ports across all addresses in a pool. The assigned ports could be sequential, staggered, or cryptographically random. The CGN is not required to support all algorithms. 4.2. MAP-T and 4rd The MAP-T and 4rd are designed to allow the coordination between CPEs and Border Relays (BR) to delegate a port segment to a CPE. A mapping rules are pre-configured both on the CPEs and BRs in order to derive the available port numbers from the delegated IPv6 prefix. The port number is adjusted by the length of IPv4 prefix and EA-bits and identified by Port-Set Identifier (PSID). Depending on the mechanism, customer sites can be assigned shared public IPv4 addresses with restricted port sets. Since the port segment is computed from delegated IPv6 prefix and IPv4 prefix, it introduces the dependency between the IPv4 and IPv6. The network planning should consider this restriction for the network deployment. Chen, et al. Expires August 17, 2014 [Page 7] Internet-Draft cgn-port February 2014 4.3. PCP Port Control Protocol can be used to reserve a single port[RFC6887] or a port set[I-D.ietf-pcp-port-set] for applications. It requires NAT is capable of PCP server. A set of port is retrieved through PCP signaling. The port resource is managed by the lifetime indicated in PCP request message. 4.4. Dynamic Port Allocation In order to share the limited supply of IPv4 addresses available in the network, the dynamic port allocation is a default behavior for a stateful NAT64[RFC6146]. It will achieve maximum port multiplexing. [I-D.tsou-behave-natx4-log-reduction]proposes a solution that allows dynamic sharing of port ranges between users while minimizing the number of logs that have to be generated. Briefly, ports are allocated to the user in blocks. Logs are generated only when blocks are allocated or deallocated. This provides the necessary traceability while reducing log generation by a factor equal to the block size, as compared with fully dynamic port allocation. When the user sends out the first packet, a port resource pool is allocated for the user, e.g., assigning ports 2001~2300 of a public IP address to the user's resource pool. Only one log should be generated for this port block. When the NAT needs to set up a new mapping entry for the user, it can use a port in the user's resource pool and the corresponding public IP address. If the user needs more port resources, the NAT can allocate another port block, e.g., ports 3501~3800, to the user's resource pool. Again, just one log needs to be generated for this port block. It can also take this idea further by allocating non- contiguous sets of ports using a pseudorandom function. Scattering the allocated ports in this way provides a modest barrier to port guessing attacks. The CGN can also remove the port block from the resource pool allocated to a given internal address when there is no port used, and make it available for other users. The timer for port block deallocation is suggested to conform with the recommendations for NAT behaviour for the protocol concerned, then the additional time that might be configured as a guard for the block as a whole need not be more than a few minutes. 5. Specific Considerations Chen, et al. Expires August 17, 2014 [Page 8] Internet-Draft cgn-port February 2014 5.1. Log Volume Optimization [RFC6269] has provided a thoughtful analysis on the issues of IP sharing. It pointed out that IP sharing may bring the impacts to law enforcements since the information of source address would be lost during the translation. Network administrators have to log the mapping status for each connection in order to identify a specific user associated with an IP address in a particular time slot. The storage of log information may post a challenge to operators, since it requires additional resources and data inspection process to indentify users. It's desirable to compact the logging information. Referring the categories of port allocation, the assignment could be managed on either per-session or per-customer. The bigger granularity would lead fewer log volume storage. A testing was made to record the log information from 200,000 subscribers for 60 days. The volume of recorded information reach up to 42.5 terabytes with per-session log. Conversely, it only occupy 40.6 gigabytes with per- customer log. There is even a method, which doesn't have to log any information. Whereas, high compression would cause low efficiency of port utilization. A port allocation based on per-customer granularity have to retain vacant ports in order to avoid traffic overflow. The efficiency could be evaluated by port utilization rate. The efficiency could be even lower if the method of static port allocation is used. The ports were pre-allocated to customers regardless online or offline status. Inactive users may also impact the efficiency. The below table is trying to make a composite analysis. +-----------------+----------------- +-----------------+-------------------+ |Type of log | Method of port | Log Volume(e.g. | Port utilization | |records | allocations | 200,000 users | ratio | | | | for 60 days) | | +-----------------+---------------- -+-----------------+-------------------+ |per-session |Dynamic NAPT | 43.5 Terabytes | 100% | +-----------------+------------------+-----------------+-------------------| |per-customer |Dynamic port-range| 40.6 Gigabytes | 75%(e.g.400 ports)| +-----------------+------------------+-----------------+-------------------+ |None Log |Deterministic NAT,| | 60% *75%= | | |MAP,4rd | 0 | 45% | +-----------------+------------------+-----------------+-------------------+ Note:75% is evaluated for port utilization ratio. 60% is evaluated for the ratio of active subscribers. The data shared in the table may roughly demonstrates the tradeoff between port utilization and log volume compression. Administrator may consider below factors to determine their own solution Chen, et al. Expires August 17, 2014 [Page 9] Internet-Draft cgn-port February 2014 o Average connectivity per customer per day o Peak connectivity per day o The amount of public IPv4 address in NAT64 o Application demands for specific ports o The processing capabilities of NAT64 o The tolerance of log volume 5.2. Connectivity State Optimization It's observed that port consumption would be significantly increased once subscribers stick to a web page for VoD, online games or map services. In those cases, multiple TCP connections may be initiated to optimize the performance of data transmissions for video download and message exchange. With the trends of the video traffic growth, it likely presents a challenge for network operators that need to optimize connectivity states and avoid port depletion. Those optimizations may even be significant to the method of port-range allocation, because a subscriber is only allowed to use a pre- configured port resource. The optimization could be considered from two aspects. o Reducing the TIME-WAIT state. User's behavior normally correlates with the system performance. It's rather common that users often change video channels. It's investigated that 60% of video watched for less than 20% of their duration. The user's access patterns may leave a number of the TIME-WAIT states. Therefore, acceleration of TIME-WAIT state transitions could increase the efficiency of port utilization. RFC6191[RFC6191] define the mechanism of reducing TIME-WAIT state by proposing TCP timestamps and sequence numbers. [I-D.penno-behave-rfc4787-5382-5508-bis]recommended applying [RFC6191] and PAWS (Protect Against Wrapped Sequence numbers described in [RFC1323]) to NAT. It might a way to improve port utilizations. o Another consideration is using Address-Dependent Mapping or Address and Port-Dependent Mapping[RFC4787] to increase the port utilization. This feature has already been implemented as vendor- specific features. Whereas, it should be noted that REQ-7, REQ-12 in[I-D.ietf-behave-lsn-requirements] may reduce the incent Chen, et al. Expires August 17, 2014 [Page 10] Internet-Draft cgn-port February 2014 5.3. Port Randomization Port randomization is a feature to enhance the defense of hijack flows. [RFC6056] specified that "A NAPT that does not implement port preservation [RFC4787] ,[RFC5382] should obfuscate selection of the ephemeral port of a packet when it is changed during translation of that packet." A NAPT based on per-session normally follow the recommendation. However, a simply algorithm on port assignment is mostly desirable for a deterministic NAT even there is hijack vulnerability. 6. Security Considerations The non-contiguous port allocations could be considered to enhance the security of port allocations. This document shares the considerations in [RFC6056]. 7. IANA Considerations This document makes no request of IANA. 8. References 8.1. Normative References [I-D.ietf-softwire-map-dhcp] Mrugalski, T., Troan, O., Dec, W., Bao, C., leaf.yeh.sdo@gmail.com, l., and X. Deng, "DHCPv6 Options for configuration of Softwire Address and Port Mapped Clients", draft-ietf-softwire-map-dhcp-06 (work in progress), November 2013. [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992. [RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007. [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, RFC 5382, October 2008. [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- Protocol Port Randomization", BCP 156, RFC 6056, January 2011. Chen, et al. Expires August 17, 2014 [Page 11] Internet-Draft cgn-port February 2014 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011. [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011. [RFC6191] Gont, F., "Reducing the TIME-WAIT State Using TCP Timestamps", BCP 159, RFC 6191, April 2011. [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, August 2011. [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 2013. 8.2. Informative References [I-D.anderson-siit-dc] Anderson, T., "Stateless IP/ICMP Translation in IPv6 Data Centre Environments", draft-anderson-siit-dc-00 (work in progress), November 2012. [I-D.donley-behave-deterministic-cgn] Donley, C., Grundemann, C., Sarawat, V., Sundaresan, K., and O. Vautrin, "Deterministic Address Mapping to Reduce Logging in Carrier Grade NAT Deployments", draft-donley- behave-deterministic-cgn-07 (work in progress), January 2014. [I-D.ietf-behave-lsn-requirements] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, "Common requirements for Carrier Grade NATs (CGNs)", draft-ietf-behave-lsn-requirements-10 (work in progress), December 2012. [I-D.ietf-pcp-port-set] Qiong, Q., Boucadair, M., Sivakumar, S., Zhou, C., Tsou, T., and S. Perreault, "Port Control Protocol (PCP) Extension for Port Set Allocation", draft-ietf-pcp-port- set-04 (work in progress), November 2013. Chen, et al. Expires August 17, 2014 [Page 12] Internet-Draft cgn-port February 2014 [I-D.ietf-pcp-port-set] Qiong, Q., Boucadair, M., Sivakumar, S., Zhou, C., Tsou, T., and S. Perreault, "Port Control Protocol (PCP) Extension for Port Set Allocation", draft-ietf-pcp-port- set-04 (work in progress), November 2013. [I-D.ietf-softwire-4rd] Despres, R., Jiang, S., Penno, R., Lee, Y., Chen, G., and M. Chen, "IPv4 Residual Deployment via IPv6 - a Stateless Solution (4rd)", draft-ietf-softwire-4rd-07 (work in progress), October 2013. [I-D.ietf-softwire-map-t] Li, X., Bao, C., Dec, W., Troan, O., Matsushima, S., and T. Murakami, "Mapping of Address and Port using Translation (MAP-T)", draft-ietf-softwire-map-t-05 (work in progress), February 2014. [I-D.ietf-softwire-stateless-4v6-motivation] Boucadair, M., Matsushima, S., Lee, Y., Bonness, O., Borges, I., and G. Chen, "Motivations for Carrier-side Stateless IPv4 over IPv6 Migration Solutions", draft-ietf- softwire-stateless-4v6-motivation-05 (work in progress), November 2012. [I-D.penno-behave-rfc4787-5382-5508-bis] Penno, R., Perreault, S., Kamiset, S., Boucadair, M., and K. Naito, "Network Address Translation (NAT) Behavioral Requirements Updates", draft-penno-behave- rfc4787-5382-5508-bis-04 (work in progress), January 2013. [I-D.tsou-behave-natx4-log-reduction] Tsou, T., Li, W., Taylor, T., and J. Huang, "Port Management To Reduce Logging In Large-Scale NATs", draft- tsou-behave-natx4-log-reduction-04 (work in progress), July 2013. [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", RFC 6269, June 2011. [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: Combination of Stateful and Stateless Translation", RFC 6877, April 2013. Chen, et al. Expires August 17, 2014 [Page 13] Internet-Draft cgn-port February 2014 Authors' Addresses Gang Chen China Mobile 53A,Xibianmennei Ave., Xuanwu District, Beijing 100053 China Email: phdgang@gmail.com Tina Tsou Huawei Technologies (USA) 2330 Central Expressway Santa Clara, CA 95050 USA Phone: +1 408 330 4424 Email: tina.tsou.zouting@huawei.com Chris Donley CableLabs 858 Coal Creek Cir Louisville, CO 80027 US Email: c.donley@cablelabs.com Tom Taylor Huawei Technologies Ottawa Canada Email: tom.taylor.stds@gmail.com Chen, et al. Expires August 17, 2014 [Page 14]