Media independent Information Service (MIIS) and Its Higher Layer Transport Requirements 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 xx, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract Media Independent Information Service (MIS) Information Services provides a framework by which a MIH (Media Independent Handover) function both in the mobile node and in the network can discover and obtain network information (both homogeneous and heterogeneous) within a geographical region to facilitate handovers. MIS includes support for various Information Elements (IEs). These IEs provide information that is essential for a handover function to make intelligent handover decision. The MIH function in a mobile node or network can obtain such network information (e.g., IEs) via both lower as well as higher layers. This document is an effort to describe use cases and requirements for higher layers Information Service while the information is transported over IP and above layers. 1. Introduction Media Independent Handover Services are a class of network services, which aim to improve the quality of handovers available to mobile 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. IEEE 802.21 working group is currently defining three broad classes of such services to facilitate the handover. They require passing of information within hosts, as well as between them: 1.1 Media Independent Event Services (MIES) provide indications from lower layers about changes in the connectivity state [802.21 draft]. Events are of two kinds: local and remote. In case of local events, information typically propagate upwards from L2 to MIH function and MIH function to upper layers within a local stack. In case of remote events, however, information may propagate from MIH or upper layers in one stack to MIH or upper layers in another stack. 1.2 Media Independent Command Services (MICS) provide mechanisms for Controlling handovers [802.21 draft]. It includes the commands from upper layer to MIH and from MIH to lower layer. These commands mainly carry the upper layer decisions to the lower layers. 1.3 Media Independent Information Service (MIIS) Information Services provides a framework by which a MIHF (Media Independent Handover Function) both in the mobile node and in the network can discover and obtain homogeneous and heterogeneous network information within a geographical region to facilitate handovers [802.21 draft]. MIIS includes support for various Information Elements (IEs). These IEs provide information that is essential for a handover function to make intelligent handover decision. The information can be made available via both lower as well as higher layers. 1.1 Higher Layer Information Services Higher layer Information Services are considered to be an important component of handover services for both horizontal and vertical handovers. Depending upon the type of mobility support, different IEs may be necessary for performing handovers. In cases where these IEs are not available natively by the access network, higher layer information service is the only means to obtain such information. Also for vertical handovers, information about heterogeneous networks is essential for mobile devices to decide the best network to handover that preserve the service and session continuity [802.21 draft]. These services are typically provided by information servers that are either available locally or can be contacted remotely. Information provided varies dependent on the purpose and operation of the information service, but may consist of: list of neighboring access networks, network operator list, roaming partners, wireless channel information (e.g., data rate, MAC type) etc. In particular, [802.21 Draft] document defines four classes of information elements: i) General access network information such as, List of operators, List of networks, etc; ii) Information about Point of Attachment (PoA) such as, location of PoA, address of PoA, etc; and iii) Higher layer information such as, subnet information, capability information, and iv) Vendor specific IEs. The delivery of such information relies upon the following reference model as defined by IEEE 802.21. 2. Information Service Reference Model Entities involved with handover information services perform the roles of an Information Services client (IS client), Information Services Proxy and an Information Services server (IS-Server). Relative positions of client and server, and the interfaces between them may produce different requirements, depending on the type of communication. Figure 1 presents a reference model for both for single and mutihop Communication. The reference model shows both client-server and client-proxy-server models. In the client-server model, an IS client is communicating with the IS server via an interface Ia which is similar to R1 or R3 as defined in Section 5.3.1 (MIH communication model)[802.21 draft]. In case of client-proxy-server model, the interface Ia` is similar to R4 or R5 in section 5.3.1 [802.21 Draft]. This new IS-Server may reside either within its administrative domain, or in another domain. ------------ ----------- | IS-client|<-------|------>|IS-Server| ------------ R1/R3 ----------- ------------ ----------- ----------- | IS-Client|<-------|------>|IS-Proxy | <-----|------> | IS-Server| ------------ R1/R3 ----------- R4/R5 ----------- Figure 1: Information Service Reference Model and Interfaces In order to support the above models, an Information Service system would need to provide more than transport such as, discovery of proxy and Information servers, security association between client-server and client-proxy-server in a variety of deployment scenarios. However, this document only addresses the transport requirements of information services over IP. Several such scenarios are described below. 3. Use Cases The models described above for information services allow deployment of IS Information Servers anywhere within the visited or home network domain. In this section example scenarios are described indicating where information services are likely to be deployed. Descriptions of particular characteristics of these deployments are made, especially where the deployments place requirements on any information service transportation deployed over IP. In each of the figures (Figure2, Figure 3 and Figure 4) below, a mobile device is currently connected to a particular wireless access network, serviced by an Access Point. In order to gain information about other wireless cells (homogeneous or heterogeneous) in the vicinity, it contacts an information server within the fixed network. In Figure 2, the information service has been deployed on a wireless Access Point. This is considered to be a likely scenario, as wireless devices themselves may be aware of local information and also may have information about administratively adjacent devices (such as first-hop routers) and other access points or base stations within the same subnet. In this scenario, transport of information services over IP may not strictly necessary, as the IS-Server may be the MAC peer of the wireless host. On the other hand if information server is an IP peer, higher transport is required. /--------\ / \ ------- -------- -------- /----/ \----\ |IS | | |--+--| |---/ \ |Client|<----->|IS | | | | / \ | | |Server| | | | \ / ------- -------- | -------- \ / Host Access | Router \----\ /----/ Point | \ / | -------- / \--------/ +--| | / Core | |-------/ Network | | -------- Router Figure 2: IS-Server on Access Point Figure 3 shows another scenario whereby the IS-server is co-located in the router. There the router has access to the upper layer information required assisting handovers. /----------\ / \ -------- -------- -------- /--/ \---\ |IS | | |--+--| |---/ \ |Client |<-----------------|->| IS | / \ | | | | | |Server| \ / --------- -------- | -------- \ / Host Access | Router \----\ /-----/ Point | \ / | -------- / \--------/ +--| | / Core | IS |-------/ Network |Server| -------- Router Figure 3: IS-Server on Subnet Router Figures 4 and 5 present the scenarios whereby Information Servers are deployed outside the mobile node's subnet. It presents both advantages and challenges. For example, the server is in a position to serve many access subnets simultaneously, which reduces administrative overheads. Conversely, network support for discovering the IS-Server becomes critically important. Since a mobile device may roam within a domain though, it may not be necessary to discover the server each time it changes subnet, so long as the mobile remains in the set of networks covered by the server. For other cases, discovery mechanisms are important, however, it is currently outside the scope of this document. /--------\ / \ ------ -------- -------- /----/ -------- \----\ | IS | | |-----| |---/ | | \ |Client|<-------------------------------------->| IS | \ | | | | | | \ |Server| / -------\ -------- -------- \ -------- / Host \ Access Router \----\ /----/ \ Point / \ / \ -------- -------- / \--------/ \ | |-----| | / Core \ | | | |-------/ Network \| | | | -------- -------- Access Router Point Visited Network Figure 3: IS-Server In the Network /--------\ / \ ----- -------- -------- /----/ \----\ | IS | | |-----| |---/ | ---- | \ |Client|<---------------------------------------> IS | \ | | | | | | \ |Server| / ----- -------- -------- \ -------- / Host \ Access Router \----\ /----/ \ Point \ / \ \--------/ \ | Core \ | Network \ | \ | \ /--------\ \ / \ \-------- -------- /---/ \----\ | |-----| |---/ |-------| \ | | | | | IS | \ | | | |---\ | Server| / -------- -------- \ | Server| / Access Router \---\ /----/ Point \ / \-------/ Visited Network Core Network Figure 4: IS-Server In the Network 3.1 Transport-Layer Issues The existing ready use of IETF developed transport layer protocols is a compelling reason to develop information services transported over IP. Particularly, it is valuable to determine if IS requirements match existing transport models and protocols. While higher layer information services are non-real time, in some scenarios (IS-Server within a subnet), the lifetimes of communications with a particular server may be too short. As such, the sequenced delivery of packets using TCP may be too complicated for this application heavy handed [2]. TCP fast recovery relies upon delivery of additional packets to stimulate additional transmissions of acknowledgements from a receiver back to a transmitter. Where packet exchanges are short and sporadic, loss of a packet may not be detected except using long retransmission timeouts [xx]. 3.2 Information Service Discovery Issues Discovery by the mobile device of the IS-Server either requires Information Server participation in a discovery protocol, network entity discovery support or use of a directory service. The directory service can then refer mobiles to an appropriate server for their location. Discovery mechanisms need to provide IP layer contact information for the IS-Server. Such a discovery system should provide protection against spoofing, to prevent attackers substituting bogus information servers. In IP networks, numerous directory and configuration services already exist. Use of these services either requires support from locally discoverable resources within the same IP hop [xx], or rely on prior configuration of the unicast address of the directory service [xx]. Prior configuration itself may be performed dynamically, along with other host services [4][15]. Network entity discovery, such as Router Discovery [9] could allow discovery of an IS server during routing configuration operations. If server discovery can be achieved through existing configuration discovery procedures, no additional packet exchanges would be required to perform discovery. As mentioned earlier, discovery of IS server is outside the scope of this document and therefore no requirements on discovery will be discussed. 3.3 Reliability Issues Reliability of IS message exchanges is important and should be supported. For example, if the messages exchanged for the information service are assumed to be processed in-order for particular exchanges, reordering of packets over the Internet may cause problems for IS function. In that case, transport-layer reliability services may be required. Alternatively, where message sequence numbers are incorporated into the Information Service messages, ordering of packets may be possible using application-layer information. In this case, it may also be possible to provide message reliability, on top of a datagram oriented transport service. Therefore, reliability may be assumed to be supported either by the IS protocol or by the user application. 3.4 Congestion Control Issues Transport protocol like TCP has congestion control mechanism and therefore in such cases this is a non issue. Where existing transport protocols do not incorporate their own congestion control and rate limitation, basic mechanisms for network protection and congestion recovery may need to be added to the IS application protocols. 3.5 Security Issues Security is important in IP networks, since there is a danger that attacking devices can attempt to adopt roles as information service devices. Such bogus devices could cause service degradation through spurious message exchanges, or by providing false information to mobile devices. IS-Servers need both to protect themselves from attack, and to provide mobile clients provable trust, in order that they can exchange the information securely and make their handover decisions without fear of malicious inaccuracies or mischief. 4. Requirements for Transport over IP Following are the very high level requirements for IS transport over IP and above layers. 4.1 The IS transport MUST work both for IPv4 and IPv6 networks The choice of transport mechanism should work with both IPv4 and IPv6 networks. 4.2 The IS protocol requires that security MUST be provided at the transport layer The MIIS message exchanges are critical to handover decision process. Therefore it has to be trusted. However, IS protocol framework does not add security at every message level. Thus it relies upon the underlying security. In such cases, the transport mechanism MUST support the necessary security. 4.2.1 The IS transport MUST provide peer authentication 4.2.2 The IS transport MUST provide message authentication and may provide confidentiality 4.2.3 The IS transport MUST provide replay protection 4.3 The IS transport MUST support the NAT traversal The transport protocol should allow the communication between MIHFs if they are behind the NAT box. 4.4 The IS transport MUST support the firewall traversal The transport protocol should allow the communication between MIHFs if they are behind the firewall. 4.5 Changes to the header fields, IEs and structure messages should not affect the security mechanisms defined for underlying transmission. MIIS defines the IE and MIH protocol formats that are processed by only MIHF peer entities. Any changes to these formats and fields MUST not require modifying the underlying security mechanisms in future. 5. Security Considerations 6. Acknowledgement