MIPSHOP E. Hepworth Internet-Draft Siemens Roke Manor Research Intended status: Informational T. Melia Expires: March 15, 2007 NEC S. Sreemanthula Nokia Research Center Y. Ohba Toshiba G. Vivek Intel J. Korhonen TeliaSonera R. Aguiar IT Sam(Zhongqi). Xia HUAWEI September 11, 2006 Mobility Services: Problem Statement draft-melia-mipshop-mobility-services-ps-00 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 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 March 15, 2007. Copyright Notice Hepworth, et al. Expires March 15, 2007 [Page 1] Internet-Draft Mobility Services September 2006 Copyright (C) The Internet Society (2006). Abstract There are on-going activities in the networking community to develop solutions that aid in IP handover mechanisms between heterogeneous wired and wireless access systems including, but not limited to, IEEE 802.21. Intelligent access selection, taking into account link layer attributes, requires the delivery of a variety of different information types to the terminal from different sources within the network and vice-versa. The protocol requirements for this signalling have both transport and security issues that must be considered. The signalling must not be constrained to specific link types, so there is at least a common component to the signalling problem which is within the scope of the IETF. This draft presents a problem statement for this core problem. Hepworth, et al. Expires March 15, 2007 [Page 2] Internet-Draft Mobility Services September 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Definition of Mobility Services . . . . . . . . . . . . . . . 4 3. Protocol Entities . . . . . . . . . . . . . . . . . . . . . . 5 4. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 5 4.1. End-to-End Signalling and Transport over IP . . . . . . . 6 4.2. End-to-End Signalling and Partial Transport over IP . . . 6 4.3. End-to-End Signalling with a Proxy . . . . . . . . . . . . 7 4.4. End-to-End Network-to-Network Signalling . . . . . . . . . 8 5. Solution Components . . . . . . . . . . . . . . . . . . . . . 8 5.1. Payload Formats and Extensibility Considerations . . . . . 9 5.2. Requirements on the Mobility Service Transport Layer . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. Conclusions and Open Issues . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Appendix A. Introduction to IEEE 802.21 . . . . . . . . . . . . . 16 A.1. Information Services . . . . . . . . . . . . . . . . . . . 16 A.2. Event Services . . . . . . . . . . . . . . . . . . . . . . 16 A.3. Command Services . . . . . . . . . . . . . . . . . . . . . 17 Appendix B. Official IEEE 802.21 Requirements for IP-based transport . . . . . . . . . . . . . . . . . . . . . . 17 Appendix C. Enabling Event and Command Services . . . . . . . . . 18 C.1. Explicit Signaling for Remote Event/Command Services . . . 19 C.2. Mitigation of Security Issues and Validation of Transported Indications . . . . . . . . . . . . . . . . . 19 C.3. Mapping of Identifiers . . . . . . . . . . . . . . . . . . 21 Appendix D. Introduction to Network Initiated Handovers (NIHO) . 22 D.1. Definition of Network Initiated Handover . . . . . . . . . 23 D.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 24 D.3. NIHO Application Areas . . . . . . . . . . . . . . . . . . 26 Appendix E. NIHO with IEEE 802.21 . . . . . . . . . . . . . . . . 27 E.1. Network Selection . . . . . . . . . . . . . . . . . . . . 28 E.2. Handover Control . . . . . . . . . . . . . . . . . . . . . 29 Appendix F. MIH services and (AP-ID, AR-Info) tuples . . . . . . 31 F.1. Construction Scenarios of (AP-ID, AR-Info) tuples . . . . 32 F.1.1. Distributed application scenario for construction . . 32 F.1.2. Centralized application scenario for construction . . 35 F.1.3. Mixed application scenario for construction . . . . . 36 F.2. Interactions between MIH services and (AP-ID, AR-Info) tuples . . . . . . . . . . . . . . . . . . . . . . . . . . 36 F.2.1. Using MIH IS in distributed construction scenario . . 37 F.2.2. Using MIH IS in centralized scenario . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 Intellectual Property and Copyright Statements . . . . . . . . . . 40 Hepworth, et al. Expires March 15, 2007 [Page 3] Internet-Draft Mobility Services September 2006 1. Introduction This Internet Draft provides a problem statement for the exchange of information to support handover in heterogeneous link environments. This mobility support service allows more sophisticated handover operations by making available information about network characteristics, neighboring networks and associated characteristics, indications that a handover should take place, and suggestions for suitable target networks to which to handover. The mobility support services work complementarily with IP mobility mechanisms to enhance the overall performance and usability perception. There are two key attributes to the handover support service problem for inter-technology handovers: 1. The Information and Information Exchange mechanism: this includes the information elements that describe the information, and any signalling exchanges that are required to support the transfer of these Information Elements. 2. The Underlying Transport: this supports the above Information Exchange between devices in the network. The requirements on this transfer mechanism include transport issues, because of the volume of data to be sent, as well as discovery and security issues for this transport, as the signalling may cross administrative boundaries and is interdependent with AAA aspects. This draft has been motivated by on-going work within IEEE 802.21, but the following description intentionally describes the problem from a more general perspective. This document represents the views of the authors, and does not represent the official view of IEEE 802.21. The structure of this document is as follows. Section 2 defines mobility services. Section 3 introduces the protocol entities. Section 4 provides a simple model for the protocol entities involved in the signalling and their possible relationships. Section 5 describes a decomposition of the signalling problem into service specific parts and a generic transport part. Section 5.2 describes more detailed requirements for the transport component. Section 6 provides security considerations, and Section 7 summarizes the conclusions and open issues. The appendixes describe some applications of the mobility services. 2. Definition of Mobility Services As mentioned in the introduction mobility (handover) support in Hepworth, et al. Expires March 15, 2007 [Page 4] Internet-Draft Mobility Services September 2006 heterogeneous wireless environments requires functional components located either in the mobile terminal or in the (access) network to exchange information and eventually to take decisions upon this information exchange. For instance traditional host-based handover solutions could be complemented with more sophisticated network- centric solutions reducing terminal complexity. Also, neighborhood discovery, potentially a complex operation in heterogeneous wireless scenarios, can result in a more simple step if implemented with an unified interface towards the access network. In this document the different supporting functions for handover management are generally referred as Mobility Services (MoS) having in common different requirements for the transport protocol. These requirements and associated functionalities are the focus of this document 3. Protocol Entities The following section provides an overview of the network entities that is expected to be involved in the signalling exchanges to support the handover operation. The following abbreviations are used in this section: o MN: mobile node o NN: network node, intended to represent some device in the network (the location of the node e.g. in the access network, home network is not specified, and for the moment it is assumed that they can reside anywhere). o EP: endpoint, intended to represent the terminating endpoints of the transport protocol used to support the signalling exchanges between nodes. o MME: A Mobility Management Entity implements network selection and handover decision algorithms and utilizes mobility signaling protocols and other protocols that aid in mobility functions. Generalizing, we call this functional entity Policy Decision Point which acts upon events and combines required actions with user profiles. The MME is able to collect information either from other network nodes or from the MN. 4. Deployment Scenarios The deployment scenarios are outlined in the following sections. Note: while MN-to-MN signalling exchanges are theoretically possible, Hepworth, et al. Expires March 15, 2007 [Page 5] Internet-Draft Mobility Services September 2006 these are not currently being considered, and are out-of-scope. The following scenarios are discussed for understanding the overall problem of transporting MIH protocol and is not intended to show the scenarios are part of the requirements in the transport design. 4.1. End-to-End Signalling and Transport over IP In this case, the end-to-end signalling used to exchange the handover information elements (the Information Exchange) runs end-to-end between MN and NN. The underlying transport is also end-to-end +------+ +------+ | MN | | NN | | (EP) | | (EP) | +------+ +------+ Information Exchange <------------------------------------> /------------------------------------\ < Transport over IP > \------------------------------------/ Figure 1: End-to-end Signalling and Transport 4.2. End-to-End Signalling and Partial Transport over IP As before, the Information Exchange runs end-to-end between the MN and the second NN. However, in this scenario, some other transport means is used from the MN to the first NN, and the transport over IP is used only between NNs. This is analogous to the use of EAP end- to-end between Supplicant and Authentication Server, with an upper- layer multihop protocol such as RADIUS used as a backhaul transport protocol between an Access Point and the Authentication Server. Hepworth, et al. Expires March 15, 2007 [Page 6] Internet-Draft Mobility Services September 2006 +------+ +------+ +------+ | MN | | NN | | NN | | | | (EP) | | (EP) | +------+ +------+ +------+ Information Exchange <------------------------------------> (Transport over /------------------\ <--------------->< Transport over IP > e.g. L2) \------------------/ Figure 2: Partial Transport 4.3. End-to-End Signalling with a Proxy In the final case, a number of proxies are inserted along the path between the two transport endpoints. The use of proxies is possible in both cases 1 and 2 above, but distinguished here as there are a number of options as to how the proxy may behave with regard to the transport and end-to-end signalling exchange. In this case, the proxy performs some processing on the Information Exchange before forwarding the information on. This can be viewed as concatenating signalling exchanges between a number of EPs. +------+ +---------+ +------+ | MN | | ProxyNN | | NN | | (EP) | | (EP) | | (EP) | +------+ +---------+ +------+ Information Exchange ------------------> -------------------> <------------------- <------------------ /---------------\ /----------------\ < Transport > < Transport > \---------------/ \----------------/ Figure 3: Information Exchange Approach The Proxy NN processes all layers of the protocol suite in the same way as an ordinary EP. There is a possibility for realizing other proxy scenarios. Hepworth, et al. Expires March 15, 2007 [Page 7] Internet-Draft Mobility Services September 2006 4.4. End-to-End Network-to-Network Signalling In this case NN to NN signalling is envisioned. Such model should allow different network components to gather information from each other. This is useful for instance in conditions where network components need to take decisions and instruct mobile terminals of operation to be executed. +------+ +------+ | NN | | NN | | (EP) | | (EP) | +------+ +------+ Information Exchange -------------------> <------------------- /----------------\ < Transport > \----------------/ Figure 4: Information Exchange between different NN Network nodes exchange information about connected terminals status. 5. Solution Components Figure 5 shows a model where the Information Exchanges are implemented by a signalling protocol specific to a particular mobility service, and these are relayed over a generic transport layer (the Mobility Service Transport Layer). Hepworth, et al. Expires March 15, 2007 [Page 8] Internet-Draft Mobility Services September 2006 +----------------+ ^ |Mobility Support| | | Service 2 | | +----------------+ | (e.g. ES) | | Mobility Service |Mobility Support| +----------------+ | Signaling | Service 1 | +----------------+ | Layer | (e.g. IS) | |Mobility Support| | +----------------+ | Service 3 | | | (other) | | +----------------+ V ================================================ +---------------------------------------+ ^ Mobility Service | Mobility Service Transport Protocol | | Transport +---------------------------------------+ V Layer ================================================ +---------------------------------------+ | IP | +---------------------------------------+ Figure 5: Handover Services over IP The Mobility Service Transport Layer provides certain functionality (outlined in Section 5.2) to the higher layer mobility support services in order to support the exchange of information between communicating mobility service functions. The transport layer effectively provides a container capability to mobility support services, as well as any required transport and security operations required to provide communication without regard to the protocol semantics and data carried in the specific mobility services. The Mobility Support Services themselves may also define certain protocol exchanges to support the exchange of service specific Information Elements. It is likely that the responsibility for defining the contents and significance of the Information Elements is the responsibility of other standards bodies other than the IETF. Example mobility services include the Information Services, Event and Command services. 5.1. Payload Formats and Extensibility Considerations Hepworth, et al. Expires March 15, 2007 [Page 9] Internet-Draft Mobility Services September 2006 The format of the Mobility Service Transport Protocol is as follows: +----------------+----------------------------------------+ |Mobility Service| Opaque Payload | |Transport Header| (Mobility Support Service) | +----------------+----------------------------------------+ Figure 6: Protocol Structure The opaque payload encompasses the Mobility Support Service information that is to be transported. The definition of the Mobility Service Transport Header is something that is best addressed within the IETF. There are a number of issues with regard to the Mobility Support Service header and payload definition. These include: 1. Responsibility for defining the header: where should the contents of the Mobility Support Service header be defined, and should there be one or multiple header definitions (i.e. will a common header definition for all mobility support services be adequate?). Where there are commonalities, it may indicate that these aspects should actually be included in the Mobility Service Transport Header. 2. Payload Format: the format or the Mobility Support Service Data payload could be represented in a number of formats, e.g. TLV, ASN/1, XML or text. Ideally, a single payload representation should be defined, as support for multiple formats leads to unnecessary complexity. It is expected that a set of Data Objects will be defined for the Mobility Support Services to exchange. 3. Sharing of Data Objects: which refers to sharing the definitions of Data Objects between Mobility Support Services, e.g. if a Capabilities object is defined that is used by multiple Mobility Support Services, should the same definition be used by all of them. If this is the case, then a common identifier space is needed to identify the different Data Objects. There is a question about where the definition of Data Objects and the management of the identifier space should take place. The answers to some of the above issues may in part depend on how many standards groups are interested in defining their own Mobility Support Services. Hepworth, et al. Expires March 15, 2007 [Page 10] Internet-Draft Mobility Services September 2006 5.2. Requirements on the Mobility Service Transport Layer The following section outlines some of the general transport requirements that should be supported by the Mobility Service Transport Protocol. Analysis has suggested that at least the following need to be taken into account: Discovery MNs need the ability to locate nodes that support particular mobility services in the network. There are no assumptions about the location of these mobility services within the network, therefore the discovery mechanism needs to operate across administrative boundaries. Issues such as speed of discovery, protection against spoofing, when discovery needs to take place, and the length of time over which the discovery information may remain valid all need to be considered. Approaches include: * Hard coding information into the MN, indicating either the IP address of the NN, or information about the NN that can be resolved onto an IP address. The configuration information could be managed dynamically, but assumes that the NN is independent of the access network to which the MN is currently attached. * Pushing information to the MN, where the information is delivered to the MN as part of other configuration operations, for example, in a Router Discovery exchange. The benefit of this approach is that no additional exchanges with the network would be required, but the limitations associated with modifying these protocols may limit applicability of the solution. * MN dynamically requesting information about a service, which may require both MN and NN support for a particular service discovery mechanism. This may require additional support by the access network (e.g. multicast or anycast) even when it may not be supporting the service directly itself. Numerous directory and configuration services already exist, and reuse of these mechanisms may be appropriate. There is an open question about whether multiple methods of discovery would be needed, and whether NNs would also need to discover other NNs. The definition of a service also needs to be determined, including the granularity of the description (for example, should the MN look for an "IS" service, or "IS-local information", and "IS-home network information" services. Hepworth, et al. Expires March 15, 2007 [Page 11] Internet-Draft Mobility Services September 2006 Information from a trusted source: The MN uses the Mobility Service information to make decisions about what steps to take next. It is essential that there is some way to ensure that the information received is from a trustworthy source. This includes cases where trusted proxies along the path have access to, and may modify, parts of the Mobility Service information. This requirement should reuse trust relationships that have already been established in the network, for example, on the relationships established by the AAA infrastructure after a mutual authentication, or on the certificate infrastructure required to support SEND. Low latency: Some of the Mobility Services generate time sensitive information. Therefore, there is a need to deliver the information over quite short timescales, and the required lifetime of a connection might be quite short lived. For reliable delivery, short-lived connections could be set up as and when needed, although there is a connection setup latency associated with this approach. Alternatively, a long-lived connection could be used, but this requires advanced warning of being needed and some way to maintain the state associated with the connection. It also assumes that the relationships between devices supporting the mobility service are fairly stable. Another alternative is connectionless operation, but this has interactions with other requirements such as reliable delivery. Reliability: Reliable delivery for some of the mobility services may be essential, but it is difficult to trade this off against the low latency requirement. It is also quite difficult to design a robust, high performance mechanism that can operate in heterogeneous environments, especially one where the link characteristics can vary quite dramatically. There are two main approaches that could be adopted: 1. Assume the transport cannot be guaranteed to support reliable delivery. In this case, the Mobility Support Service itself will have to provide some sort of reliability mechanism to allow communicating endpoints to acknowledge receipt of information. 2. Assume the underlying transport will deal with most error situations, and provide a very basic acknowledgement mechanism that (if no acknowledgement is received) will indicate that something more serious has occurred than a packet drop (since these other types of error conditions are dealt with at the transport layer). Option 1 has a number of disadvantages associated with it, namely Hepworth, et al. Expires March 15, 2007 [Page 12] Internet-Draft Mobility Services September 2006 that ultimately the protocol design ends up re-inventing a lot of the functionality already available in lower layers at a higher layer where access to information about what is going on in the network is restricted. For example, how will the higher layer determine the cause of the error, if a message is lost due to network congestion, it is pointless sending the message again. It also adds to the complexity of the higher layer protocol, and makes successful deployment less certain (the protocol will have to be trialed in a number of network situations instead of re- using a protocol that has already been tested). Congestion Control: A Mobility Service may wish to transfer large amounts of data, placing a requirement for congestion control in the transport. There is an interaction between this requirement and that of the requirement for low latency since ways to deal with timely delivery of smaller asynchronous messages around the larger datagrams is required (mitigation of head of line blocking etc.). Secure delivery: The Mobility Service information must be delivered securely between trusted peers, where the transport may pass though untrusted intermediate nodes and networks. Design considerations include whether session based or host based security associations are required along the chain of NNs, and what the rate limitation requirements of requests/responses might be. Multiplexing: The transport service needs to be able to support different mobility services. This may require multiplexing and the ability to manage multiple discovery operations and peering relationships in parallel. Multihoming: For some information services exchanged with the MN, there is a possibility that the request and response messages can be carried over two different links e.g. a handover command request is on the current link while the response could be delivered on the new link. Depending on the IP mobility mechanism, there is some impact on the transport option for the mobility information services. This may potentially have some associated latency and security issues, for example, if the transport is over IP there is some transparency but Mobile IP may introduce additional delay and both TCP and UDP must use the permanent address of the MN. In addition to the above, it may be necessary for the transport to support multiple applications (or modes of operation) to support the particular requirements of the Information Exchange being carried out between nodes. This may require the ability to multiplex multiple Hepworth, et al. Expires March 15, 2007 [Page 13] Internet-Draft Mobility Services September 2006 information exchanges into a single transport exchange. Further information about transport requirements related to specific Mobility Services can be found in the different appendixes. 6. Security Considerations Network supported mobility services aim at improving decision making and management of dynamically connected hosts. The control and maintenance of mobile nodes becomes challenging where authentication and authorization credentials used to access a network are unavailable for the purpose of bootstrapping a security association for handover services. Information Services may not require authorization of the client, but both event and command services must authenticate message sources, particularly if they are mobile. Network side service entities will typically need to provide proof of authority to serve visiting devices. Where signalling or radio operations can result from received messages, significant disruption may result from processing bogus or modified messages. The effect of processing bogus messages depends largely upon the content of the message payload, which is handled by the handover services application. Regardless of the variation in effect, message delivery mechanisms need to provide protection against tampering, and spoofing. Sensitive and identifying information about a mobile device may be exchanged during handover service message exchange. Since handover decisions are to be made based upon message exchanges, it may be possible to trace an user's movement between cells, or predict future movements, by inspecting handover service messages. In order to prevent such tracking, message confidentiality should be available. This is particularly important since many mobile devices are associated with only one user, as divulgence of such information may violate the user's privacy. Additionally, identifying information may be exchanged during security association construction. As this information may be used to trace users across cell boundaries, identity protection should be available if possible, when establishing SAs. In addition, the user should not have to disclose its identity to the network (any more than it needed to during authentication) in order to access the Mobility Support Services. For example, if the local network is just aware that an anonymous user with a subscription to operatorXYX.com is accessing the network, the user should not have to divulge their true identity in order to access the Mobility Support Services available locally. Hepworth, et al. Expires March 15, 2007 [Page 14] Internet-Draft Mobility Services September 2006 Finally, the network nodes themselves will potentially be subject to denial of service attacks from MNs and these problems will be exacerbated if operation of the mobility service protocols imposes a heavy computational load on the NNs. The overall design has to consider at what stage (e.g. discovery, transport layer establishment, service specific protocol exchange) denial of service prevention or mitigation should be built in. 7. Conclusions and Open Issues This Internet draft outlined a broad problem statement for the signalling of information elements across a network to support media independent handover services. In order to enable this type of signalling service, a need for a generic transport solution with certain transport and security properties were outlined. Whilst the motivation for considering this problem has come from work within IEEE 802.21, a desirable goal is to ensure that solutions to this problem are applicable to a wider range of mobility services. It would be valuable to establish realistic performance goals for the solution to this common problem (i.e. transport and security aspects) using experience from previous IETF work in this area and knowledge about feasible deployment scenarios. This information could then be used as an input to other standards bodies in assisting them to design mobility services with feasible performance requirements. Much of the functionality required for this problem is available from existing IETF protocols or combination thereof. This document takes no position on whether an existing protocol can be adapted for the solution or whether new protocol development is required. In either case, we believe that the appropriate skills for development of protocols in this area lie in the IETF. 8. References [1] "Draft IEEE Standard for Local and Metropolitan Area Networks: Media Independent Handover Services", IEEE LAN/MAN Draft IEEE P802.21/D01.00, March 2006. [2] Adoba, B., "Architectural Implications of Link Indications draft-iab-link-indications-03.txt", June 2005. [3] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. [4] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in Hepworth, et al. Expires March 15, 2007 [Page 15] Internet-Draft Mobility Services September 2006 IPv6", RFC 3775, June 2004. [5] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006. [6] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, June 2006. [7] 3GPP, "3GPP system architecture evolution (SAE): Report on technical options and conclusions", 3GPP TR 23.882 0.10.1, February 2006. [8] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, July 2005. Appendix A. Introduction to IEEE 802.21 At this time, three broad classes of services for handover assistance, particularly aiming at improving the inter-technology, are under consideration within the IEEE 802.21 Working Group [1]. They require passing of information within hosts, locally and between different hosts, remotely. The services are Information Services (IS), Event Services (ES) and Command Services (CS). A.1. Information Services Information Services (IS) are one part of handover services used to provide network related information about the current or neighboring networks with same or different access link technology. This allows the network or host to make informed decisions of which network to handover to or handover operations to undertake either in response to certain events, or when planning controlled or commanded handovers. The IS work complementary to the mobility management protocols in the capacity that they are utilized before making decisions for handovers in the aspect of network selection. A.2. Event Services Event Services (ES) provide indications from one layer or one functionality to another about status changes in the connectivity state. This is particularly relevant to wireless interfaces. It should be noted that the events of one link technology can be carried over current or another link technology. Remote event service is a protocol exchange mechanism between two different network nodes to inform of ES. The event notification can originate either from a mobile node or a node in the network. Receipt and processing of an event belonging to the ES may generate a reaction in the receiving Hepworth, et al. Expires March 15, 2007 [Page 16] Internet-Draft Mobility Services September 2006 node (e.g. trigger IP layer mobility). A.3. Command Services Command Services (CS) provide mechanisms for controlling handovers or functions aiding handovers either locally or between two functions. They provide mechanisms to establish, redirect, or remove state in either the network or mobile node, so that handovers occur smoothly. Remote command service is a protocol exchange mechanism between network nodes to instruct the recipient network nodes to execute a specific function. Execution of a command service at the mobile node or a node in the network may result in loss of current link connectivity and/or change in the network point of attachment. Receipt and processing of a command belonging to the CS generates an expected response in the receiving node (e.g. create a new link layer connection, disconnect a link layer connection, etc). Appendix B. Official IEEE 802.21 Requirements for IP-based transport o The transport protocol must work regardless of the network location of the MIH Protocol Entity e.g. on the same subnet, or deep in the network belonging to same or different IP administrative domain. o The transport protocol must be capable to support both IPv4 and IPv6 versions. o The transport protocol must be capable of delivering time- sensitive MIH information. o The transport protocol must enable Network address Translation (NAT) traversal for IPv4 networks. o The transport protocol must enable Firewall pass-through for IPv4 and IPv6 networks. o The discovery protocol must work regardless of the network location of the MIH Protocol Entity e.g. on the same subnet, or deep in the network belonging to same or different IP administrative domain. o The discovery protocol must work for IPv4 and IPv6 hosts. o The discovery protocol must allow for more than one MIH Protocol Entity to be discovered at a time. Hepworth, et al. Expires March 15, 2007 [Page 17] Internet-Draft Mobility Services September 2006 o The discovery protocol must enable Network Address Translator (NAT) traversal for IPv4 networks. o The discovery protocol must enable Firewall pass-through for IPv4 and IPv6 networks. o The security mechanism must provide a common security association (SA) negotiation method regardless of the network location of the MIH Protocol Entity e.g. on the same subnet, or deep within the network. o The security mechanism must provide mutual authentication of MIH end nodes. o The security mechanism may provide one way authentication of either of MIH end nodes. o The security mechanism must provide integrity protection for MIH Protocol exchanges. o The security mechanism may provide confidentiality for the MIH Protocol exchanges. o The security mechanism must protect against replay attacks. o The security mechanism may protect MIH service entities and discovery resources against denial of service attacks. o The security mechanism must not be dependent on the MIH protocol. o The security mechanism may provide means to reuse or fast reestablishment the SA due to host mobility. Appendix C. Enabling Event and Command Services This section analyzes the feasibility of remote events and commands, and describes a set of requirements to enable remote ES and CS. The section discusses some potential solutions to solve some issues typically associated with remote events and explicit signaling. However, such solutions are discussed just to provide example of how drawbacks and limitations identified e.g. in [2] can be overcome. This section does not propose any specific solutions. [2] contains a set of observations on requirements that solutions need to fulfill to justify and enable transport of events between peer entities over the media (e.g. wireless link). This section addresses these observations in order to assess the feasibility of Hepworth, et al. Expires March 15, 2007 [Page 18] Internet-Draft Mobility Services September 2006 remote ES and CS. C.1. Explicit Signaling for Remote Event/Command Services [2] indicates that alternatives not requiring explicit signaling are preferred, and that explicit signaling proposals must prove that existing implicit signaling mechanisms are inadequate. Implicit signaling (e.g. path change processing and link-aware routing metrics) has been considered for the scenarios described in this draft. However, implicit signaling may not work in several cases of inter-technology handover. As an example, in certain scenarios the handover is executed but the mobile node does not move between subnets (e.g. in 3GPP networks where the GGSN and the Packet Data Gateway (for WLAN interworking) are located in the same subnet). In other scenarios, explicit signaling is required between the mobile node and a network node to report events related to an access link different from the one currently being used by the mobile node (e.g. a mobile node using a 3GPP link detects the availability of a WLAN link). Such events would not be visible to the network node without explicit signaling. Various wireless technologies already have defined mobility management solutions that deploy explicit signaling to support handover (e.g. 3GPP, 3GPP2, IEEE 802.16, etc.), or are at present developing new solutions (e.g. IEEE 802.11 Fast BSS Transition). However, such solutions are clearly defined for intra-technology handover (e.g. 3GPP solutions apply to handover between 3GPP technologies). However, none of these wireless technologies has defined a solution that is applicable to inter-technology handover (e.g. between different IEEE 802 access links, or between a 3GPP access link and an IEEE 802 access link). C.2. Mitigation of Security Issues and Validation of Transported Indications The validity of the information delivered through explicit signaling in the Remote Event Service and the Remote Command Service is essential to guarantee that the mobile node or the network node make handover decision and perform handover based on valid conditions. In [2] the issue of validity of the indications is correctly raised, since in a generic model the receiver of the indication (e.g. the mobile node) may not have the ability to verify if the indication has e.g. been sent by a host off the actual path in use, and therefore possibly not capable of providing accurate indications. With the specific model for Remote Event Services and Remote Command Services briefly described in this document and IEEE 802.21 [1], a Hepworth, et al. Expires March 15, 2007 [Page 19] Internet-Draft Mobility Services September 2006 "relationship" is generated between the mobile node and an MME through a process of discovery and registration. Authentication can be part of such process (possibly mutual authentication), as described in the security considerations. Considering this specific model, information in Remote Event Service and Remote Command Service are generated by a node with which the recipient of the Remote Event Service and Remote Command Service has setup a relationship before hand. It is up to the recipient to ensure during the discovery and registration process that the source of Remote Event Service and Remote Command Service is reputable and can provide accurate information. An example of how this can be achieved is based on authentication mechanisms and the adoption of a trust model similar to those adopted in current networks for authentication of roaming users. The mobile node can authenticate with a home domain/network based on a subscription with such domain/network. If the MME is located e.g. in the home realm, the MME can authenticate with the MME based on credentials the mobile node possesses as a result of the subscription. If the MME is e.g. in the visited domain, a transitive trust model can be adopted, where the mobile node authenticates with the home domain/network based on a subscription and through the visited domain. As a result, a security association is established between the mobile node and the MME. A model similar to the one adopted in AAA can be adopted. Hepworth, et al. Expires March 15, 2007 [Page 20] Internet-Draft Mobility Services September 2006 Mobile Node Network |-------------------------------------| |---------| +----------+ +--------+ +--------+ +-------+ | Appl./ | | | | | | | | Transp./ | |MIHF(ES/| | Link | | MME | | Network | | CS) | | Layers | | | | Layers | | | | | | | +----------+ +--------+ +--------+ +-------+ | | | | +---------------------------------+ | | +-----------------+ | | | | Mapping of | | | | |Local Identifiers| | | | +-----------------+ | | +---------------------------------+ | | | | | +--------------------------------------------------------+ | Discovery | +--------------------------------------------------------+ | | | | +--------------------------------------------------------+ | Registration | | +----------------------------------------------------+ | | | Authentication | | | +----------------------------------------------------+ | | | +--------------------------------------------------------+ | | | | | Security Association | |<==============================================>| | | | | | Media Independent Host ID | |<==============================================>| | | | | +----------+ +--------+ +--------+ +-------+ |-------------------------------------| |---------| Legend: ===== shared between Figure 7: MN-MME relationship and Mapping of Identifiers C.3. Mapping of Identifiers [2] raises a legitimate issue regarding the fact that typically the IP layer, the link layer, the transport layer and the application layer use different identifiers, and therefore reporting of information regarding these layers to a remote node may require matching the various identifiers. Hepworth, et al. Expires March 15, 2007 [Page 21] Internet-Draft Mobility Services September 2006 When local event services generate indications within a host (e.g. the mobile node), the host has detailed knowledge of the various identifiers used at the different layers (e.g. the IP address, the MAC addresses for the various IEEE 802 accesses, etc.). As depicted in Figure 7, an MIHF located in the mobile node can maintain a local mapping of the various identifiers. When the mobile node discovers and registers with another network node (e.g. an MME), an identifier specific to Remote Event Services and Remote Command Services can be adopted to uniquely identify the mobile node , e.g. a Media Independent Host Identifier. The Media Independent Host Identifier can be e.g. assigned to the mobile node by the home network as part of a set of subscription credentials. The Media Independent Host Identifier could be a new identifier, or an existing identifier could be reused (e.g. NAI). Subsequently, all the remote even notifications and remote command exchanges can be based on the Media Independent Host Identifier, therefore limiting the need to maintain the mapping between different identifiers at different layers local to the host. Appendix D. Introduction to Network Initiated Handovers (NIHO) This section presents scenarios, functionalities and requirements for helping the handover procedure in heterogeneous environments. The mobility services enable mobile terminals to collect a large variety of information as well as the network to instruct mobile devices to perform specific actions, such as handover. Standards based IP mobility enabling protocols such as Mobile IP [3] [4], HIP [5], MOBIKE [6] are however all mobile node centric: the handover related decision making is mostly done in the mobile node only. The goal of this section is to motivate the development of advanced procedures for network initiated handovers being part of the defined MoS. Public mobile network access is gaining increased diversity, both in terms of the types of access technologies, in terms of the diversity of the offer (with clear separation of roles between access and service providers), and in terms of the size of that offer. This diversity has been compounded by increasing number of multi-access capable terminals equipped with IP technologies, and of operator- provided multi-technology mobile connection software. Overall, this creates a complex environment, where the mobile terminal might not have enough information or even the possibility to make an intelligent handover decision (as is often the case of operator- provided software). In fact, handover decisions and inherent target network selection is not necessarily anymore based on access availability but further depends on policies and commercial roaming arrangements on access network level, access provider level and service provider level. Furthermore, the information required for an Hepworth, et al. Expires March 15, 2007 [Page 22] Internet-Draft Mobility Services September 2006 intelligent target network selection might change periodically with such a frequency that maintaining all knowledge (and intelligence) in the mobile node might not be viable anymore. Some of this information is only available for network elements. However, none of the mobility protocols above referred have capabilities or procedures to significantly involve network side entities in intelligent handover decision making. A good example of the type of information only available at network entities is radio resource usage. It is expected that radio resource usage optimization will be a task of major relevance in future wireless network environments, with millions of users roaming between access routers across multiple technologies (i.e. 802.11, 802.16). This task can resort to mechanisms and algorithms able to gather measurements and force terminal handovers between cells. The handover can be issued according to predefined mobility patterns, mechanisms for intelligent flow balancing, mechanisms for optimized resource re-allocation, mechanisms for user-traffic performance optimization, or mechanisms for user profiling (e.g. access rights) - all of them ultimately leading to better service to be provided to the users, with additional increased resource usage for the network operator. For these expectations to be realized, network control capabilities are required to instruct specific terminals to perform handovers, either between access points or between different technologies. Going even further, handovers over administrative domains i.e. inter- domain handovers are not explicitly prohibited with the existing IP mobility enabling protocols, but at the same time these protocols are not designed or optimized for such cases in any way. Also a general network controlled triggering mechanism for a handover from an administrative domain to another does not currently exists. This document describes various scenarios where handovers could be network initiated, even over administrative domains, presenting some ideas on functional components and protocol operations required to fulfill the above requirements. This, however, will further require a new handover triggering mechanism that originates from entities located in the network side, and is acted upon by entities on the mobile node. These network side entities may also be located in other administrative domains than the one the mobile node is currently visiting. In Appendix E an example is provided on how IEEE 802.21 can implement the required signalling. D.1. Definition of Network Initiated Handover As mentioned above, available solutions rely on the existence of triggers generated in the mobile terminal and conveyed to respective Hepworth, et al. Expires March 15, 2007 [Page 23] Internet-Draft Mobility Services September 2006 network components which then will take adequate actions. However, recently we have been assisting to new different trends [7] where the serving radio access network issue handover preparation/execution by means of different events gathered at different levels (e.g. radio conditions, QoS requirements). We therefore are required to define use cases in which the network takes active decisions without requiring the terminal to perform expensive operations. In this section by network initiated handover we identify the action taken in the network to initiate the handover based on: o Link events originated in the mobile node. In this case the terminal sends link events to the network. The event might be generated because of radio variations, powering on of new network devices or new service requirements. In all cases the measurement action is required to be performed also in critical conditions. For instance speed dynamic effects on terminal mobility have to be taken into account as well as variable round trip time. Positioning of the decision function is a critical issue. o Events generated in the network for e.g. resource management reasons. It should be noted that the Mobile Operator can initiate an handover procedure also based on location and current services. Multihoming scenarios can also be considered as part of the overall optimization problem. The action described is similar to exiting behavior of current GSM/3G systems. Measurements are requested by the network and performed by the mobile terminal. The results of these measurements, combined with current QoS conditions and other user profile requirements, could result in the execution of an handover. Measurements are a key issue, for instance, in indoor wireless LANs environments, affected also by different user mobility patterns. D.2. Assumptions This document has some few fundamental assumptions concerning the general networking environment and network initiated handovers. The rest of the document makes use of the following assumptions: o Reusing existing security mechanisms -- The mobile node should reuse the existing security associations it created while establishing the initial access to the network and its mobility service provider (MSP). Hepworth, et al. Expires March 15, 2007 [Page 24] Internet-Draft Mobility Services September 2006 o All mobile nodes within the scope of this document are expected to support at least one (potentially modified) existing or future IP mobility enabling protocol. However, if a MN does not support network initiated handover functionality, the network might refuse to give service to that MN. o All mobile nodes, correspondent nodes and mobility management nodes are not expected to understand or support network initiated and assisted handovers. When either peer lacks support for network initiated and assisted handover triggering and signaling the peer supporting these features must fall back to the base IP mobility protocol mechanisms. o The network initiated handover concept relies on the presence of a centralized functional entity. This entity controls the network side and implement the intelligence to select nodes and targets access routers. It is not in the scope of this document to specify the policies that will be implemented. o To provide adequate scalable support, distributed functions are required to support the above functional entity. This gives more flexibility to the overall architecture and protocol operation. o It is envisioned the presence of multi wireless access, such as 802.11, 802.16, UMTS, forming an heterogeneous composition of macro and micro cells. The network support SHOULD leverage user mobility focusing on vertical handovers. Hence, the terminal does not need to apply filtering criteria to select a target network (which could be an expensive operation in heterogeneous environments). Solutions similar to the 3GPP interface between the Home Subscriber Server (HSS) and any application server, for downloading of filtering criteria at registration time, could be applied here - being the HSS a AAA backend, and the application server the MME. o Performing network initiated handover has the main implication that the network has first to assess the terminal view of the network. Signal level evaluation is a important matter when considering user mobility. This is typically very well handled with terminal initiated handovers and automatic evaluation of signal level. Different methods apply to different technologies. o Neighborhood discovery relates to the above assumption when neighborhood scanning is requested from the network. It is expected these functions to be available on the terminal side. Hepworth, et al. Expires March 15, 2007 [Page 25] Internet-Draft Mobility Services September 2006 D.3. NIHO Application Areas We foresee three possible application areas that are listed and briefly described in the following section. Each application area uses the NIHO triggering and signaling as part of their tasks. o Application for Mobility Reasons In this context user mobility is handled from the network side assisted by the mobile terminal. This particular application requires network capabilities to request measurements and evaluate technologies specific link conditions. The approach can be considered similar to what current mobile networks do. The most challenging aspect is the freshness of the reported information. Particular scenarios, such as WLAN, could impose stringent requirements. o Application for Resource Optimization Reasons As mentioned before, network optimization is a delicate issue when resources are scarce, especially in the wireless access network. Standards that able to support natively quality of services capabilities are becoming mature to be sold on the market (802.11e). A cross layer design is therefore required to convey link layer specific information to decision points located in the access network. These decision points can combine standard admission control mechanisms with advanced NIHO functionalities, resulting in a new dimension of mobility management (i.e. more terminals can be granted with network access). o Application for inter-domain handover Handovers that cause the mobile to cross administrative domain borders involve inter-domain signaling. One example of this kind of scenario is when the mobile node moves between different NAPs under the same ISP or when even the ISP changes as a result of the movement. In both of these scenarios the NIHO signaling could be used to prepare the new target domain (either ISP and/or NAP) for the arriving mobile node. Especially if the handover was initiated from the network side, the handover initiating network could help distributing all security, policies, billing and service related material cross administrative domains before the mobile node arrives. Hepworth, et al. Expires March 15, 2007 [Page 26] Internet-Draft Mobility Services September 2006 Appendix E. NIHO with IEEE 802.21 IS, ES and CS as defined in IEEE 802.21 WG can be used as enablers for network initiated and assisted handover scenarios between different access technologies. The discussion of such scenarios in IP networks can easily raise a long list of questions regarding the feasibility of e.g. sending information in real-time between the mobile node and the MME, and of sending commands between the MME and the mobile node. The issue considered in these cases is typically the delay that can be introduced by the transport and that may make the overall handover delay quite considerable. This document does not discuss these specific issues, and does not argue in favor or against such issues. However, in order to identify some of the scenarios of applicability for IS, ES and CS for network-controlled handover, we need to consider the following classification of handovers. There are two main reasons to perform a handover: 1. degradation of current link/connection quality: the quality of the link is degrading and it is necessary to perform a handover to avoid losing the current connection; 2. "opportunistic" handover: due to a set of events and based on specific policies, it is preferable to move the communication to another link. In order to support inter-technology network-controlled handovers the first case, the delay between the moment the handover decision is made and the moment the command to perform the handover is received by the mobile node needs to be considered carefully. However, for "opportunistic" handover the impact of such delay is less significant, since the mobile node is not having any degradation over the current link, and the handover will be performed because the network has policies indicating that it is preferable to move to the new link. One motivation for performing opportunistic network-controlled handover is load sharing, in scenarios where a network exercises tight control of various wireless link technologies to distribute the load of communications according to network policies. The network may perform a network-controlled handover decision in at least two steps. 1. Network selection, and 2. Handover control. The two steps are described in the following sections Hepworth, et al. Expires March 15, 2007 [Page 27] Internet-Draft Mobility Services September 2006 E.1. Network Selection Network selection is a process of selecting a favorable network for a mobile node to transfer or handover the ongoing services to the selected network. The selected network may be a different link technology from the previous one. It may also be possible that the mobile node, after handover, may not experience exactly the same level of QoS as the current link due to this network selection. But, in general, it may result in some user benefit in one way or another e.g. cost savings, higher bandwidth etc. MME in the network may have access to subscriber profile, contracts, and device capabilities to make use of the network selection algorithms for a certain subscriber or mobile node. Figure 8 shows a simple network selection procedure with the help of the mobile node. This example call flow diagram employs remote event services and information services. Remote command services are not used in this particular example, however, they can also be useful in the network selection mechanisms under certain scenarios. E.g. depending on user geographical location, the network may command the mobile node to perform a scan for a specific 802.11 network and report the results that can be used in the network selection process. In the scenario shown, the mobile node initially performs a registration or attachment to the network on any link, e.g. 3GPP network. The MME and the mobile node are able to discover each other in the same or following step. MME may then register for specific remote event services, e.g. ES-link-detect by sending a registration request and filter information for both 802.16 and 802.11 networks. The mobile node accepts the request with a positive reply. From time to time, the mobile node may receive broadcast information from 802.11 and 802.16 networks. In this scenario, the 802.16 broadcast is received and a link-detect is sent by the 802.16 MAC layer to the MIHF. The MIHF translates this to an ES-link-detect message to the MIHF implementing ES in the network (collocated in the MME) with the basic network information received in the broadcast. The MME requests for more information about the network via the IS query to another MIHF implementing IS to check the suitability of the detected network due to roaming agreements. The MME decides that this particular 802.16 network is not a favorable network and takes no action. The mobile node also takes no action and does not report the detection of same network more than once. At a later time, the mobile node may receive beacon information from 802.11 AP and the MAC layer in the mobile node reports the to the MIHF along with the SSID information. The MIHF provides this information to the MME in the network. The MME may perform an IS query based on the SSID information and determines that this SSID belongs to a favorable Hepworth, et al. Expires March 15, 2007 [Page 28] Internet-Draft Mobility Services September 2006 network. The network selection process, thereby, is completed. Mobile Node |----------------------| +--------+ +-------+ +-------+ +------+ +------+ +------+ |MIHF(ES)| | Link | | MME | | IS | |802.16| |802.11| | | | Layers| | | | | | | | | +--------+ +-------+ +-------+ +------+ +------+ +------+ | | | | | | +------------------------------+ | | | | Discovery & Registration| | | | +------------------------------+ | | | | 1.ES-reg-req | | | | |<========================| | | | | 2.ES-reg-resp | | | | |========================>| | | | ~ ~ ~ ~ ~ | |3.DL-burst| | | | | 4.link-detect|<--------------------------------| | |<-------------| | | | | | 5.ES-link-detect | | | | |========================>|6.IS-query| | | | | |--------->| | | | | +-------------+ | | | | | |not favorable| | | | | | +-------------+ | | | ~ ~ ~ ~ ~ ~ | |7.Beacon | | | | |8.link-detect |<-------------------------------------------| |<-------------| | | | | | 9.ES-link-detect | | | | |========================>|10.IS-query | | | | |--------->| | | | | +-----------+ | | | | | | favorable | | | | | | +-----------+ | | | | | | | | | +--------+ +-------+ +-------+ +------+ +------+ +------+ |----------------------| Legend: ===== ES over current link Figure 8: Network Selection in Network E.2. Handover Control Handover control procedure follows a network selection process as explained in the previous section. The following scenario in Figure 9 shows a network-controlled handover procedure with fast MIP Hepworth, et al. Expires March 15, 2007 [Page 29] Internet-Draft Mobility Services September 2006 handover signaling [8]. Here, the MME in the network utilizes MIHF implementing CS and generates a link switch command with CS-switch- req to the mobile node. The parameters in the message may include that a make-before-break mechanism is to be performed along with the target link information e.g. 802.11 network as shown from the network selection procedure earlier. The MIHF indicates the Mobile IP function of the impending link switch along with new link information. The Mobile IP functionality, If necessary, i.e., it does not have a valid Access Router Tuple-Info [RFC4068], it sends a Proxy Router Solicitation (PrRtrSol) with the new link information (e.g. MAC address of AP) and the Proxy Router Advertisement (PrRtrAdv) provides the relevant L3 information for the mobile node to use on the new link. The MIHF in the mobile node executes the command by sending an "associate" request to the 802.11 MAC which will perform all necessary L2 association and authentication procedures for the new link. For completeness, steps 3 and 4 in Figure 9 can take place in parallel to steps 3 and 4. A link-up indication is sent to the interested parties including Mobile IP functionality. Mobile IP sends a Fast Binding Update (FBU) to the old FA over the old link so that old FA could switch (tunnel) the packets to the new FA. The mobile node now is able to receive packets from new FA that are tunneled from old FA. At a later time, the mobile node performs an Mobile IP update procedure to update the binding in the HA and reroute the tunnels directly from HA to the new FA in the new network corresponding to the 802.11 link. Once the traffic uses the new link, the MIHF releases the old link by sending a request to that MAC layer, here the 3GPP radio link. A CS-switch- resp is sent back to the MME upon completion of the command. The following signaling flow shows how the network controlled handoff can work with fast MIP handover signaling [RFC4068]. It shows a make-before-break mechanism, so that the mobile node sends the FBU on the old link after the setup of the new link to minimize the latency due to L2 association and authentication procedures. For completeness, steps 3 and 4 in Figure 9 can take place in parallel to steps 2 and 3. Hepworth, et al. Expires March 15, 2007 [Page 30] Internet-Draft Mobility Services September 2006 Mobile Node |--------------------------| +----+ +-----+ +-------+ +----+ +------+ +----+ +----+ |MIP | |MIHF | | Link | | MME| |802.11| | AR | | HA | | | |(CS) | | Layers| | | | | | | | | +----+ +-----+ +-------+ +----+ +------+ +----+ +----+ | | | | | | | | | | +-----------+ | | | | | | | Network | | | | | | | | Selection | | | | | | | +-----------+ | | | | | 1.CS-switch-req | | | | 2.switch-ind|<====================| | | | |<-------| 3. PrRtrSol | | | | |=================================================>| | | | 4. PrRtrAdv | | | |<=================================================| | | |3.associate| | | | | | |---------->| 4.L2 Association | | | 5.link-up | |<---------------->| | | |<--------| | | | | | | | 6. FBU | | | | |=================================================>| | +----------------------------------------------------------------+ | Mobile IP update procedure over new link | +----------------------------------------------------------------+ | 7.release | | | | | | |---------->| | | | | | | 8.CS-switch-resp | | | | | |>>>>>>>>>>>>>>>>>>>>| | | | | | | | | | | +----+ +-----+ +-----+ +-----+ +----+ +------+ +---+ |------------------------------| Legend: ===== over current link, >>>>over new link Figure 9: Network-Controlled Handover Procedure Appendix F. MIH services and (AP-ID, AR-Info) tuples There are two kinds of handover modes in [8], which are classified based on whether mobile node has finished the IP layer related configuration before attaching to the new link of access router. One kind of mode is called "Predictive Mode" at which IP layer configuration is finished before handover, and the other is called "Reactive mode". For both of the two handover modes, it is necessary for mobile node Hepworth, et al. Expires March 15, 2007 [Page 31] Internet-Draft Mobility Services September 2006 to know the information of neighboring access routers abbreviated as "AR-Info" in [8]. The "AR-Info" is comprised of router's L2 address, router's IP address and router's IP prefix. Apart from "AR- Info", mobile node has to know the "AP-ID", the L2 link address of the imminent access point, which can be gotten during scanning processing. As for mobile node, the key knowledge is the (AP-ID, AR- Info) tuple which contains an access router's L2 address and IP address, and the prefix valid on the interface to which the access point (identified by AP-ID) is attached. This section discusses the construction scenarios fo (AP-ID, AR-Info) tuples and how MIH services are applied to these construction scenarios. F.1. Construction Scenarios of (AP-ID, AR-Info) tuples Three different deployment scenarios are outlined in this section as the following. These scenarios are intended to specify functionality requirements for the candidate solutions, not to specify the architecture of solutions. F.1.1. Distributed application scenario for construction +------+ +-------+ +--------+ | AR1 |/_ _ _ \| AR2 |/_ _ _ \| AR3 | | |\ /| |\ /| | +------+ +-------+ +--------+ / \ / \ / \ / \ / \ / \ / \ / \ / \ +---+ +---+ +---+ +---+ +---+ +---+ |AP | |AP | |BS | |BS | |BTS| |BTS| +---+ +---+ +---+ +---+ +---+ +---+ Figure 10: Reference model for distributed construction scenario Figure 10 depicts the reference model for heterogeneous network application scenario working at the distributed construction mode of (AP-ID, AR-Info) tuples. In this figure, three access routers with different functionalities are presented. AR1 is an access router for 802.11 WLAN, to which two access points are attach. AR2 has two 802.16 base stations attaching to its different down link, which plays a role of ASN Gateway. AR3 is an access router running in the 3G telecom networks, whose role may be PDSN in CDMA2000 network. AR3 has two Base Transceiver Stations attaching to its access link (in this figure, Base Station Controller connecting BTS and AR is omitted). Hepworth, et al. Expires March 15, 2007 [Page 32] Internet-Draft Mobility Services September 2006 When Fast Mobile IPv6 Protocol is applied in this heterogeneous network scenario, there are many factors implementing the construction of (AP-ID, AR-Info) tuples, which should be considered carefully. Detailed discussion is as the following. F.1.1.1. Construction of the AP-ID knowledge When access router is integrated with wireless interfaces (such as 802.11 interfaces and 802.16 interfaces), it is very easy for access router to get to know L2 address of wireless interfaces. But, for AR1 and AR2 in figure1, the access points and base stations work independently of access router. The access router can not get to know the L2 address of AP/BS's wireless interface easily. In the simpler case, manual configuration can be used to construct the L2 address knowledge of AP/BS for the access router. More sophisticated solution is to run a dynamic discovering protocol by which access router and AP/BS can interwork and deliver useful information to each other. If there is an existing protocol having this kind of ability, it can be used; otherwise new solution needs to be developed. For different networks, the dynamic protocol is different; and the designing of the dynamic protocol is outside the scope of MIPSHOP working group. AR3 is a network node in 3G networks. And BTS in 3G network works differently with that in 802 series network. The great difference is that BTS has no L2 address while AP/BS in 802 series network does have (see [3GFH]). To identify an access network in CDMA2000, the Access Network Identifier (ANID), which is composed of the System ID (SID), Network ID (NID) and Packet Zone ID (PZID) can be used, instead of using L2 address of AP/BS in 802 series wireless network. Because there are many BTSes attaching to the same access router, it is not easy for access router to get the knowledge about ANID. Similarly, both manual configuration and automatic discovering mechanism can be used to construct the ANID knowledge for the access router. F.1.1.2. Construction of (AP-ID, AR-Info) tuples Having gotten to know the information about AP-IDs, the access router has to construct the associations used in Proxy Router Advertisement between AP-IDs and AR-Info. In nature, it's not difficult for access router to construct the associations. No matter what construction mode of AP-IDs is used, AP- ID can be bound to a L3 interface which has its own information absolutely. Hepworth, et al. Expires March 15, 2007 [Page 33] Internet-Draft Mobility Services September 2006 F.1.1.3. Discovery of neighboring network access routers As for construction of (AP-ID, AR-Info) tuples, Figure1 is a distributed reference model. Different access router has to construct the repository of (AP-ID, AR-Info)s independently and serves for the mobile nodes attaching to its link. Before access routers can exchange neighboring network information, they have to know each other. It is very difficult for access router to determine the neighboring network access routers. For different deployment applications, the difference is great. Maybe the access routers at the same geographical location are not neighboring network access routers even though there is a direct link between them (i.e. neighboring routers). And maybe the access routers far from each other are neighboring network access routers even though there are many hops between them. In the simpler case, manual configuration can help access router determine neighboring network access routers. But for the large scale telecom networks, the neighboring network relationship is very complicated. And manual configuration can't be competent with this situation. More sophisticated solution is to use dynamic discovering protocol. There are many factors deserved to be considered carefully, which are outside the scope of this document. F.1.1.4. Selection of (AP-ID, AR-Info) tuples to be exchanged In figure1, AR2 has four access sub-networks and AR3 has two. In the real world, maybe there are more sub-networks attaching to the same access router. So it's not necessary for neighboring network access routers to exchange all of the (AP-ID, AR-Info) tuples. More effective way is only to exchange overlay/neighboring sub-network information. How to determine overlay/neighboring sub-networks is outside the scope of this document. F.1.1.5. Transportation of messages Transportation is performed between neighboring network access routers. Different kinds of messages require kinds of service level agreement for transportation. For example, management and control messages should be transported at reliability channel while (AP-ID, AR-Info) bearing messages require a fast and no guaranteed reliability one. Besides, many general transportation functionality should be consider carefully, such as congestion avoidance, reliability, security, fragmentation as well as reordering etc. Hepworth, et al. Expires March 15, 2007 [Page 34] Internet-Draft Mobility Services September 2006 F.1.2. Centralized application scenario for construction +-----+ | ICE | +-----+ / | \ +------------+ | +-------------+ | | | +------+ +-------+ +--------+ | AR1 | | AR2 | | AR3 | | | | | | | +------+ +-------+ +--------+ / \ / \ / \ / \ / \ / \ / \ / \ / \ +---+ +---+ +---+ +---+ +---+ +---+ |AP | |AP | |BS | |BS | |BTS| |BTS| +---+ +---+ +---+ +---+ +---+ +---+ Figure 11: Reference model for centralized construction scenario Figure 11 depicts a reference model for centralized construction scenario of (AP-ID, AR-Info). In contrast with Figure1, there is no great difference except that a new node called Information Centre Entity (ICE) is added. The Information Centre is a central repository of (AP-ID, AR-Info) tuples, which aggregates (AP-ID, AR-Info) tuples from every access router and delivers them to the requesting access router. For the centralized construction scenario, there are no new requirements about construction of AP-ID knowledge and (AP-ID, AR- Info) tuples compared with the distributed construction scenario. Introduction of Information Centre makes it unnecessary to run a dynamic discovering protocol of neighboring network access router because access router works together with ICE, instead of with neighboring network access routers. It is very important and useful to determine the (AP-ID, AR-Info) tuples to be exchanged between access router and ICE. Having constructed the (AP-ID, AR-Info) tuples, access router has to select the suitable tuples to be delivered to ICE. Access router can request (AP-ID, AR-Info) tuples from ICE based on AP-IDs; and ICE maybe push the suitable (AP-ID, AR-Info) tuples to a specific access router base on some polices. Hepworth, et al. Expires March 15, 2007 [Page 35] Internet-Draft Mobility Services September 2006 The transportation requirements for centralized construction scenario are the same as for distributed construction scenario. F.1.3. Mixed application scenario for construction +-----+ | ICE | +-----+ | | +------+ +-------+ +--------+ | AR1 |/_ _ _ \| AR2 |/_ _ _ \| AR3 | | |\ /| |\ /| | +------+ +-------+ +--------+ / \ / \ / \ / \ / \ / \ / \ / \ / \ +---+ +---+ +---+ +---+ +---+ +---+ |AP | |AP | |BS | |BS | |BTS| |BTS| +---+ +---+ +---+ +---+ +---+ +---+ Figure 12: Reference model for mixed construction scenario Figure 12 depicts a reference model for mixed (distributed and centralized) construction scenario. From functional component perspective, Figure 12 is the same as Figure 11. In Figure 12, only AR2 has established association with ICE while both AR1 and AR2 interwork with AR2. For the mixed construction scenario in Figure 12, AR1 and AR3 get neighboring network information from AR2. And AR2 exchanges information with AR1, AR2 and ICE at the same time. In this scenario, AR2 maybe acts as a proxy for AR1 and AR3 to exchange information with ICE. There are no special requirements for the mixed construction scenario compared with the above mentioned two scenarios. F.2. Interactions between MIH services and (AP-ID, AR-Info) tuples The Information Service of [1] can be used to transport and construct (AP-ID, AR-Info) tuples of neighboring access network. [MIH] has defined three kinds of information elements for Information Service. One kind is Link Layer Information Element, which can be used to transport (AP-ID, AR-Info) tuples between two access routers as well as between access router and Information Centre Entity. Hepworth, et al. Expires March 15, 2007 [Page 36] Internet-Draft Mobility Services September 2006 F.2.1. Using MIH IS in distributed construction scenario +---------+ +---------+ |AR/MIH IS| |AR/MIH IS| +---------+ +---------+ | | |____IS-Query_________\| | /| |/___IS-Response ______| |\ | | | |/___IS-Query__________| |\ | |____IS-Response______\| | /| Figure 13: Using MIH IS in distributed construction scenario Figure4 depicts the transportation and construction procedure for (AP-ID, AR-Info) tuples of neighboring network using Information Service. After two neighboring network access routers discover each other, one access router can query the other for specific (AP-ID, AR- Info) tuples; and the other can send the response to the querying access router. Besides the query and response messages, MIH Information service should support the other type of messages, such as "report message" which can be used to transport a bulk of (AP-ID, AR-Info) tuples without active query when access routers discover each other firstly. F.2.2. Using MIH IS in centralized scenario +----------+ +----------+ +----------+ |AR1/MIH IS| |ICE/MIH IS| |AR2/MIH IS| +----------+ +----------+ +----------+ | | | |____IS-Report_______\|/________IS-Report____| | /|\ | |____IS-Query________\|/________IS-Query_____| | /|\ | | | | |/___IS-Response______|_________IS-Reponse__\| |\ | /| | | | Figure 14: Using MIH IS in centralized construction scenario Hepworth, et al. Expires March 15, 2007 [Page 37] Internet-Draft Mobility Services September 2006 Figure5 depicts the transportation and construction procedure of (AP- ID, AR-Info) tuples in centralized construction scenario. In this figure, after AR1 and AR2 have discovered the ICE supporting MIH Information Service, both access routers send the report of own (AP- ID, AR-Info) tuples to ICE. And then, both of them query the (AP-ID, AR-Info) tuples of neighboring networks from ICE. For this scenario, ICE is an central repository of (AP-ID, AR-Info) tuples. Authors' Addresses Eleanor Hepworth Siemens Roke Manor Research Roke Manor Romsey, SO51 5RE UK Email: eleanor.hepworth@roke.co.uk Telemaco Melia NEC Europe Network Laboratories Kufuerstenanlage 36 Heidelberg 69115 Germany Phone: +49 6221 90511 42 Email: telemaco.melia@netlab.nec.de Srivinas Sreemanthula Nokia Research Center 6000 Connection Dr. Irving, TX 75028 USA Email: srinivas.sreemanthula@nokia.com Yoshihiro Ohba Toshiba America Research, Inc. 1 Telcordia Drive Piscateway NJ 08854 USA Email: yohba@tari.toshiba.com Hepworth, et al. Expires March 15, 2007 [Page 38] Internet-Draft Mobility Services September 2006 Vivek Gupta Intel Corporation 2111 NE 25th Avenue Hillsboro, OR 97124 USA Phone: +1 503 712 1754 Email: vivek.g.gupta@intel.com Jouni Korhonen TeliaSonera Corporation. P.O.Box 970 FIN-00051 Sonera FINLAND Phone: +358 40 534 4455 Email: jouni.korhonen@teliasonera.com Rui L.A. Aguiar Instituto de Telecomunicacoes Universidade de Aveiro Aveiro 3810 Portugal Phone: +351 234 377900 Email: ruilaa@det.ua.pt Sam(Zhongqi) Xia Huawei Technologies Co.,Ltd HuaWei Bld., No.3 Xinxi Rd. Shang-Di Information Industry Base,Hai-Dian District Beijing 100085 P.R. China Phone: +86-10-82836136 Email: xiazhongqi@huawei.com Hepworth, et al. Expires March 15, 2007 [Page 39] Internet-Draft Mobility Services September 2006 Full 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. 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Hepworth, et al. Expires March 15, 2007 [Page 40]