At 6:31 AM -0800 2/15/08, Jari Arkko wrote:
Ted,
Responding to your scope question.
Actually, we are walking a fine line with the scope. At the time that
this work got chartered, we did not have a good understanding of all the
issues.
Jari, the charter explicitly rules out some of the work in this document.
I don't have a problem with the current scope, but it isn't a fine line:
"The protocol will not attempt to hide handover between two separate
interfaces on the mobile
node." is actually one of the clearer charter statements we've ever written.
After two years of development and analysis there are some parts
of the problem space that we understand better. One of these issues
relates to being able to provide a Netlmm service without breaking
existing hosts. In 2007 it became apparent that we actually have to
understand the semantics of the host's attachment in order to not cause
a problem in situations like having two interface cards in the same host
both connected to the same Netlmm domain. Fortunately, this information
is available in certain major use cases of Netlmm. For instance, in
cellular networks the link layer actually knows what is happening when a
host moves around and can distinguish new vs. moved attachments.
At least as I understand it, this required work from folks like 3gpp; they
had to define a solution that let the network know whether a mobile
supported PMIP or not. I very much appreciate the clarity now in the document
that strongly indicates that in the absence of clear indicators that an
inter-technology attachment is a handoff, it MUST be treated as multi-homing.
Without that clarity, we would be in a far worse place.
The
support for multihoming/cross-access handovers in the document is
actually very limited, merely building on this. Its a side effect of
having to prevent a problem. As I have required that the WG not cause a
problem I also have to accept the implications. I think avoiding the
problem is more important.
(By the way, the multiple interfaces question is not the only scope
issue in the WG; they also want to work on IPv4 support. A rechartering
process is in progress for this and possibly some other extensions.)
With regards to host modifications for handling multihoming and all
types of cross-technology handovers: the current document supports
limited forms of this, and requires support from link layer to do this.
As I mentioned above such support exists in the networks that are prime
customers for this work. However, I think there is interest for an L3
solution, and I think it would be interesting work. From the perspective
of the current document that would merely be an additional source of
information. But at the same time I think it would be beneficial to look
at other issues around the multiple interfaces/handovers question. I
would support adding something along these lines to the new charter, and
have the WG produce extensions for this.
I appreciate your willingness to have this work go forward. As you recognize,
there are currently "prime customers" for this work who have a sense of
the system changes they will require to deploy inter-technology PMIP
(e.g. terminals capable of using a virtual interface over multiple physical
interfaces; handoff indicators at multiple link-layers, and so on). Without
an L3 interface that allows the terminal to support PMIP, those will be
difficult deployments. They seem to have the engineering resources
to succeed, but both that crop of networks and some not in our current
crop of customers will find this much easier going with at least the
option of using a standard L3-or-above mechanism to signal their support
of PMIP and to provide handoff indicators.
However, this should be seen as an option for relatively limited class
of networks that can actually assume host changes. For instance,
networks with purpose built handsets. I still believe in the current
charter's core idea that unmodified hosts must be able to plug into
Netlmm domains and work at least as well as they would without Netlmm.
In fact, I would go as far as stating that requiring host modifications
would be a complete non-starter for most of the applications of Netlmm
that I am aware of.
For Netllmm systems within a single technology, this is not required. It
is not even required for multi-technology hosts in a network capable of
providing inter-technology hand-off, providing the network does not try
to do inter-technology hand-off to unmodified hosts. But inter-technology
hand-off requires hosts that understand that an IP address they got on
interface0 may show up on interface1; pretty generally that involves a
modification to allow for a virtual interface that covers both.
As a result, I am against extending mn-ar-if with
new functionality and making its support a requirement for mobile nodes,
if that's what you meant.
I am on the other hand supportive of such extension. I'm even supportive
of it eventually becoming even mandatory to implement on the network
side. Perhaps this is actually what you wanted? Note that there is
really no interoperability issue with making such an extension from day
one vs. later. Hosts do not know Netlmm is running in the network, and
obviously they cannot assume they will only visit Netlmm-based networks.
As a result, whatever additional service they wish to get from the
network would have to be negotiated anyway.
Hosts that do no know NETLMM is running in an inter-technology handoff
network do not get handoff when changing technologies. They get multi-homing.
That's fine, but we need to be as clear in discussion as the draft is that this
is the case.
In the current networks, they may well signal their support and handoff at
layers below IP; for the current customers that may, indeed, work well
enough. But I believe that a standardized solution to the more general
problem is a necessary part of this solution, and we should strongly indicate
where it will fit in the toolkit as soon as possible.
For those who wonder how often the multi-interface case will arise, the laptop
I am using has 5 physical interfaces that can run IP (ethernet, bluetooth,
802.11,
firewire, evdo), and the phone sitting next to it 3 (802.11, bluetooth,
cellular).
Thanks for your response and clarifications,
Ted
Hope this clarifies,
Jari
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
http://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
http://www.ietf.org/mailman/listinfo/ietf