One document matched: draft-hepworth-mipshop-mih-design-considerations-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-23 09:49:24 |