Re: [netext] Scope of Prefixes in Flow Mobility

[Tran Minh Trung <[e-mail]>]

Hi Sri, Telemaco

On Fri, Aug 6, 2010 at 12:35 AM, Sri Gundavelli <[e-mail]> wrote:
>> 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.
>

I agree with Telemaco.

> (Couple of slides attached)
>
> The above approach will always will result in a single prefix allocation
> across interfaces, which is not desirable.

Sri, what do you mean that is is not desirable?
It is exactly the share-prefix model that I mentioned.
If we can modify the LMA/MAG operation to support it then all off 4
scenarios can coexist.


Regards.
TrungTM

> 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
>
>
> _______________________________________________
> netext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netext
>
>



-- 
Ph.D., Senior Member
Electronics and Telecommunications Research Institute
Standards Research Center
161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA
Tel : [phone],   Fax : [phone]