Internet DRAFT - draft-hepworth-mipshop-mih-design-considerations


MIPSHOP                                                      E. Hepworth
Internet-Draft                                                R. Hancock
Intended status: Informational                                      Roke
Expires: April 26, 2007                                  S. Sreemanthula
                                                   Nokia Research Center
                                                               S. Faccin
                                                       Intel Corporation
                                                        October 23, 2006

      Design Considerations for the Common MIH Protocol Functions

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on April 26, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).


   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 April 26, 2007                 [Page 1]
Internet-Draft          MIH Design Considerations           October 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 set of protocols
   that is 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.  This draft is offered for use as a mechanism
   to capture working group discussions on the design of the common
   protocol functions during their initial development, without imposing
   a particular solution on the discussion process.  It is not intended
   as a long term output.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Inter-layer Interactions . . . . . . . . . . . . . . . . . . .  4
   3.  Protocol Design Considerations . . . . . . . . . . . . . . . .  5
     3.1.  Initial Discovery and Routing  . . . . . . . . . . . . . .  5
     3.2.  Signalling Peer Changes  . . . . . . . . . . . . . . . . .  8
     3.3.  Message Transport  . . . . . . . . . . . . . . . . . . . .  9
     3.4.  State Management . . . . . . . . . . . . . . . . . . . . . 10
     3.5.  Mutiplexing and Extensibility  . . . . . . . . . . . . . . 12
     3.6.  Network Layer Interactions . . . . . . . . . . . . . . . . 12
     3.7.  Message Security . . . . . . . . . . . . . . . . . . . . . 13
     3.8.  Overload Management  . . . . . . . . . . . . . . . . . . . 14
     3.9.  Failure Handling . . . . . . . . . . . . . . . . . . . . . 15
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
   5.  Conclusions  . . . . . . . . . . . . . . . . . . . . . . . . . 16
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
   Appendix A.  Acknowledgements  . . . . . . . . . . . . . . . . . . 17
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
   Intellectual Property and Copyright Statements . . . . . . . . . . 19

Hepworth, et al.         Expires April 26, 2007                 [Page 2]
Internet-Draft          MIH Design Considerations           October 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); there are also System Management messages which
   configure the operation of the other MIH protocols themselves.  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].  This draft is offered for use as a
   mechanism to capture working group discussions on the design of the
   common protocol functions during their initial development, without
   imposing a particular solution on the discussion process.  It is not
   intended as a long term output.

   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

Hepworth, et al.         Expires April 26, 2007                 [Page 3]
Internet-Draft          MIH Design Considerations           October 2006

   developing a solution, Section 4 provides security considerations,
   and Section 5 summarises the conclusions and open issues.

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.6).

   It is assumed that the peer entities supporting an MIH service hold
   some sort of service layer state information (such as link
   measurements or event subscriptions) 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

Hepworth, et al.         Expires April 26, 2007                 [Page 4]
Internet-Draft          MIH Design Considerations           October 2006

   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; it
   may even be an implementation issue for the MIH services, in the same
   way that chains of SIP signalling nodes can be built up out of back-
   to-back user agents.

   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.

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.  Initial 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

   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

Hepworth, et al.         Expires April 26, 2007                 [Page 5]
Internet-Draft          MIH Design Considerations           October 2006

   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
   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.

   A particular issue is the precision with which the initial discovery
   process takes place.  One possibility is that the initial discovery
   detects a candidate set of nodes supporting any MIH services;
   subsequently, messages within the MIH protocols themselves determine
   the detailed capabilities of each node, and decide which nodes to use
   for which specific purpose.  The alternative is that the initial
   discovery process incorporates these selection criteria directly,
   which allows a more targeted discovery of the initial candidate set,
   at the cost of requiring a richer definition of the set of possible
   service at the layer boundary between the MIH services and the common
   protocol functions.  The first approach is simplest and may be
   appropriate in limited scale networks (or where the equivalent
   functionality is being developed at Layer 2).  However, it can easily
   lead to scaling difficulties in larger scale networks, where, even
   though the final set of communicating nodes may be small, the size of
   the candidate set could be very large.  Therefore, the ability of the
   initial discovery criteria to include such additional criteria needs
   to be considered.  The openness in this question is reflected in the
   openness of the term 'MIH service'; in the 802.21 context for
   example, it could refer either to the complete set of 802.21 MIH
   services, or to a specific one, such as IS.  This issue affects

Hepworth, et al.         Expires April 26, 2007                 [Page 6]
Internet-Draft          MIH Design Considerations           October 2006

   primarily the discovery process; for the rest of this document, we
   continue to use the term MIH service, always bearing in mind this
   spectrum of possibilities for what it could refer to.

   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
      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

   Given the above considerations, it seems likely that the most

Hepworth, et al.         Expires April 26, 2007                 [Page 7]
Internet-Draft          MIH Design Considerations           October 2006

   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

3.2.  Signalling Peer Changes

   As well as the initial discovery of the peers for signalling, it must
   also be considered how to handle the case where the correct
   signalling peer changes while the MN is attached to the network.
   Several scenarios can be considered:

   o  The MN point of attachment changes, and according to the local
      network architecture a new signalling peer is now the appropriate
      serving node for it.

   o  The signalling peer fails, and a backup must be used instead.

   o  The network infrastructure is reconfigured internally (changing
      the topology or set of available services at a given node), which
      means that a different peer or set of peers should be used.

   In so far as the common protocol functions take responsibility for
   the initial discovery process, they must also take care of the
   rediscovery and rerouting needed in these types of circumstances.
   (Conversely, if external discovery approaches are used, then it must
   be defined how these handing the peer change problem.)

   A very simple and robust approach is simply to repeat the initial
   discovery process periodically.  This always works after some time
   lag, but leads to an awkward tradeoff between efficiency (which is
   reduced if the repetition rate is high) and reactiveness (which
   requires a high refresh rate).  This problem can be mitigated if a
   long period is used but hints are allowed to trigger the process on

Hepworth, et al.         Expires April 26, 2007                 [Page 8]
Internet-Draft          MIH Design Considerations           October 2006

   particular events.  Indeed, the MIH services themselves can be used
   to deliver such triggers during periods of correct operation,
   requiring fallback to periodic discovery only to handle failure

   Whatever approach is used here, it should be noted that there needs
   to be an interaction between the service layer and common protocol to
   convey not just the possibility that rediscovery is needed, but also
   to indicate that a peer change has taken place.

3.3.  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 from a
   single instance; indeed, a service might request different transport
   characteristics for different transaction types.  The main transport
   considerations include:

   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 (e.g. to prevent them issuing large numbers
      of parallel requests if messages are already being dropped because
      of congestion effects).  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

Hepworth, et al.         Expires April 26, 2007                 [Page 9]
Internet-Draft          MIH Design Considerations           October 2006

      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

   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.

   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.4.  State Management

   The operation of the MIH services requires the existence of service
   layer 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

Hepworth, et al.         Expires April 26, 2007                [Page 10]
Internet-Draft          MIH Design Considerations           October 2006

   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

   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 include:

   o  MIH Service Layer 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

   o  Routing State: such as next hop information for routing to a peer

   o  Security State: associated with a particular message exchange.

   o  Transport State: counters and timers associated with the delivery
      of individual message fragments (datagrams) and their
      retransmission and reassembly.

   The first type of state is MIH service specific, and should be
   transparent to the common protocol functionality.  The latter four
   types could be managed by either the MIH service or the common
   protocol functionality, although the second option seems preferable
   (as will be discussed in Section 3.1 and Section 3.7).  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?  Typically, it is preferable to avoid such
   hard dependencies between the state at different layers, since it
   reduces the freedom within the common protocol part to manage
   connections most efficiently.  In other words, the service layer
   state is assumed to be managed entirely within the service layer

Hepworth, et al.         Expires April 26, 2007                [Page 11]
Internet-Draft          MIH Design Considerations           October 2006

3.5.  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.6.  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
   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

Hepworth, et al.         Expires April 26, 2007                [Page 12]
Internet-Draft          MIH Design Considerations           October 2006

   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.7.  Message Security

   Message security is needed to protect the information exchanges
   between MIH service peers.  This section focuses on authentication
   and authorisation aspects associated with MIH service support; DoS
   and overload situations are considered in Section 3.8.

   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
      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

Hepworth, et al.         Expires April 26, 2007                [Page 13]
Internet-Draft          MIH Design Considerations           October 2006

      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

3.8.  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
   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

Hepworth, et al.         Expires April 26, 2007                [Page 14]
Internet-Draft          MIH Design Considerations           October 2006

   or more signalling channels to cope with different message priorities
   in this case.  Some elements of the common functionality must operate
   even in the absence 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.9.  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.

   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

Hepworth, et al.         Expires April 26, 2007                [Page 15]
Internet-Draft          MIH Design Considerations           October 2006

   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.8).  State
   information is installed in nodes for both transport and MIH service
   purposes; 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.7.  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
   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

   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.

Hepworth, et al.         Expires April 26, 2007                [Page 16]
Internet-Draft          MIH Design Considerations           October 2006

   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., "Mobility Services: Problem Statement",
        draft-melia-mipshop-mobility-services-ps-00 (work in progress),
        September 2006.

   [2]  Cheshire, S. and M. Krochmal, "Multicast DNS",
        draft-cheshire-dnsext-multicastdns-06 (work in progress),
        August 2006.

   [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.

   [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.  This revised version of
   the draft followed comments from Subir Das, Junghoon Jee, Yoshihiro
   Ohba, Akbar Rahman, Behcet Sarikaya and Qiaobing Xie.

   Eleanor Hepworth and Robert Hancock are partly funded by Ambient
   Networks, a research project supported by the European Commission

Hepworth, et al.         Expires April 26, 2007                [Page 17]
Internet-Draft          MIH Design Considerations           October 2006

   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.

Authors' Addresses

   Eleanor Hepworth
   Roke Manor Research Ltd
   Roke Manor
   Romsey,   SO51 0ZN


   Robert Hancock
   Roke Manor Research Ltd
   Roke Manor
   Romsey,   SO51 0ZN


   Srinivas Sreemanthula
   Nokia Research Center
   6000 Connection Dr.
   Irving,   TX 75028


   Stefano Faccin
   Intel Corporation
   Santa Clara, CA


Hepworth, et al.         Expires April 26, 2007                [Page 18]
Internet-Draft          MIH Design Considerations           October 2006

Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   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


   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Hepworth, et al.         Expires April 26, 2007                [Page 19]