Network Working Group G. Daley Internet-Draft Monash University CTIE Expires: December 30, 2005 S. Faccin Nokia June 28, 2005 Some Requirements for a Media Independent Handover Information Service draft-faccin-mih-infoserv-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 30, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract Work within the IEEE's 802.21 working group is aimed at providing media independent handover service, to assist with handovers between heterogeneous link-layer technologies, and across upper-layer subnet boundaries. In order to provide canonical mechanism for media independent handover information to link-layer devices, an information service Daley & Faccin Expires December 30, 2005 [Page 1] Internet-Draft Some Requirements for an MIIS June 2005 envisaged as part of the 802.21 solution. This document is a personal effort amongst attendees to solicit assistance from IETF contributors to determine which components of the information service are already available, and the form of the components which still require protocol development. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 The Current 802.21 Working Document . . . . . . . . . . . 3 1.2 Media Independent Information Service Description . . . . 4 1.3 Information flows . . . . . . . . . . . . . . . . . . . . 4 2. Media Independent Handover Services . . . . . . . . . . . . . 6 2.1 Requirements for an MIH Information Service . . . . . . . 6 3. MIHS SAP Relations . . . . . . . . . . . . . . . . . . . . . . 7 4. Message formats for MIHS . . . . . . . . . . . . . . . . . . . 8 5. MIIS SAP Structure . . . . . . . . . . . . . . . . . . . . . . 9 5.1 MIH_Information.request . . . . . . . . . . . . . . . . . 10 5.2 MIH_Information.response . . . . . . . . . . . . . . . . . 10 5.3 InfoQueryFilter Elements . . . . . . . . . . . . . . . . . 11 5.4 Query Mechanisms and Formats . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7.1 Attacks against service entities . . . . . . . . . . . . . 13 7.2 Attacks against information . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.1 Normative References . . . . . . . . . . . . . . . . . . . 14 8.2 Informative References . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15 A. Relevant Statements in 802.21 Working Document . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . 24 Daley & Faccin Expires December 30, 2005 [Page 2] Internet-Draft Some Requirements for an MIIS June 2005 1. Introduction The current working document for media independent handover services in the IEEE 802.21 working group aims at providing information to assist upper-layer configuration at handover time [1]. In order to further assist handover decision planning, a Media Independent Information Service (MIIS) is envisaged in the working document, which would provide topological and location related information to end devices' Layer-2 media independent handover function (MIHF). The data received in the Media Independent Handover Function would be passed to interested upper layer protocols, potentially filtered for content, as is appropriate. In order to support different deployment topologies, the current working document suggests that the Media Independent Information Service runs over Upper-Layer protocols such as IP (with other upper- layer protocols). This document describes one distillation of the requirements from the current working document for 802.21's media independent information service, in order to elicit expert advice from IETF participants in developing such a network-layer and above embodiment of the protocol. 1.1 The Current 802.21 Working Document 802.21 has recently harmonized on a proposal which has been accepted as a basis for standardizing a Media Independent Handover (MIH) Service. This has resulted in a working document, which is aimed at providing a framework for implementation of MIH service access points (SAPs) to interface with upper layer protocols, as well as interfaces for communicating handover centric information between peer 802 or cellular network entities [1]. The information exchanges are classified as either Event, Command or Information services. Event services provide immediate communications to within an MIHF or to a peer MIHF on the other end of the Link-layer medium. Events indicate that changes are occurring in the wireless environment: for example, that it is now possible to send generic upper-layer frames. Command services are instructions from upper layer handover controlling entities to change the state of the wireless link, and may be sent within a stack, or passed to a peer MIH entity on the other side of a wireless link. For example: The network may be able to instruct a station to handover to another network. Daley & Faccin Expires December 30, 2005 [Page 3] Internet-Draft Some Requirements for an MIIS June 2005 Such command mechanisms may cause further event generation, either from the local Medium Independent Handover Function, or on the peer. The Media Independent Information Service distinguishes itself from the other mechanisms in that the messages are typically larger and do not have the same time critical delivery requirements. Also, the endpoint for remote communication may be a device other than the directly adjacent link-layer peer. As described in the working document, in this case, it is believed an upper-layer protocol should be used to deliver information. In that case, it is possible that network information may be either centrally stored on a server or distributed in each individual access network. Presumably, an L2 or L3 based mechanism to identify or discover a valid information server would be required. 1.2 Media Independent Information Service Description The media independent information service provides three classes of data to mobile hosts: 1. General Network Information (GNI): A general overview of the network and its nearby Points of Attachment. 2. Link Layer Information (LLI): Link-layer specific information useful to identify capabilities of a specific network. 3. Higher Layer Information (HLI): Information about upper layer protocols like IPv4 and IPv6, configuration systems such as DHCP and mobility management applications like MIPv4 [2][5]. The information service is primarily a request/response based system, with potential unsolicited multicast over raw link-layer transports in some situations (not necessarily relevant to IETF though). The information service processes queries containing a set of filter constraints on the response, as specified by the requester. It then composes a response and sends it back to the requester. Given the size and non-real time nature of the response, more than one packet of data may be required to transport all the information required. 1.3 Information flows As mentioned earlier, the are different incarnations of the Daley & Faccin Expires December 30, 2005 [Page 4] Internet-Draft Some Requirements for an MIIS June 2005 Information Service depending on whether information is being passed between two link-layer peers, or is stored on a server accessible over an upper-layer protocol such as IP. While this document is concerned solely with the L3 and above transport for MIH's information service, the information flow for both L2 and L3 based exchanges are presented for comparison: STA (Client) AP/BS MIH SAP MAC MAC MIH SAP | | | | Request |MIH_Info. | | | info from | request|Information REQUEST | | peer |--------->|---------\ | | | | \-------->|----------->| | | |MIH_Info. | | | | indication| | | | |Neighbor Map | | | |Report Gen | | |MIH_Info. | | | | response| | | /--------|<-----------| Neighbor |<---------|<---------/ | | Map Report |MIH_Info. |Information RESPONSE| | | confirm| | | Note that the primary logical differences between the information flows at the link-layer and upper layers are the endpoints for message transport. The use of a particular mechanism should be transparent to systems interfacing to the MIH Service Access Point. Daley & Faccin Expires December 30, 2005 [Page 5] Internet-Draft Some Requirements for an MIIS June 2005 STA (Client) AR/Server MIH SAP T'sport/IP T'sport/IP MIH SAP | | | | Request |MIH_Info. | | | info from | request|Information REQUEST | | peer |--------->|---------\ | | | | \-------->|----------->| | | |MIH_Info. | | | | indication| | | | |Neighbor Map | | | |Report Gen | | |MIH_Info. | | | | response| | | /--------|<-----------| Neighbor |<---------|<---------/ | | Map Report |MIH_Info. |Information RESPONSE| | | confirm| | | As described in section 6.3.4 of the 802.21 working document, as in the above figure: "MIIS within MIHF (MIH Function) is communicating with the remote MIHF that is residing either within the access network or in the core network..." [1]. Further discussion within the IEEE 802.21 Cairns interim meeting identified that forwarded (multi-hop) delivery may be needed in some cases, if IP is the basis for the upper-layer transport if information services. 2. Media Independent Handover Services The union of the Media Independent Information Service, the Media Independent Event Serviced and the Media Independent Command Service compose a Media Independent Handover Service. Certain characteristics are shared amongst all three services. Of particular note are the common SAPs, message formats and data schema. 2.1 Requirements for an MIH Information Service The MIIS needs to be in a position to provide useful information to hosts about their current visited environments. In many cases, the network side infrastructure is in a position to store overall network information, such as neighborhood cell lists and the location of mobile devices. Daley & Faccin Expires December 30, 2005 [Page 6] Internet-Draft Some Requirements for an MIIS June 2005 This provides an information model and an information repository to make more effective handover decisions. The mobile terminal accesses information from this repository using it's current network point of attachments. Apart from periodic updates when configuration change occurs, the client requests reports containing pertinent information from a remote MIIS entity. In order for upper layer protocol entities to provide queries, on the client, request messages are passed down through the MIH_SAP. When a response arrives, or if a failure occurs, a response is passed back up through the SAP. 3. MIHS SAP Relations The MIHF provides a unified SAP for its component services to upper layers such as IPv6, or mobility management applications, like MIPv6 [3][4][6]. These applications are saved the difficulty of dealing with individual Link-layer modules for handover control and monitoring. Within the MIHS, each of the entities is able to interface to media dependent operations in order to gain information from or provide control over the physical medium and MAC. In the diagram below, the MIIS is shown as being able to interface to upper layer protocols, in order to provide information service data transport. Daley & Faccin Expires December 30, 2005 [Page 7] Internet-Draft Some Requirements for an MIIS June 2005 +-----------+--------------------+------------+ Upper Layer | Other | | | Services |Upper Layer| IPv4 | IPv6 | | ^ | ^ | ^ | | | | | | | | | \----------------+----------------+--------\ | | | | \ | /-------+--------------------+--------\ | | +--+ MIH SAP +--+ | | \-------------------------------------/ | | | | | | Media Independent Handover Function | | | | | | +----------+ +-----------+ +----------+ | | | | | | | | | | / | | MIES | | MICS | | MIIS ?------/ | | | | | | | | | +----------+ +-----------+ +----------+ | | | +---------+-----------+-----------+-----------+ Media | | | | | Depend | 802.16 | 802.11 | 802.11 | UMTS | Handover | | | | | Services | | | | | +---------+-----------+-----------+-----------+ 4. Message formats for MIHS In order to make carriage of data simple and consistent in all media, a format has been defined in common for media independent message transfer. While both L2 specific and network (and above) layer transport are envisaged for the MIHS, both services define a common message format which is specialized for each of the MIHF components. The message format below is one for MIIS. The primary differences between MIIS format and the command and event services are the MIH Service ID field, and the Language Coding and Character Coding fields. The latter two only appear in Information Service messages. Daley & Faccin Expires December 30, 2005 [Page 8] Internet-Draft Some Requirements for an MIIS June 2005 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Proto Version |MIH ServiceID=3| MIH Opcode |Transaction ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Length |F| Frag Number | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MIH Function Identifier Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ MIH Function Destination Identifier ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ MIH Function Source Identifier ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MIH Message Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Language Code | Character Coding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ MIH Message Data ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The MIH service ID distinguishes amongst Event, Command and Information service messages, with individual operations providing being distinguished using the Opcode, and response matching delivered by the Transaction ID. The Identifier Length provides an identifier length for both source and destination. For MIIS messages, the MIH Service ID is set to three, and it is proposed that the first four octets of the message body define together the query language in use, and the text message encoding for responding strings sent to upper layer applications. The use of query language identification indicates that no single content format exists for the MIIS. Example schema for RDF (SPARQL) and ASN.1 are provided in sections 6.3.3.2.1 and 6.3.3.2.2 of the 802.21 working document [8][9]. Additional formats are considered possible in 9.4.5 of the same draft. 5. MIIS SAP Structure Two messages are defined on the MIH_SAP for the Intformation service: Daley & Faccin Expires December 30, 2005 [Page 9] Internet-Draft Some Requirements for an MIIS June 2005 "MIH_Information.request" and "MIH_Information.response". The elements of these services are defined below. 5.1 MIH_Information.request The request operation in the MIH Information Service SAP allows various pieces of information to be requested and filtered by the responding information service. below is a list of the parameters for the request. MIH_Information.request ( InfoQueryFilter, InfoQueryParameters ) The InfoQueryFilter provides a set of limitations to the response information, so that only information which is interesting to the querier is transmitted across the network, and passed to applications. Elements for the filters are summarized in Section 5.3. InfoQueryParameters provide the specific control of which data are interesting to a particular mobile device. Examples in the 802.21 working document describe use of SPARQL Queries within InfoQueryParameters, using storage in an 'FILTER_INTO_DATA' InfoQueryFilter [8][9]. Additionally specification of EAP in the InfoQueryParameters is described in the 802.21 document section 7.4.15.3. Interested parties are invited to look at the query schema defined in the working document [1]. 5.2 MIH_Information.response The response message contains the contents of the reply from the peer Information Service. Occasionally, this message will not respond with useful information, for example if the response comes from the local MIIS entity in communicating failure cases, the success and failure of a the query is stored in the status field. Daley & Faccin Expires December 30, 2005 [Page 10] Internet-Draft Some Requirements for an MIIS June 2005 MIH_Information.response ( InfoQueryFilter, MIH_REPORT, status ) The InfoQueryFilter exhibits the same properties as when used in a request. The status determines if the query was successful or not. The MIH report is passed as a textual string (assuming XML rendering of the content). 5.3 InfoQueryFilter Elements Query filters are applied to MIIS information queries and responses. They limit the data which is passed through to the upper-layer protocol through the SAP. They also limit the amount of data provided by the MIIS in response to queries. Query filters come in three classes aligned with the network information classes. The tables of filters below have been reproduced from section 7.4.14.1 of the 802.21 working document [1]. o GNI: FILTER_INFO_ALL_NETWORKS: Get Info about all networks FILTER_INFO_802_NETWORK: Get info about all 802 networks FILTER_INFO_GSM_NETWORK: Get info about only GSM networks FILTER_INFO_CDMA_NETWORK: Get info about only GSM networks o LLI: FILTER_INFO_ALL_ELEMENTS: Get info about all information elements FILTER_INFO_ELEMENT_MAC_ADDRESS: Get info about only the MAC Address FILTER_INFO_ELEMENT_SECURITY: Get info about only the security Daley & Faccin Expires December 30, 2005 [Page 11] Internet-Draft Some Requirements for an MIIS June 2005 o HLSI: FILTER_INFO_ALL_SERVICE_PROVISION: Get info about higher layer services FILTER_INFO_ELEMENT_ISP: Get info about the ISP FILTER_INFO_VPN_SUPPORT: Indicates the support of VPN FILTER_INFO_MIP_SUPPORT: Indicates the support of MIP Additional Filter mechanisms and requests are defined in the current 802.21 working document. These are primarily to allow flexible querying using a language such as SPARQL [9]. The following values are defined in section 7.4.14.3 of [1]: FILTER_INFO_DATA: This filter is a query and response filter for the SPARQL Database query language (defined in XML/RDF). FILTER_INFO_SCHEMA_URL: This filter is used to determine if non- mandatory portions of the schema are implemented (the extended schema), which schema they are and identifies where this data is kept. FILTER_INFO_SCHEMA: Used to retrieve templates for queries on the extended schema. 5.4 Query Mechanisms and Formats At this stage, both MIB and SPARQL (RDF/XML) schema have been specified in the 802.21 working document [8][9]. It may be useful to determine if similar or more appropriate systems are used for information services within the IETF development stream. (If such tools exist). 6. 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 Daley & Faccin Expires December 30, 2005 [Page 12] Internet-Draft Some Requirements for an MIIS June 2005 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 Media Independent Information Services need to ensure that any envisaged use development of registries are compatible with the registry operation's charter and resources. 7. Security Considerations Exchange of Link-layer related information over upper-layer protocols such as IP has the potential effect of widening the scope of attacks against both the information service's interfaces with the network, and the information itself. 7.1 Attacks against service entities Attacks against the information service become possible where information which would be limited to only one medium or bridge span, is subsequently available through an arbitrarily large IP subnet. Additionally, where information service packets may be requested or supplied from beyond the boundaries of a single routed hop, the potential scope for attack upon either of the (client or server) MIIS entities is Internet-wide. Discovery of the information server is implied as a requirement in providing information services over upper-layer protocols. Where the server is indicated through link-layer signalling, the robustness of the discovery mechanism is largely based on the security of the existing link-layer signaling mechanisms. Where the server discovery is performed over IP, special care needs to be taken to ensure that discovery may not be hijacked, especially since the underlying wireless medium may in some cases be considered vulnerable to such attack. Attacks upon these services may prevent one or more devices being unable to receive handover related information. As such this may cause degradation in handover performance. 7.2 Attacks against information Attacks against the information exchanged between the information service and the information client may potentially modify the behaviour and trust of the client protocol stack. Daley & Faccin Expires December 30, 2005 [Page 13] Internet-Draft Some Requirements for an MIIS June 2005 Where the integrity and origin of the information delivered to the client is not verifiable, the value of the information is degraded, as hosts are less able to rely upon the data received. Where the client's request is spoofed or modified, additional information may be sent to the MIHF on the client. As the client is typically upon a lower bandwidth medium than the server, there exists potential to deny service to devices on that medium. Systems which ensure proofs of identity and message integrity may be able to remove or mitigate some of these effects, by ensuring that data arrives as intended back to the client. It may be difficult, though, to bootstrap some types of security association considering a potential lack of keying material, computation and network bandwidth resources from mobile devices. 8. References 8.1 Normative References [1] "IEEE 802.21 Media Independent Handover Services Joint Harmonized Contribution", IEEE LAN/MAN Draft 21-05-0271-00- 0000-One_Proposal_Draft_Text, May 2005. 8.2 Informative References [2] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [3] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [4] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [5] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. [6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [7] Williams, M., "Directions in Media Independent Handover", IEICE Transactions on Fundamentals Special Section on Multi- dimensional Mobile Information Networks, July 2005. [8] Brickley, D. and R. Guha, "RDF Vocabulary Description Language 1.0: RDF Schema", W3C Recommendation http://www.w3.org/TR/rdf-schema, February 2004. Daley & Faccin Expires December 30, 2005 [Page 14] Internet-Draft Some Requirements for an MIIS June 2005 [9] Prudhommeaux, E. and A. Seaborne, "SPARQL Query Language for RDF", W3C Working Draft http://www.w3.org/TR/2004/WD-rdf-sparql-query-20041012, October 2004. Authors' Addresses Greg Daley Centre for Telecommunications and Information Engineering Department of Electrical and Computer Systems Engineering Monash University Clayton, Victoria 3800 Australia Phone: +61 3 9905 4655 Email: greg.daley@eng.monash.edu.au Stefano Faccin Nokia 6000 Connection Dr Irving, TX 75229 USA Phone: +1 973 894 5000 Email: stefano.faccin@nokia.com Appendix A. Relevant Statements in 802.21 Working Document S 5.1.4: ... it is necessary that 802.21 defines the network information and specifies the means by which such information can be obtained for supported access networks and made available to the upper layers. S 5.1.4: The network information could include information about link type, link identifier, link availability, link quality, etc. S 5.1.8: facilitated by providing ... timely information about overlay micro-cells and macro-cells. S 5.1.9: Media Independent Information Service (MIIS) which provides details on the characteristics and services provided by the serving and surrounding networks. The information enables effective system access and effective handover decisions. Daley & Faccin Expires December 30, 2005 [Page 15] Internet-Draft Some Requirements for an MIIS June 2005 S 5.4: The interaction with ... Information service will be through synchronous query and response type of mechanisms. S 5.4.3: MIIS primarily provides a set of information elements (IEs), the information structure and its representation and a query/ response type of mechanism for information transfer. S 5.4.3: This (note: MIIS Query/Response) contrasts with the asynchronous push model of information transfer for the event service. S 5.4.3: The information may be stored within the (note: local or peer L2) MIH functional (MIHF) entity or maybe present in some information server from where the MIH in the station can access it. S 5.4.3: The information can be made available via both lower as well as higher layers. Information can be made available at L2 through both a secure and an insecure port. S 5.4.3: Information available through insecure port would typically be less sensitive and would allow the mobile terminal to make a quick handover decision before incurring the overhead of authentication and establishing a secure L2 connection with the network. S 5.4.3: In certain scenarios L2 information may not be available or sufficient to make intelligent handover decision. In such cases, higher layer information service is required. S 5.4.3: The capability of such network information service can be obtained via schema access. The structure and definition of a schema can be represented in a high level language such as XML. S 5.4.3: While selecting for an appropriate syntax for information exchange it is desired that: * the information exchange should be done fast * the overhead in exchange of information should be as less as possible * the extraction of the information at the terminal should not include high computational complexity Daley & Faccin Expires December 30, 2005 [Page 16] Internet-Draft Some Requirements for an MIIS June 2005 S 5.4.3: The information provided by Information service conforms to structure and semantics specified within 802.21. The Media Independent Information service specifies a common (or media independent) way of representing this information across different technologies by using a standardized format such as XML or ASN.1 S 5.4.3: MIIS provides the ability to access this information about all heterogeneous networks in a geographical area from any single L2 network, depending on how the 802.21 MIIS service is implemented. S 5.4.3: MIIS either relies on existing access media specific transports and security mechanisms or L3 transport and L3 security mechanisms to provide access to the information. S 5.4.3: How this information (IEs?) is developed and deployed in a given L2 network is outside the scope of the standard. S 5.4.3: A media independent neighbor graph may be abstracted obtaining the neighbor reports from media specific technology, however, the generation and maintenance of this media independent neighbor graph is out of scope of 802.21. S 5.4.3: Some networks such as the cellular networks already have an existing means of detecting a list of neighborhood base stations within the vicinity of an area via the broadcast control channel. Other IEEE groups define similar means and supports clients in detecting a list of neighborhood access points within the vicinity of an area via either beaconing, or via broadcast of MAC management messages. S 5.4.3: The Media Independent Information Service (MIIS) provides a unified framework to help the higher layer mobility protocols (HLMP) across the heterogeneous network environment to facilitate the client's discovery and selection of multiple types of networks existing within a geographical area. S 5.4.3: In the larger scope, the macro objective (note: of MIIS) is to help the higher layer mobility protocol to acquire a global view of the heterogeneous networks to facilitate seamless handover when roaming across these networks. S 5.4.3: The Information service also provides access to static information such as neighbor reports. This information helps in network discovery. Daley & Faccin Expires December 30, 2005 [Page 17] Internet-Draft Some Requirements for an MIIS June 2005 S 5.4.3: The service may also provide access to dynamic information which may optimize link layer connectivity with different networks. This could include link layer parameters such as channel information, MAC addresses, security information, etc. Information about available higher layer services in a network may also help in more effective handover decision making before the mobile terminal actually attaches to any particular network. S 5.6.1: MIH_MGMT_SAP This defines the interface between the MIH Function layer and the management plane of different networks. This SAP can be used for sending MIH messages between MIH Function and local link layer entities as well as between peer MIH Function entities. Messages based on management frames can be sent in the unauthenticated state as well. The MIH_MGMT_SAP defines primitives for MIES, MICS and MIIS. S 6.2.1: ... information provided by MIIS is less dynamic or static in nature and is comprised of parameters such as network operators, higher layer service information, etc. MICS and MIIS Information could be used in combination by the terminal/network to facilitate the handover. S 6.3.1: Media Independent Information Service includes support for various Information Elements (IEs). Information Elements provide information that is essential for a handover module to make intelligent handover decision. S 6.3.1: Depending on the type of mobility support for different types of information elements may be necessary for performing handovers. S 6.3.1: ... horizontal handovers across different PoAs of the same access network information available from lower link layers of access network may be sufficient. In such cases information elements like intra-technology neighbor reports and other link layer information required during handovers is directly available from the access network. In such cases the availability of higher layer services offered by the network typically does not change appreciably across different network point of attachments. S 6.3.1: ... vertical handovers the terminal may move across different access networks. In such cases there is a need to select appropriate PoA in the new network based on both optimum link layer connectivity as well as availability of appropriate higher layer services to permit service and session continuity for active user applications Daley & Faccin Expires December 30, 2005 [Page 18] Internet-Draft Some Requirements for an MIIS June 2005 S 6.3.1: Media Independent Information Service (MIIS) provides the capability for obtaining the necessary information for handovers. This includes information about lower layers such as neighbor maps and other link layer parameters as well as information about available higher layer services such as access to internet connectivity, availability of VPN services, etc. S 6.3.1: The set of different higher layer services provided by the MIIS may constantly evolve. At the same time the list of access networks that are supported by MIIS may also evolve. As such there is a need for flexibility and extensibility in the way the MIIS provides support for different information elements. Towards this end the MIIS defines a schema. The schema helps a client of MIIS to discover the capabilities of MIIS and also discover the entire set of different access networks and IEs supported by a particular implementation. S 6.3.1: Schema representation also allows the terminal to query the information in a more flexible and efficient manner. As part of defining this schema the MIIS can also identify a set of basic information elements that can define the core functionality of different implementations of MIIS. Other information elements as they are added can become part of the more extended set of MIIS capabilities. S 6.3.1: MIIS provides information about different access networks such as 802 networks, 3GPP networks and 3GPP2 networks. The MIIS also allows this collective information to be accessed from any single network. Thus for example using a 802.11 access network it may be possible to get information about not only all other 802 networks in a particular region but also that of 3GPP and 3GPP2 networks as well. S 6.3.2: Information Service Elements The information service elements can be classified into three groups: * General Network Information (GNI): These information elements give a general overview of the network like network ID, location of different PoAs of the network, IP version, operator of the network, and so on. * Link Layer Information (LLI): These information elements include the information related to link layer layers such as, link layer parameters (channel, frequency, PHY types), data rates, neighbor information, security, QoS, and so forth. * Higher Layer Information (HLI): These information elements include higher layer services or applications that are Daley & Faccin Expires December 30, 2005 [Page 19] Internet-Draft Some Requirements for an MIIS June 2005 supported by the respective network. Some examples are support for Multimedia Message Service (MMS), Mobile IP (MIP), Virtual Private Network (VPN), types of applications supported (e.g. VoIP, e-mail, IPsec VPNs, streaming media, location based ), pricing of access (e.g. "a fee is be required" versus "access to the network is free"), use of NAT, roaming partners and so forth. S 6.3.2 (Current) GNI List: List of networks available: List all network types that are available given a location or POA information Location of POA: Geographical Location, Civic address, PoA ID Network standards supported: List of all available transmission technologies available Network Identifier: Unique ID of the network or network provider Operator: Name of the network provider IP Version: Indicates the version Internet Protocol used (4 and/or 6) Roaming Partners: List of direct roaming agreements Cost: Indication of costs for service/network usage SLAList: Service level Agreement list S 6.3.2 (Current) LLI List: Neighbor Information: Neighboring network information. measurement reports. Security: Link layer security supported. Technology specific (algorithms) such as WEP/TKIP (802.11/i), PKM (802.16), UEA(3G). (Security services): Authentication, Encryption Modes, Encryption Algorithm, Key Provisioning, Key Management. Quality of Service: Link QoS parameters: BER, SNR, DataRateKbps, MinLatencyMsec, MaxLatencyMsec, MaxJitterMsec AccessRouterInfo: AccessRouter Address(es??), IP Version, MobilityProtocolSupport, FASupport Daley & Faccin Expires December 30, 2005 [Page 20] Internet-Draft Some Requirements for an MIIS June 2005 S 6.3.2 (Current) HLSI List: IMS Access: (MMS, SMS, Presence, Instant Message, Push-to- Talk,...) Indication whether specific service is supported or not. ISP Supported Internet Service Provider that provides the access to internet Location based services List of Local services that are available given a location VPN Supported Network enables VPN services MIP Supported Network enables(sic) MIP version and services Use of NAT Notification that NAT is used for internet access S 6.3.2: ... MIHF entity (e.g., a STA or network entity) can extract this basic IE either from media specific broadcast information or by sending a specific request/response primitive. On the other hand, before sending a request/response, the MIHF entity should have the knowledge that the network supports the 802.21 MIH standard ... S 6.3.3: The 802.21 information service defines the various information elements and their structure. The various IEs represent information about lower layers of network stack as well as about higher layer services available in different access networks. S 6.3.3: A schema is defined by a language and can be represented in multiple ways. Examples include Resource Description Framework (RDF) which is based on XML, ASN.1 which is used in 802 MIBs, Variants or a simple TLV representation of different information elements. S 6.3.3: The MIIS schema is classified into two major categories: Basic schema that is essential for every MIH to support and Extended schema that is optional and can be vendor specific. S 7.4.14.1: MIH_Information.request This primitive is used by a station's MIH (or an application on behalf of MIH) to request information either from the network or from a remote MIH. The information query can be related to a specific interface, attributes to the network interface as well as entire network capability. In other words, the service primitive Daley & Faccin Expires December 30, 2005 [Page 21] Internet-Draft Some Requirements for an MIIS June 2005 will have the flexibility to query either a specific data within a network interface or extended schema of a given network. The network interface is not explicitly specified in the primitive, but is rather implicitly selected based on the specific MIH_MGMT SAP that is selected. S 7.4.14.1: Examples: 1. If a client is interested in getting information about all the elements of a network, it sends the following request after getting associated to the network: MIH_Information.request (FILTER_INFO_ALL_ELEMENTS) Depending on the amount of information available, the response could be big data flow. 2. If a client is interested to know whether VPN is supported by the network of interest, he could send following request: MIH_Information.request (FILTER_INFO_VPN_SUPPORT) In this case the response could be quite simple, .Yes. or .No.. 3. If a client is interested to know whether EAP support is enabled by a network, the request could be as follows: MIH_Information.request (FILTER_INFO_ELEMENT_SECURITY,EAP) In this case too the response could be quite simple: Yes or No S 9.4.2: Information Service based amendments Many media specific essential information elements have been identified. These need to be supported in the access network specific standard. Information elements specific to 802.11 access network need to be supported in the base specification as well. S 9.4.3.1.3: Extension of Network Control and Management System (NCMS) (802.16) NCMS is required to be extended to support MIH event services, command services, and information services. When NCMS in terminal or BS interfaces with MIH Function layer, NCMS may provide means for MIH Function layer to interface with management plane in MS or BS. Daley & Faccin Expires December 30, 2005 [Page 22] Internet-Draft Some Requirements for an MIIS June 2005 9.4.3.2.1: Overview of MIH Capability Delivery There are two ways for MS to obtain MIH Capability of IEEE 802.16 BSs. One is the method of Pre-acquisition before handover, and the other is the method of Post-acquisition after handover. Daley & Faccin Expires December 30, 2005 [Page 23] Internet-Draft Some Requirements for an MIIS June 2005 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 (2005). 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. Daley & Faccin Expires December 30, 2005 [Page 24]