Internet Engineering Task Force T. Tsou Internet-Draft Huawei Technologies Intended status: Informational J. Schoenwaelder Expires: December 19, 2010 Jacobs University Bremen Y. Shi Hangzhou H3C Tech. Co., Ltd. T. Taylor, Ed. Huawei Technologies June 17, 2010 Problem Statement For the Configuration of Large-Scale IP Networks draft-tsou-opsawg-network-configuration-00 Abstract This memo discusses the steps required to bring network devices in a service provider network into service in an automated fashion. The memo identifies known solutions where they exist, but notes some gaps that require further specification. 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 December 19, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. 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 Tsou, et al. Expires December 19, 2010 [Page 1] Internet-Draft Configuring Large-Scale IP Networks June 2010 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. A Model of the Process . . . . . . . . . . . . . . . . . . . . 4 3. Pre-configuration . . . . . . . . . . . . . . . . . . . . . . 4 4. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Establishment of Layer 2 Connectivity . . . . . . . . . . 5 4.2. Acquisition of IP Addresses . . . . . . . . . . . . . . . 5 4.3. Finding the Configuration Server . . . . . . . . . . . . . 6 4.4. Establishing a Secure Channel Between the Device and the Configuration Server . . . . . . . . . . . . . . . . . 6 5. Initial Configuration and Updates . . . . . . . . . . . . . . 8 6. Configuration Auditing . . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11 10. Informative References . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Tsou, et al. Expires December 19, 2010 [Page 2] Internet-Draft Configuring Large-Scale IP Networks June 2010 1. Introduction New service provider networks are being deployed that entail the installation of tens of thousands of new network elements. To keep costs down, it is desirable to automate the establishment of such networks and the configuration of these network elements to the maximum extent possible. A certain amount of the information needed to operate them must be pre-configured by the vendor or operator before the devices are physically deployed. Other information is best delivered after startup, to ensure that it is consistent with the physical deployment. 3GPP work in progress describes requirements [TS_32_500] and an architectural specification [TS_36_300] for the self-configuration of edge node entities called eNodeBs. (The expansion of eNodeB is too unwieldy to spell out.) Specifically, procedures are specified for establishing transport connections to and for exchanging configuration data with control entities called MMEs (Mobility Management Entities) and with neighbouring eNodeBs. [TS_36_300] currently assumes as a starting precondition that the eNodeB knows its own IP address and knows IP address endpoints for the target MMEs and neighbouring eNodeBs. IETF work on configuration goes back to BOOTP [RFC0951], followed eight years later by DHCP RFC 1531 and successors [RFC1531]. The years since have seen a steady growth in the number of DHCP options. The number of SNMP MIB modules grew steadily, too, but SNMP has not historically seen much use for configuration. For a period, IETF configuration efforts were focussed on the distribution of policy in the network. [RFC3139] provides a good insight into this period. More recently, NETCONF [RFC4741] was devised as an alternative to SNMP, but the development of standard NETCONF data models is just beginning. Recent IETF work closest in spirit to the 3GPP self-organizing network effort cited above is embodied in CAPWAP [RFC5415]. Like the 3GPP work, CAPWAP focusses on the configuration of edge nodes, in a Wi-Fi rather than cellular network. The CAPWAP work goes beyond that of 3GPP by specifying the process of AC (Access Controller) discovery rather than leaving discovery out of scope. With regard to the configuration process itself, CAPWAP provides for the download of new images to the WTP (Wireless Termination Point). In contrast, [TS_32_500] assumes that this has already been completed for the eNodeB. Tsou, et al. Expires December 19, 2010 [Page 3] Internet-Draft Configuring Large-Scale IP Networks June 2010 2. A Model of the Process How much of the above work is applicable to the task of automated configuration of network devices? To answer this question, we need to describe a model of the configuration process and check off the parts that have well-known solutions. The remainder may be worth studying to see if the industry can agree on a solution. Some basic terminology is needed for the discussion. Depending on the implementation, let us agree that "configuration files" consist of software and sets of configured parameters in some combination. Also, the system that provides the configuration files is called the "configuration server". Finally, the term "joining device" is used to denote a network element that is in the process of being incorporated into the network. Broadly speaking, the configuration process can be broken into five phases: Pre-configuration: configuration carried out either by the vendor or by the operator prior to physical installation. One possible example is the pre-provisioning of certificates, as described in [RFC5415]. Bootstrapping: the portion of the process from the time that physical installation is complete until a secure connection is established between the device and the configuration server. Initial configuration: downloading of the configuration files that the joining device needs to carry out its function in the network. Auditing of installed configuration: tracking image versions for each network device and verifying that the installed data matches the physical installation, the network plan, and the records of what data was downloaded. It is possible that an initial audit of the physical installation is done before initial configuration, so that the validity of the intended download can be verified. Configuration update: transferring configuration files to a fully configured and operating device from time to time as the need arises. 3. Pre-configuration This memo identifies a specific requirement for pre-configuration of an invariant device identity and authentication-related material in the form of pre-shared secrets or certificates. There is, as one Tsou, et al. Expires December 19, 2010 [Page 4] Internet-Draft Configuring Large-Scale IP Networks June 2010 alternative, a requirement for pre-configuration of information that permits the joining device to discover the address of the configuration server. 4. Bootstrapping [I-D.oflynn-core-bootstrapping] deals with the process of bootstrapping, with particular emphasis on the requirements for highly-resource- constrained devices. The draft draws heavily from Wi-Fi Protected Setup (TM) [Wi-Fi-Protected-Setup] in discussing the alternatives for achieving secure joining of a new device to a network. Wi-Fi Protected Setup is a trademark of the Wi-Fi Alliance. The draft provides a framework for discussion of the possible solutions for bootstrapping. Its primary conclusion is that there will be multiple solutions targeted to specific contexts in terms of the resources available within individual devices and for the network as a whole. Bootstrapping consists of several stages: 1. establishment of layer 2 connectivity with neighbouring nodes; 2. acquisition of IP addresses; 3. discovery of the configuration server address; 4. establishment of a secure channel to the configuration server. 4.1. Establishment of Layer 2 Connectivity The protocol aspects of this phase are out of scope, since it involves non- IETF protocols only. 4.2. Acquisition of IP Addresses For IPv4, DHCPv4 [RFC2131] is widely deployed and the usual way to get an IP address. For IPv6, a choice has to be made between stateful DHCPv6 [RFC3315] versus stateless DHCPv6 [RFC3736] combined with stateless address autoconfiguration [RFC4862]. In the latter case, DHCPv6 is needed to configure parameters such as DNS server addresses. Some security protection is provided in this stage by using DHCP authentication [RFC3118]. However, security of the configuration Tsou, et al. Expires December 19, 2010 [Page 5] Internet-Draft Configuring Large-Scale IP Networks June 2010 process as a whole has to be assured by other means. This is discussed further below. Currently the lack of a stable identifier for use in DHCPv6 messaging is an impediment to authentication of the joining device. [I-D.dhc-duid-uuid] discusses the problems with the current DHCPv6 identifiers (DUIDs) and proposes a new form that could be a more stable alternative. This has not yet been accepted as a Working Group work item, so it is not clear when or if it will be standardized. 4.3. Finding the Configuration Server Four alternatives are available for finding the configuration server: o pre-configuration; o DHCP configuration; o Service Location Protocol [RFC2608]; or o DNS SRV records [RFC2782]. Pre-configuration of an IP address is brittle and not recommended. Pre- configuration of a URI or FQDN is a better approach. One variant that has been suggested is to burn the URI of a vendor server into the device's firmware along with a device identifier, and have that server return the URI of the operator's configuration server based on the device identity. DHCP configuration uses the usual BOOTP-related options and is straightforward. For the Service Location Protocol it would be necessary to define a new service template [RFC2609]. The use of DNS SRV records requires the joining device to obtain the correct domain suffix first, presumably from DHCP. A service type would have to be defined in DNS for the purpose. See Section 3.3 of [RFC5415] for a discussion of the corresponding discovery process for CAPWAP. 4.4. Establishing a Secure Channel Between the Device and the Configuration Server Wi-Fi Protected Setup (TM) [Wi-Fi-Protected-Setup] was mentioned above. Its basic intention is to make secure Wi-Fi setup easier for consumers and small office/home office customers, but the analysis may be relevant here. The Wi-Fi Alliance has defined an architecture, specified four different physical ways to join an entity to a network, and specified the protocols needed to support their model. Tsou, et al. Expires December 19, 2010 [Page 6] Internet-Draft Configuring Large-Scale IP Networks June 2010 It is essential that the configuration server and the joining device authenticate themselves to each other, since the steps leading up to this point in the process may not be fully secure. This raises two issues: how the joining device identifies itself, and how authentication takes place. It seems best if the device has an invariant identity built in and accessible to whatever operating system is running on it. If [I-D.dhc-duid-uuid], mentioned above, becomes a standard, the UUID on which that proposal is based would be the required invariant identity. The vendor should make that identity available in a form that can be read and transferred into a database accessible to the configuration server along with the associated configuration files in advance of the bootstrapping stage (e.g., in bar-coded format on the device packaging). This leaves the mutual authentication process itself. This has two aspects: the security protocol used to perform authentication, and initial keying methodology. The security protocol is tied together with the choice of configuration file transport, but the basic choices are: o IKEv2 [RFC4306]; o TLS [RFC5246]; o DTLS [RFC4347]; o SSH ([RFC4251], [RFC4252], [RFC4253], and [RFC4254]); and o SNMPv3 default security, USM ([RFC3417], [RFC5590], [RFC5591], and [RFC5592]). For initial keying methodology, the two basic choices are between pre- shared secrets and certificates. All of the security protocols listed above except USM support both methods. USM supports pre- shared secrets only. The usual concern with pre-shared secrets is scalability. In the bootstrapping case, the scale of operation required is linear with the number of devices to be configured, so it would definitely be a feasible approach if connection to the configuration system were the only consideration. The most likely procedure would be for the secret to be configured in the device during preconfiguration and also captured in a database along with the device identity, for use by the configuration server. The problem with the use of pre-shared secrets is that the device Tsou, et al. Expires December 19, 2010 [Page 7] Internet-Draft Configuring Large-Scale IP Networks June 2010 needs to authenticate itself at an earlier stage, while it is establishing communications with its neighbours and acquiring IP addresses. It seems undesirable to use the same secret for that purpose as for the connection to the configuration server, on the basic principle of limiting the potential damage from disclosure of a particular key. This need for additional pre-shared secrets argues for consideration of certificates as an alternative. One issue for certificates is where the trust anchor resides. It seems logical that it should reside with the operator rather than the vendor, to make it easy to install equipment from multiple vendors. On that basis, preconfiguration requires operator input. CAPWAP (Section 2.4.4.3 of [RFC5415]) makes use of the Extended Key Usage (EKU) certificate extension [RFC5280] to distinguish certificates identifying the Access Controllers (i.e., the configuration servers in the CAPWAP case) from the Wireless Transfer Points (the configured devices in the CAPWAP case). Thought should be given to whether such distinctions are required in the general case of network device configuration. CAPWAP (Section 12.8 of [RFC5415]) also discusses the use of the Common Name rather than SubjectAltName field of the certificate to carry device identity, due to lack of specifications allowing the use of SubjectAltName to carry MAC addresses. This issue needs to be investigated further if another form of device unique identity is used, as discussed above. 5. Initial Configuration and Updates As mentioned at the beginning, the configuration files being downloaded may be a combination of software and data. Some of the data will be vendor- specific, not subject to standardization. It appears that there is a continuing debate on whether the configuration files should be pushed to the joining device or whether the device should pull them down. In the latter case, the device needs to know about the existence of the files and the path to reach them before it can act. One way to acquire this information is through DHCP. DHCPv4 has provided the necessary options from its beginnings, inheriting them from BOOTP. They are currently being added to DHCPv6; see [I-D.dhcpv6-opt-netboot]. Section 6.1 of [RFC5607], provides a list of potential transports, which gives us a starting point, even though [RFC5607] itself is not applicable to our problem. Other candidates are CAPWAP, already mentioned above, and COPS-PR, which is out of general favour but Tsou, et al. Expires December 19, 2010 [Page 8] Internet-Draft Configuring Large-Scale IP Networks June 2010 still in use in some networks. We end up with the following list of candidates: o SNMPv3 ([RFC3411], [RFC3412], [RFC3413], and [RFC3416]); o HTTP [RFC2616]; o NETCONF [RFC4741]; o FTP [RFC0959]; o TFTP [RFC1350] o Secure FTP ([I-D.SFTP]); o RCP and SCP, UNIX utilities differing in their degree of integration with Secure Shell (SSH); o CAPWAP ([RFC5415]); o COPS-PR ([RFC3084]). Table 1 lists the security protocols with which these transports are associated. It also indicates how file transfer is initiated. +-----------+-------------+-----------------------------------------+ | Transport | Security | File Transfer Model | +-----------+-------------+-----------------------------------------+ | SNMPv3 | USM (or SSH | Pure push model | | | option) | | | HTTP | IKEv2/IPSec | Pure pull model | | | or TLS | | | NETCONF | TLS (or SSH | Pure push model | | | option) | | | FTP | IKEv2/IPSec | Push or pull | | TFTP | IKEv2/IPSec | Push or pull | | SFTP | SSH | Push or pull | | RCP | IKEv2/IPSec | Push or pull | | SCP | SSH | Push or pull | | CAPWAP | DTLS | AC pushes individual parameters, | | | | indicates availability of software. | | | | WTP pulls software. | | COPS-PR | TLS | Push or pull | +-----------+-------------+-----------------------------------------+ Table 1: Transports For Configuration Files SNMP, NETCONF, and COPS-PR carry parameters specified in pre-defined Tsou, et al. Expires December 19, 2010 [Page 9] Internet-Draft Configuring Large-Scale IP Networks June 2010 data models. Hence they must be supplemented by one of the other transports when it comes to download of software images. CAPWAP combines the functions of parameter transport and software download. The parameter transport aspect lacks the generality offered by SNMP, NETCONF, and COPS-PR, since the parameters are specified within the protocol specification itself. The remaining transports are independent of the nature of the information being transferred. 6. Configuration Auditing To complete the process, it must be possible to audit the configuration status of the device in some detail. This is likely to begin even before all the configuration files have been downloaded. For instance, configuration management may wish to collect basic connectivity information such as the MAC addresses of the device's interfaces, the link-local addresses assigned to them, and similar information for the neighbours of the joining device. SNMP and SNMP MIB modules are obviously one way to collect this information. NETCONF [RFC4741] is an alternative, but the necessary data models have to be defined. YANG modules for NETCONF [I-D.YANG] can be prepared relatively quickly or SNMP MIBs can be translated to YANG with tools like libsmi. 7. Security Considerations Can refer to the Security Considerations sections of the individual protocol specifications. Threats: loss of control leading to all sorts of stuff. Denial of service. Attacks: impersonation, data modification, replay, ... As DHCP mentions, assuming proper filtering at the network border, attacks are primarily insider threats. Services required: authentication, integrity, confidentiality for some data. 8. IANA Considerations This memo includes no request to IANA. Tsou, et al. Expires December 19, 2010 [Page 10] Internet-Draft Configuring Large-Scale IP Networks June 2010 9. Contributors Thanks to Cathy Zhou and Mehmet Ersue for help in preparing this memo. 10. Informative References [I-D.SFTP] Galbraith, J. and O. Saarenmaa, "SSH File Transfer Protocol (Work in progress)", July 2006. http://www.watersprings.org/pub/id/draft-ietf-secsh- filexfer-13.txt [I-D.YANG] Bjorklund, M., "YANG - A data modeling language for the Network Configuration Protocol (NETCONF) (Work in progress)", June 2010. [I-D.dhc-duid-uuid] Narten, T. and J. Johnson, "Definition of the UUID-based DHCPv6 Unique Identifier (DUID-UUID) (Work in progress)", May 2010. [I-D.dhcpv6-opt-netboot] Huth, T., Freimann, J., Zimmer, V., and D. Thaler, "DHCPv6 option for network boot (Work in progress)", June 2010. [I-D.oflynn-core-bootstrapping] O'Flynn, C. and B. Sarikawa, "Initial Configuration of Resource-Constrained Devices (Work in progress)", February 2010. [RFC0951] Croft, B. and J. Gilmore, "Bootstrap Protocol", RFC 951, September 1985. [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985. [RFC1350] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC 1350, July 1992. [RFC1531] Droms, R., "Dynamic Host Configuration Protocol", RFC 1531, October 1993. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. Tsou, et al. Expires December 19, 2010 [Page 11] Internet-Draft Configuring Large-Scale IP Networks June 2010 [RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999. [RFC2609] Guttman, E., Perkins, C., and J. Kempf, "Service Templates and Service: Schemes", RFC 2609, June 1999. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. [RFC3084] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, K., Herzog, S., Reichmeyer, F., Yavatkar, R., and A. Smith, "COPS Usage for Policy Provisioning (COPS-PR)", RFC 3084, March 2001. [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001. [RFC3139] Sanchez, L., McCloghrie, K., and J. Saperia, "Requirements for Configuration Management of IP-based Networks", RFC 3139, June 2001. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC3412] Case, J., Harrington, D., Presuhn, R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3412, December 2002. [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network Management Protocol (SNMP) Applications", STD 62, RFC 3413, December 2002. [RFC3416] Presuhn, R., "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3416, December 2002. Tsou, et al. Expires December 19, 2010 [Page 12] Internet-Draft Configuring Large-Scale IP Networks June 2010 [RFC3417] Presuhn, R., "Transport Mappings for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3417, December 2002. [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004. [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006. [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Authentication Protocol", RFC 4252, January 2006. [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006. [RFC4254] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Connection Protocol", RFC 4254, January 2006. [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006. [RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, December 2006. [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008. [RFC5415] Calhoun, P., Montemurro, M., and D. Stanley, "Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification", RFC 5415, March 2009. [RFC5590] Harrington, D. and J. Schoenwaelder, "Transport Subsystem for the Simple Network Management Protocol (SNMP)", Tsou, et al. Expires December 19, 2010 [Page 13] Internet-Draft Configuring Large-Scale IP Networks June 2010 RFC 5590, June 2009. [RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model for the Simple Network Management Protocol (SNMP)", RFC 5591, June 2009. [RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure Shell Transport Model for the Simple Network Management Protocol (SNMP)", RFC 5592, June 2009. [RFC5607] Nelson, D. and G. Weber, "Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management", RFC 5607, July 2009. [TS_32_500] 3rd Generation Partnership Project, "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Telecommunication Management; Self-Organizing Networks (SON); Concepts and requirements (Release 9)", 3GPP TS 32 500, 2010. [TS_36_300] 3rd Generation Partnership Project, "3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2 (Release 9)", 3GPP TS 36 300, 2010. [Wi-Fi-Protected-Setup] WiFi Alliance, "Wi-Fi Protected Setup (TM) Specification 1.0", 2007. http://www.wi-fi.org/. Follow the "Published Specifications" link under the "Knowledge Center" tab. Authors' Addresses Tina Tsou Huawei Technologies Bantian, Longgang District Shenzhen 518129 P.R. China Email: tena@huawei.com Tsou, et al. Expires December 19, 2010 [Page 14] Internet-Draft Configuring Large-Scale IP Networks June 2010 Juergen Schoenwaelder Jacobs University Bremen Campus Ring 1, Bremen 28759 Germany Email: j.schoenwaelder@jacobs-university.de Yang Shi Hangzhou H3C Tech. Co., Ltd. Beijing R&D Center of H3C, Digital Technology Plaza, NO.9 Shangdi 9th Street, Haidian District, Beijing China(100085) Phone: +86 010 82775276 Email: young@h3c.com Tom Taylor (editor) Huawei Technologies 1852 Lorraine Ave. Ottawa K1H 6Z8 Canada Email: tom111.taylor@bell.net Tsou, et al. Expires December 19, 2010 [Page 15]