[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [netlmm] [MEXT] [netext] NEXTEXT2: first draft of the bof description

To: <Basavaraj.Patil at nokia.com>, <marcelo at it.uc3m.es>
Subject: Re: [netlmm] [MEXT] [netext] NEXTEXT2: first draft of the bof description
From: Hesham Soliman <hesham at elevatemobile.com>
Date: Wed, 01 Jul 2009 10:34:01 +1000
Cc: netlmm at ietf.org, netext at ietf.org
Delivered-to: netlmm at core3.amsl.com
In-reply-to: <C66F9ED7.2A792%basavaraj.patil at nokia.com>
List-archive: <http://www.ietf.org/mail-archive/web/netlmm>
List-help: <mailto:netlmm-request@ietf.org?subject=help>
List-id: NETLMM working group discussion list <netlmm.ietf.org>
List-post: <mailto:netlmm@ietf.org>
List-subscribe: <https://www.ietf.org/mailman/listinfo/netlmm>, <mailto:netlmm-request@ietf.org?subject=subscribe>
List-unsubscribe: <https://www.ietf.org/mailman/listinfo/netlmm>, <mailto:netlmm-request@ietf.org?subject=unsubscribe>
Thread-index: Acn5kqjXH9wejvH2ykym7Pqo3qqaXgACA+CbABI6J3s=
Thread-topic: [netlmm] [MEXT] [netext] NEXTEXT2: first draft of the bof description
User-agent: Microsoft-Entourage/12.19.0.090515
Hi Raj, 

I told Marcelo I'll go through the exercise from the beginning again, but I
can't help respond to this comment.



>> => Ok, you're right about my assumption about the answer but it's not coming
>> from vaccuum :), it's not the first time this is discussed. But ok, I'm
>> happy to go through this exercise from the beginning. Let's ask "what" and
>> regardless of the answer ask "why" as well. Because requirements always need
>> to be justified.
> 
> Quite simply, the answer is that in certain deployments it is not feasible
> to expect DS(MIP6) capability on hosts. An operator cannot expect that every
> host connecting to the network implements (DS)MIP6. The operator has no
> control of the hosts or their capabilities to a large extent. The only thing
> the operator can and does control is the network, and hence the
> consideration to add such capabilities to a deployment which used network
> based mobility protocol.

=> No one I know can get a 3G data card to access the Internet from their PC
without having to install a piece of software  on their PC to make it work.
So I think your assumption that the operator cannot mandate software on the
host is questionable, because they already do (unfortunately).

Hesham

> 
> One of the outcomes of this discussion is quite possibly the fact that the
> IETF believes the use of host based mobile IP protocols is the right choice
> and recommends it as such. And that is fine. But I think we should also
> consider the approaches to providing these features for PMIP6 which would
> not necessarily result in reinventing host based mobile IP type of
> capabilities on the MNs.
> 
> I don't know if the above justifies the reason why we are having this
> discussion (yet again :) ).
> 
> -Raj
> 
>> 
>> Hesham
>> 
>>> 
>>> Regards, marcelo
>>> 
>>>> Hesham
>>>> 
>>>> 
>>>>> Regards, marcelo
>>>>> 
>>>>> 
>>>>> Hesham Soliman escribió:
>>>>> 
>>>>>> A quick comment.
>>>>>> I don't see any reason for an IETF WG to look for a solution that works
>>>>>> for
>>>>>> a limited set of technologies and try to solve that on layer 2. This is
>>>>>> clearly not our job. Similarly, there is little gain in solving this for
>>>>>> a
>>>>>> limited set of technologies on L3 given that we already have a layer 2
>>>>>> agnostic solution. Why would we want to develop another one for a limited
>>>>>> set of link layers?
>>>>>> 
>>>>>> Hesham
>>>>>> 
>>>>>> 
>>>>>> On 30/06/09 10:39 PM, "marcelo bagnulo braun" <marcelo at it.uc3m.es> wrote:
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> George,
>>>>>>> 
>>>>>>> 
>>>>>> great summary
>>>>>> 
>>>>>> just one comment below...
>>>>>> 
>>>>>> 
>>>>>> George Tsirtsis
>>>>>> 
>>>>>> 
>>>>>>> escribió:
>>>>>>> With PMIP things are not so clear....it is not even clear we are
>>>>>>> 
>>>>>>> talking about the *network layer*... and thus it is not so clear how
>>>>>>> 
>>>>>>> "generic" solutions can be.
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> right, so one relevant question is how
>>>>>> 
>>>>>> 
>>>>>>> generic we want this to be.
>>>>>>> 
>>>>>>> 
>>>>>> For instance, it may be also sufficient to support
>>>>>> 
>>>>>> 
>>>>>>> inter technology
>>>>>>> 
>>>>>>> 
>>>>>> handovers for a subset of L2 technologies that can support
>>>>>> 
>>>>>> 
>>>>>>> it at the L2
>>>>>>> 
>>>>>>> 
>>>>>> as you stated.
>>>>>> So, one thing that we need to define is whether
>>>>>> 
>>>>>> 
>>>>>>> we are looking for a
>>>>>>> 
>>>>>>> 
>>>>>> solution that supports inter technology handover with
>>>>>> 
>>>>>> 
>>>>>>> any two L2
>>>>>>> 
>>>>>>> 
>>>>>> combiantios or are we looking for a solution that supports inter
>>>>>> 
>>>>>> technology handovers for a limited set of technologies?
>>>>>> I think this is a key
>>>>>> 
>>>>>> 
>>>>>>> requirements that we need to be explicit about.
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> The challenge for the BOF
>>>>>>> is to throw some light on how PMIP can be
>>>>>>> compatible with this extended
>>>>>>> functionality,  what type of additional
>>>>>>> signalling is needed, and at which
>>>>>>> layer they intend to implement such
>>>>>>> signalling. Let's see.
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> while i
>>>>>> 
>>>>>> 
>>>>>>> agree with that, i think a first step that this bof needs to
>>>>>>> 
>>>>>>> 
>>>>>> throw some light
>>>>>> 
>>>>>> 
>>>>>>> on is what are the functional requirements for the
>>>>>>> 
>>>>>>> 
>>>>>> support of the required
>>>>>> 
>>>>>> 
>>>>>>> features. I think the previous is a good example
>>>>>>> 
>>>>>>> 
>>>>>> of one requirement that we
>>>>>> 
>>>>>> 
>>>>>>> need to flesh out. There are many others.
>>>>>>> 
>>>>>>> 
>>>>>> Regards, marcelo
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> George
>>>>>>> 
>>>>>>> On
>>>>>>> Tue, Jun 30, 2009 at 1:43 AM, Charles E.
>>>>>>> 
>>>>>>> Perkins<charles.perkins at earthlink.net> wrote:
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>> Hello Basavaraj,
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>> Isn't make-before-break a function performed
>>>>>>> 
>>>>>>> 
>>>>>>>> at the link layer?
>>>>>>>> 
>>>>>>>> It
>>>>>>>> 
>>>>>>>> 
>>>>>>> certainly isn't PHY, and I wouldn't think it
>>>>>>> 
>>>>>>> 
>>>>>>>> qualifies as MAC (i.e., it
>>>>>>>> 
>>>>>>>> 
>>>>>>> doesn't control the
>>>>>>> 
>>>>>>> 
>>>>>>>> device's access to the medium).
>>>>>>>> 
>>>>>>>> Regards,
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>> Charlie P.
>>>>>>> 
>>>>>>> 
>>>>>>>> PS. Which is the proper mailing list for this
>>>>>>>> 
>>>>>>>> 
>>>>>>> discussion?
>>>>>>> 
>>>>>>> 
>>>>>>>> Basavaraj.Patil at nokia.com wrote:
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> Hi
>>>>>>>>> 
>>>>>>>>> 
>>>>>>> Frank,
>>>>>>> 
>>>>>>> 
>>>>>>>>> Make-before-break is inherently supported in certain
>>>>>>>>> 
>>>>>>>>> 
>>>>>>> technologies such as
>>>>>>> 
>>>>>>> 
>>>>>>>>> CDMA/WCDMA (which has soft HO features built in). The
>>>>>>>>> 
>>>>>>>>> 
>>>>>>> same is not possible
>>>>>>> 
>>>>>>> 
>>>>>>>>> for example in TDMA (GSM) or OFDMA (802.16e and
>>>>>>>>> 
>>>>>>>>> 
>>>>>>> WiFi). 802.16e does have a
>>>>>>> 
>>>>>>> 
>>>>>>>>> contorted mechansim for achieving the same but
>>>>>>>>> 
>>>>>>>>> 
>>>>>>> that's besides the point.
>>>>>>> 
>>>>>>> 
>>>>>>>>> So IMO it is a capability of the Phy/Mac.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>> However it is possible to emulate soft-handovers and achieve
>>>>>>> 
>>>>>>> make-before-break in certain cases. For example it is possible to be
>>>>>>> 
>>>>>>> simultaneously connected to HSPA and WiFi and accomplish a
>>>>>>> 
>>>>>>> make-before-break
>>>>>>> 
>>>>>>> 
>>>>>>>>> HO. I guess the definition of the term depends on an
>>>>>>>>> 
>>>>>>>>> 
>>>>>>> access tchnology or
>>>>>>> 
>>>>>>> 
>>>>>>>>> the
>>>>>>>>> combination of access technologies in the
>>>>>>>>> 
>>>>>>>>> 
>>>>>>> context of a use-case.
>>>>>>> 
>>>>>>> 
>>>>>>>>> -Raj
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On 6/29/09 4:36 PM, "ext Frank
>>>>>>>>> 
>>>>>>>>> 
>>>>>>> Xia" <xiayangsong at huawei.com> wrote:
>>>>>>> 
>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> Hi Raj
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>> IMHO Make-before-break is not a link-layer technology.
>>>>>>> 
>>>>>>> 
>>>>>>>>>> , but  a concept
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>> (or a strategy).    Related to the topic we
>>>>>>> 
>>>>>>> 
>>>>>>>>>> are discussing, making target
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>> interface ready before moving
>>>>>>> 
>>>>>>> 
>>>>>>>>>> traffic to it is kind of
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>> make-before-break.
>>>>>>> 
>>>>>>> 
>>>>>>>>>> BR
>>>>>>>>>> Frank
>>>>>>>>>> 
>>>>>>>>>> ----- Original Message
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>> -----
>>>>>>> 
>>>>>>> 
>>>>>>>>>> From: <Basavaraj.Patil at nokia.com>
>>>>>>>>>> To:
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>> <xiayangsong at huawei.com>; <marcelo at it.uc3m.es>; <netext at ietf.org>;
>>>>>>> 
>>>>>>> <mext at ietf.org>; <netlmm at ietf.org>
>>>>>>> 
>>>>>>> 
>>>>>>>>>> Cc: <netext-chairs at tools.ietf.org>;
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>> <rdroms at cisco.com>
>>>>>>> 
>>>>>>> 
>>>>>>>>>> Sent: Monday, June 29, 2009 3:43 PM
>>>>>>>>>> Subject: Re:
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>> [netext] [netlmm] NEXTEXT2: first draft of the bof
>>>>>>> 
>>>>>>> description
>>>>>>> 
>>>>>>> 
>>>>>>>>>> Hi Frank,
>>>>>>>>>> 
>>>>>>>>>> Comments
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>> inline:
>>>>>>> 
>>>>>>> 
>>>>>>>>>> On 6/29/09 2:57 PM, "ext Frank Xia"
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>> <xiayangsong at huawei.com> wrote:
>>>>>>> 
>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>> Hi
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>> Raj
>>>>>>> 
>>>>>>> 
>>>>>>>>>>> My main point is make-before-break strategy
>>>>>>>>>>> is the best
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>> way to solve multi-radio handover.
>>>>>>> 
>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> The IETF cannot
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>> do anything about whether an MN has the ability to
>>>>>>> 
>>>>>>> 
>>>>>>>>>> accomplish
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>> make-before-break connectivity. It depends on the link-layer
>>>>>>> 
>>>>>>> 
>>>>>>>>>> technology,
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>> spectrum that they operate in, etc. So this approach is a
>>>>>>> 
>>>>>>> 
>>>>>>>>>> non-starter.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>> The IETF solution has to be agnostic to underlying access
>>>>>>> 
>>>>>>> technologies.
>>>>>>> 
>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>> Please see my inline
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>> response.
>>>>>>> 
>>>>>>> 
>>>>>>>>>>> BR
>>>>>>>>>>> ----- Original Message -----
>>>>>>>>>>> From:
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>> <Basavaraj.Patil at nokia.com>
>>>>>>> 
>>>>>>> 
>>>>>>>>>>> To: <xiayangsong at huawei.com>;
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>> <marcelo at it.uc3m.es>; <netext at ietf.org>;
>>>>>>> 
>>>>>>> 
>>>>>>>>>>> <mext at ietf.org>;
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>> <netlmm at ietf.org>
>>>>>>> 
>>>>>>> 
>>>>>>>>>>> Cc: <netext-chairs at tools.ietf.org>;
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>> <rdroms at cisco.com>
>>>>>>> 
>>>>>>> 
>>>>>>>>>>> Sent: Monday, June 29, 2009 11:50 AM
>>>>>>>>>>> Subject:
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>> Re: [netlmm] NEXTEXT2: first draft of the bof
>>>>>>> description
>>>>>>> 
>>>>>>> 
>>>>>>>>>>> Frank,
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> On 6/29/09 11:16
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>> AM, "ext Frank Xia" <xiayangsong at huawei.com> wrote:
>>>>>>> 
>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>> Hi Guys
>>>>>>>>>>>> 
>>>>>>>>>>>> I have comments on inter-technology
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>> handover.
>>>>>>> 
>>>>>>> 
>>>>>>>>>>>> IMHO, flow mobility could solve problems
>>>>>>>>>>>> which
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>> inter-tech handover is try to deal with.
>>>>>>> 
>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> Flow
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>> mobility also includes the ability to move a flow from one mobility
>>>>>>> 
>>>>>>> session to another. Multiple mobility sessions could be established via
>>>>>>> 
>>>>>>> a
>>>>>>> 
>>>>>>> 
>>>>>>>>>>> single interface in which case flow mobility would be achieved
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>> within
>>>>>>> 
>>>>>>> 
>>>>>>>>>>> the
>>>>>>>>>>> scope of a single interface. Hence flow mobility and
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>> inter-technology
>>>>>>> 
>>>>>>> 
>>>>>>>>>>> handovers are separate features.
>>>>>>>>>>> Frank=>IMHO,
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>> inter-technology is trying to move all the traffic on
>>>>>>> 
>>>>>>> 
>>>>>>>>>>> one interface to
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>> another interface.
>>>>>>> 
>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> Right. I guess you answered the
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>> question about the difference between
>>>>>>> 
>>>>>>> 
>>>>>>>>>> flow
>>>>>>>>>> mobility and
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>> inter-technology handovers. You could extrapolate and say
>>>>>>> 
>>>>>>> 
>>>>>>>>>> that
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>> inter-technology HO is the case where you move all flows from one
>>>>>>> 
>>>>>>> interface
>>>>>>> 
>>>>>>> 
>>>>>>>>>> to another and hence a variant of flow mobility. While that is
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>> true, you
>>>>>>> 
>>>>>>> 
>>>>>>>>>> should also recognize that the granularity of flow mobility is
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>> finer and
>>>>>>> 
>>>>>>> 
>>>>>>>>>> does not have to necessarily be a relocation of a flow between
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>> physical
>>>>>>> 
>>>>>>> 
>>>>>>>>>> interfaces.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>>> I assume that two
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>> heterogeneous interfaces are
>>>>>>> 
>>>>>>> 
>>>>>>>>>>>> all active during the handover.  It is
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>> easy to move
>>>>>>> 
>>>>>>> 
>>>>>>>>>>>> a flow(or all flows) from an interface to
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>> another.
>>>>>>> 
>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> Possibly.. But the point is to
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>> identify what extensions (possibly to the
>>>>>>> 
>>>>>>> 
>>>>>>>>>>> MN)
>>>>>>>>>>> are needed in order
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>> to achieve handovers across interfaces.
>>>>>>> 
>>>>>>> 
>>>>>>>>>>> Frank=>If we see inter-tech
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>> handover as a subset of flow mobility,
>>>>>>> 
>>>>>>> 
>>>>>>>>>>> there is one problem left, that
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>> is flow mobility.
>>>>>>> 
>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> See above. Flow mobility is a
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>> feature that can work across multiple
>>>>>>> 
>>>>>>> 
>>>>>>>>>> mobility
>>>>>>>>>> sessions within the
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>> scope of a single interface as well.
>>>>>>> 
>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>>> This is
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>> probably the reason why there is no
>>>>>>> 
>>>>>>> 
>>>>>>>>>>>> inter-tech handover solution
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>> standerdized
>>>>>>> 
>>>>>>> 
>>>>>>>>>>>> for client MIP.
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> Client
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>> MIP inherently supports handovers across multiple interfaces.
>>>>>>> 
>>>>>>> Performance improvements to the handovers are accomplished using
>>>>>>> 
>>>>>>> solutions
>>>>>>> 
>>>>>>> 
>>>>>>>>>>> such as FMIP.
>>>>>>>>>>> Frank=>Maybe, I am missing something.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>> However FMIP  is not applicable
>>>>>>> 
>>>>>>> 
>>>>>>>>>>> to PAR/NAR collocated scenario.  For
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>> example, a mobile node with two
>>>>>>> 
>>>>>>> 
>>>>>>>>>>> interface connects to the same access
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>> router (ASN-GW for WiMAX,
>>>>>>> 
>>>>>>> 
>>>>>>>>>>> PDN-GW for LTE).   Does FMIP work when mobile
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>> node handover from
>>>>>>> 
>>>>>>> 
>>>>>>>>>>> one technology to another?
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> Not sure I understand the question. In your example above, I believe
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>> the
>>>>>>> 
>>>>>>> 
>>>>>>>>>> MN
>>>>>>>>>> would connect to the ASN-GW via the WiMAX interface and to an
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>> S-GW via
>>>>>>> 
>>>>>>> 
>>>>>>>>>> the
>>>>>>>>>> LTE interface. The P-GW (LMA) may be the same. If the
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>> question is, can
>>>>>>> 
>>>>>>> 
>>>>>>>>>> you
>>>>>>>>>> use FMIP to optimize handovers in such a
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>> scenario... Yes. Not FMIP, but
>>>>>>> 
>>>>>>> 
>>>>>>>>>> PFMIP6 (ref. MIPSHOP WG I-D). But I don't
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>> think we are looking at
>>>>>>> 
>>>>>>> 
>>>>>>>>>> optimizing
>>>>>>>>>> handovers in this
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>> discussion.
>>>>>>> 
>>>>>>> 
>>>>>>>>>> As per the current PMIP6 specification wherein no changes to
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>> the host are
>>>>>>> 
>>>>>>> 
>>>>>>>>>> required, it is not possible to do an inter-technology
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>> handover. This is
>>>>>>> 
>>>>>>> 
>>>>>>>>>> a
>>>>>>>>>> limitation which implies that PMIP6 provides
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>> host mobility to an MN
>>>>>>> 
>>>>>>> 
>>>>>>>>>> within
>>>>>>>>>> the scope of a single access
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>> technology. Host based mobile IP does not
>>>>>>> 
>>>>>>> 
>>>>>>>>>> have
>>>>>>>>>> this
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>> problem.
>>>>>>> 
>>>>>>> 
>>>>>>>>>> -Raj
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>> -Raj
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>> BR
>>>>>>>>>>>> Frank
>>>>>>>>>>>> 
>>>>>>>>>>>> ----- Original Message -----
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>> From: "marcelo bagnulo braun" <marcelo at it.uc3m.es>
>>>>>>> 
>>>>>>> 
>>>>>>>>>>>> To:
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>> <netext at ietf.org>; "mext" <mext at ietf.org>; <netlmm at ietf.org>
>>>>>>> 
>>>>>>> 
>>>>>>>>>>>> Cc:
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>> <netext-chairs at tools.ietf.org>; "Ralph Droms" <rdroms at cisco.com>
>>>>>>> 
>>>>>>> 
>>>>>>>>>>>> Sent:
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>> Sunday, June 28, 2009 1:16 PM
>>>>>>> 
>>>>>>> 
>>>>>>>>>>>> Subject: [netlmm] NEXTEXT2: first draft
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>> of the bof description
>>>>>>> 
>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>> Hi,
>>>>>>> 
>>>>>>> 
>>>>>>>>>>>> This is a first draft of the BOF description for your
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>> consideration.
>>>>>>> 
>>>>>>> 
>>>>>>>>>>>> It
>>>>>>>>>>>> is
>>>>>>>>>>>> still very open so, feel free to
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>> comment on whether the proposed
>>>>>>> 
>>>>>>> 
>>>>>>>>>>>> approach
>>>>>>>>>>>> seems appropriate or
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>> not.
>>>>>>> 
>>>>>>> 
>>>>>>>>>>>> NETEXT2 BOF description
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>> -----------------------
>>>>>>> 
>>>>>>> 
>>>>>>>>>>>> Proxy Mobile IPv6 (PMIP6) [RFC5213] is
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>> a network based mobility
>>>>>>> 
>>>>>>> 
>>>>>>>>>>>> protocol built on Mobile IPv6 [RFC3775].
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>> PMIP6 provides mobility to
>>>>>>> 
>>>>>>> 
>>>>>>>>>>>> IP hosts without requiring any protocol
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>> enhancements or additional
>>>>>>> 
>>>>>>> 
>>>>>>>>>>>> capabilities on the host.
>>>>>>>>>>>> Current
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>> PMIP6 specification fully defines how to provide mobility
>>>>>>> 
>>>>>>> 
>>>>>>>>>>>> support for
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>> mobile nodes with a single interface roaming in a PMIP6
>>>>>>> 
>>>>>>> 
>>>>>>>>>>>> domain. The
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>> goal of this BOF is gain understanding of how to support
>>>>>>> 
>>>>>>> 
>>>>>>>>>>>> nodes with
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>> multiple interfaces (of possible different technologies) in
>>>>>>> 
>>>>>>> 
>>>>>>>>>>>> a
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>> PMIP6 network.
>>>>>>> 
>>>>>>> 
>>>>>>>>>>>> In particular, this BOF assumes the following
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>> scenario:
>>>>>>> 
>>>>>>> 
>>>>>>>>>>>> We have a single PMIP6 domain that has deployed
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>> multiple
>>>>>>> 
>>>>>>> 
>>>>>>>>>>>> access technologies and needs to support nodes that
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>> have
>>>>>>> 
>>>>>>> 
>>>>>>>>>>>> multiple interfaces, possibly of different
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>> technologies.
>>>>>>> 
>>>>>>> 
>>>>>>>>>>>> In particular, the following capabilities are
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>> needed:
>>>>>>> 
>>>>>>> 
>>>>>>>>>>>> - Inter-technology handover support. The MN has
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>> initiated a
>>>>>>> 
>>>>>>> 
>>>>>>>>>>>> communication over one interface and it needs to be able
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>> to move
>>>>>>> 
>>>>>>> 
>>>>>>>>>>>> the established connection to a different interface of
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>> a possibly different technology. The reason for moving
>>>>>>> 
>>>>>>> 
>>>>>>>>>>>> the
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>> communication to another interface is because of the MNs
>>>>>>> 
>>>>>>> 
>>>>>>>>>>>> mobility and
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>> attaching via a different interface. Basically
>>>>>>> 
>>>>>>> 
>>>>>>>>>>>> the ability to perform
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>> handovers that span different access
>>>>>>> 
>>>>>>> 
>>>>>>>>>>>> technologies.
>>>>>>>>>>>> 
>>>>>>>>>>>> -
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>> Multihoming support. The MN with multiple interfaces of possibly
>>>>>>> 
>>>>>>> different technologies should be able to use them simultaneously to
>>>>>>> 
>>>>>>> exchange data and manage the mobility of communications
>>>>>>> 
>>>>>>> 
>>>>>>>>>>>> established
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>> through the different interfaces.
>>>>>>> 
>>>>>>> 
>>>>>>>>>>>> - Flow mobility. A MN with
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>> multiple interfaces of possibly
>>>>>>> 
>>>>>>> 
>>>>>>>>>>>> different technologies must be able to
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>> move a flow from
>>>>>>> 
>>>>>>> 
>>>>>>>>>>>> one interface to another. Moreover, the MN should be
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>> able
>>>>>>> 
>>>>>>> 
>>>>>>>>>>>> to inform the network through which interface it wishes
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>> to receive different types of flows.
>>>>>>> 
>>>>>>> 
>>>>>>>>>>>> In order to provide the
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>> support for these capabilities, different
>>>>>>> 
>>>>>>> 
>>>>>>>>>>>> approaches can be
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>> envisioned, namely:
>>>>>>> 
>>>>>>> 
>>>>>>>>>>>> - L2 only approaches. In this type of approaches,
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>> the mechanisms
>>>>>>> 
>>>>>>> 
>>>>>>>>>>>> to provide the required capabilities are fully L2
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>> mechanisms and
>>>>>>> 
>>>>>>> 
>>>>>>>>>>>> no modification of the IP layer is needed.
>>>>>>>>>>>> - L3
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>> only approaches. In this type of approaches, the mechanism to
>>>>>>> 
>>>>>>> 
>>>>>>>>>>>> provide
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>> to required capabilities are located in the IP layer
>>>>>>> 
>>>>>>> 
>>>>>>>>>>>> - Hybrid L2/L3
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>> approaches. In this case, some mechanisms are
>>>>>>> 
>>>>>>> 
>>>>>>>>>>>> located in L2 and other
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>> mechanisms are located in L3.
>>>>>>> 
>>>>>>> 
>>>>>>>>>>>> Now, the different possible approaches
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>> vary greatly in their nature
>>>>>>> 
>>>>>>> 
>>>>>>>>>>>> and resulting capabilities. To
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>> understanding the benefits and
>>>>>>> 
>>>>>>> 
>>>>>>>>>>>> suitability of these alternatives, the
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>> requirements have to be
>>>>>>> 
>>>>>>> 
>>>>>>>>>>>> properly defined and
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>> understood.
>>>>>>> 
>>>>>>> 
>>>>>>>>>>>> The main goal of the BOF is understanding the need
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>> for work in the
>>>>>>> 
>>>>>>> 
>>>>>>>>>>>> IETF in this area. In order to do so, during the BOF,
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>> we will attempt
>>>>>>> 
>>>>>>> 
>>>>>>>>>>>> to:
>>>>>>>>>>>> 
>>>>>>>>>>>> 1) Understand the applicable
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>> scenarios, and the problem statement
>>>>>>> 
>>>>>>> 
>>>>>>>>>>>> related
>>>>>>>>>>>> to
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>> those
>>>>>>> 
>>>>>>> 
>>>>>>>>>>>> 2) Understand the restrictions and requirement imposed to
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>> solutions to
>>>>>>> 
>>>>>>> 
>>>>>>>>>>>> address the problem statement and scenarios
>>>>>>>>>>>> 3)
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>> Get an overview of the proposed solutions
>>>>>>> 
>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> 
>>>>>>> 
>>>>>>>>>>>> netlmm mailing
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>> list
>>>>>>> 
>>>>>>> 
>>>>>>>>>>>> netlmm at ietf.org
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>> https://www.ietf.org/mailman/listinfo/netlmm
>>>>>>> 
>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> netext mailing
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>> list
>>>>>>> 
>>>>>>> 
>>>>>>>>>>> netext at ietf.org
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>> https://www.ietf.org/mailman/listinfo/netext
>>>>>>> 
>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> 
>>>>>>> 
>>>>>>>>> MEXT mailing list
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>> MEXT at ietf.org
>>>>>>> 
>>>>>>> 
>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> MEXT mailing list
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>> MEXT at ietf.org
>>>>>>> 
>>>>>>> 
>>>>>>>> https://www.ietf.org/mailman/listinfo/mext
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> netlmm mailing list
>>>>>>> 
>>>>>>> netlmm at ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/netlmm
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> _______________________________________________
>>>>>> netlmm mailing
>>>>>> 
>>>>>> 
>>>>>>> list
>>>>>>> 
>>>>>>> 
>>>>>> netlmm at ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/netlmm
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>> 
>> 
>
Follow-Ups:
- Re: [netlmm] [MEXT] [netext] NEXTEXT2: first draft of the bof description
  - From: Basavaraj.Patil
References:
- Re: [netlmm] [MEXT] [netext] NEXTEXT2: first draft of the bof description
  - From: Basavaraj.Patil
Prev by Date: Re: [netlmm] [netext] [MEXT] NEXTEXT2: first draft of the bof description
Next by Date: Re: [netlmm] [MEXT] [netext] NEXTEXT2: first draft of the bof description
Previous by thread: Re: [netlmm] [MEXT] [netext] NEXTEXT2: first draft of the bof description
Next by thread: Re: [netlmm] [MEXT] [netext] NEXTEXT2: first draft of the bof description
Index(es):
- Date
- Thread