| Dynamics
|
| Foreign Agent state machine
| $Revision: 1.2 $
| State approved
|
| Date 07-Dec-1998
| Author Tom Weckström
|
| Review date 09-Dec-1998
| Reviewed by Jouni Malinen
|
| Approval date 10-Dec-1998
| Approved by Jouni Malinen
|
$Id: FA_machine.html,v 1.2 1998/12/09 23:40:31 jkmaline Exp $
Foreign Agent state machine
This is the Foreign Agent state machine document that describes the operation
of a Foreign Agent mainly from signaling point of view, but also some other
details have been added. The modeling of Foreign Agent daemon follows loosely
the definitions of a finite state machine. However, the states are rather
temporary places for the executed daemon. At the end of information processing
cycles the machine always returns to the basic state or halts.
The modeling of one plain signaling machine is relatively easy, since
each binding that constitutes one signaling machine, only can be essentially
in two states: confirmed or unconfirmed. Thus we chose this
combination model of state machine and data flow chart to depict the functionality
of the Foreign Agent.
Below is a list of states and transitions. Each transition has input
data which affects the output data. Sometimes only a specific input
data value is accepted for the transition, sometimes there is logic inside
the transition and the output varies depending on the input. All the transitions
also have the Variables & processing field to inform what variables
are affected by the transition and what kind of processing the transition
does. The return values of all the transitions are fully imaginary and
will be defined in the code and later definitions.
This state machine is depicted in a separate FA
state machine picture.
The picture of a single FA binding
state machine illustrates the functionality of one single binding from
signaling point of view. There is no textual state machine definition
for the single binding state machine, but the functionality is embedded
into the FA state machine.
State: STARTING
FA state machine initial state when the daemon is started.
Transitions
Transition: read_config
Input:
Config file parameters and values are read in one by one.
Output:
Initialization message is reported to the stdout.
Unsuccessful initialization will cause special return values.
Variables & processing:
The pre-configured information is stored into global variables in the
program memory space.
Next state:
State: CONF INIT
Configuration has been read and the FA proceeds according to the read_config
transition return value.
Transitions
Transition: config_error
Input:
Negative config initialization return value from the transition
read_config.
Output:
Log the error to syslog.
Echo an error report on the stderr.
Variables & processing:
Close the possibly open files and sockets.
All the memory of the program is freed.
The daemon exits with exit value 1.
Next state:
Transition: init_sockets
Input:
Positive config initialization return value from the transition
read_config.
Output:
Echo initialization message to the stdout.
Return status indicates the success or the error type.
Variables & processing:
Sockets are created for API and signaling:
Initialize one socket for reading the information from the FA (for
the API).
Initialize one socket for reading and writing (modifying) the dynamic
information of the FA (for the API).
Initialize one UDP socket on port 434 for signaling.
Next state:
State: SOCKET INIT
Now the interfaces have been initialized. There is an success or error
value available from init_sockets.
Transitions
Transition: sock_init_error
Input:
Error return value from the socket initialization
Output:
Log the error to syslog.
Echo the error message to stderr.
Variables & processing:
Close open files and sockets.
All the memory of the program is freed.
The daemon exits with exit value 1.
Next state:
Transition: init_data
Input:
Success return value from the socket initialization.
Output:
Echo initialization message to the stdout.
Return values from initialization of data structures.
Variables & processing:
General data structures are initialized:
The data structures for bindings are initialized.
Timers are initialized.
The unused variables are initialized to NULL (or 0).
Next state:
State: INIT END
This state ends the initialization steps.
We either start the work or exit because of previous errors.
Transitions
Transition: gen_init error
Input:
Return values from the init_data transition.
Output:
Log the error to syslog.
Echo the error message to stderr.
The daemon exits with exit value 1.
Variables & processing:
Close open files and sockets.
The daemon exits with exit value 1.
Next state:
Transition: init_complete
Input:
Successful return value from the init_data transition
Output:
Echo initialization success message to the stdout.
Log successful startup to the syslog.
Variables & processing:
Next state:
State: INIT ERROR
Daemon initialization has failed and the error has been logged.
This is an unsatisfactory machine stop state.
The daemon has exited.
State: FA_READY
This is the basic state of the FA daemon.
From this state all the actions start.
In this state the incoming signaling messages are initially
recognized and forwarded for further processing.
Transitions
Transition: advertisement_timer_expiration
Input:
Timer tester indicates that the advertisement timer has expired.
Output:
Variables & processing:
Next state:
Transition: receive_request
Validates the UDP request messages
Input:
Signaling Registration Request message in UDP packet.
Output:
Validation result value.
Log request to syslog.
Variables & processing:
Verify the request by comparing it with the binding information.
Classify the request to: new_binding_request, binding_update_request
(KeepAlive or an update for an existing binding from a new direction )
or erroneous (badly formatted) request.
Next state:
Transition: receive_reply
FA receives a registration request reply coming from upper FAs and
initially from the HA.
Input:
Registration Reply in an UDP signaling packet
Output:
Return validation result code.
Variables & processing:
Validate registration reply format and compare the message information
it with the information of bindings.
Next state:
Transition: incoming_api_call
Input:
Socket data from monitoring or configuration tool.
Output:
API call validation value.
Variables & processing:
Validate the API call.
If the call was: "List active tunnels", set return value X.
If the call was: "Read available tunnel information for a specific
tunnel", set return value Y.
If the call was: "Destroy tunnel", set return value Z.
If the call was: erroneous, report about it in the return value
to silently discard the call.
Next state:
Transition: binding_expiration
Input:
Expiration timer tester indicates that the binding timer has expired.
Output:
Variables & processing:
The expired binding is removed.
Next state:
State: PROCESSING API CALL
A simplistic state showing actions in the API call situation.
Transitions
Transition: reply_to_api_call
Input:
Return value from the API call validation.
Output:
If the call was: "List active tunnels", send binding information
into the socket.
If the call was: "Read available tunnel information for a specific
tunnel", send binding information for the requested tunnel.
Variables & processing:
If the call was: "Destroy tunnel", remove the binding.
If the call was: erroneous API call, silently discard.
Next state:
State:
HANDLING REQUEST
This state leads to the main operations of an FA. States from this
state on handle the mobility and bindings.
Transitions
Transition: validate_solicitation
The FA has received a request which has been validated to be an Mobility
Agent Solicitation message.
Input:
The message validation result from receive_request transition.
The message itself.
Output:
The message check result.
The message itself.
Variables & processing:
Further validate the message.
Check the available resources.
Check the possible rejection factors. (erroneous format, IP-address,
etc...)
Next state:
Transition: new_binding_request
FA has received a request from a previously unknown MN.
Input:
The message validation result.
The message itself.
Output:
Message check and resource availability result.
The message itself.
Variables & processing:
Check the message validity throughly. (Check the validity of all message
fields.)
Check the availability of resources.
Next state:
Transition: update_request.
Tunnel update request has been received.
Input:
The update request message.
The message validation result value.
Output:
Further request validation return value.
The message itself.
Variables & processing:
Validate the message thoroughly.
Check the existing bindings for information about the requesting Mobile
Node.
If the binding exist:
if the care-of addresses match: set return value
to X.
if the care-of addresses do NOT match: set return
value to Y.
If the binding does not exist: set the return value to Z.
If the MAC is incorrect: set the return value to Z.
If the message is erroneous: set the return value to W (negative validation
result).
Next state:
State:
HANDLING UPDATE REQUEST
When the machine comes to this state, the complete validation and resource
checking has been done.
From this point on the machine can either accept or reject the update
message.
Transitions
Transition: reject_update
Input:
Negative message validation result from update_request transition.
The message structure.
Output:
Log registration failure to syslog.
Silently discard the erroneous request.
Variables & processing:
None influenced.
The binding will be destroyed at the timer expiration time.
Next state:
Transition: handle_address_match
Input:
Return value indicating address match between the lower FA address
of the binding and that of the request.
Output:
Log registration success to syslog.
Send the registration request up to the upper FA.
Variables & processing:
Update care-of-address (just for sure if it has changed).
Start the Wait reply timer to be able to count the remaining
binding life-time when the reply arrives.
Next state:
Transition: handle_address_mismatch
This transition happens when the mobile has been moving from one access
point to another.
The first common FA of the old and new tunnels will trigger this transition.
Input:
Return value indicating address mismatch between the the lower
FA address of the binding and that of the request.
The message itself.
Output:
Log registration success to syslog.
Send Registration reply indicating registration success and the remaining
binding life-time to the care-of address of the Registration Request.
Send Registration Reply with lifetime set to 0 to the old lower
FA.
Variables & processing:
Update the binding:
Update care-of-address (just for sure if it has
changed).
Update the lower FA address.
Update the lower FA public key.
Start the Wait reply timer.
Next state:
Transition: accept_update
Input:
Positive message validation result.
Output:
The value of address checking.
Variables & processing:
Compare the care-of-addresses
Create a new unconfirmed binding and set its expiration time. Wait
for HA's reply.
Compare the care-of-address of the request with that of the old existing binding.
Next state:
State:
CONFIRMING NEW REQUEST
In this state the new binding request is either accepted or rejected.
Transitions
Transition: accept_new_binding
Input:
Positive resource availability result
The Registration (binding) request message
Output:
Forward the request upwards to the upper FA in the hierarchy. Add FA
public key to the UDP packet.
Variables & processing:
Add the new unconfirmed binding to the bindings data structure.
Set an expiration time for the unconfirmed binding.
Next state:
Transition: deny_new_binding
Input:
Negative resource availability result.
Output:
Send Registration Reply to the care-of-address, from which the request came, indicating
that the FA is busy.
Variables & processing:
Next state:
State: HANDLING REPLY
In this state FA handles the registration request reply according to
the validation value.
Transitions
Transition: Manage binding
FA has validated the message and shall act according to the result.
Input:
Registration Reply in an UDP signaling packet.
Validation result.
Output:
Log registration reply message and the validation result to syslog.
If OK: Forward the reply downwards in the hierarchy with the updated
expiration time.
Variables & processing:
If: the validation code is NOT ok, (no matched bindings, no
correct message format): the reply will be silently discarded.
ElseIf: the validation code is OK, there is a matching binding.
Set the Binding timer to a defined fraction
of the original value.
Set the SK.
FA checks if the public key of the lower FA is same.
The key is found from the binding information.
If the keys are same the FA does not have to re-encrypt
the session key.
Encrypt the message with the lower FA public key
IF necessary.
Set the other possibly changed binding settings.
Confirm the binding.
Next state:
State: BROADCAST ADVERTISING
In this state FA is about to broadcast a Mobility Agent Advertisement
message.
Transitions
Transition: Broadcast Advertisement
Input:
The advertisement cause value is indicating that the advertisement
timer had expired.
Output:
FA sends a Mobile Agent Advertisement message to the broadcast address.
Variables & processing:
The Advertisement timer is reset.
Next state:
State:
HANDLING SOLICITATION
In this state FA answers to or rejects the Mobility Agent Solicitation
message.
Transitions
Transition: answer_solicitation
Input:
A positive solicitation message check result.
The entire request message.
Output:
FA sends a Mobile Agent Advertisement message.
The message was requested, so it is sent only to the requester.
Variables & processing:
No variables influenced.
If there are NO resources available, set the busy bit on in the answer
message.
Next state:
Transition: reject_solicitation
Input:
A negative solicitation message check result.
The entire request message.
Output:
None. FA silently discards the solicitation.
Variables & processing:
Next state:
