Network Working Group Eric Njedjou Julien Riera Internet Draft France Telecom Expires November 2006 May 2006 Problem Statement for Global IP Mobility Management draft-njedjou-globalmm-ps-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. "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 a "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html" This Internet-Draft will expire on November 2, 2006. Copyright Notice Copyright © The Internet Society (2006) Abstract This document discusses the problem of global IP mobility management in a context where some mobile operators and service providers are looking for adequate solutions to the inter-system IP mobility problem. The document addresses the specific issue of moving between IP access domains that use different mobility management protocols and mechanisms. Indeed this type of movement would be an important subset of global IP mobility scenarios. njedjou Expires November 2006 [Page 1] Internet-Draft problem statement May 2006 Table of Contents 1. Introduction................................................2 2. Terminology.................................................4 3. Abbreviations...............................................6 4. Deployment scenarios considered.............................6 4.1. Movement between different access network systems assisted with a third party provider......................7 4.2. Movement within an integrated access network provider.......8 5. Issues and problems with Existing global IP mobility management (gmm)solutions................................10 5.1. Signaling volume over the radio............................10 5.2. Complexity of mobility management procedures...............11 5.3. Complexity of hosts........................................11 5.4. Network initiation of mobility.............................11 5.5. Terminal initiation of mobility............................12 5.6. Mobility between two heterogeneous mobility management domains owned by a same operator.........................12 5.7. Inter-system mobility in other SDOs........................15 6. Security Considerations....................................15 7. Conclusion.................................................15 8. References.................................................16 9. Acknowledgments............................................16 10. Authors Addresses..........................................16 1. Introduction Global mobility management protocols have been under design by the IETF for the past fifteen years or so (assuming the creation of the Mobile IP Working Group as a start). The basic goal pursued at the time of starting that effort, was the ability to continue an IP session when a host IP address had to change. The targeted IP sessions were those involving a transport level connection. No other motivation but to achieve session continuity has really been taken into account so far in defining the existing solutions for global IP mobility management. Effectively, the main goal has always been to hide the IP address change from the transport level as well as from the correspondent node perspective. In such a way, a host would keep its transport connection opened and continue to be reachable while moving. The functions achieved were; . Updating the network of the host IP configuration change . Having a mobility anchor node perform the route update (upon moving node alert) or notify correspondents that the moving host care-of address had changed Njedjou Expires November 2006 [Page 2] Internet-Draft problem statement May 2006 . having a mapping on the host between a current and permanent address to deliver packet to applications Solutions as Mobile IP or HIP operate on that pattern. Actually, global mobility management architectures and protocols at IP layer have grown in more or less a parallel to those designed in other SDOs as 3GPP where other considerations were taken into account aside that of just continuing the session of a user. Indeed 3GPP would be motivated by other considerations as for example the need for the provider to control the selection of the target access network of attachment. And still, future global mobility systems will tend to marry existing mechanisms from different standardization actors (IETF, 3GPP, IEEE802…) built with different purposes and motivations. This tendency will grow even wider as services will move to be all-IP based and access agnostic. With the previous picture taking place, there is a growing feeling that the match between these mobility mechanisms built in these different SDOs is far from being perfect and suitable. This is especially true when considering some market oriented requirements as can have; . Mobile operators owning several access networks of different types that they want to make cooperate to provide their users with global mobility . Third parties operators that want to provide IP mobility to customers, regardless of the operators to which these customers are subscribed for the accesses. Indeed the fact that an IP session handover has to be seamless should not be the only motivation when solving the global mobility problem. What appears as a simple movement actually involves a lot of external factors. While ensuring seamless continuity for the user, other objectives are to be fulfilled. Such objectives can be as numerous as: . Judiciously using the "newly" available radio capacity (Wifi, Wimax…) to relieve cellular systems and provide multimedia services; . Guaranteeing service level for the users by helping them determine the best system for the service they want to access to; . Optimizing the use of the radio resources (especially on cellular), so as to dedicate the radio spectrum to serving more data/voice by lowering the signaling overhead; . Making integrated (and therefore already composite) architectures less complex, as well as minimizing protocols to render overall systems more scalable; . Lowering requirements and constraints on hosts for an easier support of inter-system mobility. Njedjou Expires November 2006 [Page 3] Internet-Draft problem statement May 2006 Some of the previous bullets points basically require that the global mobility management system be network initiated/operated while other could be met independently of the mobility operation model. Therefore an IP mobility solution designed to enable the previous requirements should fit both terminal and network initiation and operation schemes. So that any service provider would be free to make the use of the solution they want, according to their architectures and services. Most of the listed requirements seem not to be in favor of the global mobility management solutions as they exist today. The remainder of this document is dedicated at developing the previous statement. 2. Terminology Terminology is an aspect of mobility management that is in constant change, because of often evolving requirements. The definitions précised below are wanted consensual enough not to confuse the reader. Aggregate router This is a specific router in an access network acting as its border router on the core network side. Care-of-address In this document, a care-of-address refers to an IP address temporarily acquired by a mobile host while visiting an IP access network, irrespective of which global mobility management protocol the host is running. Therefore, a host may have a care-of-address without running MIP. Coming revisions of this document might suggest an alternative expression to avoid ambiguity. IP location update This is a generic procedure whereby a host informs a mobility anchor in the network or a correspondent located anywhere on the internet that it has a new active care-of-address and therefore a new IP location. This procedure is called registration in Mobile IPv4 and re-association in HIP. Comprehensive Mobility management Njedjou Expires November 2006 [Page 4] Internet-Draft problem statement May 2006 RFC 3753 defines local and global mobility management but the notion of mobility management itself is not defined. For the purposes of this document, comprehensive mobility management will be defined as the process of performing and sequencing the following actions; . Collect information from terminal, Radio Access Points and Resource Controllers to assess the need or opportunity for a handover . Choose a handover target, as a result of deciding the next Radio Access Network and Point of attachment based on collected information, QoS needs and other policies. . Execute the handover on the terminal. This generally consists in switching between radio links, preparing the IP configuration over the new link and performing the IP location update. This definition does not make any assumption of which side between the network and the terminal decides of the handoff target. Global IP mobility management IP Mobility management is said to be global in this document whenever it involves a mobile host that is moving between IP domains that use different mobility procedures and protocols. Heterogeneous access networks would basically constitutes such IP domains. These domains can be part of the same administrative boundaries, eg an operator integrating several access networks providers or belong to different network administrations. With this definition an UMTS/WLAN IP service transition will be global, as well as will be a movement between a NETLMM operated domain and a 3GPP LTE domain. Network global IP mobility management A global mobility management initiated or operated by the network Local IP mobility management Mobility management is said to be local whenever it involves a mobile host moving . Within an IP domain using a single mobility management procedure . Between two IP domains that use the same mobility management procedures and protocols. With this definition, the movement of a host within a Wlan or Wimax domain will be considered local. Indeed, in such domains, a single IP mobility management protocol would basically be used. Also will be considered local, a transition between two NETLMM domains. Njedjou Expires November 2006 [Page 5] Internet-Draft problem statement May 2006 Mobility anchor A mobility anchor is an IP node that either: . Performs the forwarding and path update of IP packets destined to the moving host . notifies correspondents that the moving host care-of address has changed With this definition, a mobility anchor only participates to the goal of making the moving host reachable. The Home Agent of MIP and the Rendez-Server of HIP are examples of defined mobility anchors. However this terminology does not necessarily relates to these nodes. Inter-System Mobility Agent This is a function typically located either in an integrated access operator network or in the terminal and that helps deciding of the mobile host target system (step 2 of comprehensive mobility management) based on several criteria. Such an agent is used in this document to illustrate the global mobility management problem. Considerations associated with selection criteria are clearly out of scope. 3. Abbreviations gmm: global IP mobility management NETLMM: network localized IP mobility management LTE: Long Term Evolution of the radio access network currently prepared by 3GPP MIH: Media Independent Handover. This is a functionality of the Draft IEEE 802.21 specification IMS: IP Multimedia Subsytem of 3GPP 4. Deployment scenarios considered As said earlier, global mobility refers to the movement performed by a host as it changes its point of attachment from an IP domain to another that has a different mobility procedure. Such movements will either occur between two access networks of different providers or also between two access networks owned by the same service provider. The problem raised in this document addresses both categories of movement. Njedjou Expires November 2006 [Page 6] Internet-Draft problem statement May 2006 4.1. Movement between different access network systems assisted with a third party provider. The following figure depicts a deployment model where a host is moving between two access networks (as described previously) operated by different providers. Such providers will usually not cooperate for the purpose of comprehensive mobility management as defined earlier, nor cooperate with a third party that will serve the mobility between those access networks. Such a third party will typically own the IP mobility anchor. * * * * * +----------+ * | Mobility | * | Anchor | * +----------+ * * * * * * * * * * * * Internet * * * * * * * * * * * * * * +-------+ +-------+ |AggR A1| |AggR B1| +-------+ +-------+ AN A @ @ @ AN B Provider A @ @ @ Provider B @ @ @ @ @ @ +-----+ +-----+ +-----+ |AR A1| |AR A2| |AR B1| +-----+ +-----+ +-----+ * * * * * * * * * * * * * * * * * * * * /\ /\ /\ /\ /\ /AP\ /AP\ /AP\ /AP\ /AP\ / A1 \ / A2 \ / A3 \ / B1 \ / B2 \ ------ ------ ------ ------ ------ | | | | | | Njedjou Expires November 2006 [Page 7] Internet-Draft problem statement May 2006 +--+ +--+ |MN|----------------->|MN| +--+ +--+ Figure 1: example Deployment scenario for two access networks owned by different providers The terminal is in this case, the only entity in good position to initiate the mobility management functions. Indeed it is the only node capable of getting access networks information, necessary to decide of the movement. Global mobility management solutions as they are specified today (i.e basically host based) well apply to this deployment model. However, as said earlier, the right mobility architecture should be able to accommodate all deployment models and mobility controls schemes. 4.2. Movement within an integrated access network provider The following figure depicts a classical deployment scenario for an operator that is owner of several access networks that it can make cooperate, because of the need to ensure the goals and requirements as listed in the introduction. * * * * * * * + ----------+ * |Inter-System| * | Mobility | * Operator network | function | + ----------+ * * +---------- + * |IP Mobility| * | Anchor | * +---------- + * * * * * * * * * * * * * * +-------+ +-------+ |AggR A1| |AggR B1| +-------+ +-------+ AN A @ @ @ AN B @ @ @ Njedjou Expires November 2006 [Page 8] Internet-Draft problem statement May 2006 @ @ @ @ @ @ +-----+ +-----+ +-----+ |AR A1| |AR A2| |AR B1| +-----+ +-----+ +-----+ * * * * * * * * * * * * * * * * * * * * /\ /\ /\ /\ /\ /AP\ /AP\ /AP\ /AP\ /AP\ / A1 \ / A2 \ / A3 \ / B1 \ / B2 \ ------ ------ ------ ------ ------ | | | | | | +--+ +--+ |MN|----------------->|MN| +--+ +--+ Figure 2: Deployment scenario for an integrated operator 4.2.1. Inter-System Mobility management In such an integrated operator scenario, the network is in good position to initiate mobility management. It is specifically able to watch over the capacity of every system and monitor terminal conditions so as to take the best decision for the user target. An Inter-System Mobility function would basically perform this IP handover preparation. Specifications as the 802.21 draft would see the MIH Point of Service into such a function (with a corresponding entity in the terminal and radio access points). Note that this inter-system mobility function can be co-located to the node acting as the IP Mobility anchor. However these considerations are informative only and out of scope here. IP mobility is clearly the focus of this document. However the authors intent is to make the point that IP mobility can not be discussed regardless of the inter-system mobility architectures that are likely to be deployed. 4.2.2. Knowledge of host care-of address change by the network When a core network is able to federate the IP domains, information can be easily exchanged between these domains and such a core network, belonging to the provider. Therefore, the current IP configuration of a host can be known in the provider home network. Njedjou Expires November 2006 [Page 9] Internet-Draft problem statement May 2006 Effectively IP configuration assignment schemes of a provider would be managed from within the provider home network. On the event of a handover to another IP access domain of the integrated provider, the target IP configuration of the host (including the care-of-address to use) would be prepared in the home network so that the host would not have to make any notification back upon receiving that new configuration. However a mobility anchor would still have to perform the routing update consequently to the host changing its active IP connectivity from one domain to another. Therefore, the explicit IP location update as well as the necessity to keep association states between hosts and mobility anchor of existing global mobility solutions (Registration and REA procedures of MIP or HIP) can be avoided in this model. The next paragraph precisely describes the problem encountered when resorting to such an explicit IP location update and association with a IP mobility anchor. It is to be made explicitly clear that any specific procedure by which the network can be aware of the terminal new and old IP configuration is not assumed. Every implementation of the deployment model can figure out how they want to get the information. 5. Issues and problems with Existing global IP mobility management (gmm)solutions This paragraph captures the reasons why classical gmm solutions are problematic with regards to driving requirements as presented in the introduction. 5.1. Signaling volume over the radio Global IP mobility management solutions known to date do not guarantee an efficient use of the radio capacity, especially with the need to associate to a mobility anchor and perform frequent explicit re-associations. Terminals are required to support more and more control planes as they are becoming convergent. A single terminal would have to support, multiple radios, as well as multiple authentications protocols, inter-system mobility, IMS… that all generate fair amount of signaling. Aside of IP session continuity, integrated mobility architecture will also have to address such transitions as VoIP to circuit switched voice. So will multi-systems terminals. This additional type of session continuity requires specific mobility anchors that are different from entities as Home Agents (that can only perform Njedjou Expires November 2006 [Page 10] Internet-Draft problem statement May 2006 the switch between two IP legs). Therefore, it is a strong requirement that signaling overhead from hosts to these different gateways do not grow as their number or type multiplies. 5.2. Complexity of mobility management procedures As said in the introduction, simplifying architectures and hosts, as well as minimizing the protocols is a requirement on the road to rendering next generation mobility architectures more scalable. Comprehensive mobility management procedures would basically require that a mechanism exist to perform the steps as described in section 2, basically collecting information to prepare a handover, and indicating the target to the terminal. Solutions for gmm do not provide these steps, which anyway they are not meant for. The very problem is that they were not thought to be included to the comprehensive procedures. Therefore the gmm mechanisms would usually superpose to the previous procedures to create complex state machines and heavy message exchange flows between hosts and the network. Also, usually the integrated architecture would already have mobility management states for every activated link (UMTS, Wimax…) on the terminal. To that, is superposed the global IP mobility management protocol. This protocol superposition adds sensitiveness to the overall stability of the architecture. In the middle of that, the integrated architecture will necessarily have to support inter-media convergence functions such as the MIH of 802.21. 5.3. Complexity of hosts Lowering software support requirements on hosts would facilitate early adoption of seamless mobility by reducing the time to market for terminals to be IP mobility compatible. This is already a requirement of NETLMM. However such a requirement difficulty applies for scenarios where the host has to move between domains operated by different administrations. Another example of ongoing standard specification where the principle to get rid of host support applied is the VCC (VoIP to Circuit Switched) transition work item carried out in 3GPP. This item is being addressed with no specific needed support on the host but native IMS. 5.4. Network initiation of mobility An integrated deployment model as presented in 3.2 has the ability to facilitate network initiation of handovers. This brings guarantee of service level to moving users. Indeed the integrated Njedjou Expires November 2006 [Page 11] Internet-Draft problem statement May 2006 provider can monitor the load of a base station before allowing a user application to move to that point of attachment. Network initiation also brings assurance that the capacity of the provider is efficiently spread across the wireless domains. Initiating an IP handover from the network requires that the re- association procedure should be initiated by the network. Taking the MIP example, a host would have to perform the registration update just after receiving an indication from the network to switch to a different system. Therefore, a specific requirement on the MIP stack would be to trigger the registration update exchange upon indication to switch between links. Furthermore, as the existing gmm solutions as MIP let it totally implementation dependant the set of events that trigger the IP location update procedure, it is practically impossible for all implementations to have the same state machine for triggering such a re-association. Therefore, implementations as would be wanted for network initiation will have to be featured in a way to perform the re- association procedure only after a network indication to do so. Flexibility of standard implementation is often desired but can be become cumbersome in such a case. Many integrated operators are building roadmaps for deploying seamless mobility for IP services with the requirements presented at the beginning of the document. Because of the previously identified problem of gmm solutions to date, such operators have to make specific requests for quotations to smart devices vendors to design implementations that fit their purposes. This burden becomes considerable when deployment is considered at a large scale. 5.5. Terminal initiation of mobility For terminal initiated mobility scenarios, a similar problem is present. Despite the fact that it would be an inter-system mobility agent on the terminal that would decide to pass the traffic to a different link, the gmm protocol still has to be able to understand an order to do so. 5.6. Mobility between two heterogeneous mobility management domains owned by a same operator Two mobility management domains are said to be heterogeneous whenever the protocols they run for mobility are different. An alternative deployment scenario for an integrated provider willing to offer global mobility would via the aggregation of several heterogeneous mobility domains anchored to a unique core network. Njedjou Expires November 2006 [Page 12] Internet-Draft problem statement May 2006 Effectively, a mobile operator could deploy WiMax in a hotzone and LTE all around, with an IP mobility protocol (NETLMM for example) inside the Wimax zone. * * * * * * * Operator's * * Aggregation * * Network * * * * * * * * * * * * * * * * * * * * * * * * * * * * MM Domain A * * MM Domain B * * * * * * IP based * * 3GPP based * * * * * AN A * * * * AN B * * * * * * * * * * * * * * * * * * * * * * * * * /\ /\ /\ /\ /\ /AP\ /AP\ /AP\ /AP\ /AP\ / A1 \ / A2 \ / A3 \ / B1 \ / B2 \ ------ ------ ------ ------ ------ | | | | | | +--+ +--+ |MN|------------------->|MN| +--+ +--+ Figure 4: Mobility between mobility management domains of a single operator As in the scenario of figure 2, the fact that both domains belong to the same administration, make it possible the exchange of information for mobility management within the network. Njedjou Expires November 2006 [Page 13] Internet-Draft problem statement May 2006 As different localized mobility management protocols would be used in each access domain, a different mobility protocol will have to be resorted to for the inter-domain transition. Again for architecture scalability and host simplicity, it would not be desirable to multiply such mobility protocols. Therefore, solutions as NETLMM would certainly better be commoditized for integrated architectures and made more compliant to global mobility, so that the hosts and the network do not require any additional mobility management protocol to achieve the inter- mobility management domain movement. Also if it eventually turns out that a host based solution as MIP is used for the movement from a NETLMM to another mobility management domain, and especially when these domains are owned by the same operator, it will not have been very useful to bring new solutions where the host is not involved. It is to be made clear that in the case where access domains A and B are operated by different administrations (eg. NETLMM domain owned by operator A and LTE domain owned by operated B), the moving host stands as the unique federation entity and would therefore have to be more implicated in the global mobility management. Domains owned by several operators will usually not exchange mobility management information. * * * * *third party* * mobility * * anchor * * * * Internet * * * * * * * * * * * * * * * * * * * * * * * * * * MM Domain A * * MM Domain B * * * * * * IP based * * 3GPP based * * * * * AN A * * * * AN B Provider A * * * * *Provider B * * * * * * * * * * * * * * * * * * * * Njedjou Expires November 2006 [Page 14] Internet-Draft problem statement May 2006 /\ /\ /\ /\ /\ /AP\ /AP\ /AP\ /AP\ /AP\ / A1 \ / A2 \ / A3 \ / B1 \ / B2 \ ------ ------ ------ ------ ------ | | | | | | +--+ +--+ |MN|------------------->|MN| +--+ +--+ Figure 5: Mobility between mobility management domains of different access network providers As a general observation it is worth reminding that it is making more and more sense from the market perspective to work on mobility management solutions meeting the requirement of both terminal and network modes of mobility management 5.7. Inter-system mobility in other SDOs 3GPP is working on evolved inter-system architectures that could require global IP mobility protocols for 3GPP to non-G3PP mobility. Solutions meeting requirements presented in this document would be particularly adapted to these new architectures. Available gmm solutions may still work from a pure technical point of view, but would not meet important requirements as system scalability, host complexity, signaling volume reduction and many others discussed earlier. IEEE 802.21 is defining procedures for managing the transition of a host across several media. For that purpose, a media independent handover protocol will have to be supported in the mobility architecture. Therefore the Internet mobility architecture is definitely to be adapted to the constraints of inter-media mobility scenarios that 802.21 is developing. 6. Security Considerations Security issues linked with existing gmm solutions can not be said to be an obstacle to deploying architectures with network global mobility management. Therefore there is no security issue identified as such. However design goals of a solution to address the problem described here will have to state precise security requirements. 7. Conclusion Njedjou Expires November 2006 [Page 15] Internet-Draft problem statement May 2006 This document has tried to illustrate the problem of performing IP mobility with IETF already defined solutions. The context has been confined to a specific family of deployment scenarios, deemed to have the potential to grow wide enough to legitimate dedicated solutions. It turns out that most of the issues that have been gone through were especially bad for network global mobility management. It can be said that existing solutions were thought in a terminal centric approach and as such match pretty well the needs of the types of deployments scenarios that where the host would have to initiate the mobility. 8. References [MIPV4] "IP Mobility Support", C. Perkins (editor), RFC 2002, October 1996. [MIPV6] "Mobility Support in IPv6", D. Johnson, C. Perkins, and Jari Arkko, RFC 3677, June 2004. [TERM] "Mobility Related Terminology", J. Manner, M., RFC 3753 June 2004 [HIP] "Host Identity Protocol", P. Jokela (editor), draft-ietf- hip-base-04, work in progress, October 2005 [NETLMM] "Problem Statement for IP Local Mobility", J. Kemps (editor), draft-ietf-netlmm-nohost-ps-00.txt, work in progress, February 2006 [NAH] "Motivation for Network Controlled Handoffs using IP mobility between heterogeneous Wireless Access Networks", E. Njedjou, P. Bertin, P. Reynolds, draft-njedjou-inter-an-handoffs- 00.txt, February 2003. 9. Acknowledgments The authors would like to thank Karine Guillouard, Servane Bonjour, Jean Christophe Rault from France Telecom for the valuable inputs they had as reviewers of this document. 10. Authors Addresses Eric Njedjou France Telecom 4, rue du CLos Courtel 35512 Cesson Sévigné BP 91226 France Phone: +33299124878 Email: eric.njedjou@france.telecom.com Njedjou Expires November 2006 [Page 16] Internet-Draft problem statement May 2006 Julien Riera France Telecom 38/40, rue du Général Leclerc 92794 Issy Les Moulineaux Cedex 9 France Phone: +33145298994 Email: julien.riera@francetelecom.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Njedjou Expires November 2006 [Page 17] Internet-Draft problem statement May 2006 Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Njedjou Expires November 2006 [Page 18]