[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: comments on draft-larsson-v6ops-mip-scenarios-00.txt

Hi,

Sorry for a bit of delay in responding...

On Tue, 16 Nov 2004, Eva Gustafsson wrote:
First, let me say a few words about the scope of the draft. The purpose of this draft is to provide an overview of (a) possible network and handoff scenarios; (b) possible deployment cases; and (c) possible solutions. In this draft, we do not state which deployment cases are the most probable ones - we just list the possibilities. The intention is to lay out the field, so that later on, more specific problem statements and solution proposals can be made, referring to subsets of the scenarios described in this draft.

Do you have any comments on this approach?

So, you're saying this is kind of a "framework" for all the possible scenarios and solutions.

I'm not sure how sensible that is, because we don't have those specific problem statements/scenario documents. Further, such a framework document might be a wrong place to have lengthy discussion of solutions.

I certainly sympathize with you that this document should not be place to have length discussions of each scenario and the problem statement behind each scenario -- but what I did prefer to see was around a paragraph or two of text per each scenario, trying to describe it somehow, and state if that's a deployed/planned scenario (and where?), etc. -- just something minor for the readers to get a feel which scenarios are most urgent deployment/planning wise.

Generic comments:

- you raise a number of (potentials) scenarios by enumerating the
possibilities. I think it would be useful to try to describe, e.g., using a
paragraph or two each, the practical use case for each scenario if one
exists, deployments which are planned or exist, etc. -- just as a means for
us to try to identify which are the *MOST* relevant scenarios which must be
addressed.

See above. More deployment-specific problem statements can be made later, but that's not really within the scope of this draft.

I think that diminishes the value of the draft, especially as it tries to analyze the solutions -- which doesn't seem to make sense unless we have some agreement about which scenarios are actually the useful ones?

- there should probably be some form of problem statement
why dual MIP protocols is not a good thing. In each scenario, one might
also consider whether connection survivability is required in that
scenario.

See above. In this draft, we do not make statements on whether different deployment scenarios are good or not - we simply list different possibilities.

I wasn't saying "good or not" :) Just whether it exists today, is seriously planned, etc. -- something to highlight those cases which are more than rows in the matrix for completeness' sake.

If we can see that there are 2-3 most urgent problems, maybe that might be a factor in figuring out which way we need to start solving these problems.

  - it probably needs to be evaluated whether it's assumed that particular
type of access technology (and the resulting tunneling method) must be
usable everywhere, or just in particular operator's (or operators')
networks.  I.e., "where can the user roam, and still expect this to work?"
Different solutions have different assumptions on this..

Ok... I'm not sure I fully understand what you mean by "type of access technology". Could you please elaborate on this? 

Sorry, I meant like, IPv4 (private), IPv4 (public), IPv6.

For each of these also when the service is available no matter where you're located in the Internet, or whether just when you are in a particular access network (e.g., inside a particular operator's network). (This is probably a very important distinction, because these are fundamentally very different service models.)

semi-substantial
----------------

    The issue of handoff latency would be especially important in cases
    where Mobile IP provides mobility for real-time applications, e.g.
    Voice over IP calls.  In these cases, an absolute minimum of
    signaling roundtrips is required at each handoff.  Also, when running
    real-time applications, a mobile node cannot afford to await timeouts
    in deciding which mobility signaling mechanism to use when arriving
    at a new access network.

==> it's worth mentioning the unstated assumption here is that wireless
links being considered here have very long roundtrips (e.g., 0.2-1.0
seconds) that it is actually *this* what causes the problems, not as such
the number of roundtrips..

Sure, the latency depends on the length of the roundtrip as well as the number of roundtrips. We have not made any assumption on the length of the roundtrips for wireless links though.

Right.. but I think the fundamental assumption is not that the signalling roundtrips are too costly (too many bits sent), but rather because signalling with many roundtrips just takes way too much time (due to the access technology), thus the need to minimize the number of roundtrips.

    o  A solution for deployment case III (MIPv4-MIPv6) needs to handle
       network scenarios 1-2, 7-8 in Table 1 and 9-10 in Table 2.  The
       handoff scenarios listed in Tables 3 and 4 are not really
       applicable to this type of solution.  As the aim is to address
       MIPv4-MIPv6 interworking, we may assume that MIPv4 and MIPv6 run
       in parallel on the MN and the HA, and that the MN will be able to
       shift MIP version during a handoff, accommodating to the IP
       version of its current access network.  For this to work, the MIP
       stack in the MN also needs to provide the appropriate MIP
       transport for both IPv4 and IPv6 sockets.

==> "run in parallel" -- does that mean that only one version is used at a
time (as a means of transitioning from X to Y -- some UEs might implement
both, but just one both), or that both are used?

As MIPv4 does not run over IPv6, and MIPv6 does not run over IPv4, the assumption is that the MN runs MIPv4 when in an IPv4 network and MIPv6 when in an IPv6 network. 

OK.  An in a dual-stack network...?

Maybe the problem statement for deployment case III, then, is that it's OK to have to implement both MIP protocols on the hosts and HAs, but it's not OK to have to perform dual signalling either on v4-only, dual-stack or v6-only network?

    A solution of this kind consists of two parts:
    1.  Enhance MIPv4 to provide support for tunneling MIPv4 packets over
        IPv6 transports.  This solves scenario 5 in addition to 1, and
        scenario 6 if combined with the enhancement below.
    2.  Enhance MIPv4 to carry IPv6 payloads.  This solves scenario 2,
        and scenario 6 if combined with the enhancement above.

[...]

    A solution of this kind consists of two parts:
    1.  Enhance MIPv6 to provide support for tunneling MIPv6 packets over
        IPv4 transports.  This solves scenario 4 in addition to 8, and
        scenario 3 if combined with the enhancement below.
    2.  Enhance MIPv6 to carry IPv4 payloads.  This solves scenario 7,
        and scenario 3 if combined with the enhancement above.

==> I think you should also discuss how you assign v6 or v4 addresses
(respectively) on top of that link ?  I.e., how address assignment is done?

We did not consider address assignment within the scope of this draft. The only issue I can think of would be the case of an MIPv4 FA. We could elaborate on that. Was that what you had in mind?

It may not be in scope of the draft as such, but it is certainly in scope of the solutions you're discussing in the draft. MIPv4 or MIPv6 extensions (at least under certain scenarios) seem to require an address assignment mechanism, which has not been addressed in the solutions, and hence is a short-coming in the solutions.

For example, if you have a dual-stack node in a v6-only network and using MIPv6, and you want to run v4-only apps on that node, you'll need somehow to assign the v4 address on the node. Using transition mechanisms provides you an address; using MIPv6 would require that MIPv6 extension would also include a DHCP-like mechanism for the hosts to obtain a v4 address. The same applies to MIPv4 for v6 addresses.

    In general, transition mechanisms solve the issue of transporting,
    e.g.  MIPv6 over an IPv4 network (public or private).  Mechanisms in
    the host for allowing the Mobility protocol to transport multiple IP
    protocol versions, rather than only the native IP protocol version,
    need to be addressed through extensions to the Mobility protocol.

==> is the latter sentence substantiated?

As far as we understand, this would be the most straighforward way of solving it. Do you have a suggestion of alternative ways?

One could, for example, add a tunnel to the stable home address; this would cause additional encapsulation. Not sure if that would be OK, but at least it's an option.

For example, when in v4-only environment and using MIPv4, one could build a v4-in-v6 tunnel (if FA is co-located) to the v4 home address, also addressing the IPv6 address stability problems without any need for signalling etc.

--
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings