Hi Alex,
Thank you very much for the detailed review and comments. I have tried to
answer them, but if I was not able to be clear enough, I will be happy to
discuss this with you.
I am removing parts of the previous exchange so that everyone can find the open
questions and answers more easily.
Regards,
/Danny
--------------- Text removed from previous exchange-----------------
--------------------------------------------------------------------------------
Alex >
Yet, some questions arise:
The apps which don't require a session-lasting IP address can obviously work
with a session-lasting IP address too. So some of the session-lasting IP
addresses can be non-persistent IP addresses?
Danny >
True, applications that do not require a session-lasting IP address can work
correctly with a session-lasting IP address. But in that case, the network will
invest resources in guaranteeing this without any real need and thus, these
resources will be wasted. From the application side, its traffic may suffer
from the treatment associated with providing session-lasting characteristics
(non-optimal routing, encapsulation/decapsulation overhead which influences
MTU, etc). Still, I believe that there will be cases when this is performed.
One example is in cellular networks that automatically provide tunneling and do
not support the ability to receive IP address type requests from the mobile
node.
But, if an application requests a session-lasting IP address, and the network
provides one, it should treat it as such - e.g. provide IP continuity guarantee
throughout the lifetime of the session. The network cannot tell if the address
is 'really' using the guarantee or not.
I did not understand what you mean by 'So some of the session-lasting IP
addresses can be non-persistent IP addresses?'. No, if the network provides a
session-lasting IP address, it is committed to guarantee it (even if the
application does not need the service).
Alex >
The apps which require a session-lasting IP address wish to introduce overhead
in the network?
Danny >
Apps which require session-lasting IP addresses are apps that cannot recover
from the event of source IP addresses becoming obsolete as a result of the
mobile node moving to a LAN with a different IP prefix. This is why they
request a session-lasting IP address. Not because they wish to introduce
overhead - this is a by product...
Alex >
Mobile operators using GTP or PMIP do not provide non-persistent IP addresses?
Danny >
Mobile operators using GTP or PMIP provide a guarantee that the source IP
address they allocated to a mobile node will continue to exist (and be valid)
as long as the mobile node is connected to the network (or as long as the DHCP
lease condition are meat - if DHCP is used). This even a better guarantee than
what we defined by 'session-lasting' IP address, because the GTP/PMIP source IP
address is guaranteed regardless of the initiation/end of IP session. In our
understanding, this extra guarantee is not really needed and in the DMM
environment where they may be multiple mobility anchors might even introduce
inefficient routing (which could be avoided in the newly introduced scheme).
To the best of my knowledge, mobile operators do not provide non-persistent IP
addresses.
Alex>
> Basically, current implementations provide a guarantee for the source
> IP address to be valid throughout the time the mobile host is
> connected to the mobile network. We concluded that mobile hosts do not
> really require such a guarantee. It is sufficient to require a
> guarantee of the IP address availability while there is/are an IP
> session(s) using this IP address and hence the more accurate
> definition.
I dont understand.
Until here the app requirements where important. Now we change to make the
mobile host to be important(?)
Danny >
In current implementation a source IP address is allocated to the mobile host
and is valid throughout the connection of the mobile host to the network. This
is why I use the term 'mobile host' in the description that you quoted.
We are introducing an new concept - 'OnDemand' - where each time an IP session
is created (by an application running on the host), an application can request
a specific source IP address for that session (with specific type). From the
network's perspective, this address was allocated to a mobile host. This means
that at any given time, a mobile host might have more than one source IP
address allocated to in, and different IP sessions initiated by that host (by
different applications running on that host) may be used in different packets
being sent/received by it.
I can understand why this is confusing. If this explanation is not sufficient,
I will be happy to discuss this point with you.
Alex >
> Furthermore, some WG members have shown cases in DMM where it is more
> efficient for applications to request a new Session-lasting IP address
> when launched rather than using an existing one that was allocated to
> the mobile host in the past.
Well, I wonder about this.
Danny >
Well, they did not use the term 'OnDemand' specifically, but they did show that
in a distributed mobility anchor scheme, there are cases where allocating a new
IP address may result in a more optimal route of the IP flow compared with
using the already-allocated IP address. This is because the original IP address
is served by one mobility anchor (hence all traffic must be routed through it),
and after the mobile host moves to a new location, traffic may possibility be
routed via a different mobility anchor which is topologically better. Once
again, we can further discuss this topic).
Please refer to the following IDs:
https://datatracker.ietf.org/doc/draft-bernardos-dmm-distributed-anchoring/
https://tools.ietf.org/html/draft-seite-dmm-dma-07
Alex >
In the environments I work I never saw an application (e.g. a browser) to
request an IP address. It is the connection manager which deals with address
configuration. This connection manager is not in contact with other
applications like web browsers.
Danny >
That is correct - application do not request IP addresses. This is a new
concept we are introducing. Application, through the Socket interface, can
indicate to the TCP/IP stack, the type of source IP address they require. The
TCP/IP stack, will ether associate an existing IP address with that Socket or
initiate a request to the network for a source IP address of the desired type.
Alex >
> This is due to possible movement of the mobile host to a LAN which is
> being served by a mobility anchor that is different from the one that
> was used when the older Session-lasting IP address was assigned to the
> mobile host. Fixed IP address (no renaming ...): We believe that this is
> where our original text was the most unclear leading to the confusion
> on the mailing list and the comments from the flour.
> A Fixed IP address is guaranteed by the network to Always be valid,
> even if the mobile host is not utilizing any IP sessions, or has been
> disconnected from the network for some time. This is a special service
> that mobile network operators provide for a premium charge, for
> servers, VPNs , secured content and other applications. With this IP
> address type the network operator provide IP address reachability in
> addition to IP session continuity, and mobile hosts may register these
> addresses in DNS infrastructure for name resolution.
I can understand the intention of the fixed IP address definition.
But I wonder whether there can be an improved definition of a fixed IP address.
Because of the following:
A 'fixed' IP address, as much as it can be guaranteed by an operator at a
premium cost, will not be possible if moving to a more remote area:
for example, when moving from US to Europe can not maintain that fixed IP
address even if it is paid a very high price.
Danny >
With the appropriate roaming implementation, even this can be achieved. But,
when moving to an area where no roaming partner exists, you are correct. But
this sounds to me like a business issue, not technical.
Alex >
> Clearly, most mobile hosts do not require Fixed IP
Again: _mobile hosts_ require? Or apps require?
Danny >
You are correct. Its applications, not mobile hosts...
Alex >
A more coherent definition can take advantage of using only app requirements,
or only mobile host reqs, or both but everywhere (i.e.
each of the 3 types of addresses relates to both MH reqs and to app reqs).
Danny >
I agree
Alex >
> addresses and their owners will not pay the premium cost for this
> service, but still, it is a service that mobile operators provide and
> this is enough proof for us to acknowledge its need.
> Please see some examples
Thank you very much for these pointers. This makes it easier to understand the
intention.
> from AT&T -
> _https://www.wireless.att.com/businesscenter/solutions/connectivity/ip
> -addressing.jsp_,
Is this IPv4 only?
> Verizon -
> _http://www.verizonwireless.com/businessportals/support/features/data_
> services/static_ip.html_
Is this IPv4 only?
> Sprint -
> _https://www.sprint.com/business/solutions/sprint_enablers/sprint_data
> link_and_static_ip/index.html#.VxC7xSN9480_
Is this IPv4 only?
I am asking the IP version question because address configuration is very
different in IPv6 than IPv4.
For example, in IPv6 the network does not assign an address to a host (as in
IPv4 is done with context setup), but advertises a prefix to a link and the
host forms an address. In such a context the potential mechanism to achieve
static IP addresses is very different - not only the network is in charge but
the terminal too.
Moreover, whereas in IPv4 cellular networks the mechanism to achieve static IP
address is standardised (NAI, PDP context setup, ppp), in IPv6 there is no such
mechanism standardised nor deployed.
Is there an example of deployed static IPv6 addresses in cellular networks? (as
the IPv4 example of AT&T, Verizon, Sprint). That would be very relevant too.
Danny >
Well, to the best of my knowledge, IPv4 is still more popular than IPv6 in the
States. But if this service is available for IPv4 today, I believe operators
will provide it with IPv6 service once they believe there is a business
justification. We do not want to prevent this right?
Alex
---------------------------------------------------------------------
A member of the Intel Corporation group of companies
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm
