Re: [netext] Scope of Prefixes in Flow Mobility

[Sri Gundavelli <[e-mail]>]

> The LMA will be receiving a PBU with the necessary information and can take
> the decision on whether to assign multiple prefixes or the same across
> different access networks.

(Couple of slides attached)

The above approach will always will result in a single prefix allocation
across interfaces, which is not desirable. If the feature is active, we
start with one prefix on a interface and start sharing on the other
interface. Couple of points:

1.) For each new interface attachment, always allocate a new prefix, or set
of prefixes, just as in 5213.
2.) However, if the flow policy requires an existing active flow on a
different interface to be relocated to the new interface, the approach of
prefix sharing across interfaces can be considered.

As I said yesterday (please see the attached slides), we have 4 scenarios.
Scenario-1 and Scenario-2 are covered in 5213. Now, we have scenario-3,
moving all the flows associated with a prefix (i.e. Using the source address
from the same prefix) i.e. Mohana's draft, to a new interface. This is
almost like Sceanario-1, we have proper indicators.

The other scenario, which I never liked is scenario-4, requiring shared
prefixes across interfaces. But, scenario-4 and scenario-2 should not be
seen as mutually exclusive. In other words, its not always multihoming vs
prefix sharing, but rather its always multihoming, but some flows that had
to moved to different interface (determined by policy), even if they are
using a prefix from the prev interface, we need to share so those flows can
be relocated. Assuming new flows will pick up the right source
address/interface selection and eventually keeping the prefixes to the
respective interfaces.


Sri







On 8/5/10 2:09 AM, "MELIA, TELEMACO (TELEMACO)"
<[e-mail]> wrote:

> Hi all,
> 
> Let me share few thoughts with you.
> 
> I think that the flow mobility feature can be regarded as a service to which
> mobile customers subscribe.
> This can be a flag in  the mobile node's profile (section 6.2 of RFC 5213). I
> suggest to extend the mandatory fields by adding the flow mobility service.
> The LMA will be receiving a PBU with the necessary information and can take
> the decision on whether to assign multiple prefixes or the same across
> different access networks. The presence of the flow mobility bit implicitely
> triggers the extended prefix assignment algorithm.
> The LMA will not be aware of the logical interface but knows that the MN can
> handle flow mobility.
> 
> Now, about filters vs. prefix only configured in the MAG for flow mobility. I
> think we should be flexible and allow both to be transferred to the MAG. This
> allows the MAG to understand flows if required (else routing is only possible
> via IP addreses).
> 
> telemaco 
> ________________________________________
> From: [e-mail] [[e-mail]] On Behalf Of Sri
> Gundavelli [[e-mail]]
> Sent: Thursday, August 05, 2010 5:18 AM
> To: Tran Minh Trung
> Cc: [e-mail]
> Subject: Re: [netext] Scope of Prefixes in Flow Mobility
> 
> 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
>>> 
>> 
>> 
> 
> _______________________________________________
> netext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netext