Subject: [seamoby] Real-time Mobile IPv6 Framework nomenclature

From: Kulwinder Atwal <[email-masked]>
Date: Sun, 7 Jan 2001 00:42:59 -0500

I have reviewed draft-blair-rt-mobileipv6-seamoby-00.txt.

Possible Problem Statement:

"Seamoby will perform the Real-Time switching of packet flows for mobile
devices traveling within and across all types of IP networks"

We cannot guarantee seamless behavior where the new path is significantly
longer than the old path (i.e. switching to satellite).  Our switching will
always be "best effort".

My intent is to provide suggestions that are network neutral.  Referring to
the draft:

Policy Decision Point:

Responsible for: 

- access authorization 
- QoS authorization
- billing and settlement issues

Only wireless Billable Minutes business models require "billing and
settlement issues", or Accounting. Some wireless networks have EAA
(Encryption, Authentication, Authorization) in place of AAA.

Instead of talking about AAA:

Authorization
Authentication
Accounting ( billing of minutes )

We can talk about just AA.  This has the advantage of not having to transfer
the old state.  A mobile may choose to, under a reactive handoff not to
request that the old state be transferred when transferring only reliable
microflows.  Instead, it may choose to get AA at the new AP.  This will
result in faster handoffs for mobiles that don't need Accounting.  The old
AP and PDP can be notified after the handoff.

A PDP in a *particular network* is implemented in the Mobile.  I think we
want to say the AP's PDP since we are dealing with an edge network. 

Key Distribution Center:

I have a problem with a key distribution entity sending keys over a wireless
link.  Anyone nearby listening to the wireless transmission has the
potential to sniff the key.  There should be a requirement for the correct
level of encryption to be enabled before a key is sent, or a requirement
that a wired link be used.

The KDC may not exist in the Home Node.  The KDC in a *particular network*
is implemented in the Mobile.  A mobile with a KDC may have greater
authority than a mobile without an internal KDC.  

I think if we need to contact a particular entity for a particular service,
lets say an Accounting service for billable minutes, then this service would
have a KDC associated with it.  A *particular network* using a Billable
Minutes business model could make the Accounting service mandatory when its
interface is activated.

I am also thinking of a banking service like "Account Inquiry", or "Bill
Payment" provided by a bank.  A bank will want its own separate KDC.  When a
mobile requests the "Account Inquiry" service the bank's PDP would set KDC
policy.  Such as what level of encryption is mandatory, and how the keys
must be exchanged, etc.

What this suggests is that Accounting is an application layer service that
wireless networks using a Billable Minutes business model have placed lower
down in the stack.  By moving Accounting out the Seamoby protocol and
attaching it to a particular interface, we can make Seamoby more network
independant.  

Wake-up Sequence:

The problem with this sequence is that it does not require positive
confirmation of a mobile's existence after sleep mode is initiated.  This is
similar to a memory leak in an OS.  Failing, absent, or devices experiencing
interference are not detected.  Unused network resources are not recovered
in a well bounded time limit.  Since we want real-time performance, we want
all network activity to be well bounded.  Also, since only a downlink is
provided there is no way for the mobile to ever ask for an uplink.  The user
may want to send something: The sleep of death. :)

A better way is for the mobile to provide positive confirmation of its
operational status by transmitting a small ID, or Null packet at an agreed
upon time interval.  This is the only practical solution to the "Ships in
the Night" problem.

Uplink/Downlink:  Some networks have bi-directional links (Simplex).  Maybe,
upstream and downstream, or upflow and downflow are more link independent
terms.

Some new terms,

The issuing of a Switch Trigger is the point-of-no-return.  A switch timeout
will be started to ensure that the mobile has not failed, or lost
communications.  The mobile will select the moment such that end user
activity is least affected.  A Switch Trigger will start the critical
portion of a transfer process for the APs. 

In-order Switch Trigger:  A mobile requests that the old state be
transferred first before the new link is made active.  Reliable micro-flows
will be redirected in a timely manner.  Unreliable micro-flows will be
started at the new AP.  Proactive handoff trigger required.

Reliable Micro-flow Switch Trigger:  A mobile requests that the link be made
active first, and that the old state be terminated in a timely manner.
Reliable micro-flows will be redirected in a timely manner.  No unreliable
micro-flows exist.  Fast reactive handoff trigger possible.

Unreliable Micro-flow Switch Trigger:  A mobile requests that only
unreliable micro-flow context be transferred first, before a new link is
made active.  Reliable micro-flows will be re-directed in a timely manner.
Unreliable micro-flows will be started at the new AP.  Fast proactive
handoff trigger possible. 

Mobile Switch Start Command:  If the mobile sent the switch trigger the old
AP may provide switch parameters with this message.  If the AP sent the
switch trigger the mobile may combine the switch parameters with the switch
trigger message.

Mobile Switch Complete Event:  The Mobile indicates to new AP that the
Mobile switch is complete.  The new AP directs old AP to complete switch.

Old AP Switch Complete Event:  The old AP indicates to new AP that the old
AP switch is complete.

A Switch Trigger may be preceded by a Handoff Request (Proactive).
Depending on circumstances, or network type either the mobile, or AP may
perform a handoff decision followed by a Handoff Request.  A Handoff Request
causes both sides to make preparations for a transfer, knowing that the
issuing of a Handoff Cancel Request will abort the Handoff process.

When the old state is terminated, any "in flight" packets between the access
router and old AP are forwarded in a timely manner.  A mobile moving inside
of a network type (micro-mobility?) may not need the old state transferred
if it is using only reliable flows.  The access router may be asked to
re-associate the state for the mobile to the new AP.

Mobile Node IP Address:  An IPv6 address that is constant for the life of
the mobile.

Mobile Repository:  A fixed location where a Mobile Locator Table is stored
that maps Mobile Node IP addresses to Current Access Router IPv6 addresses.
Can be used to redirect microflows to mobile.  A Mobile Node Locator Entry
may appear in multiple repositories to efficiently route microflows, but the
Current Access Router IP address must be the same in all entries.  

Home Router: The router where a mobile could be attached as a stationary
device without a Locator Entry.  There will be at least one MR at the Home
router.  The Home router will know the location of all MRs by way of a MR
Locator Table.  There will be one and only one active MR Locator Table and
it will be located at the Home router.

Current Access Router:  The current access router will be the router located
nearest the current AP and old AP.  The AR will also have a Mobile Locator
Table.  The AR will notify the MR(s) of Access Router changes in a
transaction based manner.

Next Access Router:  The new access router will be the closest router
located between the current AP and the next AP.

- Kulwinder.