MIPSHOP Working Group S. Sreemanthula Internet-Draft S. Faccin Expires: September 7, 2006 Nokia E. Hepworth Siemens Roke Manor G. Daley Panasonic March 06, 2006 Problem Statement and Requirements for Event and Command Services in Media Independent Handovers draft-sreemanthula-es-cs-problem-02.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than 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 September 7, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document discusses the usage scenarios and usage models of event services and command services involving inter-system IP mobility, specifically media independent handovers. The discussion is intended Sreemanthula, et al. Expires September 7, 2006 [Page 1] Internet-Draft ES/CS for MIH March 2006 to aid the MIPSHOP WG in understanding the problem domain and requirements of the event and command services in the Internet. Sreemanthula, et al. Expires September 7, 2006 [Page 2] Internet-Draft ES/CS for MIH March 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology and Definitions . . . . . . . . . . . . . . . . . 5 2.1. Remote Command Service (CS) . . . . . . . . . . . . . . . 5 2.2. Local Command Service . . . . . . . . . . . . . . . . . . 6 2.3. Remote Event Service (ES) . . . . . . . . . . . . . . . . 6 2.4. Local Event Service . . . . . . . . . . . . . . . . . . . 6 2.5. Information Service (IS) . . . . . . . . . . . . . . . . . 6 2.6. Inter-technology Handover . . . . . . . . . . . . . . . . 6 2.7. Media Independent Handover Function (MIHF) . . . . . . . . 7 2.8. Mobility Management Entity (MME) . . . . . . . . . . . . . 7 2.9. Network node . . . . . . . . . . . . . . . . . . . . . . . 7 2.10. Access Network Node . . . . . . . . . . . . . . . . . . . 7 2.11. Core Network Node . . . . . . . . . . . . . . . . . . . . 7 2.12. Proxy Network Node . . . . . . . . . . . . . . . . . . . . 7 2.13. Network-Controlled Handover . . . . . . . . . . . . . . . 7 2.14. Station (STA) . . . . . . . . . . . . . . . . . . . . . . 8 3. Architectural Issues . . . . . . . . . . . . . . . . . . . . . 8 3.1. Network Controlled Mobility Scenarios . . . . . . . . . . 8 3.2. Remote Event Services . . . . . . . . . . . . . . . . . . 9 3.2.1. Event Services Classification . . . . . . . . . . . . 10 3.3. Remote Command Services . . . . . . . . . . . . . . . . . 11 3.4. Information Services . . . . . . . . . . . . . . . . . . . 12 4. Usage Models for Event Services . . . . . . . . . . . . . . . 12 5. Usage Models for Command Services . . . . . . . . . . . . . . 14 6. Usage Scenarios for Remote Events and Commands . . . . . . . . 15 6.1. Network-Controlled Handover Scenarios . . . . . . . . . . 15 6.2. Network Selection . . . . . . . . . . . . . . . . . . . . 16 6.3. Handover Control . . . . . . . . . . . . . . . . . . . . . 18 7. Enabling Event and Command Services . . . . . . . . . . . . . 20 7.1. Feasibility of Remote Events and Commands . . . . . . . . 21 7.1.1. Explicit Signaling for Remote Event/Command Services . . . . . . . . . . . . . . . . . . . . . . . 21 7.1.2. Mitigation of Security Issues and Validation of Transported Indications . . . . . . . . . . . . . . . 21 7.1.3. Mapping of Identifiers . . . . . . . . . . . . . . . . 23 7.2. Transport Selection Requirements . . . . . . . . . . . . . 24 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 8.1. Event Service Considerations . . . . . . . . . . . . . . . 26 8.2. Command Service Considerations . . . . . . . . . . . . . . 26 8.3. Security Considerations for Transport . . . . . . . . . . 27 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 27 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 Intellectual Property and Copyright Statements . . . . . . . . . . 30 Sreemanthula, et al. Expires September 7, 2006 [Page 3] Internet-Draft ES/CS for MIH March 2006 1. Introduction Handover services are a class of network services, which aim at providing service continuity and transparency to users during changes in network point of attachments and assist the quality of handovers available to wireless devices. In order to support more intelligent handover services it is often necessary to be able to exchange information between mobile and fixed nodes within the network. Such information include reporting events by a mobile node to the network and vice versa, as well as issuing inter-technology handover commands by the network to the mobile node. A comprehensive description of the problem related to the general information exchange aiding in inter-technology handovers can be found in [1]. Performing inter-technology handover management requires homogeneity in information exchange mechanisms between mobile node and network for all of the involved systems. In most 3GPP systems, such information exchange happens using existing protocols on the signaling plane that are specific to 3GPP. In IEEE 802 systems, and especially in WLAN, appropriate information exchange between the mobile nodes and the network for handover control by the network does not exist. In general, there is currently no mechanism that can be applied to various technologies (e.g. 3GPP wireless links, IEEE 802 wireless links, etc.) to enable the exchange of information between mobile nodes and the network to support management and control of inter-technology handover. Potentially, standardization fora (e.g. 3GPP) may define solutions to support the exchange of information between mobile nodes and the network to support management and control of inter-technology handover in a way that is applicable to 3GPP systems for various access technologies. However, several parties believe that an alternative that shall be considered is to adopt solutions being developed in IEEE 802.21 and enable the use of IP transport mechanisms for such solutions, since this would facilitate the deployment of seamless mobility services in networks where access- technology specific solutions do not exist or the equipment has not been updated to include such solutions. It is certain that performances considerations will have to be well understood. It is also worthwhile mentioning that not all seamless mobility scenarios require extremely high performance in terms of latency reduction, as described in this draft. 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. They require passing of information within hosts, locally and between different hosts, remotely. The services are Event Services (ES), Sreemanthula, et al. Expires September 7, 2006 [Page 4] Internet-Draft ES/CS for MIH March 2006 Command Services (CS), and Information Services (IS). Specifically: o Event Services (ES) provide indications from one layer or functionality to another about changes in the connectivity state. This is particularly relevant to wireless interfaces. o Command Services (CS) provide mechanisms for controlling handovers or functions aiding handovers. They provide mechanisms to establish, redirect, or remove state in either the network or mobile node, so that handovers occur smoothly. For details on the IS, [1] contains a detailed description. Each service carries L2-specific information that may be processed locally or require communication with peer services on other nodes, and this communication may be transported over IP, to communicate with peer services on other nodes. The main relevance of ES and CS to IETF and the MIPSHOP WG is the exchange of information related to ES and CS between peer nodes. This is referred to as Remote ES and Remote CS. The IETF has been working on how handover services can be used to assist mobility signaling protocols, and has been analyzing interactions between handover services and network/transport layers. At the same time, other groups (e.g. IEEE 802.21) have been taking a more generally applicable view. This document provides a view of the authors, and does not represent the official view of either IEEE 802.21 or an IETF WG. Assistance is sought to improve this document, in order to reflect consensus viewpoints from the appropriate groups. 2. Terminology and Definitions This section defines terminology used in this draft. Where not defined, refer to [6] for Mobility Related Terminology - RFC 3753. 2.1. Remote Command Service (CS) 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). Sreemanthula, et al. Expires September 7, 2006 [Page 5] Internet-Draft ES/CS for MIH March 2006 2.2. Local Command Service Local command service is a communication facility within a host enabling one functionality to request execution of certain commands in certain other functionality (e.g. the IP function may request to establish a connection over a link layer). 2.3. Remote Event Service (ES) Remote event service is a protocol exchange mechanism between network nodes to inform of recently happened or impending change in link or network status information. 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 node (e.g. trigger IP layer mobility). 2.4. Local Event Service Local event service is a communication facility within a host for one functionality to provide indications or notifications of certain state changes pertaining to the network to a certain other functionality (e.g. IEEE 802.11 MAC layer may inform the IP function that the wireless signal is lost). In [2], indication of local event services is referred to as link indications. In this document, local event services include indications generated at other layers than link layer (e.g. IP layer or layers above the IP layer). 2.5. Information Service (IS) Information service is a protocol exchange mechanism between network nodes to provide or query information related to specific networks. For more information see [1]. 2.6. Inter-technology Handover In this document the term Inter-Technology Handover refers to handover of communications between different wireless technologies. Specifically, the following cases are considered: o Handover between 3GPP wireless links and IEEE 802.11 o Handover between 3GPP wireless links and IEEE 802.16 o Handover between IEEE 802.11 and and IEEE 802.16 Other scenarios involving IEEE 802 technology may also be considered. Handover between different wireless technologies defined in 3GPP and with GSM are defined in 3GPP and are not considered to be inter- Sreemanthula, et al. Expires September 7, 2006 [Page 6] Internet-Draft ES/CS for MIH March 2006 technology handover in this document. Similarly, 3GPP inter-GGSN handover is out of scope. 2.7. Media Independent Handover Function (MIHF) Media independent handover function is a shim layer in the mobility management protocol stack of the mobile nodes or network element that provide media independent or inter-technology mobility, specifically handovers (e.g. as defined in IEEE 802.21). MIHF utilizes the event services and command services. "MIHF(CS)" and "MIHF(ES)" refer to command services and event services part of the MIHF, respectively. 2.8. Mobility Management Entity (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. MME functionality utilizes MIHF. 2.9. Network node It is any node that is part of the network. It includes mobile nodes, link layer nodes (e.g. IEEE 802.11 AP, IEEE 802.16 BS) and IP or higher layer nodes (e.g. routers, servers, etc.). 2.10. Access Network Node Access network node is a Network Node that provides link layer services to the mobile nodes (e.g. AP or base station). 2.11. Core Network Node A core network node is node in the network beyond an/the access network that is reachable by mobile nodes only by IP based protocols. The core network node can only originate or terminate protocol messages. 2.12. Proxy Network Node A proxy network node is node in the network in or beyond an/the access network that can neither originate nor terminate protocol messages, but can only pass or proxy protocol messages to a different network node. 2.13. Network-Controlled Handover In this document the term Network-Controlled Handover refers to an Inter-Technology Handover where a function in the network makes the Sreemanthula, et al. Expires September 7, 2006 [Page 7] Internet-Draft ES/CS for MIH March 2006 handover decision (e.g. based on information from the mobile node, network policies, etc.) 2.14. Station (STA) See the definition of mobile node in [6]. This is a specific term used in IEEE 802.11 wireless technologies. 3. Architectural Issues This section covers several architectural issues involved with Media Independent Handovers. These issues are not all tightly coupled together, but form parts of the overall problem space for Media Independent Handovers. 3.1. Network Controlled Mobility Scenarios Several operators or network service providers, including those deploying multiple access technologies, view their network resources as a single resource pool. These resources are used to maximize their network efficiency and improve the performance, thus providing a better user experience. This can be viewed as something analogous to a network pool of multiple routers for network balance and redundancy and increased capacity to reroute traffic and relieve congestion under heavy loads in their network. For access involving radio technologies, the available network bandwidth is directly related to the available frequency spectrum. For a given cost, radio technologies provide varied degrees of QoS affecting the user experience. This is due to the varied cost of spectrum acquisition and network deployment of various radio technologies. Also at any given instant, the service providers, including those with multiple access technologies, would like to see that no specific part their network, is operating under heavy loads and prefer to balance the traffic across all the available network paths for optimum performance. Generally speaking, the network wishes to exercise control over the mobile nodes to make use of a certain network path for mutual benefit of the users and the service providers themselves. The network, therefore, reserves the right to make handover decisions at the MME, for mobile nodes to utilize a more optimized network path. When multiple link technologies are involved, this could also mean that the network may instruct the mobile nodes to handover from current link technology to handover to another link technology. MME may make use of several parameters like subscription agreement, user device capabilities, network policies, roaming agreements, network Sreemanthula, et al. Expires September 7, 2006 [Page 8] Internet-Draft ES/CS for MIH March 2006 load conditions, overall cost to the user and of course, the user experience to arrive at a certain handover decision. 3.2. Remote Event Services Remote event services are the exchange of notification or indication messages of certain network status changes between peer network nodes at the same layer (above IP in this draft context). The state change refers to either the conditions of the existing link (e.g. a link layer connectivity is lost) or of the newly detected links (e.g. the mobile node can detect the presence of a new link technology, e.g. it receives beacons from an IEEE 802.11 AP that was previously not visible). Remote event services are different from link indications as defined in [2] in that link indications are defined to carry information from the link layer to the upper layer like local event services. However, the remote event services can utilize link indications as one triggering mechanism to send event information to the same layer on a peer network node. There can be other triggering mechanisms, perhaps from other layers in the node that may also result in event notifications. Remote event services can be originated by a mobile node and transported to a peer network node and vice versa. It is also possible for remote event services to be exchanged between two nodes in the network. In the same capacity, the events originated by a network node can be proxied by another node and terminated at a different node. It should be highlighted that the remote event services are envisioned to be used as an opt-in feature, meaning that a requesting entity would register for specific event types that it is interested in and provide the appropriate filter rules when that specific event type must be matched. These features will ensure that the protocol does not result in excessive load on either the network or the network node processing the event notification reports from multiple event generating nodes. Figure 1 shows a high-level usage model for the event services. Link layers at any network node can provide triggers or link indications to notify the state change to the upper layers. The triggers can also be originated from other sources at various layers or functionality within the same host. These trigger indications are checked and scoped based on the filters set by the requesting entity. Trigger indications that do not match the existing filter sets are discarded and for those that match, a corresponding event indication is sent to the requesting node. Sreemanthula, et al. Expires September 7, 2006 [Page 9] Internet-Draft ES/CS for MIH March 2006 |-------------------------| |---------------------------| +-------+ Other +--------+Remote Event+--------+ Other +-------+ | Other |------->| MIHF |<---------->| MIHF |<-------|Other | |Sources|triggers| (ES) | Services | (ES) |triggers|Sources| +-------+ +--------+ +--------+ +-------+ ^ ^ Link | | Link Indications | | Indications | | +-------+ +-------+ | Link | | Link | | Layer | | Layer | +-------+ +-------+ |-------------------------| |----------------------------| Network Network Node Node Fig.1 Event Service Model. 3.2.1. Event Services Classification Event services can be broadly classified to incorporate two different types of network notifications, Micro and Macro. While the event services discussed in this draft include both of these types, it mainly details those to be used specifically for macro network events. This is based on the view from earlier studies compiled by [2] which show that some link indications can result in unreliable information and also that the transport of such micro events would result in a higher network load. 3.2.1.1. Micro Network Events Micro network events refer to event notifications corresponding to microscopic changes in the network state information. The reporting of events between two nodes can be scoped or filtered to provide minute changes in the network state information. Examples of such events are Link-Parameters-Change, Link-Going-Down, Link-Threshold- Exceeded etc. Perhaps, within an example implementation, Link-Up and Link-Down could also be considered as micro network events with varying degrees, if the event reporting is scoped for state changes within the same AP, same subnet or same access technology. Generally, these network events may be characterized by frequent exchange of messages between the peer nodes to report minute changes in the state information. Sreemanthula, et al. Expires September 7, 2006 [Page 10] Internet-Draft ES/CS for MIH March 2006 3.2.1.2. Macro Network Events Macro network events refer to macroscopic changes in the network state information. Here, the reporting of events between two nodes is scoped or filtered to provide only macroscopic changes in the network. These can be triggered due to link indications such as Link-Detect, Link-Up, Link-Down involving subnet changes across same or multiple access networks. As explained before, it is also possible for other sources to generate the triggers. Generally, these network notifications may be characterized by an infrequent exchange of messages between the peer nodes, depending on the nature of the mobility of the mobile node itself. The choice of triggering indications in combination with the filters (e.g. a set of parameter and/or measurements), set by the requesting nodes, can be used to unambiguously trigger the macro network events. E.g. only a new link-detect indication with a filter for strong signal strength would result in an event notification for Link_Detect. 3.3. Remote Command Services Remote command services form a request-response mechanism utilized by the nodes in the network to instruct other network nodes to carry out or execute a specific function affecting the current link or a different link. Commands can also impact other layers, e.g. IP layer. The result of the command execution is provided in a response back to the originating node. The nodes receiving and executing the commands can either be a node in the network or a mobile node. In the same capacity, it is possible for one node to originate the service and another node to pass or proxy the service to a different node that terminates and executes the command. The remote command services are utilized as part of the MIHF which is in turn employed by the MME that implements handover decision algorithms for various mobile nodes. The functionality of MME or the handover decision algorithms are outside the scope of this draft. As compared to remote event services, the remote command services do not use opt-in features, meaning there is no registration needed to receive commands. However, the command services may use filtering information to scope the extent of execution of commands. E.g. the MME may command the mobile node to scan for specific access technologies in its vicinity. Some basic examples for remote command service are listed below: 1. Link-switch to switch from one link to another link Sreemanthula, et al. Expires September 7, 2006 [Page 11] Internet-Draft ES/CS for MIH March 2006 2. Link-scan to scan for specific links in the vicinity Figure 2 shows a high level usage model for the remote command services. MME may initiate command requests based on certain handover decision algorithms addressing a specific mobile node to the MIHF(CS). The request is translated to a CS request and forwarded to the MIHF(CS) in the target node where the c ommand will be executed. Depending on the type of the command, the execution may affect the link layer or other functionality in the same host. After the command is executed the result of command is carried back in a CS response to the originating node and finally to the MME. |------------------------------| |--------| +---------+ Commands +--------+ Remote Command +--------+ | Other |<-------->| MIHF |<-------------->| MIHF | | Layers/ | req/resp | (CS) | Service | (CS) | |Functions| +--------+ +--------+ +---------+ | | Link | |Commands Commands | |req/resp V V +-------+ +-------+ | Link | | MME | | Layer | | | +-------+ +-------+ |------------------------------| |-------| Network Network Node Node Fig.2 Command Service Model. 3.4. Information Services Information services are covered in detail in [1]. Information services, in a nut shell, provide an information query mechanism for network nodes to obtain information about specific networks and their capabilities. The event and command services covered in this draft work in conjunction with the information services. The information service plays a critical role in the network selection at the mobile node or in the network. Section 9 on usage scenarios will show the extent of their interworking and how they complement each other to achieve a common goal of enabling such scenarios. 4. Usage Models for Event Services The following usage models are shown as examples of possible models Sreemanthula, et al. Expires September 7, 2006 [Page 12] Internet-Draft ES/CS for MIH March 2006 that the event services are expected to enable. The list is not exhaustive and furthermore it is possible to derive new models using a combination of these models. -----> wireless link / +-------+ Remote ES / +-------+ | MIHF |-------------->| MIHF | | (ES) | Services | (ES) | +-------+ +-------+ Mobile Access, Proxy or Core Node Network Node Fig.3 ES: Mobile Node to Access, Proxy or Core Network Node. -----> wireless link / +-------+ Remote ES / +-------+ | MIHF |-------------->| MIHF | | (ES) | Services | (ES) | +-------+ +-------+ Mobile Access or Core Node Network Node Fig.4 ES: Mobile Node to Access or Core Network Node. +-------+ Remote ES / +-------+ | MIHF |-------------->| MIHF | | (ES) | Services | (ES) | +-------+ +-------+ Access Network Core Network Node Node Fig.5 ES: Access Network Node to Core Network Node. +-------+Remote ES+-------+Remote ES+-------+ | MIHF |-------->| MIHF |-------->| MIHF | | (ES) |Services | (ES) | Services| (ES) | +-------+ +-------+ +-------+ Access Network Proxy Core Network Sreemanthula, et al. Expires September 7, 2006 [Page 13] Internet-Draft ES/CS for MIH March 2006 or Mobile Node Network Node Node Fig.6 ES: Network Node to Proxy Network Node to Core Network Node. 5. Usage Models for Command Services The following usage models are shown as some of the possible models that the command services are expected to enable. The list is not exhaustive and further, it is possible to derive new models using a combination of these models. -----> wireless link / +-------+ Remote CS / +-------+ | MIHF |<--------------| MIHF | | (CS) | Services | (CS) | +-------+ +-------+ Mobile Access, Proxy or Core Node Network Node Fig.7 CS: Access or Core Network Node to Mobile Node. +-------+ Remote CS / +-------+ | MIHF |<--------------| MIHF | | (CS) | Services | (CS) | +-------+ +-------+ Access Network Core Network Node Node Fig.8 CS: Core Network Node to Access Network Node. +-------+Remote CS+-------+Remote CS+-------+ | MIHF |<--------| MIHF |<--------| MIHF | | (CS) |Services | (CS) | Services| (CS) | +-------+ +-------+ +-------+ Access Network Proxy Core Network or Mobile Node Network Node Node Fig.9 CS: Network Node to Proxy Network Node to Network Node. Sreemanthula, et al. Expires September 7, 2006 [Page 14] Internet-Draft ES/CS for MIH March 2006 6. Usage Scenarios for Remote Events and Commands While the authors of this draft agree with most of the comments raised in [2], the authors believe that remote transport of events for ES is feasible under specific conditions. The intention behind ES and CS is not to cater for every possible scenario, but to target specific scenarios. In particular, the focus is on network architectures deploying multiple access technologies, where inter-technology handover is required. 6.1. Network-Controlled Handover Scenarios Remote ES and CS can be used as enablers for network-controlled handover scenarios between different access technologies. The discussion of network-controlled 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 Remote 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 Sreemanthula, et al. Expires September 7, 2006 [Page 15] Internet-Draft ES/CS for MIH March 2006 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 6.2. 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 10 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(ES). The MIHF(ES) translates this to an ES-link-detect message to the MIHF(ES) in the network (collocated in the MME) with the basic network information received in the broadcast. Sreemanthula, et al. Expires September 7, 2006 [Page 16] Internet-Draft ES/CS for MIH March 2006 The MME requests for more information about the network via the IS query to an IS server to check the suitability of the detected network due to roaming agreements [1]. 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(ES) along with the SSID information. The MIHF(ES) 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 network. The network selection process, thereby, is completed. Sreemanthula, et al. Expires September 7, 2006 [Page 17] Internet-Draft ES/CS for MIH March 2006 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: ===== Remote ES over current link Fig.10 Network Selection in Network. 6.3. Handover Control Handover control procedure follows a network selection process as explained in the previous section. The following scenario in Figure 11 shows a network-controlled handover procedure with fast MIP handover signaling [3]. Here, the MME in the network utilizes Sreemanthula, et al. Expires September 7, 2006 [Page 18] Internet-Draft ES/CS for MIH March 2006 MIHF(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 MICH(CS) 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 [3], 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(CS) 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 11 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(CS) 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 [3]. 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 11 can take place in parallel to steps 2 and 3. Sreemanthula, et al. Expires September 7, 2006 [Page 19] Internet-Draft ES/CS for MIH March 2006 Mobile Node |--------------------------------| +--------+ +--------+ +-------+ +-----+ +------+ +------+ +-----+ |MobileIP| |MIHF(CS)| | Link | | MME | |802.11| | FA | | HA | | | | | | Layers| | | | | | | | | +--------+ +--------+ +-------+ +-----+ +------+ +------+ +-----+ | | | | | | | | | | +-----------+ | | | | | | | Network | | | | | | | | Selection | | | | | | | |(sect. 9.1)| | | | | | | +-----------+ | | | | | 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 Fig.11 Network-Controlled Handover Procedure. 7. 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. Sreemanthula, et al. Expires September 7, 2006 [Page 20] Internet-Draft ES/CS for MIH March 2006 This draft does not propose any specific solutions. 7.1. Feasibility of Remote Events and Commands [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 remote ES and CS. 7.1.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 explicit 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 PDG 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). 7.1.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, Sreemanthula, et al. Expires September 7, 2006 [Page 21] Internet-Draft ES/CS for MIH March 2006 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 described in this document, as described in section 9 a "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 a re 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 network, 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. Sreemanthula, et al. Expires September 7, 2006 [Page 22] Internet-Draft ES/CS for MIH March 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 Fig.12 Mobile Node - MME Relationship and Mapping of Identifiers. 7.1.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. Sreemanthula, et al. Expires September 7, 2006 [Page 23] Internet-Draft ES/CS for MIH March 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 12, 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. 7.2. Transport Selection Requirements A transport MUST be selected for the event and command services based on general protocol requirements discussed in this draft. o Provide an ES/CS transport mechanism which works whether ES/ CS-Server is on the same subnet, or deep in the network belonging to same or different administrative domain. o Provide a remote ES/CS service transport mechanism which works with both IPv6 and IPv4. o Enable efficient, optimized and timely delivery of ES/CS information. o Distinguish between the packet source and query source (allow proxies). o Enable NAT traversal for IPv4 networks. o Enable Firewall traversal for IPv4 and IPv6 networks. o Optionally allow for multiple queries per transport session. o Optionally ensure compatibility between the ES/CS transport and those required for information services transport. o Describe an ES/CS discovery mechanism for IPv4 and IPv6 hosts. Sreemanthula, et al. Expires September 7, 2006 [Page 24] Internet-Draft ES/CS for MIH March 2006 o Provide a common discovery method regardless of whether the ES/ CS-Server is on the same subnet, or deep within the network. o Optionally ensure compatibility between the Event and Command Services over IP, and those required for information services discovery mechanisms. o Allow for more than one ES or CS Server to be discovered at a time. o Provide a common SA negotiation method regardless of whether the ES/CS-Server is on the same subnet, or deep within the network. o Protect against ES/CS-Server and wireless device impersonation (with authentication). o Protect against data insertion and modification (provide message authentication). o Protect against replay attacks. o Provide confidentiality of query and response contents. o Protect the identity of a querier against eavesdroppers. o Protect ES/CS-Server and discovery resources against denial of service. o Minimize computational and transmission resources for mobile clients. o Provide compatibility with Address or Security Association Mobility management, to allow use of an ES/CS server after host movements without renegotiating an SA. o Allow for security services to be disabled. o Changes to the ES/CS payload should not affect the security mechanisms defined in the underlying transport mechanism to ensure protocol modifications and evolutions defined in payload. o Enable fast SA setup to handle address mobility. 8. Security Considerations When exchanging events and commands between hosts, extreme caution needs to be exercised in establishing communications securely. Sreemanthula, et al. Expires September 7, 2006 [Page 25] Internet-Draft ES/CS for MIH March 2006 Unless endpoints are identified and authorized for communications, one or more service entities may be affected by state changes as a result of inappropriate registration, event or command reception. 8.1. Event Service Considerations When receiving events, their impact on entities in their target layer (for example the link-layer for link-indications) may be well defined. Their effect on other protocol layers may be unclear though. This may be the case because changes to protocol entities at one layer do not cause changes in another, or because the event is not considered trustable or authoritative [2]. Event indications are therefore likely to be interpreted as hints by other protocol layers, without necessarily modifying protocol state. Where unauthorized third parties impersonating legitimate ES entities can generate hints, attackers can cause damage to communications to or from a mobile node. Such bogus hints can potentially cause additional packet transmissions at other layers, cause a host to be denied service or cause non-preferred services to be selected. Unless appropriate security mechanism and a security model are adopted, attacks may be particularly simple on a wireless medium, where even valid event messages may be replayed at a later stage by an attacker. As event services allow events to be delivered across multiple IP forwarding hops, spoofed ES messages potentially may arrive from anywhere on the Internet. In order to mitigate this issue, where signaling is constrained to be within an IP subnet, link-local signaling may be appropriate [4][5]. For event services generated beyond the local link, security mechanisms need to be in place to ensure that the node receiving an ES message can verify the source of the message and the validity of the message (e.g. to avoid tampering or injection of bogus ES messages). Events sent to network side ES entities may cause changes to services provided to a wireless terminal. Such events could then generate further events and commands to be generated. Also, the mobile node to which the bogus events referred may be unaware of the event delivery, or indeed of any reaction to the event within the network. 8.2. Command Service Considerations Command services experience most of the same attacks as event Sreemanthula, et al. Expires September 7, 2006 [Page 26] Internet-Draft ES/CS for MIH March 2006 services, although their effects may be even more severe. CS deal with impending, typically mandatory, state changes which control the association and allocated resources of the network or mobile node. Therefore, a recipient of a command may feel compelled to comply with a requested state change, even if the change is not legitimate or useful. This can be used to force disconnection or poor service selection. This level of control over remote services requires very careful monitoring and access control. 8.3. Security Considerations for Transport Remote Command and Event services using a transport at IP level or above need in several cases to traverse network boundaries. Considering that transport for Remote Command and Event services should not be restricted to IPv4-only or IPv6-only, crossing boundaries implies that the messages for Remote Command and Event services need to traverse both firewall and NATs. It is essential for Remote Command and Event services to maintain the security of existing networks and not create new threats when crossing boundaries. At the same time, it must be ensured that Remote Command and Event services using a transport at IP level can cross NATs and firewalls. 9. IANA Considerations The IANA provide registry services for a large number of protocol identifiers used within IETF-related protocols. The IEEE standards association maintains its own registries for organizationally unique identifiers, ethertypes, and logical link control identifiers. This document does not in itself cause changes or demands to be placed upon the IANA or IEEE registries. Subsequent development of standards which may reference or create IANA or IEEE registries have the potential induce changes of loads particular registries. Proposals for Remote Event Services and Remote Command Services need to ensure that any envisaged use development of registries are compitible with the registry operation's charter and resources. 10. Conclusions The scenarios describing the problem in the draft show the possible Sreemanthula, et al. Expires September 7, 2006 [Page 27] Internet-Draft ES/CS for MIH March 2006 usage extent of event and command services in aiding the inter-system mobility. Event and command services can serve inter-system handovers by providing an interface between the multi-access handover logic to the functional entities that executes mobility signaling in the mobile node or in the network. 11. Acknowledgments The author would like to acknowledge and thank the participants of this working group and IEEE 802.21 community for openly discussing the problem and showing interest to solve it. 12. References [1] Hepworth, E., "Media Independent Handovers: Problem Statement", draft-hepworth-mipshop-mih-problem-statement-01 (work in progress), March 2006. [2] Faccin, S., "Requirements for a Media Independent Handover Information Service draft-faccin-mih-infoserv-02.txt", March 2006. [3] Adoba, B., "Architectural Implications of Link Indications draft-iab-link-indications-03.txt", June 2005. [4] Koodli, R., "RFC4068: Fast Handovers for Mobile IPv6", July 2005. [5] Deering, S. and R. Hinden, "RFC2460: Internet Protocol, Version 6 (IPv6) Specification", December 1998. [6] Hinden, R. and S. Deering, "RFC3513: Internet Protocol Version 6 (IPv6) Addressing Architecture", April 2003. [7] Manner, J. and M. Kojo, "RFC3753: Mobility Related Terminology", June 2004. Sreemanthula, et al. Expires September 7, 2006 [Page 28] Internet-Draft ES/CS for MIH March 2006 Authors' Addresses Srinivas Sreemanthula Nokia NH3:400 6000 Connection Dr. Irving, TX 75039 USA Phone: +1 9728945000 Email: srinivas.sreemanthula@nokia.com Stefano Faccin Nokia NH3:400 6000 Connection Dr. Irving, TX 75039 USA Phone: +1 9728945000 Email: stefano.faccin@nokia.com Eleanor Hepworth Siemens Roke Manor Romsey Hants S051 0ZN UK Phone: Email: eleanor.hepworth@roke.co.uk Greg Daley Panasonic Digital Networking Laboratory 2 Research Way Princeton, New Jersey 08540 USA Phone: +1 609 734 7334 Email: greg.daley@research.panasonic.com Sreemanthula, et al. Expires September 7, 2006 [Page 29] Internet-Draft ES/CS for MIH March 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Sreemanthula, et al. Expires September 7, 2006 [Page 30]