Re: [netext] Scope of Prefixes in Flow Mobility

[Sri Gundavelli <[e-mail]>]

Tran:

>> However, the LMA may choose to assign the same prefix(es) as well as new
>> prefix(es) if it so chooses based on the ATT field. This would be scenario 3
>> below.
>> 

Right. We assume the network provides the handover hints. We do not have the
MN-AR interface at this point. When we were writing the base spec, the MN-AR
interface was factored into the design. Julien was working on this and some
where we lost track of this critical interface.

http://tools.ietf.org/html/draft-ietf-netlmm-mn-ar-if-03

We need to revive this at some point. I was hoping Telemaco/Carlos/Juan
Carlos will revive this in for different SDO architectures, at least that
was our understanding.

http://ietfreport.isoc.org/idref/draft-melia-netext-3gpp-mn-ar-if/

Ideally, the handover hints will come from that interface. If we build this
interface, eventually, the mobile node can express the handover preferences
and flow-path preference. This will allow us to cleanly support the shared
prefix scenario.



Sri








On 8/4/10 7:09 PM, "Tran Minh Trung" <[e-mail]> wrote:

> Hi Rajeev,
> 
> Please see my comments inline:
> 
> On Thu, Aug 5, 2010 at 2:39 AM, Rajeev Koodli <[e-mail]> wrote:
>> 
>> Hi,
>> 
>> I am still trying to understand what will not work if we don't make this
>> assumption..
>> 
>> There are two parts here, which I outlined as 2) & 3) below.
>> 
>> Signaling extension in Binding Update to inform the LMA to support same
>> prefix assignment. This can be another value assignment for the HI field.
>> When this value is set, the LMA knows that it can assign the same
>> prefix(es). This is scenario 2 below.
>> 
> 
> How can we set the value of HI exactly?.  Without signaling from the
> MN, I think it is not easy.
> Let's assume that we can set the value of HI exactly. Then if the MN
> uses 2 logical interfaces to hide two different sub-interface paths,
> how can LMA differentiate them by just depending on HI?
> 
>> However, the LMA may choose to assign the same prefix(es) as well as new
>> prefix(es) if it so chooses based on the ATT field. This would be scenario 3
>> below.
>> 
> 
> I think just ATT is not enough. The MN can be equipped with 2
> interfaces using the same ATT and they can be hidden by different
> logical interface.
> 
>> So, why do we need to know anything more than this?
>> 
>> Thanks,
>> 
>> -Rajeev
>> 
> 
> PS: I can not find the scenario 2,3 that you mentioned. Are they the
> scenarios in your previous email?
> 
> Regards,
> TrungTM
> 
> 
>> 
>> On 8/3/10 11:38 PM, "Tran Minh Trung" <[e-mail]> wrote:
>> 
>>> Dear Rajeev,
>>> 
>>> Should we assume that the LMA is aware of the logical interface at the MN?.
>>> If not, how LMA can differentiate which physical interfaces are hidden
>>> by the same logical interface?
>>> If LMA can not recognize which physical interfaces are hidden by the
>>> same logical interface then it is impossible to assign prefix(es)
>>> exactly to different attachments.
>>> 
>>> In case we assume that the LMA is aware of the logical interface at
>>> the MN, then it is easy to enable LMA to assign the same prefix(es) to
>>> all attachments of the logical interface.
>>> 
>>> Thank you very much for making it more clear.
>>> Regards,
>>> TrungTM
>>> 
>>> 
>>> On Wed, Aug 4, 2010 at 2:37 AM, Rajeev Koodli <[e-mail]> wrote:
>>>> 
>>>> Hello Carlos, All,
>>>> 
>>>> We had some good discussion on the prefix model for the flow mobility work.
>>>> I have tried to capture the scenarios in the following text. Let¹s work
>>>> towards incorporating this into the draft.
>>>> 
>>>> 
>>>> X. Prefix Model
>>>> 
>>>> Flow mobility assumes simultaneous access to more than one network, in
>>>> a contrast to a typical handover where connectivity to a physical
>>>> medium is relinquished, and is re-established with another.
>>>> There are multiple prefix models under which a flow mobility protocol needs
>>>> to work:
>>>> 
>>>> 1. At the time of a new attachment, the MN obtains a new prefix or a
>>>> new set of prefixes. This is the default behavior with RFC 5213.
>>>> 
>>>> 2. At the time of a new attachment, the MN obtains the same prefix or
>>>> the same set of prefixes as already assigned to an existing
>>>> session.  This is not the default behavior in RFC 5213, and the LMA
>>>> needs to be able to provide the same assignment even for the
>>>> simultaneous attachment (as opposed to the handover scenario only).
>>>> 
>>>> 3. At the time of a new attachment, the MN obtains a combination of
>>>> prefix(es) in use and new prefix(es). This is a hybrid of the above
>>>> two scenarios. The local policy determines whether the new prefix is
>>>> exclusive to the new attachment or it can be assigned to an existing
>>>> attachment as well.
>>>> 
>>>> Among the above, scenario 2 needs extensions to RFC 5213 signaling at
>>>> the time of a new attachment. Subsequently, no further signaling may
>>>> be necessary between the LMA and the MAG. The scenario 1 requires
>>>> flow mobility signaling whenever the LMA determines the need for
>>>> relocating flows between the different attachments. The scenario 3
>>>> requires flow mobility signaling whenever the LMA
>>>> determines the need for relocating flows for the new prefix(es) which are
>>>> not shared across attachments.
>>>> In all the scenarios, a prefix has to  be valid on the
>>>> concerned MAGs in order for flow mobility to work. Furthermore, each
>>>> MAG MUST advertise to the MN the all the prefixes received from the LMA.
>>>> 
>>>> 
>>>> _______________________________________________
>>>> netext mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/netext
>>>> 
>>>> 
>>> 
>>> 
>> 
>> _______________________________________________
>> netext mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netext
>> 
> 
>