Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bofdescription

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 01 Jul 2009 14:31:10 +0200

Koodli, Rajeev escribió:
>
>>>   
>>>       
>> right, what are the required functions that are provided by a 
>> network based mobility that are lacking in a host based 
>> mobility approach?
>>     
>
> As a starting point, the host is not involved in mobility management
> (aka, managing persistence and reachability).
>   
right, this is what i was asking

So, i think this can be defined in terms of what is in control of the 
network, correct?
So, would it make sense to define this as a requirement that it must be 
network that decides through wich interface the node sends traffic
In particular, it is the network side that decides:
- when the node performs a handoff to the other interface
- how the traffic is distributed among interfaces
- which flow flows through each interface

Is that what you have in mind?

Regards, marcelo

> What we are looking at here is not to change the mobility management
> model (i.e., host does not know anything about mobility at L3), but to
> consider MN - Network (MAG) interactions which *may* need L3 extensions.
>   
> Regards,
>
> -Rajeev
>
>
>   
>> Regards, marcelo
>>
>>
>>     
>>> -Raj
>>>
>>>
>>>   
>>>       
>> _______________________________________________
>> netext mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/netext
>>
>>     
>
>
> This email and any attachments may contain legally privileged and/or confidential information of Starent Networks, Corp. and is intended only for the individual or entity named in the message.  The information transmitted may not be used to create or change any contractual obligations of Starent Networks, Corp.  Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this e-mail and its attachments by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify the sender immediately -- by replying to this message or by sending an email to [email-masked] -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you.
>
>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 01 Jul 2009 14:32:11 +0200

Sri Gundavelli escribió:
> Hi Marcelo,
>
>
> On Tue, 30 Jun 2009, marcelo bagnulo braun wrote:
>
>>>
>> so what is the assumption requiremnent here?
>> Is the requriemnent that the solution must work wihtout requiring any 
>> host support? Or is there some level of host support that is 
>> acceptble? If so, why? (i mena, why some level of host support is 
>> accpetbale and other is not)
>>
>>
>
> The requirement is to have that intelligence on the network for 
> supporting
> these features, while allowing the mobile node to only express 
> preferences
> on network attachment/multihoming or flow mobility.

Right, i think this can be expresserd as a requirement.
please see the email i have just sent to Rajeev

regards, marcelo

> he participation of
> the client will be to minimal proportions. The goal is to have a simple
> client, with a minimal software component such as for managing these
> aspects and not require an extensive set of protocol stacks.
>
>
>
>>>  2. An operator may choose to deploy a network with only network based
>>>  mobility protocol support
>>>
>>>
>> right, what are the required functions that are provided by a network 
>> based mobility that are lacking in a host based mobility approach?
>>
>
> I'm not sure, if we want to compare the missing features and say they
> will be available in host mobility protocols and so we go that route.
> We could have said that even before we standardized network-based
> mobility approaches. But, there is interest to support network-based
> mobility protocols and so we need to ensure we do that job completly.
>
> Industry has accepted network-based mobility approaches in the form of
> GTP/PMIPv6. We have to add the missing features and support that
> accepted model completly. This is about completing the work.
>
> Regards
> Sri
>
>
>
>
>> Regards, marcelo
>>
>>
>>>  -Raj
>>>
>>>
>>>
>>

---

From: George Tsirtsis <[email-masked]>
Date: Wed, 1 Jul 2009 16:31:28 +0100

Sri, just one question below...

On Tue, Jun 30, 2009 at 6:33 PM, Sri Gundavelli<[email-masked]> wrote:
> Hi George,
>
>
> On Tue, 30 Jun 2009, George Tsirtsis wrote:
>
>> Hey Sri,
>>
>> So let me see if I understand.
>> You think that the MN will only have to signal during network
>> attachment, so, essentially out-of-band from PMIP perspective; is that
>> correct?
>
> They can be  out-of-band from PMIP perspective, but act as triggers to
> PMIP signaling.
>
>
>> I assume by network attachment you mean on a per technology basis?
>> i.e., when WiFi IF attached to a given network, and when a 3G IF
>> attaches it signals again?
>>
>
> Yes. When the mobile attaches to the network over a given interface,
> it can identify the type of attachment (Handoff from Int-X, New
> Attachment). It can be on a per-interface basis, on every attach event.
>
> Lets take this example of host with 3G and WiFI interafaces. Possible
> scenarios:
>
> Host initially attaches over WiFI a.) Later brings up 3G interface for
> multihoming
> b.) or, performs an handoff to 3G
>
> Host attaches through 3G and Wifi interfaces and performs
> an handoff from multihoming to single attach.
> a.) WiFI b.) 3G
>
> In all these cases, I need the host to be able to suggest the
> following:
>
> Event-1: NEW ATTACHMENT, Interface Type: WiFI, IfId: 1
> Event-2: HANDOFF, FROM: 3G, IfIf:2   TO: WiFI, IfId: 1
>
> Do I need more extensive attach preferences ?
>
>
>> If yes, then what kind of network attachment signalling do you intend
>> to define in the IETF?  Could you elaborate a bit, keeping in mind
>> that network attachment is typically an L2 process (except PANA I
>> guess?)?
>>
>
> Its too early to discuss the semantics of the signaling. Its at a L2
> layer or L3-layer ... that leads to the solution discussion. I'm sure,
> we can have detailed discussions on the semantics.
>

GT> Sri, the protocol details (e.g., message format, semantics etc) is
indeed solution space. Whether this an L2 vs L3 protocol, however,
must be relevant to whether this work happens in the IETF or somewhere
else, don't you think so? Don't you think that this decision  needs to
be taken before such work goes ahead in the IETF?

>> Also, if you only signal during attachment; does it mean that
>> multi-homing feature in PMIP will ONLY apply to different technologies
>> (i.e., you exclude multihoming on the same technology)?
>>
>
> I dont follow completly.
>
> Between multihoming and inter-tech handoff, we need the host to be
> able to specify if a given attachment is as a result of bringup of
> a new interface (simultaneous attach) or a result of a handoff. The
> host and the network has the complete view of the hosts attachment
> over all its interfaces. So, not sure why the multihoming features
> will appear only across technologies.
>

GT> OK, so if two IFs of the same technology connect to the network,
they will both have to go through the attach procedures you are
talking about.

> Regards
> Sri
>
>
>
>> Thanks
>>
>> On Tue, Jun 30, 2009 at 5:36 PM, Sri Gundavelli<[email-masked]> wrote:
>>>
>>> Hi Marcelo,
>>>
>>>
>>>> host
>>>> support? Or is there some level of host support that is acceptble? If
>>>> so,
>>>> why? (i mena, why some level of host support is accpetbale and other is
>>>> not)
>>>>
>>>>
>>>
>>> on network attachment/multihoming or flow mobility. The participation of

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Wed, 1 Jul 2009 19:02:17 -0400

Hi Marcelo, 

> So, i think this can be defined in terms of what is in 
> control of the network, correct?
> So, would it make sense to define this as a requirement that 
> it must be network that decides through wich interface the 
> node sends traffic In particular, it is the network side that decides:

Yes, this is a good formulation. 

Thanks,

-Rajeev

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 02 Jul 2009 09:39:42 +0200

> Yes, this is a good formulation. 
So, i understand that the answer to the question 3

3)- What capabilities need to be controlled by the network?
When the MN performs a handover from one interface to another one?
How the node distributes the load among interfaces? in which direction?
Which flow is routed through which interface? in which direction?

Is the network in all cases, correct?
That would be a requirement for the solution?

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Thu, 2 Jul 2009 13:30:49 -0400

>That would be a requirement for the solution?

For network-based mobility, it is reasonable to think that the network is in charge of inducing handovers. The control logic of when to induce handover, "which direction" etc. are node-internal; we are only interested in protocol aspects when a node does decide to act.

The granularity of handover can vary - entire HNP is moved vs. a subset of flows. Nevertheless, the design is from a network perspective. 

-Rajeev