[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [netlmm] [netext] [MEXT] NEXTEXT2: first draft of the bof description
Sri, just one question below...
On Tue, Jun 30, 2009 at 6:33 PM, Sri Gundavelli<sgundave at cisco.com> 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<sgundave at cisco.com> wrote:
>>>
>>> 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. The 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
>>>>>
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> netext mailing list
>>>> netext at ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netext
>>>>
>>>>
>>> _______________________________________________
>>> netext mailing list
>>> netext at ietf.org
>>> https://www.ietf.org/mailman/listinfo/netext
>>>
>