Internet Engineering Task Force CY Lee INTERNET DRAFT J DeClercq Expires June 2003 November 2002 CE Auto-Configuration Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Abstract This draft describes the mechanisms required to automatically configure a Customer Edge (CE) Equipment to support a VPN service offered by the provider (aka as Provider Provisioned CE-based VPN). 1. Motivation To offer provider provisioned CE-based VPN [CE-VPN] ( or CE-based Virtual Private LAN [CE-VPL]), a provider has to configure on a CE, tunnel(s) to remote CE(s) of a VPN. In this document, the term VPN includes VPL and the term CE includes CLE (Customer Located Equipment) In CE-based VPNs, if a site of a VPN is added or removed, other CE(s) belonging to the VPN must be reprovisioned with the new or updated tunnel endpoint. It is desirable to have a CE to be automatically updated with the change in tunnel endpoints and for the CE to self- provision a new tunnel to a remote site. This auto-discovery or update and self-provisioning features on CE shall be referred to as CE auto-configuration. PP CE-based VPNs which do not require the provider to manually perform configuration on the CEs reduces the cost of offering VPN service. If CEs of a VPN are fully-meshed, using CE auto- configuration instead of manually provisioning CEs, reduces the provisioning required from O(n^2) to O(n), where n is the number of sites. 2. Overview Figure 1 below is based on Figure 1 from [CE-VPN] and shows the reference model for auto-configuration of CEs for PP CE-based VPN. Customer | Provider's network | Customer Site | | site | +-------------+ | | |VPN | | | |Configuration| | | |server | | | +-------------+ | | | | edge edge | | router router| Customer ---CE1 ----PE1----- Backbone -----PE2-----CE2---- Customer X's network | | X's network | | | | | | Figure 1: Reference model for auto-configuration of CEs A VPN Configuration server is a server which can update CEs of tunnel endpoint information or/and where CE may request tunnel endpoints information. 3. VPN service parameters The parameters that can be auto-configured at a CE device to allow a CE to self provision tunnels include: i) the list of remote CE IP address(es) ii) the VPN identification iii) the transform sets defining the security protocols and algorithms that shall be used by two CEs for encryption and authentication (for IPSec). The (pre-shared or CE's private) key for IPSec tunnels must be pre- configured on the CE. Other VPN service related configuration which do not change as sites are removed or added to a VPN may also be configured a priori or remotely (and manually) configured if the parameters do not change frequently. The intent here is to define a minimal set of VPN service parameters that should be auto-configured. Hence, this draft shall focus on the auto-configuration of tunnel(s) to remote CE(s). If necessary, the transform sets for IPSec and other service parameters shall be defined to be auto-configured in future. The scope here are VPN service parameters, other service parameters related to managed Internet service, firewall configuration are not within the scope of this draft. 4. CE Auto-Configuration requirements The CE auto-configuration solution should: - minimize the number of parameters that must be pre-configured - minimize the number of parameters that shall be auto-configured - allow CE to automatically request tunnel endpoint information - be able to automatically update CEs with new tunnel endpoint information - allow a CE to automatically provision the tunnels (discovered or being updated earlier on) to other CEs - allow a provider to provision tunnel information for a CE independent of whether a CE is up and running. When a CE comes back on line, the auto-update procedures must reliably obtain the latest tunnel information - allow authentication of the tunnel endpoint information - a customer must not be allowed to tamper with any part of the CE's configuration other than the part that the customer is allowed to configure - allow a provider to explicitly add or remove sites of a VPN e.g. a tunnel setup or removal does not necessarily imply a site should be added or removed from the VPN The CE auto-configuration solution may: - allow configuration of CEs in different AS (Autonomous Systems) or network provider - leverage providers' existing AAA infrastructure - hide or encrypt the tunnel endpoint information [Note: If a CE uses a private key/certificate pair tunnel authentication, the remote end CE can use the corresponding public key when authenticating the other end CE. In this case, the private key may be configured on CEs a priori, and not sent as part of the tunnel endpoint information. Alternatively, if [PIC, XAUTH] is used, a CE may request credentials from an Authentication Server instead, and there is no need to pre- configure a CE with a private key, instead the CE ID and the password may be pre-configured on the CE. "It is assumed then that the CE possesses (e.g. by pre-configuration) the public key of the Authentication Server, or it has the means to obtain and validate a certificate for the Authentication Server (e.g., by pre-configuration of a CA (Certificate Authority) public key)" In this case, the CE credentials must be encrypted if sent as part of the tunnel endpoint information. Otherwise an independent key distribution protocol may be used to distribute keys, instead of sending the key as part of the tunnel endpoint information.] - automate IP address association with a CE of a VPN [Note: a provider may have to be informed of a CE location offline and has to manually associate an IP address (that the CE is reachable from a provider's network) with a CE of a VPN. Hence it is useful to allow a CE to authenticate itself to a VPN Configuration server and then to "register" itself. This allows a VPN Configuration server to associate the CE with its current IP address or alternatively, if the CE is within the service provider's network, the VPN Configuration server may be able to assign the IP address to the CE (on the port facing a network provider), associate the CE with the assigned IP address and at the same time provide the remote CE IP addresses [See Appendix]. 4.1 General Ideal Solution Ideally on bootup, a CE should be able to automatically perform procedures to gain network access if needed and obtain an IP address to allow it to communicate with other CEs in the IP network, e.g. via [DHCP] or for PPP links via IPCP. Subsequently the CE shall request tunnel information from a VPN Configuration server. CEs need only be pre-configured with : a) a shared key or private key/certificate pair or a password, to allow it to authenticate itself to the VPN Configuration server and If a shared key is used, a CE may additionally be pre-configured with a CE Identification (ID) in some service deployment scenarios, e.g. where the service provider is not able to infer the "location" of the CE or infer from the IP address of a CE which CE it is communicating with. b) a shared key or a CA's public key to allow it to authenticate the VPN Configuration server CEs may be pre-configured with the VPN Configuration server name if the CE is not able to discover the VPN Configuration server or if the server involved in the network access configuration process (e.g. DHCP Server or NAS (Network Access Server), see [L2TP]) cannot be leveraged as a VPN Configuration server. If the CE is pre-configured with the VPN Configuration server name, the CE may find out the VPN Configuration server IP address via e.g. the DNS. A CE shall query or retrieve the tunnels information of a VPN it belongs from the VPN Configuration server. The VPN Configuration server shall authenticate the CE and provide the tunnel endpoint information to the CE, encrypting any information if necessary. [To leverage existing AAA infrastructure, the VPN Configuration server may choose to authenticate the CE via e.g. RADIUS and obtain the tunnel information from the RADIUS Server as well. In this case, the VPN Configuration server is acting as a RADIUS client, and shall send the CE Identification and password to the RADIUS server See the Appendix for further discussion]. The CE shall authenticate the tunnel information provided by the VPN Configuration server, before provisioning the tunnels. 5. Protocol choices and features Some candidate protocols that could be used for CE auto-configuration and the extensions that are required are identified here. A combination of these approaches may also be considered. 5.1 SNMP It is not recommended that an operator configure CEs directly via SNMP, as it is not easy to setup up the tools to provide the necessary timeliness and reliability. A new auto-discovery framework is required on CEs and SNMP "manager" code which allows a CE to "get" VPN service parameters (a defined IP VPN MIB) from a VPN Configuration server is required to be implemented on a CE. Normally a Network Element (NE) has an SNMP "agent" which allows a Network Manager to "get" MIB objects from the NE. If it is not feasbible for a CE to "get" VPN parameters, the VPN Configuration server may have to send SNMP traps to the CE to trigger the CE to do a "get" VPN parameters from the VPN Configuration server. An new auto update framework is required on a Network/VPN Service Provisioning Manager. SNMPv3 may be used to automatically update CEs. SNMPv1/v2 over IPSec may used to configure CE, but this cannot prevent a customer from tampering with a CE. 5.2 LDAP/DNS A CE could retrieve tunnel endpoint information (to add new tunnels) from a (DNS or LDAP) server, and may be located in a different provider's network. However, a provider is not able to inform a CE to explicitly teardown a tunnel to a site unless the CE poll the DNS or LDAP server for VPN update information or a message is sent from another server using a different protocol to trigger the CE to pull information from the DNS or LDAP server. If another messaging/protocol is required to inform a CE to remove a tunnel endpoint, that same protocol could be used to inform a CE to add a tunnel endpoint, instead of LDAP/DNS, i.e. the use of LDAP/DNS for CE auto-configuration would be redundant then. This "receive-trigger-then-pull" paradigm is more complicated than the "polling" paradigm, especially when protocols that do not have the necessary reliability mechanisms built into them are used. Both paradigms have some difficulties in figuring out whether the absence of some previously present data is significant or not (e.g., there may be a transient problem in the delivery mechanism), when the protocol used does not have reliability mechanisms. It should be noted that some of the mechanims considered in this draft such as DHCP has reliability mechanisms and while the RADIUS protocol itself does not provide reliability mechanisms, the retransmission & reliability procedures are provided by implementation. 5.3 IKE When a CE attempts to setup tunnel to a remote CE (which may be located in a different provider's network), the remote CE is implicitly being informed of the tunnel endpoint. The remote CE may still need to contact the VPN Configuration Server (using another protocol) to download other tunnel endpoint information. This implies a provider is not able to explicitly teardown a tunnel to a site, unless a message is sent from a server using another protocol, as in the LDAP/DNS approach (the "receive-trigger-then-pull" paradigm). 5.4 COPS COPS allows a CE to retrieve tunnel endpoint information as well as to be updated of tunnel endpoint information from a PDP (a server). CEs may be located in different providers' network and SSL/TLS may be leveraged to provide secure commnunication between CEs and the VPN Configuration Server. The PDP (Policy Decision Point) must maintain a large number of TCP sessions if there are a large number of CEs. 5.5 XML and HTTP/HTTPS May require another auto-discovery and update protocol, on top of http/https, unless the "gets/sets" are simple and the outcome of a "get/set" is either a success or failure. May require an auto- discovery and update framework on the CE and the VPN Configuration Server. 5.6 DHCP Auto-discovery and auto-update framework (with reliability mechanisms) already exist on DHCP client and server. Automate CE address association with CEs of a VPN and faciliate CE address management and reuse. Applicable when CEs of a VPN are within a provider network. Multiple DHCP servers may be used in a network and these can be configured from one management station. Configuration information is sent from the management station to multiple DHCP servers. It is not clear at this point if the mechanisms to configure multiple servers need to be standardized. In the case where CEs span inter-domain networks and hence the network access configuration process may not be leveraged, an approach where a front-end Authentication Server [See PIC, XAUTH] is used to authenticate CEs in another provider's network and request VPN information from a back-end server (e.g. a RADIUS server or DHCP Server), may be required. The CEs in another provider's domain cannot be updated with new VPN information, unless the back-end server is able to provide VPN information update to the front-end Authentication Server, and the front-end Authentication Server is able to inform CEs of the VPN information change. It should be noted that authentication may not be required when the CEs are attached to the service provider's network, because the service provider could use ingress filtering to prevent VPN Provisioning Server or CE masquerading. When the CEs are not attached to the service provider's network, it is necessary then to authenticate the auto-provisioning. This approach is discussed in the Appendix. 5.7 RADIUS This allows a provider to leverage existing AAA framework for IP VPN. Currently this approach does not allow a server to update CEs of VPN information. This approach is discussed in the Appendix. 6. Management Boundary Issues We do not see a motivation for a VPN provider using a CE-based VPN approach to share management of a VPN with another VPN provider. A VPN provider could provide a VPN service that spans inter-domain boundaries as long as all the CEs are reachable inter-domain. Hence, we do not see a need to address this type of inter-provider management at this point in time. In the case where the CE is provisioned by both the customer and provider, let us consider this example. Consider a PC at home being auto-configured (e.g. with an IP address, web server, DNS etc) by an ISP. One could view this as crossing provisioning boundaries (the PC owner & the ISP are allowed to provision the same box), but in this case the provisioning by the ISP is made transparent by auto- configuration. Auto-provisioning in this case is quite different from conventional management (which may allow configuring of a more general set of parameters, whereas in the former, only a well-defined set of parameters are being configured by another party). This auto- provisioning paradigm may be used in a similar manner to configure VPNs. In the case of where the CEs of a VPN are in one domain, a network provider should perform ingress filtering to prevent VPN Provisioning Server masquearading as described in the Appendix. In the case where CEs may span inter-domain, it is necessary to authenticate the auto- provisioning of a well-defined set of parameters as described in the Appendix. 7. Conclusion To facilitate CE auto-configuration, the following alternatives may be considered: a) specify the MIB required for CE auto-configuration. This MIB may be part of the IP VPN MIB for CEs, which can be used to perform remote manual provisioning of other parameters that do not require auto-configuration, as well. Vendors may build proprietary auto- configuration framework independently and configure the MIB objects on CEs via SNMP. b) specify the tunnel information to be carried in a suitable protocol, which ideally should meet the requirements of CE auto- configuration and allows existing network device configuration framework to be leveraged for CE auto-configuration 7. Acknowledgments The authors would like to thank Andrew Krywaniuk and Pierre Bolduc for providing helpful technical information, Craig Sheppard, Phil Nelson, Cliff Wang and Eric Rosen for CE configuration discussions. We have also used some text suggested by Eric Rosen in this draft. References Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [CE-VPN] A Framework for Provider Provisioned CE-based Virtual Private Networks http://search.ietf.org/internet-drafts/draft-ietf- ppvpn-ce-based-01.txt [CE-VPL] CE-based Virtual Private LAN http://search.ietf.org/internet-drafts/draft-lee-ce-based-vpl-01.txt [DHCP] Dynamic Host Configuration Protocol, http://www.ietf.org/rfc/rfc2131.txt [DHCP-AUTH] Authentication for DHCP Messages, ftp://ftp.isi.edu/in- notes/rfc3118.txt [PPP] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994. [IPCP] G. McGregor, "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1172, May 1992 [XAUTH] Beaulieu, Pereira, "Extended Authentication within IKE (XAUTH)", draft-beaulieu-ike-xauth-02.txt, October 2001. [PIC] Sheffer, Y., Krawczyk, H., Aboba, B., "PIC, A Pre-IKE Credential Provisioning Protocol", Internet draft (work in progress), draft- ietf-ipsra-pic-05.txt, February 2002. [DSL_autoconf] Technical Report TR-044, "Auto-Configuration for Basic Internet (IP-based) Services", DSL Forum, November 2001 [HTTP-BCP] http://www.ietf.org/rfc/rfc3205.txt?number=3205 [PPVPN-REQ] http://search.ietf.org/internet-drafts/draft-ietf- ppvpn-requirements-03.txt Appendix 1. Overview of CE Auto-configuration solutions A CE shall be automatically configured with an IP address to allow it to communicate with the provider's network. Different protocols (depending on the network access method and VPN service deployment requirements) which allow CEs to discover and/or be updated with VPN service information are described here. Both the automatic configuration of IP address on the CE and provisioning of services on the CE should be authenticated to prevent malicious users from tampering with CE configuration. 2. Auto-configuration of IP address of CE If a CE is located in the VPN service provider's network (also the network provider in this case), a CE may use DHCP to automatically obtain and configure its IP address (facing a provider's network). Otherwise the CE IP address is assigned by the CE's network provider, and VPN service provider must be informed of the CE IP address offline, or when a CE contact the VPN Configuration Server as described in later sections. The CE shall obtain an IP address from a DHCP server using the procedures defined in [DHCP]. The DHCP server and CE shall be configured with a shared key a priori. The CE and the DHCP server shall use the Delayed Authentication protocol defined in [DHCP-AUTH] (instead of Configuration Token). A CE should authenticate a DHCP server to ensure the DHCP server is the provider's DHCP server and not a rogue server. A DHCP server should authenticate the CE to ensure the CE is a legitimate DHCP client. No changes to [DHCP] and [DHCP-AUTH] are required during the auto- configuration of IP address of CE as described above. 3. Auto-configuration of VPN service - leveraging DHCP Once the CE has obtained an IP address, the CE shall send DHCPINFORM directly to the DHCP server to solicit for other configuration information. The DHCP server shall respond with a DHCPACK and the following VPN related DHCP option(s). If a VPN site is removed or added (or the CEs must be updated with new VPN configuration information), the DHCP server may send DHCP FORCERENEW to the CEs belonging to the VPN. The CEs shall send DHCPINFORM as described in the previous paragraph to obtain new VPN site information. This section lists the new DHCP option(s) required. 3.1 Peer CE DHCP Option The Peer CE option specifies the VPN ID (a unique number identifying a VPN or VPL within a service provider's network) and a list of Peer CE(s) which the client may connect to. The CE should setup a tunnel to every Peer CE listed. The code for this option is to be assigned by IANA. The minimum length for this option is 4 octet, and the length MUST always be a multiple of The VPN ID is 4 octet and the CE addresses are IPv4 addresses. The Reserved field is 1 octet - the 1 "O"peration bit to indicate if these are additional CEs to be added or deleted, if the "A" bit is set to 1 or to 0, respectively. 4. Code Len CE Address 1 CE Address 2 +-----+-----+------+--------+-+-----+-----+-----+-----+-----+--- | TBD | n | VPNID|Reserved|O| a1 | a2 | a3 | a4 | a1 | a2 ... +-----+-----+------+--------+-+-----+-----+-----+-----+-----+---- 4. Auto-configuration of VPN service - leveraging PPP If a CE is connected to a provider's network via PPP, the remote CE addresses of a VPN may be configured via the IPCP Configuration Options which allow negotiatiation of desirable Internet Protocol parameters. The most up-to-date values of the IPCP Option Type field are specified in the most recent "Assigned Numbers" RFC [6]. A new TBD IPCP option can be used to configure remote CE addresses of a VPN if a CE is connected to the provider's network via PPP. However this requires NAS (Network Access Servers) to support this new IPCP option. A forward looking extension may be to define an opaque IPCP option to allow some configuration options to be relayed to or from a back-end server transparently. 4.1 VPN-IP-Addresses IPCP Option This Configuration Option list the remote CE IP addresses of the VPN. By default, no VPN IP address is assigned. The IP-Address Configuration Option format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved |O| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VPNID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CE-IP-Address1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CE-IP-Address2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ........... Type TBD Length 6 + n*IP address length, where n is the number of CEs Reserved The Reserved field is 1 octet: the 1 "O"peration bit to indicate if these are additional CEs to be added or deleted, if the "A" bit is set to 1 or to 0, respectively. VPNID the VPN Identification, allowing CEs to distinguish between the different VPNs they may belong to CE-IP-Address The CE-IP-Address is the address of a remote CE. Default No CE-IP-Address is assigned. 5. Auto-configuration of VPN service - using a VPN Configuration server approach It should be noted, this approach is applicable to a customer provisioned VPN as well, the provider in this case, is the VPN administrator. The CE should be configured a priori with the name or address of the VPN Configuration server. This MAY be accomplished by pre-configuring a CE before it is being deployed or alternatively the VPN Configuration server address MAY be obtained from a DHCP server via a new DHCP option (if the CE is within the provider's network). The CE must be pre-configured with the CE's private key and digital certificate pair or the CE Identification and password (if [PIC, XAUTH] is used), and the provider's Certificate Authority (CA) and the CA's public key or the VPN Configuration Server's public key. This allows a CE to authenticate the VPN Configuration Server and the CE to be authenticated by the VPN Configuration Server (or relayed to an authentication server via the VPN Configuration Server) The CE should then be able to contact the VPN Configuration server. VPN configuration parameters may be solicited from a VPN Configuration server. If [PIC, XAUTH] is used to contact an Authentication Server (aka the VPN Configuration Server in this document), a new ISAKMP payload to carry a VPN Information request can be defined to allow the CE to request VPN Information via the Authentication Server. The VPN Information request should be sent after the CE has been authenticated. The front-end Authentication Server (aka VPN Configuration Server here) may request the VPN Information from a back-end legacy server e.g. RADIUS. See [PIC] for the rationale on using a front-end and back-end server. 5.1 Default VPN Configuration server DHCP Option (Optional) This feature may be useful if a CE network access is managed by the VPN service provider as well. The new DHCP option required is the VPN Configuration server option. The VPN Configuration server option specifies a list of servers available to the client. VPN Configuration server should be listed in order of preference. The code for this option is TBD. The minimum length for this option is 4 octets, and the length MUST always be a multiple of 4. Code Len Address 1 Address 2 +-----+-----+-----+-----+-----+-----+-----+-----+-- | TBD | n | a1 | a2 | a3 | a4 | a1 | a2 | ... +-----+-----+-----+-----+-----+-----+-----+-----+-- 6. Security Considerations for DHCP The addition of DHCP option(s) for VPN auto-configuration does not affect the security of DHCP. The security issues of DHCP are described in [DHCP-AUTH] and as it pertains to the auto-configuration of CEs, the security issues are described in this draft. If an unauthorised CE configure its own IP address, the CE may not be permitted to use any services unless the CE has been authenticated for the particular service. For e.g. a device or the default filter at the ingress to the network can be configured to discard all traffic except DHCP messages from the client (port 67) unless the client has been authenticated for services as described in Section 3. In addition all DHCP messages on port 68 from the client should be discarded (a network user should not be sending DHCP messages from a DHCP server into the provider's network). This measure which is applicable to Section 3, does not prevent a malicious user from launching a DoS attack on DHCP servers in the provider's network. [Note: If Layer 2 authentication is available, (e.g. 802.1x), it may be used to provide authenticated access to the Layer 2 network. In this case, unauthorised users are not allowed to send traffic]. To reduce DoS attacks, the DHCP server may choose to "quarantine" CEs which have exceeded the pre-defined number of communication attempts allowed with the DHCP server within a given period. Subsequent messages from these CEs may be discarded. If these measures are necessary, the text in DHCP-AUTH would need to be modified accordingly. Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Authors' Addresses Cheng-Yin Lee Email: Cheng-Yin.Lee@alcatel.com Jeremy deClercq Email: jeremy.de_clercq@alcatel.be