MIPSHOP E. Hepworth Internet-Draft R. Hancock Expires: December 21, 2006 Roke S. Sreemanthula Nokia Research Center S. Faccin Intel Corporation June 19, 2006 Design Considerations for the Common MIH Protocol Functions draft-hepworth-mipshop-mih-design-considerations-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 21, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The MIPSHOP working group is currently developing functionality to support media independent handover services, which are intended to aid IP handover mechanisms between heterogeneous wired and wireless access systems. These handover services provide a mechanism by which Hepworth, et al. Expires December 21, 2006 [Page 1] Internet-Draft MIH Design Considerations June 2006 information such as the presence of neighbouring links and networks, and their associated characteristics, can be delivered to mobile and other network nodes for the purposes of supporting better handover decisions. A key component of the solution is the protocols that are used to deliver the various types of information to the appropriate destination node. A separate problem statement draft outlines a structure for this set of protocols as a unified set of common functions, supporting a more diverse set of application specific protocols. This draft outlines the key considerations that have to be considered when selecting or designing protocols for such common functionality. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Inter-layer Interactions . . . . . . . . . . . . . . . . . . . 4 3. Protocol Design Considerations . . . . . . . . . . . . . . . . 5 3.1. Discovery and Routing . . . . . . . . . . . . . . . . . . 5 3.2. Message Transport . . . . . . . . . . . . . . . . . . . . 7 3.3. State Management . . . . . . . . . . . . . . . . . . . . . 9 3.4. Mutiplexing and Extensibility . . . . . . . . . . . . . . 10 3.5. Network Layer Interactions . . . . . . . . . . . . . . . . 10 3.6. Message Security . . . . . . . . . . . . . . . . . . . . . 11 3.7. Overload Management . . . . . . . . . . . . . . . . . . . 12 3.8. Failure Handling . . . . . . . . . . . . . . . . . . . . . 13 4. Security Considerations . . . . . . . . . . . . . . . . . . . 14 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 14 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . . . 18 Hepworth, et al. Expires December 21, 2006 [Page 2] Internet-Draft MIH Design Considerations June 2006 1. Introduction The MIPSHOP working group is currently developing functionality to support media independent handover services, which are intended to aid IP handover mechanisms between heterogeneous access systems, both wired and wireless. These handover services provide a mechanism by which information such as the presence of neighbouring links and networks, and their associated characteristics, can be delivered to mobile and other network nodes for the purposes of supporting better handover decisions. An initial set of handover services, and the information that these services exchange between two peers, is under development within IEEE 802.21. These services are referred to as the Media Independent Handover Services (MIH Services) and the initial set consists of the event, command and information services (ES, CS and IS). The transport security and related aspects associated with delivery of these messages across the network at the IP level (including over the air where direct layer 2 transport is not being used) will not be addressed by IEEE 802.21. It is the expectation that this area will be addressed by the MIPSHOP working group. An architectural framework and set of common requirements is proposed in the problem statement draft [1], which includes a decomposition of the overall MIH problem into a common part and a set of MIH services that are layered over the top. It is intended that the common part is suitable not only for the delivery of IEEE 802.21 MIH services (ES/CS/IS), but can also be applied to non-802.21 architectures and handover services. This draft outlines detailed design considerations for the common part delivery mechanism, with the goal of providing a basis for discussing different solutions and providing a means to ensure that important solution requirements are considered by subsequent proposals. This draft is not intended as a comprehensive analysis of different solutions, but does include some discussion of solution characteristics and possible solution options as examples where appropriate. It is assumed that the requirements on the common part imposed by the IEEE 802.21 MIH services are wholly captured in the problem statement draft [1]. The structure of this document is as follows. Section 2 introduces some general design goals for the common part, Section 3 describes a set of design considerations that should be taken into account when developing a solution, Section 4 provides security considerations, and Section 5 summarises the conclusions and open issues. Hepworth, et al. Expires December 21, 2006 [Page 3] Internet-Draft MIH Design Considerations June 2006 2. Inter-layer Interactions The framework presented in [1] decomposes the MIH protocol problem into two parts; the Information and Information Exchange mechanism, and the functionality common to all MIH services. This is subsequently referred to as common protocol functionality. The intention of the separation is to allow all MIH services access to this functionality from a single protocol module without having to re-implement or re-integrate the same functionality individually for each MIH service. The problem statement presents an outline of this decomposition; however, the precise details of the split of functionality and interaction between the layers need to be refined as the design of the common part proceeds. Indeed, one important design consideration is that it should be possible to define these interactions precisely and in an easily implementable manner. This section indicates some specific inter-layer interaction issues that need to be taken into account in this way. One of the key questions is how MIH service peer identity knowledge is split between the service and the common part. In other words, does the MIH service have knowledge about the location of a peer (in terms of IP address), or does it simply pass a message to the common protocol functionality and expect it to be delivered. If the MIH service manages the resolution of peer identities to IP addresses, issues such as NAT traversal can become more complicated (as discussed in Section 3.5). It is assumed that the peer entities supporting an MIH service hold some sort of state information that is being accessed or updated in some way. So, a second issue is whether there is any relationship between the management of this state lifetime and the common protocol functionality. This draft assumes that service layer state lifetime is transparent to the common protocol functionality, and operations such as soft state refresh are not explicitly visible at the lower level. However, note that the common protocol functionality can be used to transmit refresh messages generated by an MIH service if such a refresh mechanism is required, but the generation and timing of these messages is the responsibility of the MIH service. In the overall problem description it can be seen that some signalling transactions involve a sequence of three or more nodes rather than a simple peer to peer communication. There is therefore a question of whether the common protocol functionality should be explicitly aware of the complete chain of nodes involved in a transaction, or whether it should see only the directly adjacent peers. In this draft, we assume the latter case; therefore, the concatenation of message exchanges along a sequence of nodes is something that has to be managed within the MIH service itself. Hepworth, et al. Expires December 21, 2006 [Page 4] Internet-Draft MIH Design Considerations June 2006 In the long term, in order to make the inter-layer separation precise, a service interface between the MIH service and the common protocol functionality should be defined. This service interface would expose a set of functionality that can be used by the MIH service to discover and send messages to peer entities, and could allow the common protocol functionality to be configured to suit particular needs associated with an MIH service, for example, reliable versus fast delivery. 3. Protocol Design Considerations There are a number of key considerations that should be considered when designing a solution to support MIH message delivery. These are described in the following subsections. 3.1. Discovery and Routing When an MN joins a network, it must be able to discover various network nodes that support the MIH services that it wishes to use. The location of the MIH services in the network is not fixed. Some may be supported locally by the access network, whilst others may be supported by a node deeper in the network, or a sequence of such nodes. The sequence may reach back all the way to the user's home network. The process of discovering a suitable peer and establishing a route towards it has a number of aspects that need to be considered. The first of these is how MIH services are identified. For an MN interested in a particular MIH service, the identity of the service must be usable in some discovery and name resolution procedure that ultimately returns an IP address to the interested MN. Therefore, the name space within which MIH services are identified has an interaction with the set of possible discovery mechanisms. For example, use of a particular discovery procedure may require extensions to support a new namespace or new registrations within an existing one. The selection of a suitable peer and its subsequent use may be based on a number of aspects including the capabilties of the MIH peer and the ability to setup a secure communications channel to that device. Therefore, the discovery process has interactions with other transport layer functionality, which may need to be considered as part of the discovery procedure itself. In the simplest case, the selection of an appropriate peer can be left entirely to the network, based purely on the service identifier. Where the MIH service is entirely implemented in the local access network, this is probably sufficient. In such a scenario, the MN could send a query to the network requesting support for a particular Hepworth, et al. Expires December 21, 2006 [Page 5] Internet-Draft MIH Design Considerations June 2006 MIH service, and allow the network to select the most appropriate MIH peer. Some options for this are discussed below. More sophisticated services may require interactions further into the network, for example involving the user's home operator; this would be an example of "proxy operation". This may be influenced by configuration information provided by the MN, such as operator identity. There are two basic approaches that can be considered: o a simple method, especially from the MN perspective, is to treat this as a generalisation of the basic case where the discovery process is repeated recursively along the proxy chain. o a more complex method is to require the MN to discover the complete set of nodes up to and including the signalling endpoint. This gives more control over the process to the MN at the cost of having to expose more details about inter-network relationships. The discovery and routing functionality could either be invoked directly by the MIH service, or could be integrated with the common protocol functionality. In the former case, the MIH service would be responsible for carrying out the discovery exchange with the network, and would have to indicate the results of the discovery procedure to the common part to allow delivery of mesasges to the appropriate peer. In the latter case, the MIH service would simply request the delivery of a message from the common protocol functionality, and leave the discovery and resolution procedures to the lower layers. Either approach is feasible, but the following issues should be considered when designing a solution: o support for discovery before full IP connectivity. In some cases, the MN may want to communicate with an MIH service before full IP connectivity is available. o transparency of the network topology. The internal structure of the network should be hidden from the MIH service, which allows arbitrary network deployments, and changes to those deployments without impacting the MIH service. o localisation of information. The information associated with supporting a particular MIH service should be located in as few places as possible to aid failure recovery, and reduce requirements on MNs to hold large amounts of state information. o elimination of duplicates and reduction of round trips. To reduce latency and network load, the required information should be discovered using as few signalling messages as possible both in the initial discovery case and post handoff where it is necessary Hepworth, et al. Expires December 21, 2006 [Page 6] Internet-Draft MIH Design Considerations June 2006 to check that the signalling relationships are still valid. For example, if a peer for a particular MIH service has already been discovered that can be used for an alternative MIH service as well, it would be preferable to avoid performing a duplicate discovery procedure when the information is already known. o adaptation of the discovery mechanisms. Some approaches to discovery may be particularly applicable to specific technologies or in particular administrative environments and therefore a single perfect solution may not be attainable. However, it is important to localise the impact of this variability as much as possible. Given the above considerations, it seems likely that the most appropriate place to implement the discovery and routing functionality is as part of the common protocol functionality. It is possible that the discovery process could be bootstrapped from other protocol state or protocol exchanges, but the suitability of these approaches and the architectural assumptions associated with their use needed to be assessed. For example, DHCP [3][4] is a possible candidate, but would only be most suitable for link technoloiges where this is used as an address assignment method. Another possibility is SLP [5], although this is not curently widely deployed; mDNS [2] falls into the same category. DNS itself can also be used (for example, SRV records [6] support the discovery process for services associated with a particular DNS domain), however, it is difficult to use them to do service discovery in a way that automatically takes into account the current network point of attachment. Router level advertisements are also an option, but the mechanism may be hard to extend to support advertisement of all MIH services, so this would be mainly to provide bootstrap to some other approach. 3.2. Message Transport Message transport is responsible for the actual delivery of messages between peer entities, and should be configurable to suit the needs of the particular MIH service, for example, reliable versus expedited delivery. Note that it is not assumed that a single instance of the common protocol functions has to be configured and used in exactly the same way by all the MIH services at any given node. Different services might request different levels of transport support; indeed, a service might request different transport characteristics for different transaction types. The main transport considerations include: Hepworth, et al. Expires December 21, 2006 [Page 7] Internet-Draft MIH Design Considerations June 2006 Congestion Avoidance: some form of congestion control is required to guarantee that MIH service operation cannot damage the network. This is particularly critical for services that may transport large volumes of data. Congestion control could either be provided in a specialised way as part of a custom transport protocol directly over IP, or provided through the use of an existing protocol such as TCP or SCTP. In the latter case, standard transport parameter estimation algorithms may need to be assessed in order to work out their suitability for different MIH services. It is assumed that the various MIH services do not have specialised requirements for congestion handling. Reliability: some MIH services require reliable delivery of their messages and this has to be achieved efficiently in an environment (i.e. mobile/wireless) where data transfer latency can be highly variable between different technology types and data loss may be high. This reliability can either be implemented within the MIH services themselves or provided by the common transport. While implementation within the MIH service is technically possible, it does not make best use of the sophistication that has been achieved in transport layer optimisation in recent years. For example, a full implementation would need to consider functionality such as windowing, adaptive retransmission timeouts and loss detection mechanisms, which are non-trivial to design. In addition, relying on the service layer to handle all reliability issues opens the question of whether timer values should be based on message transfer latency or application processing latency, and these two can differ significantly. Allowing the option of a reliable transport service means that the additional recovery mechanisms within the service layer can be made very simple and robust because they do not need to be optimised for efficient recovery of message loss within the network. Fragmentation: the transport protocol must be capable of performing fragmentation when the amount of data in a message to be sent is too big to fit into a single IP packet. IP fragmentation could be used, but would require Path MTU discovery procedures to be supported, unless very conservative path MTU estimates could be assumed by default. However, note that fragmentation at the IP layer amplifies packet loss rates because the loss of a single fragment destroys the entire packet, and also the entire packet has to be retransmitted. Therefore, it is preferable to support the fragmentation requirements within a reliable transport. Hepworth, et al. Expires December 21, 2006 [Page 8] Internet-Draft MIH Design Considerations June 2006 Re-ordering and Head of Line Blocking: depending on the lower layer in use, messages may arrive out of order. If the transport does not provide in order delivery, it will be the responsibility of the MIH services themselves to handle this problem. In addition, head of line blocking may be an issue in cases where multiple MIH services are using a single connection between two peer entities. Duplicate Message Detection: multiple copies of a message may arrive at a node. Does the transport layer provide duplicate message detection, or is this left up to the MIH service? 3.3. State Management The operation of the MIH services requires the existence of state within the network, for example, registrations of interest for particular types of events or location information to configure the delivery of neighbourhood lists. Various transaction models can be identified that allow different entities to initiate an MIH message exchange to set up such state. The transaction sequences that are permitted to install and manipulate this state will most likely be MIH specific (it is unlikely that a single transaction model will be applicable to all MIH services), but even so there will be impacts on the common protocol functionality, for example, influencing the symmetry required in the message delivery mechanism. In addition, the dependency of one set of MIH transactions on another has to be considered, for example, can transactions be nested, or can they overlap with each other. Example transaction sequences include: 1. MN initiated only; where exchanges can only be initiated by the MN, and the network only responds to explicit requests for information. 2. MN and NN intiated; where both the MN can request information, and the NN can deliver information asynchronously to the MN. The current MIH services that have been identified require MN and NN initiated exchanges as a minimum. The types of state information that are manipulated during an MIH exchange includes: o MIH Service State: information related to the particular MIH service, that is accessed and maintained by that service. o Peer State: including peer capabilities, and any negotiated parameters. Hepworth, et al. Expires December 21, 2006 [Page 9] Internet-Draft MIH Design Considerations June 2006 o Routing State: such as next hop information for routing to a peer entity. o Security State: associated with a particular message exchange The first type of state is MIH service specific, and should be transparent to the common protocol functionality. The latter three types could be managed by either the MIH service or the common protocol functionality, although the latter option seems preferable (as will be discussed in Section 3.1 and Section 3.6). A fundamental question that has to be considered is how these different types of state information are related to each other. For example, if a connection to a peer entity is lost, is the MIH service state now considered to be invalid? 3.4. Mutiplexing and Extensibility Multiple MIH services have already been defined, and it is highly likely that different MIH services will be co-located within single nodes (this will definitely be true of the MN, and may be true for infrastructure nodes depending on the MIH deployment). A consideration that needs to be addressed is how multiple MIH services are handled by the common protocol functionality. One option would be to hide the presence of multiple MIH services completely. However, this would limit the ability of a node to talk to different MIH peers depending on which service is being used, if the discovery is handled as part of the common protocol functionality. An alternative is to expose the multiple MIH services individually to the common protocol functionality, and allow it to multiplex MIH service messages at the transport level if appropriate (for example, if both messages are destined for the same peer entity and have the same transport requirements). In addition, the extensibility of the MIH services needs to be considered. For example, if multiple versions of an MIH service are available, this may impact the common protocol functionality in terms of discovery of compatible MIH service implementations (see Section 3.1). 3.5. Network Layer Interactions The MIH functionality interacts with the network layer in two distinct ways. Firstly, the signalling messages must be able to pass through the network between signalling peers even when the network infrastructure contains addressing boundaries and firewalls where policies on Hepworth, et al. Expires December 21, 2006 [Page 10] Internet-Draft MIH Design Considerations June 2006 allowed traffic types are imposed. Therefore, it is important to limit the protocols used to support the common functionality as far as possible to those that such middlebox devices can be configured to process and support. For example, standard transport protocols such as TCP or UDP are relatively easy to deploy especially if transactions are initiated from the internal side of the middlebox whereas ICMP extensions are much more problematic. Secondly, if some parts of the MIH service payload contain addressing information, such as the current IP address associated with a device or addresses of other access routers, NAT traversal becomes much more difficult as the NAT may have to change these payloads. It is preferable to standardise the location of such information across all the different MIH services so that NATs do not have to support different Application Layer Gateways for each and every MIH service that has been or will be defined. This suggests that addressing information should be carried at the lowest possible level in the MIH protocol stack. 3.6. Message Security Message security is needed to protect the information exchanges between MIH service peers. This section focusses on authentication and authorisation aspects associated with MIH service support; DoS and overload situations are considered in Section 3.7. It is highly desirable to reuse standard channel security protocols, but there are still several possible protocol choices. There are a number of considerations: Authentication and Key Management: authentication can either be performed unilaterally, where only one party confirms the identity of the other, or mutually, where both parties confirm each other's identity. For some MIH services, it is important that mutual authentication is possible, since the information exchanged initiates complex processing in both peers. Although this does not necessarilty imply that the MIH service must perform the authentication itself, it may still be important for the service to be aware of the authenticated identity of the peer it is communicating with. Because standard channel security protocols necessarily include peer authentication to provide keying material, it is natural to think of the authentication functionality as being part of the common protocol functionality. Credential Reuse message security depends on the existence of credentials to identify the peers taking part in the signalling exchange; the credentials are used in the protocols to provide node authentication and keying material for message protection Hepworth, et al. Expires December 21, 2006 [Page 11] Internet-Draft MIH Design Considerations June 2006 itself. Different protocols can exploit different credential types and so it may be possible to select protocols in order to build on existing relationships in the network. Authorisation: authorisation controls who is allowed to perform what actions on state information and message exchanges between MIH peers. It may also be possible to build MIH trust models that reuse existing relationships in the network, for example, if an MIH service is provided locally by an access network to an MN, the fact that the information is being relayed by a trusted AP may indicate to the MN that the information is from a valid source. In cases where the MIH service is provided by an operator deeper in the network, roaming relationships could be re-used to support delivery of MIH information. However, in this draft we assume that the authorisation problem is handled primarily within the MIH services themselves. Privacy: various identifiers will be used by the MIH service and the common protocol functionality to support authentication, peer discovery and message delivery. These identifiers will relate in some cases to users and organisations whose privacy needs to be respected and whose identity should not be freely disclosed except to authorised parties. Therefore, any security solution needs to consider how such identifier information is protected. The visibility that the MIH service has of the security functionality also needs to be thought about. One extreme would be for the MIH service to be responsible for setting up the secure channel over which to communicate, but this may require the MIH service to have more knowledge about the underlying network topology than is otherwise necessary. Alternatively, the common protocol functionality can include the security aspects, and the MIH service can request a secure channel from the lower layers when establishing a relationship with an MIH peer based on some MIH specific security policy. This has the added advantage that different security protocols can more easily be integrated into the MIH protocol suite (once into the common part, as opposed to once for every MIH service). 3.7. Overload Management Overload management handles situations where a node is flooded with messages. These situations can occur both during normal use, or as a result of a flooding attack by a malicious user. In either case, the common protocol functionality has a role to play in handling such situations needs to be considered, because these problems are closely associated with the message security and congestion control aspects. In particular, it is important that overload situations are Hepworth, et al. Expires December 21, 2006 [Page 12] Internet-Draft MIH Design Considerations June 2006 considered for the design of the common protocol functionality as it is impossible to support reliability without overload management strategies in place. The overload issue is related to processing within a node when it starts to receive messages faster than it can process them, and what facilities are provided within the common protocol functionality and MIH service to handle these situations. In addition, nodes should also detect that a peer is overloaded, and try and mitigate the situation somehow. One solution is to provide some rate control either at the MIH service, in the common protocol functionality or both. The common protocol functionality cannot entirely solve this problem because the adaptation to overload situations may be MIH service specific. However, the overload situation can be detected and indicated to the MIH service. It may be necessary to provide one or more signalling channels to cope with different message priorities in this case. Some elements of the common functionality must operate even in the absense of a congestion or flow-controlled transport connection, such as the initial discovery process. Typically their design must incorporate some sort of robust overload management mechanism, such as exponential backoff. If a standard discovery protocol (like DHCP) is being used, this behaviour is built in. 3.8. Failure Handling Nodes may fail at any time, and some mechanism is needed to allow graceful recovery. Failure situations include: o inability to discover a peer - this is related to discovery and routing Section 3.1. o the loss of a peer, which must be detected. o local shutdown, and informing current peer nodes. As for overload management, the common protocol functionality cannot be solely responsible for addressing this issue since some failure conditions will affect only the MIH service and not the lower communications layers. Also, the recovery procedure will be partly application specific. However, other failure conditions can be detected more rapidly and efficiently at lower layers of the protocol stack; for example, rather than implementing a keepalive mechanism within each MIH service, a single mechanism at the lower level can be used to check the overall status of a given node. Therefore, the MIH service must be partially responsible for detecting the loss of an MIH peer, but may use hints provided by the common protocol functionality to speed up the detection process. Hepworth, et al. Expires December 21, 2006 [Page 13] Internet-Draft MIH Design Considerations June 2006 For local shutdown cases, it should be the responsibility of the MIH services to inform peer nodes of the situation. 4. Security Considerations When developing a solution for supporting the exchange of MIH service information between two peer devices, there are a number of security issues that need to be taken into account. The discovery and information exchange may occur in situations where full IP connectivity is unavailable. In this case, the secure transport cannot be provided end-to-end, but could potentially be provided between a proxy device and the peer MIH, for example, between an access router and appropriate server. The trust model and security implications of supporting this mode of operation needs to be investigated. In the alternative scenario with end-to-end IP connectivity, the security issues are slightly simpler though securing the discovery remains an issue. The co-existence of the security mechanisms for the full and partial IP connecivity will need to be considered. The effect of Denial of Service attacks also needs to be managed, for example, by reacting to overload situations (see Section 3.7). State information is installed in nodes for both transport and MIH service purposes, and the processing associated with installing or managing this state by nodes in the network should be kept to a minimum prior to secure channel setup. The identifier space that is used to support authentication, and how privacy is managed for these identities is also a key concern. The use of these identifiers to support authorisation needs to be analysed, and these issues are discussed in more detail in section Section 3.6. It is currently assumed that the common protocol functionality must provide message (channel) security for the MIH services to support message integrity/authentication. 5. Conclusions This Internet Draft outlined a number of design considerations that need to be taken into account when developing the common functionality required by MIH services to exchange information between peers. The main issue that needs to be considered is how to split reponsibility for various parts of the functionality between the MIH service and the common protocol part. There is good justification for supporting certain aspects of the Hepworth, et al. Expires December 21, 2006 [Page 14] Internet-Draft MIH Design Considerations June 2006 required functionality in a common part that can be used by multiple MIH services. This independence provides a way to hide the specifics of a particular network from the MIH service, prevents the same functionality being re-implemented multiple times, and supports easier integration of new or enhanced protocols into the overall MIH solution. However, it is also possible that different MIH services will ultimately have slightly different requirements from the underlying transport, depending both on the type of information managed by the MIH service, and the particular message that is being exchanged. Therefore, it is important that the transport mode used for particular message exchanges can be configured in some way by the MIH service to suit its requirements. It should also be noted that the common protocol functionality cannot be wholly responsible for providing some aspects of the solution, for example, reliability and overload management requires support at both the lower layer, where information about network conditions is readily available, and at the MIH service itself, where specific information about the state managed by the service and the strategies to react to certain conditions is maintained. In terms of the protocols used by the common part, it is clear that a single protocol will not be sufficient to meet all identified requirements. Therefore, it is likely that the common part will in fact be implemented as multiple protocols that are integrated below a simple service interface exposed to the MIH services above. 6. References [1] Hepworth, E., "Media Independent Handovers: Problem Statement", draft-hepworth-mipshop-mih-problem-statement-01 (work in progress), March 2006. [2] Cheshire, S. and M. Krochmal, "Multicast DNS", draft-cheshire-dnsext-multicastdns-05 (work in progress), July 2005. [3] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [4] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [5] Guttman, E., Perkins, C., Veizades, J., and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999. Hepworth, et al. Expires December 21, 2006 [Page 15] Internet-Draft MIH Design Considerations June 2006 [6] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. Appendix A. Acknowledgements Thanks to Andrew McDonald for his inputs. Eleanor Hepworth and Robert Hancock are partly funded by Ambient Networks, a research project supported by the European Commission under its Sixth Framework Program. The views and conclusions contained herein are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements, either expressed or implied, of the Ambient Networks project or the European Commission. Hepworth, et al. Expires December 21, 2006 [Page 16] Internet-Draft MIH Design Considerations June 2006 Authors' Addresses Eleanor Hepworth Roke Manor Research Ltd Roke Manor Romsey, SO51 0ZN Email: eleanor.hepworth@roke.co.uk Robert Hancock Roke Manor Research Ltd Roke Manor Romsey, SO51 0ZN Email: robert.hancock@roke.co.uk Srinivas Sreemanthula Nokia Research Center 6000 Connection Dr. Irving, TX 75028 USA Email: srinivas.sreemanthula@nokia.com Stefano Faccin Intel Corporation Santa Clara, CA USA Email: stefano.m.faccin@intel.com Hepworth, et al. Expires December 21, 2006 [Page 17] Internet-Draft MIH Design Considerations June 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. Hepworth, et al. Expires December 21, 2006 [Page 18]