Network Working Group A. Mihailovic Internet-Draft Kings College London Expires: March 16, 2002 M. West R. Hancock Siemens/Roke Manor P. Eardley BTexact Technologies T. Suihko VTT Information Technology Septembar 16, 2002 Experience of the BRAIN and MIND Projects in the Development of IP Mobility Solutions 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." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 24, 2002. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This draft gives an overview of the design of IP mobility protocols conducted in BRAIN and MIND IST projects. Mihailovic, et al. Expires December 24, 2002 [Page 1] Internet-Draft Experience of BRAIN and MIND June 2002 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Initial Strategy . . . . . . . . . . . . . . . . . . . . . . . 3 3. Design principles . . . . . . . . . . . . . . . . . . . . . . 4 4. Proposed IP Mobility Solution . . . . . . . . . . . . . . . . 7 5. Further Discussion on the IP Mobility Solution . . . . . . . . 8 5.1 Architecture Considerations . . . . . . . . . . . . . . . . . 10 5.2 Modularity . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.3 Scaling and Resilience . . . . . . . . . . . . . . . . . . . . 11 5.4 Current BCMP work . . . . . . . . . . . . . . . . . . . . . . 12 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 12 7. Project Details . . . . . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 15 Mihailovic, et al. Expires December 24, 2002 [Page 2] Internet-Draft Experience of BRAIN and MIND June 2002 1. Introduction The BRAIN [1] project dealt with the development of an IP-based architecture for IP access networks. Extensive research into IP mobility protocols was one of the main activities of the project. The BRAIN Access Network (AN) is defined as a static IP access network with wired internal infrastructure and heterogeneous wireless access for mobile nodes (MNs). IP functionality is contained in the entire system from gateways to Access Routers (ARs) where MNs are assumed to run IP protocols with additional capabilities required to take advantage of the connectivity offered by the AN. The MIND [2] project is the follow-up project to BRAIN continuing the development of the AN architecture by including some new network scenarios (MANET / NEMO extensions). However, MIND also deals with improvements to and testing of the results of BRAIN (including the IP mobility protocol developed). In the following we present a summary of our design processes for development of IP micro-mobility [8] solutions by discussing our initial research strategy, some particular design decisions made along the way, current results of our work and reasoning behind our decisions embodied in the results. 2. Initial Strategy The ultimate result of our effort was intended to be a recommendation for the IP mobility solution for deployment in the AN. Initially, this development was not restricted in any sense, our options were: selection of an existing IP mobility protocol that would satisfy the set of requirements; enhancement or simplification of an existing IP mobility protocol; or development of a new solution. Due to the overwhelming number and variety of available IP mobility protocols, we initially decided to perform a detailed analysis of existing IP mobility mechanisms. This was expected to provide extraction of the key issues that need to be solved by any IP mobility protocol and to allow comparison of the different concepts applied in solving those issues [3]. Those issues were named Protocol Design Issues and included all aspects of IP mobility: packet forwarding mechanisms, path updates, handover management, address management, support for idle MNs/paging, security, requirement for MNs, requirements for Core Network Interface and Routing Topology. To assist the analysis we proposed a classification of IP mobility protocols where the most relevant axis for separation of protocols was the difference in concepts applied for mechanisms of packet Mihailovic, et al. Expires December 24, 2002 [Page 3] Internet-Draft Experience of BRAIN and MIND June 2002 forwarding. The classification was generally applicable to any micro-mobility protocols. (Macro-mobility was considered as a separate issue as discussed in the following sections.) The classification produced two main categories of micro-mobility Protocols: 1) Protocols deploying Proxy Agents and typically using IP tunnels for packet forwarding between the Agents. This effort has now converged in HMIP-based proposals (Regional Registrations for IPv4 and HMIPv6) for IPv4 and IPv6. 2) Protocols deploying enhanced routing methods in scoped domains. These are all types of protocols that use a form of per-node routing techniques (we called these "Localised Enhanced Routing Schemes"). This category can be further divided as follows: 2a) pure per-node forwarding techniques: mobility protocols deploying new routing features by typically installing per-node states in routers in the localised domains (e.g. HAWAII, Cellular IP,...). 2b) mobility protocols using multicast as the routing solution in localised domains. 2c) mobility protocols deploying (modified) ad-hoc routing protocols as the routing solution in localised domains (e.g. MER-TORA). We picked an exemplar protocol from each of the protocol categories above, and assessed them against the Protocol Design Issues for several Evaluation Criteria (efficiency; scalability and robustness; applicability / ease of deployment). The conclusions from this exercise were that no existing micro-mobility protocol - or category of protocol - is clearly preferable (each has pros and cons). Our next step was to argue about what "design principles" a micro- mobility protocol should have - the high-level, mostly architectural, features that a good solution should have. 3. Design principles Defining a set of design principles and solution requirements is a vital step in the evaluation and development of IP mobility protocols. It assists in creating a constructive perspective to the problem, which may sometimes appear too abstract to solve. While this method of working around the problem is not a novelty, our particular design principles and solution requirements are further shaped by the particular architecture of the IP AN in consideration. Mihailovic, et al. Expires December 24, 2002 [Page 4] Internet-Draft Experience of BRAIN and MIND June 2002 We believe that this approach demonstrates a useful experience and could help the development of all IP mobility protocols, not only the ones to be deployed in the above explained IP ANs. Some of the design principles we found helpful are listed: 1. IP's 'usual' design principles: the architectural principles of the Internet, (e.g. the end-to-end principle which is sometimes reduced to the concept of the dumb network); layered design ('IP over everything, everything over IP'); and modular design (to help flexible deployment and evolution) 2. A well-defined problem scope: Our problem scope was an IP AN where MNs move around from one AR to another. From a pure IP perspective this AN, which is controlled by a single operator is a single administrative domain and it is of arbitrary size. 3. Transparency principle: This was the term we used to capture our assertion that the basic goal of the AN is to make mobile wireless Internet access look like 'normal' access through wired infrastructure. For example, this means that the access network completely hides, from other fixed networks and correspondent nodes (CNs), the mobility and wireless aspects; these are only visible as performance impacts such as transient QoS variations - just as occur with other access systems. Additionally, the AN is expected to perform appropriate uplink and downlink forwarding of packets without changing or discriminating their contents, provided MNs are authorised to use the network. 4. Impact of transparency principle on addressing: The AN must allow a MN to get an IP address to use in communicating with CNs (again no assumption on macro-mobility mechanisms because the AN may be the 'home network' of MN), and to keep this address whilst it moves(because if mobility caused its address to change that would be visible outside the AN, violating the 'transparency principle'). Therefore the AN must: * assign addresses to MNs - which are globally reachable * route packets to the MNs based purely on these locally assigned IP addresses. 5. Micro and macro mobility should be solved with separate protocols: This follows as another corollary of the transparency principle. If macro mobility (i.e. MN moving between ANs) were to impact micro mobility, then the latter would be unable to work with alternative macro mobility protocols - which would violate the transparency principle. Further, since routing within the AN Mihailovic, et al. Expires December 24, 2002 [Page 5] Internet-Draft Experience of BRAIN and MIND June 2002 is based on the locally assigned IP address, when the MN moves into another AN it must get a new IP address. This conclusion is different from much of the existing IP mobility work which try and solve all mobility problems with a set of extensions closely coupled to some version of Mobile IP. 6. Modularity: Starting from the initially identified Protocol Design Issues it was considered beneficial to re-group the functions they represent into (semi) independent modules of the complete mobility solution. Naturally, not all of the identified Protocol Design Issues are functionally separable from the rest of mobility. Some initial conclusions were: separated air interface protocols from internal protocols, paging, address management, AAA, interaction with lower layers... The AN must allow a MN to obtains an IP address for all of its correspondences, to retain that address and must be capable of routing packets to the MN based on the acquired IP address. While obeying these requirements there should be a fair amount of freedom offered to MNs to actually change the obtained IP address or obtain more than one address. The separation of handover management, path updating and paging is not new and is already seen for MIP-based and HMIP-based solutions [5], the Edge Mobility Architecture (EMA) [6] and Seamoby paging [7]. An outline of the benefits of such separation is (the references contain more detailed discussion): * easier design (eg handover management doesn't have to worry about scalability, as it only ever involves three entities (old and new ARs and MN)) * easier evolution - breaking up the problem along clear functional boundaries between the modules allows for separate evolution of the components. * easier deployment - (potentially) allow standardisation of the air interface signalling - a universal standard would allow a mobile to work on any network (providing of course that it had the appropriate wireless link technology), whilst also allowing an operator to choose a path update protocol appropriate to their particular circumstances (eg different protocols for large and small networks). * Easier 'fallback' - eg in a "planned" handover, when the MN ends up not moving as expected onto the new AR. 7. Scaling and Resilience: It is important to consider these two requirements from the very start of the design process. In particular we identified the following specific requirements on Mihailovic, et al. Expires December 24, 2002 [Page 6] Internet-Draft Experience of BRAIN and MIND June 2002 the micro-mobility solution: support multiple AN gateways, encourage route aggregation and provide fast recovery in case of link or router failures. 4. Proposed IP Mobility Solution The main modules consist of routing, handover, path updates, addressing, and paging where the additional mechanisms such as AAA and link layer interaction should be treated independently or as functions associated with the mechanisms of a particular module. We now discuss each of these modules further; we leave open the question of which 'modules' could/should be separate protocols. 1. Address Management: address allocation is independent of the other 'modules'. Address change does not occur as an automatic consequence of mobility inside the AN. However, it can be triggered by a MN or the AN, according to their particular preferences. This approach to address management contrasts with many other IP mobility solutions; one of its advantages is that the network operator can manage addresses in the manner that suits them. In case the allocated address is prefix routable inside the AN (apart from being globally routable) its origin should be any possible entity in the network: AR, any internal router or any network gateway. 2. Handover Management: Separated Handover Management gives flexibility and freedom for development of appropriate solutions considering the relevant criteria. Depending on the suitability to a particular deployment scenario handovers can be mobile or network controlled/assisted, independent/dependent on particular wireless scenarios... As mentioned there should be no direct relation and interdependence between the addressing and any stage of the execution of the handover sub-protocol. 3. Path updates: This relates to the mechanism for facilitating re- routing of packet flows in the AN (executed after handover completion). Assuming that handover management protocol takes care of the temporary redirection of packets during the handover, the importance of path updates with respect to handover latencies is reduced. The path updates should be triggered when the AR transfer facilitated by the handover management is certain. The initiator of the path updates can be AR or MN. MN is inevitably involved in stages of the handover protocol and since handover is decoupled from the rest of mobility, it is beneficial to "hide" the process of path updates from MNs and trigger them from ARs (this option may also be preferred for security reasons). Mihailovic, et al. Expires December 24, 2002 [Page 7] Internet-Draft Experience of BRAIN and MIND June 2002 4. Routing: Routing (or packet forwarding) considering the above setup mostly relates to the way in which packets are forwarded from the address origin (router entity allocating the addresses in case they are prefix-routable inside the AN or the local domain ingress entity in case they are not). Our conclusion was that both per host or tunnel based protocols can meet these requirements for this particular protocol step. In addition, regular prefix-based routing inside AN should be encouraged for resilience as discussed below. 5. Note: routing as a separate module is not separable from the rest of mobility as clearly as other presented modules but involves an important design decision (i.e. per node vs. tunnel based...) which, according to the presented discussed platform, can be considered independently. 6. Paging: Paging should run on its own when required, with minimal interactions with other mobility modules but with close interaction with link layer solutions. 7. IP-to-Wireless (IP2W): We developed a standardised API between IP and a generic wireless link layer. Further discussion of this "IP2W" interface is in [1]. As regards the path updating / routing modules, we were not able to reach consensus about whether per-node or tunnel based protocols are better; views depended on what other implementation factors are considered important. MER-TORA [6] is a per-node (per host) protocol that comes close to fulfilling our requirements. It meets the requirements of the transparency principle as it impacts addressing (Section 3d) and the separation from macro-mobility (Section 3e). It applies a modular approach (Section 3f) by separating handover management from path updating - the former is dealt with by, what it terms, the Edge Mobility Architecture (EMA) and the latter by a modification / extension of the TORA routing protocol. It does not deal with paging. BCMP is a tunnel based protocol that was designed within the BRAIN/ MIND projects to fulfil our design principles. The protocol and how it meets our requirements is described in more detailed below. 5. Further Discussion on the IP Mobility Solution The explained elements of the platform form the required template for creation and/or adoption of complementary mobility protocols. One such protocol is BRAIN Candidate Mobility Protocol (BCMP) initially Mihailovic, et al. Expires December 24, 2002 [Page 8] Internet-Draft Experience of BRAIN and MIND June 2002 developed in the BRAIN project and is currently being tested and refined in MIND. BCMP operations can be summarised into two main protocol parts: protocol features inside the AN and the protocol run by MNs for connecting to the AN. The latter is called MN-AR (sub)protocol and resembles the "fast handover proposals" for MIP and HMIP proposal. The MN-AR handover (sub-)protocol consists of two parts: planned and unplanned, where the unplanned part is designed as an incomplete planned handover to allow the whole handover process to successfully recover in case the planned handover fails. The central entity in the AN is the Anchor Point (ANP). The MNs are allocated addresses prefix routable to the appropriate ANP, which stands as the address origin. Note that the allocation is not performed by the ANP itself but by an independent agent in the network. There are no restrictions on the number and location of ANPs in AN: ANP can be an internal router, gateway or AR. During the downlink packet forwarding ANP tunnels received packets to the current AR where MN is attached. Although address change is possible in BCMP, by default, MNs retain the serving ANP and the allocated address during mobility within the AN. BCMP also deploys a paging mechanisms and contains additional features for AAA support, post-login address change, optimisation of the serving ANP. More details can be found in [4][1]. The candidate solution protocol BCMP is recognised to contain some similarities with some already proposed solutions mostly regarding the tunnel-based packet forwarding setup (in particular HMIP and HMIP-based solutions such as the latest variances of MIP integration with Regional Tunnelling). Also, the handover management protocol (MN-AR protocols) resembles the "fast handover" proposal for MIP and HMIP considering the mechanics of control message transfer. A summary of some main differences of BCMP and HMIP are: o BCMP makes no assumption about the global mobility protocol or tunnelling solutions o BCMP only has a single level of mobility agents (the ANPs), whereas HMIP allows multiple levels of hierarchy (ie multiple levels of MAPs - although the current recommendation is for a single level only) o Packets are tunnelled to the AR, rather than to the MN o MN is not acquiring a new "on-link" CoA every time it moves o address allocation is controlled by the network: the AN operator chooses which ANP the MN should use, in HMIP the choice is Mihailovic, et al. Expires December 24, 2002 [Page 9] Internet-Draft Experience of BRAIN and MIND June 2002 effectively made by the MN o reverse tunnelling is used from AR to ANP. 5.1 Architecture Considerations Adherence to the "transparency principle" can be explained considering the following points: o As a natural consequence of the preservation of allocated addresses, mobility of MNs is hidden from the external networks and hosts. o The handover protocol is the interface protocol for MNs connecting to the AN. The rest of the mobility mechanism inside the AN should be hidden from MNs. In BCMP, the setup of message transfers (in particular the MN-AR protocol) is such that the location of the serving ANP or any additional information about it is kept hidden from MNs. In simple terms, this means that the MN acquires an IP address during the login phase and it is only required to run the MN-AR protocol without any further mobility- related intelligence thus keeping the inside of the AN invisible to the attaching MNs. o Encouraging the prefix-routing inside the AN limits the exposure of mobility in the network. BCMP executes AAA-based control at the initial login. In practical terms, upon the initial message exchange between AR and MN, the AR consults a local AAA-entity and the address allocation agent in the network before the appropriate ANP is selected. Furthermore, BCMP deploys a reverse tunnel from the AR to ANP for uplink transmission by MN. This feature enhances the "transparency" of the protocol and offers a useful functionality for other mechanisms of the AN. In abstract terms, this causes all traffic flowing to and from the MN to appear as if it terminates and originates at the serving ANP respectively. Effectively, the template platform for mobility and BCMP as its realised example is a stand-alone micro mobility solution. It does not inhibit the use of any macro mobility protocols such a Mobile IP and can also support other global mobility mechanisms such as SIP. The stand-alone property of such a mobility solution is considered important for connectivity scenarios in IP ANs where the connecting hosts may use the actual AN as their home network. MNs are allocated globally routable IP addresses. Considering BCMP, MNs are allowed to change the obtained address not as a mobility- Mihailovic, et al. Expires December 24, 2002 [Page 10] Internet-Draft Experience of BRAIN and MIND June 2002 imposed necessity but as the controlled option for achieving optimisation of packet flows or for provisioning some other architectural aspects (QoS, ingress filtering, multi-homing). Also, MNs are allowed to request more than one IP address, even subnets, provided they satisfy the necessary requirements for such actions (again these requirements often depend on other aspects of the architecture). BCMP was primarily designed for IPv6 systems but its features are free of IPv6 or IPv4 dependency. As an example BCMP's operations are intentionally independent of any subnet structuring or autoconfiguration options. 5.2 Modularity BCMP overall setup can be decomposed to reveal the individual protocol elements of the adopted template platform for mobility. Separating the air interface protocols from the network internal protocols directly maps into the distinction between the handover management protocol (MN-AR) and the path updating process inside the access network. The addressing setup of the protocol does not impose great requirements on the handover and path updating processes. Location of ANPs is not restricted, they can be AN gateways or any routers in the network as well as ARs. Due to the MN-AR handover protocol, location of ANP is not expected to influence packet losses. Modularity allows for easy enhancement and evolution of the deployed mobility support through modification or complete change of some protocol parts of the template platform. This particular property has been the driver for the refinement work on BCMP currently being conducted in the MIND project. BCMP interoperates with other architectural components such as QoS, Radio Resource Management (RRM) and security by primarily not conflicting with their requirements and functionalities and additionally providing a platform for integration of them. 5.3 Scaling and Resilience The initial consideration for resilience of mobility solutions is that the specific mobility-imposed resilience mechanisms should be minimised and mostly assisted by the embedded support in the AN. Our conclusion was that the resilience of BCMP comes from the property of routing in the protocol, which does not rely on the specific installation of routing entries and thus overcomes any failures in the network using the default mechanisms for the internal routing setup in the AN (routing 'module'). This point should be interpreted as the explanation of the mechanism for achieving resilience, rather that mitigation of the resilience requirement. ANPs are the weakest points of the protocol, hence ANP changes are needed should the serving one fail. The utilisation of the network internal routing Mihailovic, et al. Expires December 24, 2002 [Page 11] Internet-Draft Experience of BRAIN and MIND June 2002 methods (because the MN's address is prefix routable to the ANP from where the tunnel is again prefix routable to the serving AR) provides a natural support for multiple AN gateways. Some micro-mobility protocols rely on a specific gateway-entity in the network, BCMP does not inflict any routing requirements for the ingress and egress points of the network. This again allows for better scaling of the mobility protocols as the process of assigning a particular ANP to MNs through the allocation of IP addresses and can be further controlled by the network in a traffic-engineering manner. Additionally, utilisation of the internal routing as the only packet forwarding mechanism of the protocol mitigates risks of bottlenecks (specifically imposed by the mobility support) and provides a sufficient level of confidence for scenarios of dense population of MNs. BCMP setup is applicable to any network size. 5.4 Current BCMP work As mentioned BCMP's details are currently being refined in the MIND project. The particular features of BCMP provide a good level of freedom for routing configuration of the AN, which can be required for some scenarios of multi-homing support and particular ingress and egress filtering requirements for AN connection with Internet Service Providers. It is considered that the performance of the proposed mobility platform is not particularly dependent on the topological layout of the network. Testing of BCMP reveals that there is no negative relation of the protocol's performance with the network topology (eg. tree vs. mesh) [4]. Two independent implementations of BCMP are currently being developed and will be demonstrated soon. 6. Conclusions This document presents the research steps behind the development of mobility management for BRAIN/MIND ANs. The foremost intention was to present the stages of the design and some of the consequent decisions in order to assist the further efforts in development of micro-mobility solutions. The proposed template platform for development of mobility protocols Mihailovic, et al. Expires December 24, 2002 [Page 12] Internet-Draft Experience of BRAIN and MIND June 2002 is believed to be a beneficial concept which can be endorsed either as a development skeleton (which we used) or as an evaluation metric for other design strategies. Also the mentioned design processes and devised requirements can be further extended and enhanced. 7. Project Details The candidate solution protocol BCMP has been briefly presented and discussed. The BRAIN (Broadband Radio Access for IP Networks) [1] project ran for 18 months to March 2001. MIND (Mobile IP-based Network Development) [2] is in progress and it is a follow-up of BRAIN continuing some of the work initiated in BRAIN and further studying MANET/MONET scenarios in IP Access Networks. Most of the work in mobility management was initiated in Work Package 2 of the BRAIN project and can be found in Deliverable 2.2 in the referenced public web site. Both projects have been conducted as collaborative projects within the EU 5th RTD Framework Programme. 8. Security Considerations Any protocol arising from discussions such as those detailed in this document will be subject to a number of security issues. However, this draft primarily describes the process of protocol evaluation and selection that was performed within the BRAIN and MIND projects. Some thought was given to the security issues within these projects. However, this draft does not address specific security considerations in and of itself. 9. Acknowledgements This work has been (partially) performed in the framework of the IST project IST-2000-28584 MIND, which is partly funded by the European Union. The authors would like to acknowledge the help of their colleagues in preparing this document, in particular Markku Kojo and Dave Wisely. References [1] "Project BRAIN (Broadband Radio Access for IP Networks)- Deliverable 2.2", IST 1999-10054, March 2001, . [2] "Project MIND (Mobile IP-based Network Developments)", IST 2000- 28584, May 2002, . Mihailovic, et al. Expires December 24, 2002 [Page 13] Internet-Draft Experience of BRAIN and MIND June 2002 [3] Eardley, P., Mihailovic, A. and T. Suihko, "A Framework for Evaluation of IP Mobility Protocols", The eleventh IEEE Internation Symposium on Personal Indoor and Mobile Radio Communications (PIMRC 2000) London, UK, September 2000. [4] Keszei, C., Georganopoulos, N., Turanyi, Z. and A. Valko, "Evaluation of the BRAIN Candidate Mobility Management Protocol", IST Summit Barcelona, September 2001. [5] Dommety, G., Yegin, A., Perkins, C., Tsirtsis, G., El-Malki, K. and M. Khalil, "Fast Handover for Mobile IPv6", draft-ietf- mobileip-fast-mipv6-04.txt (work in progress), March 2002. [6] O'Neill, A., Tsirtsis, G. and S. Corson, "Edge Mobility Architecture", draft-oneill-ema-02.txt (work in progress), July 2000. [7] Kempf, J., Chitrapu, P., Pagtzis, T., Sreemanthula, S. and H. Wei, "Dormant Mobile Host Alerting (DMHA) Protocol Assessment", draft-ietf-seamoby-paging-protocol-assessment-01.txt (work in progress), February 2002. [8] Malinen, J. and C. Williams, "Micromobility Taxonomy", draft- irtf-mm-taxonomy-01.txt (work in progress), November 2001. Authors' Addresses Andrej Mihailovic Kings College London Centre for Telecommuncations Research Kings College London Strand London WC2R 2LS UK Phone: +44 (0)20 7848 2889 EMail: andrej.mihailovic@kcl.ac.uk URI: http://www.ctr.kcl.ac.uk Mark A. West Siemens/Roke Manor Roke Manor Research Ltd. Romsey, Hants SO51 0ZN UK Phone: +44 (0)1794 833311 EMail: mark.a.west@roke.co.uk URI: http://www.roke.co.uk Mihailovic, et al. Expires December 24, 2002 [Page 14] Internet-Draft Experience of BRAIN and MIND June 2002 Robert Hancock Siemens/Roke Manor Roke Manor Research Ltd. Romsey, Hants SO51 0ZN UK Phone: +44 (0)1794 833601 EMail: robert.hancock@roke.co.uk URI: http://www.roke.co.uk Philip Eardley BTexact Technologies pp B28/2B, Adastral Park, Martlesham Ipswich IP5 3RE UK Phone: +44 (0)1473 645938 EMail: philip.eardley@bt.com URI: http://www.bt.com Tapio Suihko VTT Information Technology P.O. Box 1203 FIN-02044 VTT Finland Phone: +358 9 456 6078 Fax: +358 9 456 7028 EMail: tapio.suihko@vtt.fi Full Copyright Statement Copyright (C) The Internet Society (2002). 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 Mihailovic, et al. Expires December 24, 2002 [Page 15] Internet-Draft Experience of BRAIN and MIND June 2002 "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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Mihailovic, et al. Expires December 24, 2002 [Page 16]