< draft-schilcher-mobike-trigger-api-01.txt   draft-schilcher-mobike-trigger-api-02.txt >
IKEv2 Mobility and Multihoming U. Schilcher IKEv2 Mobility and Multihoming U. Schilcher
(mobike) H. Tschofenig (mobike) Universitaet Klagenfurt
Internet-Draft F. Muenz Internet-Draft H. Tschofenig
Expires: January 19, 2006 Siemens AG Expires: April 25, 2006 F. Muenz
July 18, 2005 Siemens AG
October 22, 2005
Application Programming Interface to a Trigger Database for MOBIKE Application Programming Interface to a Trigger Database for MOBIKE
draft-schilcher-mobike-trigger-api-01.txt draft-schilcher-mobike-trigger-api-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 19, 2006. This Internet-Draft will expire on April 25, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
The purpose of MOBIKE is the creation and maintenance a set of The purpose of MOBIKE is the creation and maintenance of a set of
available addresses and provide them to the communication partner. A available addresses and provide them to the communication partner. A
MOBIKE peer should have some information about the status of each MOBIKE peer should have some information about the status of each
address and interface in order to execute the respective actions. address and interface in order to execute the respective actions.
Examples may comprise switching from address or interface to another. Examples may comprise switching from one address or interface to
This information, which will be referred as trigger, is distributed another. This information, which will be referred as trigger, is
over a number of protocols daemons at an end host. To make this distributed over a number of protocol daemons at an end host. To
information available to the MOBIKE daemon it is necessary to store make this information available to a MOBIKE daemon, it is necessary
it centrally at the host (called trigger database) and to enable the to store it centrally at the host (called trigger database) and to
protocols to insert the triggers and to allow MOBIKE to obtain timely enable the protocols to insert the triggers and to allow MOBIKE to
information. obtain timely information.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Trigger Classification . . . . . . . . . . . . . . . . . . . 5 3. Trigger Database and MIH . . . . . . . . . . . . . . . . . . . 6
4. API for the Trigger Database . . . . . . . . . . . . . . . . 6 4. Trigger Classification . . . . . . . . . . . . . . . . . . . . 8
5. Supported Message Types . . . . . . . . . . . . . . . . . . 7 5. API for the Trigger Database . . . . . . . . . . . . . . . . . 10
6. Payload Format . . . . . . . . . . . . . . . . . . . . . . . 12 6. Supported Message Types . . . . . . . . . . . . . . . . . . . 12
7. Applicability . . . . . . . . . . . . . . . . . . . . . . . 17 7. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 18 8. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 22
9. Security Considerations . . . . . . . . . . . . . . . . . . 19 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 20 10. Security Considerations . . . . . . . . . . . . . . . . . . . 24
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25
11.1 Normative References . . . . . . . . . . . . . . . . . . 21 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
11.2 Informative References . . . . . . . . . . . . . . . . . 21 12.1. Normative References . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 21 12.2. Informative References . . . . . . . . . . . . . . . . . 26
Intellectual Property and Copyright Statements . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
Intellectual Property and Copyright Statements . . . . . . . . . . 28
1. Introduction 1. Introduction
When a MOBIKE implementation is started first it has to build a set When a MOBIKE daemon is started it first has to build a set of all
of all available addresses (or a subset of them for policy reasons; available addresses (or a subset of them for policy reasons; see [3])
see [3]) before communicating with another peer. From these before communicating with another peer. From these addresses, it has
addresses, it has to select one of the addresses as preferred address to select one of the addresses as the preferred address that will be
that will be used as the source address in the communication with the used as the source address in the communication with the MOBIKE peer.
MOBIKE peer.
This address set together with the preferred address may change This address set together with the preferred address may change
during operation because of several reasons, e.g. an interface could during operation because of several reasons, e.g. an interface is
be disconnected or the communication path becomes unavailable due to disconnected, a handover between two different link layer
router failure. Many of the events, which cause the change of the technologies takes place or the communication path becomes
address set, are out of the scope of the MOBIKE protocol itself but unavailable due to router failure. Many of the events, which cause
need an interaction with other protocols daemons locally at the end the change of the address set, are out of the scope of the MOBIKE
host. protocol itself but need an interaction with other protocols daemons
locally at the end host.
For MOBIKE to work, it is really important to know about the status In order to make MOBIKE working properly, it is really important to
of the available addresses in order to make reasonable decisions. A know about the status of the available addresses for making
number of other protocols running on the end host might have various reasonable decisions. A number of other protocols running on the end
information necessary to derive a decision whether to switch from one host might have various information necessary to derive a decision,
preferred address to another or whether it is necessary to modify the whether to switch from one preferred address to another or whether it
peer address set. is necessary to modify the peer address set.
An example is the IEEE 802.21 Media Independent Handover (MIH)
standard [4], which is currently under development. The MIH is
defined as a shim layer in the mobility-management protocol stack of
both, the mobile node and the network elements, that provide mobility
support. The MIH Function provides abstracted services to higher
layers about the status and performance of any link layer technology.
To benefit from this information on higher layers, however, the MIH
services must be combined with information from upper layers in order
to facilitate a basis for decisions above network layer.
In this document, we therefore suggest to define an API that allows In this document, we therefore suggest to define an API that allows
protocol daemons to insert information (triggers) into a "database" protocol daemons to insert information (triggers) about addresses and
that can later be made available to the MOBIKE daemon. The API is interfaces into a "database" that can later be made available to the
based on the BSD routing socket API in a similar fashion as PF_KEY MOBIKE daemon (or other protocols). The API will provide similar
[1] extends the same API for generic key management usage. This services to the MOBIKE daemon like MIH does for layer 3 and above.
document therefore heavily focuses on the functionality offered by It is based on the BSD routing socket API in a similar fashion as
the PF_KEY specification. PF_KEY [1] extends the same API for generic key management usage.
This document therefore heavily focuses on the functionality offered
by the PF_KEY specification and uses the MIH Function as an example
for retrieving necessary information for a decision making process.
Please note that the authors use the term 'database' in a symbolic
way. It is a container for storing information about events.
Information about the status of interfaces and addresses might not
even be stored directly in this database and could well be
implemented using a collection of pointers to the respective
information.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [2]. document are to be interpreted as described in [2].
Additionally, the following terms are introduced: Additionally, the following terms are introduced:
o Trigger: Information which is relevant for MOBIKE about an o Trigger: Information which is relevant for MOBIKE about an
address. address.
o Trigger Database (TDB): Collection of triggers which can be o Trigger Database (TDB): Collection of triggers which can be
accessed via the API defined in this document. accessed via the API defined in this document.
3. Trigger Classification o Media Independent Handover (MIH): Described in IEEE draft 802.21
[4] which is currently under development. The MIH Function
provides abstracted services to higher layers about the status and
performance of any link layer technology.
3. Trigger Database and MIH
The following section should give a rough overview for the
interaction of Media Independent Handover (MIH) with Trigger Database
(TDB) and MOBIKE daemon. The services of MIH are used e.g. for
compiling relevant information about interface performance, which is
then signalled through the Trigger Database to the MOBIKE daemon.
Based on this data, the MOBIKE daemon may select a new preferred
address or continues using the current one.
+--------------------------------------+
| MOBIKE daemon |
| +-------------------+ |
| | PF_TRIGGER socket | |
| +--------------+----+ |
| ^ | |
+-----------|-----------|--------------+
| |
| |
TDB TDB
Events Commands
| |
| v
+-----------+--------------------------+
| Trigger Database (TDB) |
| (Layer 3 an above) |
+--------------------------------------+
^ | ^
| | |
MIH MIH Information
Events Commands Service
| | |
| v v
+--------------------------------------+
| Media Independent Handover Function |
+--------------------------------------+
^ | ^
| | |
Link Link Information
Events Commands Service
| | |
| v v
+--------------------------------------+
| Lower Layers (Layer 2 and below) |
+--------------------------------------+
To receive event notifications from the MIH, the Trigger Database
must perform two steps:
Capability discovery:
While the MIH provides many services, not all of them may be
supported on a given platform. For learning, which of them are
actually supported, the Trigger Database must query the MIH with a
"MIH_Capability_Discover.request". The response, a
"MIH_Capability_Discover.response" message will then indicate with
a bit mask which services are supported. Alternatives and
solutions for not supported but required services is done in a
future version of this draft.
Service registration:
Now knowing the supported services, the Trigger Database must
register to the services it is interested in with a
"MIH_Event_Register.request" message. To confirm registration,
the MIH answers with a "MIH_Event_Register.confirm" message and
notifies the Trigger Database in case of status change of
interfaces.
4. Trigger Classification
Many different events may cause a change in the address set used by Many different events may cause a change in the address set used by
MOBIKE (see [3]). These events can be notified by many different MOBIKE (see [3]). These events can be issued by many different
protocols running in kernel or user space. Since the reaction (if protocols running in kernel or user space. Since the reaction (if
any) on a given event depends on the type of the event, a any) on a given event depends on the type of the event, a
classification of these events is necessary. classification of these events is necessary.
As an example, we define the following triggers in this document: As an example, we define the following triggers in this document:
Trigger type Value Description Trigger type Value Description
---------------------------+-------+------------------------------- ---------------------------+-------+-------------------------------
TDB_TTYPE_IF_ADDED | 1 | New interface added TDB_TTYPE_IF_ADDED | 1 | New interface added
TDB_TTYPE_IF_REMOVED | 2 | Interface removed TDB_TTYPE_IF_REMOVED | 2 | Interface removed
TDB_TTYPE_IF_ADDRADDED | 3 | New address added to interface TDB_TTYPE_IF_REMOVEDSOON | 3 | Interface is expected to be
TDB_TTYPE_IF_ADDRREMOVED | 4 | Address removed from interface | | removed soon
TDB_TTYPE_IF_ADDRCHANGED | 5 | Interface has changed one of its TDB_TTYPE_IF_ADDRADDED | 4 | New address added to interface
TDB_TTYPE_IF_ADDRREMOVED | 5 | Address removed from interface
TDB_TTYPE_IF_ADDRCHANGED | 6 | Interface has changed one of its
| | addresses (e.g. new DHCP lease) | | addresses (e.g. new DHCP lease)
TDB_TTYPE_TUNNEL_ADDED | 6 | IPSec tunnel was established TDB_TTYPE_TUNNEL_ADDED | 7 | IPSec tunnel was established
TDB_TTYPE_TUNNEL_CHANGED | 7 | IPSec tunnel conf. changed TDB_TTYPE_TUNNEL_CHANGED | 8 | IPSec tunnel conf. changed
TDB_TTYPE_TUNNEL_REMOVED | 8 | IPSec tunnel was removed TDB_TTYPE_TUNNEL_REMOVED | 9 | IPSec tunnel was removed
TDB_TTYPE_CONN_ESTABLISHED | 9 | e.g. dial-in network TDB_TTYPE_CONN_ESTABLISHED | 10 | e.g. dial-in network
| | has connected | | has connected
TDB_TTYPE_CONN_LOST | 10 | connection to network lost TDB_TTYPE_CONN_LOST | 11 | connection to network lost
TDB_TTYPE_DEST_UNREACHABLE | 11 | e.g. ICMP packet received TDB_TTYPE_DEST_UNREACHABLE | 12 | e.g. ICMP packet received
TDB_TTYPE_MAX | 12 | Maximum value for trigger types TDB_TTYPE_MAX | 13 | Maximum value for trigger types
A future version of this document will add more triggers and a more The types TDB_TTYPE_TUNNEL_ADDED, TDB_TTYPE_TUNNEL_CHANGED and
detailed description of them. The types TDB_TTYPE_TUNNEL_ADDED, TDB_TTYPE_TUNNEL_REMOVED are inspired by [5]. Any listed trigger
TDB_TTYPE_TUNNEL_CHANGED and TDB_TTYPE_TUNNEL_REMOVED are inspired by types will be signalled using the "tdb_trigger" message structure
[4]. described in Section 7
The above listed trigger types will be signaled using the Details about the supported message types and their formats can be
"tdb_trigger" message structure described in Section 6 found below:
4. API for the Trigger Database TDB_TTYPE_IF_ADDED:
This message is signalled if a new interface comes up and directly
refers to the "Link_Up.indication" event notification of the MIH
Function.
TDB_TTYPE_IF_REMOVED:
This message is signalled if an interface is going down and
directly refers to the "Link_Down.indication" event notification
of the MIH Function.
TDB_TTYPE_IF_REMOVEDSOON:
This message is signalled if an interface is expected (predicted)
to go down within a certain time interval and directly refers to
the "Link_Going_Down.indication" event notification of the MIH
Function.
A future version of this document will add more triggers and a more
detailed description of them.
5. API for the Trigger Database
To access the trigger database, an API is defined. For that purpose To access the trigger database, an API is defined. For that purpose
the new network protocol family ID PF_TRIGGER has to be defined. The the new network protocol family ID PF_TRIGGER has to be defined. The
operation of the API is analogue to the PF_KEY interface (see [1]). operation of the API is analogue to the PF_KEY interface (see [1]).
To access the API, a socket of the family PF_TRIGGER has to be To access the API, a socket of the family PF_TRIGGER has to be
created. To communicate with the Trigger Database, messages are sent created. To communicate with the Trigger Database, messages are sent
and received through the socket with the send and recv commands. Any and received through the socket with the send() and recv() functions.
other commands like bind, connect, etc. are not supported and MUST Any other functions like bind(), connect(), etc. are not supported
NOT have any effects on a socket of the PF_TRIGGER family. and MUST NOT have any effects on a socket of the PF_TRIGGER family.
The following exhibits an example socket creation: The following exhibits a sample socket creation:
int s = socket(PF_TRIGGER, SOCK_RAW, PF_TRIGGER); int s = socket(PF_TRIGGER, SOCK_RAW, PF_TRIGGER);
The format of the messages is the following: Each message starts with The format of the messages is the following: Each message starts with
a fixed header. Appended to this header, there are some payloads a fixed header. Appended to this header, there are some payloads
depending on the type of the message. The available message types depending on the type of the message. The available message types
are described in Section 5. are described in Section 6.
Each time when a message is sent to the Trigger Database, it will Each time when a message is sent to the Trigger Database, it will
respond with a message of the same type. This response contains the respond with a message of the same type. This response contains the
same payloads as transmitted to the Trigger Database, only some same payloads as transmitted to the Trigger Database, only some
additional information MAY be included (e.g., the Trigger Database additional information MAY be included (e.g., the Trigger Database
assigns an id to each trigger). assigns an id to each trigger).
The normal operation works in the following way: A MOBIKE The normal operation works in the following way: A MOBIKE
implementation, which wants to be informed about every new trigger, implementation, which wants to be informed about changes in the
registers itself to the Trigger Database by sending a TDB_REGISTER Trigger Database, registers itself to the Trigger Database by sending
message. If a protocol daemon wants to add a new trigger, it sends a a TDB_REGISTER message.
TDB_ADD message to the Trigger Database including information that is
important for this new trigger.
The Trigger Database acknowledges this message with a TDB_ADD If a protocol daemon wants to add, delete or modify an existing
response to the network protocol and with a TDB_NOTIFY message to the trigger it sends a TDB_ADD, TDB_DELETE or TDB_MODIFY message
registered MOBIKE implementation. This notify message contains some respectively to the Trigger Database including information that is
information about the new trigger including its id. All information important to add, delete or modify the trigger.
available about the new trigger can be requested with a TDB_GET
The Trigger Database acknowledges this message with a TDB_ADD,
TDB_DELETE or TDB_MODIFY response to the network protocol and with a
TDB_NOTIFY message to the registered MOBIKE implementation. This
notify message contains information about the newly added, deleted or
modified trigger including its ID. All information available about a
trigger can be requested with a TDB_GET message.
If a MOBIKE implementation no longer wants to receive notifications
for changes to the Trigger Database, it sends a TDB_DEREGISTER
message. message.
In a future version of this document, we will try to add some In a future version of this document, we will try to add some
information about scenarios to better illustrate the interaction. information about scenarios to better illustrate the interaction.
5. Supported Message Types 6. Supported Message Types
Several different message types can be sent to the Trigger Database Several different message types can be sent to the Trigger Database
using a PF_TRIGGER socket. The message type is indicated by the using a PF_TRIGGER socket. The message type is indicated by the
tdb_header_msgtype field that is part of the generic message header tdb_header_msgtype field that is part of the generic message header
(see Section 6) and can be one of the following values: (see Section 7) and can be one of the following values:
Message type Value Description Message type Value Description
------------------+---------+------------------------------ ------------------+---------+------------------------------
TDB_ADD | 1 | Add a trigger to the TDB_ADD | 1 | Add a trigger to the
| | Trigger Database | | Trigger Database
TDB_GET | 2 | Get information about an TDB_GET | 2 | Get information about an
| | existing trigger. | | existing trigger.
TDB_DELETE | 3 | Delete a trigger from the TDB_DELETE | 3 | Delete a trigger from the
| | Trigger Database | | Trigger Database
TDB_REGISTER | 4 | Register an application TDB_REGISTER | 4 | Registers an application
| | to receive a messages for | | to receive messages for
| | each new trigger added. | | each new trigger added.
TDB_NOTIFY | 5 | A new trigger has been TDB_DEREGISTER | 5 | Deregisters an application
| | from receiving messages for
| | each new trigger added.
TDB_NOTIFY | 6 | A new trigger has been
| | added, deleted or updated. | | added, deleted or updated.
TDB_MODIFY | 6 | Modify a trigger in the TDB_MODIFY | 7 | Modify a trigger in the
| | Trigger Database | | Trigger Database
TDB_DUMP | 7 | Dump all Trigger Database TDB_DUMP | 8 | Dump all Trigger Database
| | entries | | entries
TDB_FLUSH | 8 | Delete all Trigger Database TDB_FLUSH | 9 | Delete all Trigger Database
| | entries | | entries
TDB_MAX | 9 | Generic maximum for message TDB_MAX | 10 | Generic maximum for message
| | types | | types
Each message type requires different payloads to be appended. Each Each message type requires different payloads to be appended. Each
payload starts with a generic payload header followed by payload payload starts with a generic payload header followed by payload
specific data. The generic header has the following structure: specific data. The generic header has the following structure:
struct tdb_payload { struct tdb_payload {
uint16_t tdb_payload_len; uint16_t tdb_payload_len;
uint16_t tdb_payload_type; uint16_t tdb_payload_type;
} __attribute__( ( packed ) ); } __attribute__( ( packed ) );
/* sizeof( struct tdb_payload ) == 4 */ /* sizeof( struct tdb_payload ) == 4 */
The tdb_payload_len field contains the length of the payload divided The tdb_payload_len field contains the length of the payload divided
by 8. The type of the payload is determined by the tdb_payload_type by 8. The type of the payload is determined by the tdb_payload_type
field, which contains one of the following values: field, which contains one of the following values:
Payload type Value Description Payload type Value Description
---------------------------+---------+------------------------------- ---------------------------+---------+-------------------------------
TDB_PT_INTERFACE | 1 | Information about an interface TDB_PT_INTERFACE | 1 | Information about an interface
TDB_PT_ADDRESS | 2 | The IP address of an IF TDB_PT_ADDRESS | 2 | The IP address of an interface
TDB_PT_TRIGGER | 3 | Trigger id, type, etc. TDB_PT_TRIGGER | 3 | Trigger id, type, etc.
Details about the supported message types and their formats can be Details about the supported message types and their formats can be
found below: found below:
TDB_ADD: TDB_ADD:
If an application or network protocol wants to add a new trigger, If an application or network protocol wants to add a new trigger,
it sends a TDB_ADD message to the Trigger Database. The new it sends a TDB_ADD message to the Trigger Database. The new
trigger is stored in the Trigger Database and a corresponding trigger is stored in the Trigger Database and a corresponding
skipping to change at page 8, line 37 skipping to change at page 13, line 43
The response from the Trigger Database contains the same The response from the Trigger Database contains the same
information as the request: information as the request:
<HEADER, TRIGGER, INTERFACE, [ADDRESS]> <HEADER, TRIGGER, INTERFACE, [ADDRESS]>
TDB_DELETE: TDB_DELETE:
A trigger, which is stored inside the Trigger Database, can be A trigger, which is stored inside the Trigger Database, can be
deleted using the TDB_DELETE payload. In the request the only deleted using the TDB_DELETE payload. In the request the only
information, which has to be specified is the id of the trigger, information, which has to be specified is the id of the trigger,
which is stored in 'TRIGGER(*)'. which is stored in 'TRIGGER(*)'. A corresponding TDB_NOTIFY
message that indicates that a trigger has been deleted is sent to
all registered applications.
The format of the message is: The format of the message is:
<HEADER, TRIGGER(*)> <HEADER, TRIGGER(*)>
The Trigger Database responds with a message with the following The Trigger Database responds with a message with the following
format: format:
<HEADER, TRIGGER> <HEADER, TRIGGER>
skipping to change at page 9, line 41 skipping to change at page 15, line 5
been added to the database. The format of the message is: been added to the database. The format of the message is:
<HEADER> <HEADER>
No additional payload has to be added. The Trigger Database No additional payload has to be added. The Trigger Database
responds with a message of the same type and with the same responds with a message of the same type and with the same
content, i.e. its format is: content, i.e. its format is:
<HEADER> <HEADER>
TDB_DEREGISTER:
An application, which is no longer interested in receiving
notifications about trigger changes, can de-register itself from
the Trigger Database. The format of the message is:
<HEADER>
No additional payload has to be added. The Trigger Database
responds with a message of the same type and with the same
content, i.e. its format is:
<HEADER>
TDB_NOTIFY TDB_NOTIFY
An application that has registered itself to get informed about An application that has registered itself to get informed about
the new triggers or updates to these triggers, receives a the new triggers or updates to these triggers, receives a
TDB_NOTIFY message. The format of the message is the same as for TDB_NOTIFY message. The format of the message is the same as for
a TDB_ADD message. The only difference is that some field are a TDB_ADD message. The only difference is that some field are
filled by the Trigger Database before sending the TDB_NOTIFY filled by the Trigger Database before sending the TDB_NOTIFY
message. message.
The format of the message is: The format of the message is:
<HEADER, TRIGGER, [INTERFACE], [ADDRESS]> <HEADER, TRIGGER, [INTERFACE], [ADDRESS]>
Since this message is sent by the Trigger Database itself, a Since this message is sent by the Trigger Database itself, a
registered application MUST NOT respond to it. registered application MUST NOT respond to it.
TDB_MODIFY: TDB_MODIFY:
If an application or a network protocol wants to modify a new If an application or a network protocol wants to modify a trigger
trigger (because its status has changed), it sends a TDB_MODIFY (because its status has changed), it sends a TDB_MODIFY message to
message to the Trigger Database. The new trigger is stored and a the Trigger Database. The new trigger is stored and a
corresponding TDB_NOTIFY message that indicates that an existing corresponding TDB_NOTIFY message that indicates that an existing
trigger has been modified is sent to all registered applications. trigger has been modified is sent to all registered applications.
The format of the message is: The format of the message is:
<HEADER, TRIGGER, [INTERFACE], [ADDRESS]> <HEADER, TRIGGER, [INTERFACE], [ADDRESS]>
The TRIGGER payload indicates the type of the trigger and also The TRIGGER payload indicates the type of the trigger and also
includes some trigger specific data. includes some trigger specific data.
The response from the Trigger Database contains the same The response from the Trigger Database contains the same
information as the request: information as the request:
<HEADER, TRIGGER, [INTERFACE], [ADDRESS]> <HEADER, TRIGGER, [INTERFACE], [ADDRESS]>
TDB_DUMP: TDB_DUMP:
An application, that wants to learn all currently available An application, that wants to learn all currently available
triggers should send a TDB_DUMP message. Since a TDB_GET message triggers should send a TDB_DUMP message. Since a TDB_GET message
requires a specific trigger id for retrieval, applications which requires a specific trigger id for retrieval, applications which
to not know all trigger ids depend on this message class for to not know all trigger IDs depend on this message class for
learning all unknown triggers. The format of the message is: learning all unknown triggers. The format of the message is:
<HEADER> <HEADER>
The Trigger Database will respond with all currently available The Trigger Database will respond with all currently available
triggers entries by serially sending the following message: triggers entries by serially sending the following message:
<HEADER, TRIGGER, INTERFACE, [ADDRESS]> <HEADER, TRIGGER, INTERFACE, [ADDRESS]>
TDB_FLUSH: TDB_FLUSH:
skipping to change at page 12, line 5 skipping to change at page 17, line 5
message is used. Since the TDB_GET message requires a specific message is used. Since the TDB_GET message requires a specific
trigger id for deletion, reliable cleaning of a Trigger Database trigger id for deletion, reliable cleaning of a Trigger Database
can be done with this message. The format of the message is: can be done with this message. The format of the message is:
<HEADER> <HEADER>
The Trigger Database will respond with the following message: The Trigger Database will respond with the following message:
<HEADER> <HEADER>
6. Payload Format 7. Payload Format
HEADER: HEADER:
Each message starts with the fixed header. It contains general Each message starts with the fixed header. It contains general
information about the message and determines, which payloads have information about the message and determines, which payloads have
to be included in it. It has the following format: to be included in it. It has the following format:
struct tdb_header { struct tdb_header {
uint8_t tdb_header_version; uint8_t tdb_header_version;
uint8_t tdb_header_msgtype; uint8_t tdb_header_msgtype;
skipping to change at page 12, line 31 skipping to change at page 17, line 31
uint32_t tdb_header_pid; uint32_t tdb_header_pid;
} __attribute__( ( packed ) ); } __attribute__( ( packed ) );
/* sizeof( struct tdb_header ) == 16 */ /* sizeof( struct tdb_header ) == 16 */
The fields of this structure contain the following values: The fields of this structure contain the following values:
tdb_header_version: The version of the used PF_TRIGGER interface. tdb_header_version: The version of the used PF_TRIGGER interface.
This document specifies this API in version 1. This document specifies this API in version 1.
tdb_header_msgtype: This field contains the type of the message. tdb_header_msgtype: This field contains the type of the message.
All possible values are listed in the table in Section 5. All possible values are listed in the table in Section 6.
tdb_header_errno: If an error occurred while processing a request, tdb_header_errno: If an error occurred while processing a request,
the response will only include the message header without any the response will only include the message header without any
payloads. The type of the error is indicated by the value in payloads. The type of the error is indicated by the value in
this field. The values are taken from the error number this field. The values are taken from the error number
specification of the operating system (e.g. the errno.h file). specification of the operating system (e.g. the errno.h file).
tdb_header_msglen: The length of the message divided by 8 is tdb_header_msglen: The length of the message divided by 8 is
stored into this field. stored into this field.
skipping to change at page 13, line 19 skipping to change at page 18, line 19
INTERFACE: INTERFACE:
The INTERFACE payload is used to provide all needed information The INTERFACE payload is used to provide all needed information
about an active network interface. about an active network interface.
The format of the INTERFACE payload is the following: The format of the INTERFACE payload is the following:
struct tdb_interface { struct tdb_interface {
uint16_t tdb_interface_len; uint16_t tdb_interface_len;
uint16_t tdb_interface_pltype; uint16_t tdb_interface_pltype;
uint32_t tdb_interface_selector; uint32_t tdb_interface_selector;
uint32_t tdb_interface_type; uint32_t tdb_interface_type;
uint32_t tdb_interface_bandwidth;
uint32_t tdb_interface_quality; uint32_t tdb_interface_quality;
uint32_t tdb_interface_reserved;
} __attribute__( ( packed ) ); } __attribute__( ( packed ) );
/* sizeof( struct tdb_interface ) == 16 */ /* sizeof( struct tdb_interface ) == 16 */
This fields contain the following values: This fields contain the following values:
tdb_interface_len: This field contains the length of the payload tdb_interface_len: This field contains the length of the payload
divided by 8. divided by 8.
tdb_interface_pltype: This field contains the value tdb_interface_pltype: This field contains the value
TDB_PT_INTERFACE. TDB_PT_INTERFACE.
tdb_interface_selector: The tdb_interface_selector field stores tdb_interface_selector: The tdb_interface_selector field stores
interface enumeration information for unique identification (IF interface enumeration information for unique identification (IF
#0, #1, #2, ...). When a new interface comes up, this value #0, #1, #2, ...). When a new interface comes up, this value
should be set by the kernel. should be set by the kernel.
tdb_interface_type: Information about classification of an tdb_interface_type: Classification of an interface, for instance
interface, for instance Indication, of fixed or wireless fixed or wireless network link. The MIH Function provides this
network link and theoretical maximum bandwidth. information by issuing a "MIH_Poll.request" from the Trigger
Database, before creating any event notification destined for
the MOBIKE daemon.
tdb_interface_quality: This field provides quality information tdb_interface_bandwidth: Information about the maximum bandwidth
about a certain interface for making interface selections of an interface. The MIH Function provides this information by
possible (e.g. load balancing; handover). This value should be issuing a "MIH_Poll.request" from the Trigger Database, before
a very general indicator calculated and set by the kernel creating any event notification destined for the MOBIKE daemon.
space. It could be based on latency (ping), signal quality for
wireless links, packet-loss rate and average data-throughput/
bandwidth. (Author's note: If a single value is not
reasonable, separate indicators for all these evaluation
criteria's should be defined.)
Further information about an interface might be necessary. This tdb_interface_quality: Information about current connection
is left for future investigation. quality of an interface. The MIH Function provides this
information by issuing a "MIH_Poll.request" from the Trigger
Database, before creating any event notification destined for
the MOBIKE daemon.
tdb_interface_reserved: This field is reserved for future use and
MUST be set to zero.
Further information about an interface might be necessary.
Especially asymmetric link connectivity/availability in case of
wireless connections might be relevant. This is left for future
investigation.
ADDRESS: ADDRESS:
The ADDRESS payload is used to provide the IP address of an The ADDRESS payload is used to provide the IP address of an
interface to the Trigger Database or registered application. This interface to the Trigger Database or registered application. This
information is important for most triggers. But it might be information is important for most triggers. But it might be
possible that there trigger types that do not need an ADDRESS possible that there are trigger types which do not need an ADDRESS
payload. payload.
The format of the ADDRESS payload is: The format of the ADDRESS payload is:
struct tdb_address { struct tdb_address {
uint16_t tdb_address_len; uint16_t tdb_address_len;
uint16_t tdb_address_pltype; uint16_t tdb_address_pltype;
uint8_t tdb_address_proto; uint8_t tdb_address_proto;
uint8_t tdb_address_prefixlen; uint8_t tdb_address_prefixlen;
uint16_t tdb_address_reserved; uint16_t tdb_address_reserved;
} __attribute__( ( packed ) ); } __attribute__( ( packed ) );
/* sizeof( struct tdb_address ) == 8 */ /* sizeof( struct tdb_address ) == 8 */
/* followed by some form of struct sockaddr */ /* followed by some form of struct sockaddr */
Information about IP address and probably ports is provided by a Information about IP address and probably ports is provided by a
sockaddr structure which is attached to the tdb_address structure. sockaddr structure which is attached to the tdb_address structure.
A sockaddr structure is capable of storing both a IPv4 and IPv6 A sockaddr structure is capable of storing both a IPv4 and IPv6
address. The fields of the tdb_address structure contains the address. The fields of the tdb_address structure contains the
following values: following values:
skipping to change at page 15, line 9 skipping to change at page 20, line 17
tdb_address_len: This field contains the length of the payload tdb_address_len: This field contains the length of the payload
including the sockaddr structure divided by 8. including the sockaddr structure divided by 8.
tdb_address_pltype: The tdb_address_pltype field contains the tdb_address_pltype: The tdb_address_pltype field contains the
value TDB_PT_ADDRESS. value TDB_PT_ADDRESS.
tdb_address_proto: The tdb_address_proto field is normally set to tdb_address_proto: The tdb_address_proto field is normally set to
zero. However, if is are set in the attached sockaddr needed, zero. However, if is are set in the attached sockaddr needed,
then the field SHOULD be set to the protocol number of the then the field SHOULD be set to the protocol number of the
upper layer protocol. (e.g. TCP or UDP). This functionality upper layer protocol. (e.g. TCP or UDP). This functionality
may become relevant for signaling IPSec related information may become relevant for signalling IPSec related information
(e.g. tunnel changes) (e.g. tunnel changes)
tdb_address_prefixlen: This field contains the prefix length of tdb_address_prefixlen: This field contains the prefix length of
the address. the address, which might be useful to key management
applications, which employ it in access control decisions. If
the tdb_address_prefixlen is non-zero the address has a prefix.
tdb_address_reserved: The tdb_address_reserved field is reserved tdb_address_reserved: The tdb_address_reserved field is reserved
for future use and MUST be set to zero. for future use and MUST be set to zero.
TBD: Clarification about the prefix len needs to be provided in a
future document version.
TRIGGER: TRIGGER:
The TRIGGER payload is used to provide all needed information The TRIGGER payload is used to provide all needed information
about a trigger itself, e.g. the trigger type, an id, etc. The about a trigger itself, e.g. the trigger type, an id, etc. The
notation TRIGGER(*) indicates that only the id field is used to notation TRIGGER(*) indicates that only the id field is used to
identify the trigger and all other fields SHOULD be set to zero. identify the trigger and all other fields SHOULD be set to zero.
The format of the TRIGGER payload is the following: The format of the TRIGGER payload is the following:
struct tdb_trigger { struct tdb_trigger {
skipping to change at page 15, line 39 skipping to change at page 21, line 4
struct tdb_trigger { struct tdb_trigger {
uint16_t tdb_trigger_len; uint16_t tdb_trigger_len;
uint16_t tdb_trigger_pltype; uint16_t tdb_trigger_pltype;
uint16_t tdb_trigger_type; uint16_t tdb_trigger_type;
uint16_t tdb_trigger_reserved1; uint16_t tdb_trigger_reserved1;
uint32_t tdb_trigger_id; uint32_t tdb_trigger_id;
uint32_t tdb_trigger_reserved2; uint32_t tdb_trigger_reserved2;
} __attribute__( ( packed ) ); } __attribute__( ( packed ) );
/* sizeof( struct tdb_trigger ) == 16 */ /* sizeof( struct tdb_trigger ) == 16 */
This fields contain the following values: This fields contain the following values:
tdb_address_len: This field contains the length of the payload tdb_address_len: This field contains the length of the payload
divided by 8. divided by 8.
tdb_address_pltype: This field contains the value TDB_PT_TRIGGER. tdb_address_pltype: This field contains the value TDB_PT_TRIGGER.
tdb_address_type: The type of the trigger is stored into this tdb_address_type: The type of the trigger is stored into this
field. All possible values are listed in the table in section field. All possible values are listed in the table in section
Section 3. Section 4.
tdb_address_id: The id of a trigger is assigned by the Trigger tdb_address_id: The id of a trigger is assigned by the Trigger
Database itself. In the message sent by userspace programs, Database itself. In the message sent by userspace programs,
which do not know this value (e.g. for TDB_ADD messages), this which do not know this value (e.g. for TDB_ADD messages), this
value MUST be set to zero. value MUST be set to zero.
Further information about a trigger might be necessary. This is Further information about a trigger might be necessary. This is
left for future investigation. left for future investigation.
7. Applicability 8. Applicability
Even though this document is intended to give a solution for MOBIKE, Even though this document is intended to give a solution for MOBIKE,
the API is generic enough to make information available for other the API is generic enough to make information available for other
protocols as well. protocols as well.
The Next Step In Signaling (NSIS) protocol suite, for example, The Next Step In Signaling (NSIS) protocol suite, for example,
requires access to up-to-date information about IP addresses, requires access to up-to-date information about IP addresses,
interfaces and interactions with mobility protocols. In order to interfaces and interactions with mobility protocols. In order to
react on mobility events some sort of interaction between the kernel, react on mobility events some sort of interaction between the kernel,
various signaling protocols (including Mobile IP, IKE/IPsec, etc.) various signalling protocols (including Mobile IP, IKE/IPsec, etc.)
and the NSIS daemon is required (see [5]). Hence, an NSIS daemon and the NSIS daemon is required (see [6]). Hence, an NSIS daemon
supporting mobility could benefit from a generic interface to meet supporting mobility could benefit from a generic interface to meet
it's requirements for fast and accurate detection of mobility events, it's requirements for fast and accurate detection of mobility events,
address and interface changes. GIMPS, for example, demands immediate address and interface changes. GIMPS, for example, demands immediate
reaction in case of a mobility event (e.g., handover). Monitoring reaction in case of a mobility event (e.g., handover). Monitoring
procedures of mobility management protocols like Mobile IP are procedures of mobility management protocols like Mobile IP are
required to react to these mobility events in an appropriate way. required to react to these mobility events in an appropriate way.
The trigger database and it's API could provide necessary information The trigger database and it's API could provide necessary information
for detecting such a movement (new interface/IP address available, for detecting such a movement (new interface/IP address available,
expiring Mobile IP timers). expiring Mobile IP timers).
8. IANA Considerations 9. IANA Considerations
This document defines an IANA registry for the protocol family This document defines an IANA registry for the protocol family
PF_TRIGGER. PF_TRIGGER.
An IANA registry might be needed for the different trigger types (for An IANA registry might be needed for the different trigger types (for
which examples are provided in Section 3). which examples are provided in Section 4).
9. Security Considerations 10. Security Considerations
This document describes an API which allows information about IP This document describes an API which allows information about IP
addresses to be obtained at a local host. A malicious application or addresses to be obtained at a local host. A malicious application or
protocol daemon could disseminate wrong information. This would make protocol daemon could disseminate wrong information. This would make
other protocols, such as MOBIKE, believe that the status of a other protocols, such as MOBIKE, believe that the status of a
particular address has changed. This will likely lead to unexpected particular address has changed. This will likely lead to unexpected
protocol behavior, such as switching between addresses back-and- protocol behaviour, such as switching between addresses back-and-
forth. Hence, a certain trust has to be placed into the applications forth. Hence, a certain trust has to be placed into the applications
and protocol daemons that are allowed to access the database to and protocol daemons that are allowed to access the database to
insert, modify or delete triggers. Access control mechanisms might insert, modify or delete triggers. Access control mechanisms might
enforce certain rights to use the API or parts of it. enforce certain rights to use the API or parts of it.
10. Acknowledgments 11. Acknowledgments
The authors would like to thank Murugaraj Shanmugam for his comments. The authors would like to thank Murugaraj Shanmugam, Yu Xinwen,
Wolfgang Groeting and Stefan Berg for their comments. Furthermore,
the authors would like to thank Emanuel Corthay for pointing them to
the IEEE 802.21 draft.
11. References 12. References
11.1 Normative References 12.1. Normative References
[1] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key Management API, [1] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key Management API,
Version 2", RFC 2367, July 1998. Version 2", RFC 2367, July 1998.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", March 1997. Levels", March 1997.
11.2 Informative References 12.2. Informative References
[3] Kivinen, T. and H. Tschofenig, "Design of the MOBIKE protocol", [3] Kivinen, T. and H. Tschofenig, "Design of the MOBIKE Protocol",
draft-ietf-mobike-design-02 (work in progress), February 2005. draft-ietf-mobike-design-04 (work in progress), October 2005.
[4] Sugimoto, S. and F. Dupont, "PF_KEY Extension as an Interface [4] Rajkumar, Ajay., Williams, Michael., Liu, Xiaoyu., and Vivek.
Gupta, "Media Independent Handover Services", IEEE-Draft Draft
IEEE Standard for Local and Metropolitan Area Networks / IEEE
P802.21/D00.01, July 2005.
[5] Sugimoto, S. and F. Dupont, "PF_KEY Extension as an Interface
between Mobile IPv6 and IPsec/IKE", between Mobile IPv6 and IPsec/IKE",
draft-sugimoto-mip6-pfkey-migrate-00 (work in progress), draft-sugimoto-mip6-pfkey-migrate-01 (work in progress),
February 2005. August 2005.
[5] Lee, S., Jeong, S., Tschofenig, H., Fu, X., and J. Manner, [6] Lee, S., Jeong, S., Tschofenig, H., Fu, X., and J. Manner,
"Applicability Statement of NSIS Protocols in Mobile "Applicability Statement of NSIS Protocols in Mobile
Environments", Environments",
draft-ietf-nsis-applicability-mobility-signaling-01 (work in draft-ietf-nsis-applicability-mobility-signalling-02 (work in
progress), February 2005. progress), July 2005.
Authors' Addresses Authors' Addresses
Udo Schilcher Udo Schilcher
Siemens Universitaet Klagenfurt
Otto-Hahn-Ring 6 Klagenfurt, Carinthia 9020
Munich, Bayern 81739 Austria
Germany
Email: USchilcher@siemens.com Email: udo.schilcher@edu.uni-klu.ac.at
Hannes Tschofenig Hannes Tschofenig
Siemens Siemens
Otto-Hahn-Ring 6 Otto-Hahn-Ring 6
Munich, Bayern 81739 Munich, Bayern 81739
Germany Germany
Email: Hannes.Tschofenig@siemens.com Email: Hannes.Tschofenig@siemens.com
Franz Muenz Franz Muenz
Siemens AG Siemens AG
Otto-Hahn-Ring 6 Otto-Hahn-Ring 6
Munich, Bayern 81739 Munich, Bayern 81739
Germany Germany
Email: Franz.Muenz@thirdwave.de Email: Franz.Muenz@thirdwave.de
Intellectual Property Statement Intellectual Property Statement
 End of changes. 70 change blocks. 
157 lines changed or deleted 321 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/