One document matched: draft-tsou-opsawg-network-configuration-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-24 02:48:11 |