D105 Figure 3
From: Jari Arkko
Subject: [Mobike] design draft issue: figure 3
Date: Wed, 21 Dec 2005 12:51:46 +0200
| +-------------+ +---------+
| |User-space | | MOBIKE |
| |Protocols | +-->>| Daemon |
| |relevant for | | | |
| |MOBIKE | | +---------+
| +-------------+ | ^
| User Space ^ | ^
| ++++++++++++++++++++++++++++ API ++++++ API ++++ PF_KEY ++++++++
| Kernel Space v | v
| _______ | v
| +-------------+ / \ | +--------------+
| |Routing | / Trigger \ | | IPsec |
| |Protocols |<<-->>| Database |<<-+ +>+ Engine |
| | | \ / | | (+Databases) |
| +-----+---+---+ \_______/ | +------+-------+
| ^ ^ ^ | ^
| | +---------------+-------------+--------+-----+
| | v | | |
| | +-------------+ | | |
| I | |Kernel-space | | | | I
| n | +-------->+Protocols +<----+-----+ | | n
| t v v |relevant for | | v v v t
| e +----+---+-+ |MOBIKE | | +-+--+-----+-+ e
| r | Input | +-------------+ | | Outgoing | r
| f | Packet +<--------------------------+ | Interface | f
| ==a>|Processing|===============================| Processing |=a>
| c | | | | c
| e +----------+ +------------+ e
| s s
| ===> = IP packets arriving/leaving a MOBIKE node
| <-> = control and configuration operations
|
| Figure 3: Framework
I am confused by the role of the "Kernel-space protocols
relevant for MOBIKE" box in this figure. There are parts
of a node implementation that have to deal with IPsec
processing; is this what you mean? And there are parts
of a node implementation that may provide information
to, e.g., MOBIKE and MOBILE IP -- such as IPv6 NUD or
DNA. Is this what you mean? I think the latter is an important
part that should be shown, but such components would appear
to provide input to the MOBIKE daemon directly or via
a "trigger database" rather than effect input and output
processing directly.
What are "User-space Protocols Relevant for MOBIKE"?
I can't think of any...
Also, I'd rather not see "routing protocols" in this
figure, as it will confuse people. And while a trigger
database is a good idea, I'd rather not introduce it
here. It would be better to have a simplified ascii
version of the slide from IETF-62:
http://www3.ietf.org/proceedings/05mar/slides/mobike-1/sld6.htm
From: Tero Kivinen
Subject: [Mobike] D105 design draft issue: figure 3
Date: Tue, 3 Jan 2006 18:32:19 +0200
| I am confused by the role of the "Kernel-space protocols
| relevant for MOBIKE" box in this figure. There are parts
| of a node implementation that have to deal with IPsec
| processing; is this what you mean? And there are parts
| of a node implementation that may provide information
| to, e.g., MOBIKE and MOBILE IP -- such as IPv6 NUD or
| DNA. Is this what you mean?
I think both, i.e. both the IPsec processing things, i.e. for example
detecting IPsec packets coming from wrong address, etc, and also other
protocols like you list there.
There is quite limited space for drawing pictures in ascii, so it is
better to cluster things a bit more and describe the actual modules
needed, and not try to duplicate each box from the Pasi's slide.
| I think the latter is an important
| part that should be shown, but such components would appear
| to provide input to the MOBIKE daemon directly or via
| a "trigger database" rather than effect input and output
| processing directly.
The kernel-space protocols has arrows to trigger database, and to the
input / output processing.
| What are "User-space Protocols Relevant for MOBIKE"?
| I can't think of any...
DHCP, perhaps PPP etc.
| Also, I'd rather not see "routing protocols" in this
| figure, as it will confuse people.
Routing do affect the selection of the addresses and interfaces, so I
think it needs to be shown here.
| And while a trigger database is a good idea, I'd rather not
| introduce it here. It would be better to have a simplified ascii
| version of the slide from IETF-62:
I think having trigger database there actually do simplify the picture
quite a lot, and that's why I think it is good idea to keep it there.
| http://www3.ietf.org/proceedings/05mar/slides/mobike-1/sld6.htm
Simplifying that picture does not really help, as the main idea for
that picture was to so complicated enough picture having all kind of
boxes and arrows, so that everybody would understand that this MOBIKE
is only very small part of the whole solution.
Simplification of a very complicated picture which is complicated on
purpose (actually complicated to make sure it obfuscates things)
doesn't really help... :-)
From: Tero Kivinen
Subject: [Mobike] D105 design draft issue: figure 3
Date: Fri, 3 Mar 2006 15:46:44 +0200
Replaced framework picture with new one from Jari.