Subject: [Netext] Charter Scope and Work Items
From: pierrick.seite at orange-ftgroup.com (pierrick.seite at orange-ftgroup.com)
Date: Tue, 31 Mar 2009 15:08:35 +0200

Hi Sri,

I agree with items you are proposing. However the virtual interface may not be the only solution to support inter-technology handover. I don't think we should restrict the solution space at this stage.

Regards,
Pierrick

> -----Message d'origine-----
> De?: netext-bounces at mail.mobileip.jp [mailto:netext-
> bounces at mail.mobileip.jp] De la part de Sri Gundavelli
> Envoy??: vendredi 27 mars 2009 06:43
> ??: netext at mail.mobileip.jp
> Objet?: [Netext] Charter Scope and Work Items
> 
> IMHO, there are number of extensions to Proxy Mobile IPv6 that we need for
> successful deployment of the protocol in any system architecture. To most
> part these are minor extensions that we need them for addressing a
> deployment
> problem, alignment with other protocols such as GTP, add a minor missing
> feature useful in optimizations, or some thing that helps in
> implementations.
> 
> I've identified some work items, that we discussed in the past. This is
> just
> my opinion. Welcome to dispute. Also, Where ever we do this work, netext,
> netlmm,
> mext or mipshop, is not my interest, but we need these extensions. Thats
> the
> only part I care. If this was discussed in the past, fine, but this is my
> list as I see it, bear with me.
> 
> All the items listed here do not require host stack changes, except the
> following immediate list which may in some cases:
> 
> - Multi-homing Support, when sharing the same address on two interfaces
> - Handoff triggers from the mobile node
> - Flow Management, when not moved as a group associated to a prefix
> - Prefix coloring via RA extensions
> 
> I really hope the charter will consider most of the work items listed
> below.
> 
> 
> 
> 1. Dynamic LMA Assignment
> 
> In blade architecture systems or in a load balancer configuration, the
> PDNGW
> should have the ability to dynamically assign a LMA on the fly, along the
> lines of Mobile IPv4 Dynamic Home Agent Address Assignment support
> [RFC-4433].
> Currently, GTP provides such semantics and this is a important requirement
> for deployment. Here the goal is to
> 
> a.) Expose a single IP address to the SGW
> b.) The exposed IP address should not be in path once the assignment is
> done.
> 
> 
> 
> [LMA1]---
>   |      |
> [LMA2]--[LMA]==========[MAG]
>   |      |
> [LMA3]---
> 
> 
> Along the lines of:
> 
> http://tools.ietf.org/html/draft-korhonen-netext-redirect-01
> 
> 
> 
> 2. Multicast Support in Proxy Mobile IPv6
> 
> We need an informational specification on how multicast support can be
> enabled in Proxy Mobile IPv6 environment. Behcet has done extensive
> analysis
> on
> this. This is required and critical for enabling any multicast services.
> However,
> Behcet may disagree with the scope of the work.
> 
> 
> 
> 
> 3. Bulk Registration Support
> 
> This is a simple extension which helps in signaling optimization, along
> the
> lines of:
> 
> http://tools.ietf.org/html/draft-premec-netlmm-bulk-re-registration-02
> 
> 
> 
> 
> 4. Partial Failover Support
> 
> We need a mechanism to notify the peer on revoke a partial set of bindings.
> 
> http://tools.ietf.org/id/draft-koodli-netlmm-path-and-session-management-
> 00.
> txt
> 
> 
> 
> 
> 
> 5. Group Identifier Support for Proxy Mobile IPv6
> 
> This provides a simple and a generic semantic for assigning a group
> identifier
> to a mobile node's binding. GTP has very similar semantics, Connexion Set
> Id.
> Both #3 and #4 can leverage this. Additionally, in load balancer systems
> where
> the load balancer is in path for all signaling messages, it can use this
> as
> a
> tag for redirecting the message.
> 
> http://tools.ietf.org/html/draft-gundavelli-netext-mn-groupid-option-00
> 
> 
> 
> 6. Virtual-Interface Support on IP host for supporting Inter-tech handoffs:
> 
> 
> RFC-5213 supports handoff between two interfaces. The ability to move
> prefixes between interfaces. In other words address continuity is assured
> with any IPv6 host on the planet and with absolutely no changes. This
> meets
> even Dave's comment, that "no changes to any IETF RFC's.". Now, what is
> not assured is the aspect of session continuity. Which requires a virtual
> interface implementation on the host, by binding the address/prefix to a
> virtual interface and by not exposing the physical interface or by hiding
> the handoff events from the layer-3 stack.
> 
> In essence, we need an informational specification which provides some
> general guidance to how to leverage the feature support provided in
> RFC-5213,
> along the lines of:
> 
> http://tools.ietf.org/html/draft-yokota-netlmm-pmipv6-mn-itho-support-00
> 
> 
> 
> 7. Route Optimization for Proxy Mobile IPv6
> 
> There were atleast 4 drafts in this area on Route Optimization. Marco
> Liebsch
> analyzed this exensively:
> 
> 
> http://tools.ietf.org/html/draft-liebsch-netext-pmip6-ro-ps-00
> http://www.ietf.org/internet-drafts/draft-koodli-netext-local-forwarding-
> 00.
> txt
> 
> 
> 
> 
> 
> 8. Prefix Management in Proxy Mobile IPv6 support
> 
> Proxy Mobile IPv6 allows the assignment of multiple home network prefixes
> to a given mobile node's interface. It might be useful to specify how the
> LMA manages this aspects. It can potentially use DHCP PD, Local Pools or
> AAA to manage this aspect. Behcet has one draft on this.
> 
> 
> 
> 9. Partial Handoff Support
> 
> We are missing some semantics in 5213 for moving a subset of the prefixes
> between interfaces as part of the inter-tech handoff. This is about
> defining
> a new handoff value. This allows partial flow management, but moving the
> flows associated to a prefix, as a whole group.
> 
> http://tools.ietf.org/html/draft-jeyatharan-netext-pmip-partial-handoff-00
> 
> 
> 
> 
> 10. CMIPv4/PMIP Interworking
> 
> This is probably required to specify how an IPv4-only can move between
> CMIP and PMIP environments.
> 
> http://sunsite.mff.cuni.cz/MIRRORS/ftp.rfc-editor.org/internet-
> drafts/draft-
> meghana-netlmm-pmipv6-mipv4-00.txt
> 
> 
> 
> 
> 11. NEMO/Prefix delegation to Mobile Node in Proxy Mobile IPv6
> 
> 
> 
> 
> 
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext

From: domagoj.premec.ext at nsn.com (Domagoj Premec)
Date: Tue, 31 Mar 2009 11:17:55 +0200
Subject: [Netext] Today's BOF Discussion
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Ryuji,
 
> If we define special signaling for PMIP, it is obviously modification.
> Otherwise, it is just hack (implementation issue).

OK, so you're saying that the host changes are OK as long as they are not
visible on the protocol level, right?

> 
> If your statement is valid, the multiple IF support of 
> RFC5213 already breaks the rules!

hmm... not really. The RFC 5213 states that if in doubt the PMIPv6 domain
must assign different prefixes to different interfaces of the MN and so the
RFC 5213 works fine with unmodified hosts.

> Node cannot easily switch an address from one IF to another IF.
> You need at least script or something application to handle this.

I agree that something is needed.

domagoj

> -----Original Message-----
> From: ext Ryuji Wakikawa [mailto:ryuji.wakikawa at gmail.com] 
> Sent: 31. ozujak 2009 03:21
> To: Domagoj Premec
> Cc: 'ext Sri Gundavelli'; netext at mail.mobileip.jp; 
> dthaler at windows.microsoft.com
> Subject: Re: [Netext] Today's BOF Discussion
> 
> Hi Domagoj,
> 
> On 2009/03/27, at 0:07, Domagoj Premec wrote:
> 
> > Hi Sri,
> >
> > Having to install a new application on the host qualifies as a host 
> > change in my eyes. We can debate what exactly is the host 
> change, is 
> > this a change to the IP stack, or to the link layer, or an 
> additional 
> > application... My opinion is that as long as it doesn't work out of 
> > the box with the off-the-shelf hosts, it is a host change.
> 
> It is difficult to say what is the default setting of the 
> off-the- shell hosts.
> for example, you can not use Windows XP machine as an IPv6 
> host. (IPv6 is disable in default)
> 
> If we define special signaling for PMIP, it is obviously modification.
> Otherwise, it is just hack (implementation issue).
> 
> If your statement is valid, the multiple IF support of 
> RFC5213 already breaks the rules!
> Node cannot easily switch an address from one IF to another IF.
> You need at least script or something application to handle this.
> 
> ryuji
> 
> >
> >
> > domagoj
> >
> >
> >> -----Original Message-----
> >> From: ext Sri Gundavelli [mailto:sgundave at cisco.com]
> >> Sent: 26. ozujak 2009 23:53
> >> To: Domagoj Premec
> >> Cc: netext at mail.mobileip.jp; dthaler at windows.microsoft.com
> >> Subject: RE: [Netext] Today's BOF Discussion
> >>
> >> Hi Domagoj,
> >>
> >>>
> >>>> Now, what is not assured is the aspect of session continuity.
> >>>> Which requires a virtual interface implementation on the 
> host, by 
> >>>> binding the address/prefix to a virtual interface and by
> >> not exposing
> >>>> the physical interface or by hiding the handoff events from the
> >>>> layer-3 stack.
> >>>
> >>> For me, this is a host change. The host needs to be aware of the
> >>> PMIPv6 service in the network (how?) so that it knows that
> >> it needs to
> >>> instantiate the virtual interface and assign the address to the 
> >>> virtual interface instead of assigning it to a physical
> >> interface. And
> >>> then some sort of connection manager is neccessary that 
> takes care 
> >>> that the virtual interface is associated with the right physical 
> >>> interface (the active one) as the MN moves across access networks.
> >>>
> >>
> >> The piece of software that is required on the host for supporting 
> >> this capability, is not changing "any of the IETF RFC's", 
> 4861, 4862, 
> >> ... name it. To qualify this, all OS's provide software SDK to 
> >> implement this. So, application requirement does not imply host 
> >> change.
> >>
> >> If you install a IPsec client on a host, it creates a virtual 
> >> adapter, the VPN address is bound to the adapter and all 
> applications 
> >> bind to this address. Is this a host change or an application 
> >> requirement ?
> >>
> >> When we say we dont want host change, as I see it, we are not 
> >> requiring changes to the earlier specified IETF protocol 
> >> specifications, it does count an application requirement.
> >>
> >> Sri
> >>
> >>
> >>
> >
> > _______________________________________________
> > NetExt mailing list
> > NetExt at mail.mobileip.jp
> > http://www.mobileip.jp/mailman/listinfo/netext
> 
> 

From: pierrick.seite at orange-ftgroup.com (pierrick.seite at orange-ftgroup.com)
Date: Tue, 31 Mar 2009 09:39:00 +0200
Subject: [Netext] Today's BOF Discussion
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <DD8B8FEBBFAF9E488F63FF0F1A69EDD105A3BCE9@ftrdmel1>

Hi,

A terminal handling several interfaces should support a connection manager to deal with multiple interfaces issues (discussed during MIF BoF at San Francisco). I mean this kind of "host support" is not required to support multihoming with PMIP but would be necessary even without mobility.

Regards,
Pierrick

> -----Message d'origine-----
> De?: netext-bounces at mail.mobileip.jp [mailto:netext-
> bounces at mail.mobileip.jp] De la part de Domagoj Premec
> Envoy??: vendredi 27 mars 2009 07:41
> ??: 'ext Sri Gundavelli'; netext at mail.mobileip.jp
> Cc?: dthaler at windows.microsoft.com
> Objet?: Re: [Netext] Today's BOF Discussion
> 
> Sri,
> 
> > The network when it projects prefixes on a given interfaces,
> > it withdraws the same from the other interface. So, the
> 
> How does the network know that the host doesn't want to be multihomed?
> 
> > Now, what is not assured is the aspect of session continuity.
> > Which requires a virtual interface implementation on the
> > host, by binding the address/prefix to a virtual interface
> > and by not exposing the physical interface or by hiding the
> > handoff events from the layer-3 stack.
> 
> For me, this is a host change. The host needs to be aware of the PMIPv6
> service in the network (how?) so that it knows that it needs to
> instantiate
> the virtual interface and assign the address to the virtual interface
> instead of assigning it to a physical interface. And then some sort of
> connection manager is neccessary that takes care that the virtual
> interface
> is associated with the right physical interface (the active one) as the MN
> moves across access networks.
> 
> domagoj
> 
> 
> > -----Original Message-----
> > From: netext-bounces at mail.mobileip.jp
> > [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext Sri
> > Gundavelli
> > Sent: 26. ozujak 2009 22:03
> > To: netext at mail.mobileip.jp
> > Cc: dthaler at windows.microsoft.com
> > Subject: [Netext] Today's BOF Discussion
> >
> > I'm still wondering how we ended up spending 95% of the BOF
> > time discussing the issues related to supporting the same IP
> > address simultaneously on two interfaces, the scenario that
> > we don't even support in the base spec.
> >
> > Couple of points:
> >
> > 1. RFC-5213 supports handoff between two interfaces. The
> > ability to move prefixes between interfaces. In other words
> > address continuity is assured with any IPv6 host on the
> > planet and with absolutely no changes.
> >
> > The network when it projects prefixes on a given interfaces,
> > it withdraws the same from the other interface. So, the
> > prefixes are only one interface at a point of time. This
> > meets even Dave's comment, that "no changes to any IETF
> > RFC's.". Now, what is not assured is the aspect of session continuity.
> > Which requires a virtual interface implementation on the
> > host, by binding the address/prefix to a virtual interface
> > and by not exposing the physical interface or by hiding the
> > handoff events from the layer-3 stack.
> >
> > In essence, we need an informational specification which
> > provides some general guidance to how to leverage the feature
> > support provided in RFC-5213, along the lines of:
> >
> > 1.
> > http://tools.ietf.org/html/draft-yokota-netlmm-pmipv6-mn-itho-
> > support-00
> > 2. Please see the attached paper, a simple example using
> > bridge control interface
> >    on Linux.
> >
> > In the absence of such document, vendors may still achieve
> > this, but a document will relieve them from some pain. This
> > is not introducing any changes on the host, this is about how
> > to use Windows adapter API, or Linux Netlink interface to
> > support session continuity, by creating virtual interfaces.
> > IPsec
> > client or L2TP client all do  this. No one should have a
> > problem with this work item, hopefully.
> >
> >
> > Regards
> > Sri
> >
> >
> >
> >
> >
> 
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext

From: ryuji.wakikawa at gmail.com (Ryuji Wakikawa)
Date: Mon, 30 Mar 2009 18:20:47 -0700
Subject: [Netext] Today's BOF Discussion
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Domagoj,

On 2009/03/27, at 0:07, Domagoj Premec wrote:

> Hi Sri,
>
> Having to install a new application on the host qualifies as a host  
> change
> in my eyes. We can debate what exactly is the host change, is this a  
> change
> to the IP stack, or to the link layer, or an additional  
> application... My
> opinion is that as long as it doesn't work out of the box with the
> off-the-shelf hosts, it is a host change.

It is difficult to say what is the default setting of the off-the- 
shell hosts.
for example, you can not use Windows XP machine as an IPv6 host. (IPv6  
is disable in default)

If we define special signaling for PMIP, it is obviously modification.
Otherwise, it is just hack (implementation issue).

If your statement is valid, the multiple IF support of RFC5213 already  
breaks the rules!
Node cannot easily switch an address from one IF to another IF.
You need at least script or something application to handle this.

ryuji

>
>
> domagoj
>
>
>> -----Original Message-----
>> From: ext Sri Gundavelli [mailto:sgundave at cisco.com]
>> Sent: 26. ozujak 2009 23:53
>> To: Domagoj Premec
>> Cc: netext at mail.mobileip.jp; dthaler at windows.microsoft.com
>> Subject: RE: [Netext] Today's BOF Discussion
>>
>> Hi Domagoj,
>>
>>>
>>>> Now, what is not assured is the aspect of session continuity.
>>>> Which requires a virtual interface implementation on the host, by
>>>> binding the address/prefix to a virtual interface and by
>> not exposing
>>>> the physical interface or by hiding the handoff events from the
>>>> layer-3 stack.
>>>
>>> For me, this is a host change. The host needs to be aware of the
>>> PMIPv6 service in the network (how?) so that it knows that
>> it needs to
>>> instantiate the virtual interface and assign the address to the
>>> virtual interface instead of assigning it to a physical
>> interface. And
>>> then some sort of connection manager is neccessary that takes care
>>> that the virtual interface is associated with the right physical
>>> interface (the active one) as the MN moves across access networks.
>>>
>>
>> The piece of software that is required on the host for
>> supporting this capability, is not changing "any of the IETF
>> RFC's", 4861, 4862, ... name it. To qualify this, all OS's
>> provide software SDK to implement this. So, application
>> requirement does not imply host change.
>>
>> If you install a IPsec client on a host, it creates a virtual
>> adapter, the VPN address is bound to the adapter and all
>> applications bind to this address. Is this a host change or
>> an application requirement ?
>>
>> When we say we dont want host change, as I see it, we are not
>> requiring changes to the earlier specified IETF protocol
>> specifications, it does count an application requirement.
>>
>> Sri
>>
>>
>>
>
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext

From: Mohana.Jeyatharan at sg.panasonic.com (Mohana Jeyatharan)
Date: Tue, 31 Mar 2009 08:16:39 +0800
Subject: [Netext] Today's BOF Discussion
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Hi Behcet,

I think the issue of multilink subnet is not a issue if the host is slightly changed and knows this is PMIP domain and not the conventional multilink subnet. What I mean is we have a Point to point ink model here for PMIP and we have unique prefix per MN and the issues with multilink will not appear. A small host fix would do. Anyway many SDOs do some small host fixes even when they apply PMIP. 

For example, unmodified host DAD is essential according to IETF RFCs. But in 3GPP standard document they say DAD can be optional reason being per MN unique prefix. Thus small
host modification when we consider PMIPv6 alone should be allowed and I really don't see why not.

These are few thoughts.

BR,
Mohana

________________________________________
From: netext-bounces at mail.mobileip.jp [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of Behcet Sarikaya
Sent: Tuesday, March 31, 2009 5:12 AM
To: Domagoj Premec; ext Sri Gundavelli
Cc: netext at mail.mobileip.jp; dthaler at windows.microsoft.com
Subject: Re: [Netext] Today's BOF Discussion

I agree with Domagoj.
Besides advertizing the same prefix on two different interfaces of MN as in Fig. 4 of Ryuji's paper will create multi-link subnet at the LMA.
?
Unless these two interfaces are single-radio interfaces.
?
Regards,
?
Behcet

________________________________________
From: Domagoj Premec <domagoj.premec.ext at nsn.com>
To: ext Sri Gundavelli <sgundave at cisco.com>
Cc: netext at mail.mobileip.jp; dthaler at windows.microsoft.com
Sent: Friday, March 27, 2009 2:07:04 AM
Subject: Re: [Netext] Today's BOF Discussion

Hi Sri,

Having to install a new application on the host qualifies as a host change
in my eyes. We can debate what exactly is the host change, is this a change
to the IP stack, or to the link layer, or an additional application... My
opinion is that as long as it doesn't work out of the box with the
off-the-shelf hosts, it is a host change.

domagoj

> -----Original Message-----
> From: ext Sri Gundavelli [mailto:sgundave at cisco.com] 
> Sent: 26. ozujak 2009 23:53
> To: Domagoj Premec
> Cc: netext at mail.mobileip.jp; dthaler at windows.microsoft.com
> Subject: RE: [Netext] Today's BOF Discussion
> 
> Hi Domagoj,
> 
> >
> >> Now, what is not assured is the aspect of session continuity.
> >> Which requires a virtual interface implementation on the host, by 
> >> binding the address/prefix to a virtual interface and by 
> not exposing 
> >> the physical interface or by hiding the handoff events from the 
> >> layer-3 stack.
> >
> > For me, this is a host change. The host needs to be aware of the 
> > PMIPv6 service in the network (how?) so that it knows that 
> it needs to 
> > instantiate the virtual interface and assign the address to the 
> > virtual interface instead of assigning it to a physical 
> interface. And 
> > then some sort of connection manager is neccessary that takes care 
> > that the virtual interface is associated with the right physical 
> > interface (the active one) as the MN moves across access networks.
> >
> 
> The piece of software that is required on the host for 
> supporting this capability, is not changing "any of the IETF 
> RFC's", 4861, 4862, ... name it. To qualify this, all OS's 
> provide software SDK to implement this. So, application 
> requirement does not imply host change.
> 
> If you install a IPsec client on a host, it creates a virtual 
> adapter, the VPN address is bound to the adapter and all 
> applications bind to this address. Is this a host change or 
> an application requirement ?
> 
> When we say we dont want host change, as I see it, we are not 
> requiring changes to the earlier specified IETF protocol 
> specifications, it does count an application requirement.
> 
> Sri
> 
> 
> 

_______________________________________________
NetExt mailing list
NetExt at mail.mobileip.jp
http://www.mobileip.jp/mailman/listinfo/netext

From: behcetsarikaya at yahoo.com (Behcet Sarikaya)
Date: Mon, 30 Mar 2009 14:12:07 -0700 (PDT)
Subject: [Netext] Today's BOF Discussion
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

I agree with Domagoj.
Besides advertizing the same prefix on two different interfaces of MN as in Fig. 4 of Ryuji's paper will create multi-link subnet at the LMA.

Unless these two interfaces are single-radio interfaces.

Regards,

Behcet

________________________________
From: Domagoj Premec <domagoj.premec.ext at nsn.com>
To: ext Sri Gundavelli <sgundave at cisco.com>
Cc: netext at mail.mobileip.jp; dthaler at windows.microsoft.com
Sent: Friday, March 27, 2009 2:07:04 AM
Subject: Re: [Netext] Today's BOF Discussion

Hi Sri,

Having to install a new application on the host qualifies as a host change
in my eyes. We can debate what exactly is the host change, is this a change
to the IP stack, or to the link layer, or an additional application... My
opinion is that as long as it doesn't work out of the box with the
off-the-shelf hosts, it is a host change.

domagoj

> -----Original Message-----
> From: ext Sri Gundavelli [mailto:sgundave at cisco.com] 
> Sent: 26. ozujak 2009 23:53
> To: Domagoj Premec
> Cc: netext at mail.mobileip.jp; dthaler at windows.microsoft.com
> Subject: RE: [Netext] Today's BOF Discussion
> 
> Hi Domagoj,
> 
> >
> >> Now, what is not assured is the aspect of session continuity.
> >> Which requires a virtual interface implementation on the host, by 
> >> binding the address/prefix to a virtual interface and by 
> not exposing 
> >> the physical interface or by hiding the handoff events from the 
> >> layer-3 stack.
> >
> > For me, this is a host change. The host needs to be aware of the 
> > PMIPv6 service in the network (how?) so that it knows that 
> it needs to 
> > instantiate the virtual interface and assign the address to the 
> > virtual interface instead of assigning it to a physical 
> interface. And 
> > then some sort of connection manager is neccessary that takes care 
> > that the virtual interface is associated with the right physical 
> > interface (the active one) as the MN moves across access networks.
> >
> 
> The piece of software that is required on the host for 
> supporting this capability, is not changing "any of the IETF 
> RFC's", 4861, 4862, ... name it. To qualify this, all OS's 
> provide software SDK to implement this. So, application 
> requirement does not imply host change.
> 
> If you install a IPsec client on a host, it creates a virtual 
> adapter, the VPN address is bound to the adapter and all 
> applications bind to this address. Is this a host change or 
> an application requirement ?
> 
> When we say we dont want host change, as I see it, we are not 
> requiring changes to the earlier specified IETF protocol 
> specifications, it does count an application requirement.
> 
> Sri
> 
> 
> 

_______________________________________________
NetExt mailing list
NetExt at mail.mobileip.jp
http://www.mobileip.jp/mailman/listinfo/netext

      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090330/3ba655bc/attachment.html>

From: rkoodli at starentnetworks.com (Koodli, Rajeev)
Date: Mon, 30 Mar 2009 13:05:03 -0400
Subject: [Netext] Today's BOF Discussion
References: <[email-masked]><[email-masked]><[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hello folks,
 
good that we are having the discussion. 
 
It is one thing to have a host-internal mechanism to be able to handle the same address across multiple interfaces. It is another to thing to say that classical Mobile IP is the only way to do this. 
 
There appear to be use cases for PMIP6 where this functionality (i.e., the ability to assign the same HNP/Address to multiple interfaces) is needed. Use of virtual interface may be one way to go, and we may want to document this.
 
As for NetExt itself, there is no reason not to work on the problems which may require such host-internal mechanisms (i.e., use of virtual interfaces).
 
Regards,
 
-Rajeev

________________________________

From: netext-bounces at mail.mobileip.jp on behalf of Domagoj Premec
Sent: Fri 3/27/2009 12:07 AM
To: 'ext Sri Gundavelli'
Cc: netext at mail.mobileip.jp; dthaler at windows.microsoft.com
Subject: Re: [Netext] Today's BOF Discussion

Hi Sri,

Having to install a new application on the host qualifies as a host change
in my eyes. We can debate what exactly is the host change, is this a change
to the IP stack, or to the link layer, or an additional application... My
opinion is that as long as it doesn't work out of the box with the
off-the-shelf hosts, it is a host change.

domagoj

> -----Original Message-----
> From: ext Sri Gundavelli [mailto:sgundave at cisco.com]
> Sent: 26. ozujak 2009 23:53
> To: Domagoj Premec
> Cc: netext at mail.mobileip.jp; dthaler at windows.microsoft.com
> Subject: RE: [Netext] Today's BOF Discussion
>
> Hi Domagoj,
>
> >
> >> Now, what is not assured is the aspect of session continuity.
> >> Which requires a virtual interface implementation on the host, by
> >> binding the address/prefix to a virtual interface and by
> not exposing
> >> the physical interface or by hiding the handoff events from the
> >> layer-3 stack.
> >
> > For me, this is a host change. The host needs to be aware of the
> > PMIPv6 service in the network (how?) so that it knows that
> it needs to
> > instantiate the virtual interface and assign the address to the
> > virtual interface instead of assigning it to a physical
> interface. And
> > then some sort of connection manager is neccessary that takes care
> > that the virtual interface is associated with the right physical
> > interface (the active one) as the MN moves across access networks.
> >
>
> The piece of software that is required on the host for
> supporting this capability, is not changing "any of the IETF
> RFC's", 4861, 4862, ... name it. To qualify this, all OS's
> provide software SDK to implement this. So, application
> requirement does not imply host change.
>
> If you install a IPsec client on a host, it creates a virtual
> adapter, the VPN address is bound to the adapter and all
> applications bind to this address. Is this a host change or
> an application requirement ?
>
> When we say we dont want host change, as I see it, we are not
> requiring changes to the earlier specified IETF protocol
> specifications, it does count an application requirement.
>
> Sri
>
>
>

_______________________________________________
NetExt mailing list
NetExt at mail.mobileip.jp
http://www.mobileip.jp/mailman/listinfo/netext

From: domagoj.premec.ext at nsn.com (Domagoj Premec)
Date: Fri, 27 Mar 2009 00:07:04 -0700
Subject: [Netext] Today's BOF Discussion
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Sri,

Having to install a new application on the host qualifies as a host change
in my eyes. We can debate what exactly is the host change, is this a change
to the IP stack, or to the link layer, or an additional application... My
opinion is that as long as it doesn't work out of the box with the
off-the-shelf hosts, it is a host change.

domagoj

> -----Original Message-----
> From: ext Sri Gundavelli [mailto:sgundave at cisco.com] 
> Sent: 26. ozujak 2009 23:53
> To: Domagoj Premec
> Cc: netext at mail.mobileip.jp; dthaler at windows.microsoft.com
> Subject: RE: [Netext] Today's BOF Discussion
> 
> Hi Domagoj,
> 
> >
> >> Now, what is not assured is the aspect of session continuity.
> >> Which requires a virtual interface implementation on the host, by 
> >> binding the address/prefix to a virtual interface and by 
> not exposing 
> >> the physical interface or by hiding the handoff events from the 
> >> layer-3 stack.
> >
> > For me, this is a host change. The host needs to be aware of the 
> > PMIPv6 service in the network (how?) so that it knows that 
> it needs to 
> > instantiate the virtual interface and assign the address to the 
> > virtual interface instead of assigning it to a physical 
> interface. And 
> > then some sort of connection manager is neccessary that takes care 
> > that the virtual interface is associated with the right physical 
> > interface (the active one) as the MN moves across access networks.
> >
> 
> The piece of software that is required on the host for 
> supporting this capability, is not changing "any of the IETF 
> RFC's", 4861, 4862, ... name it. To qualify this, all OS's 
> provide software SDK to implement this. So, application 
> requirement does not imply host change.
> 
> If you install a IPsec client on a host, it creates a virtual 
> adapter, the VPN address is bound to the adapter and all 
> applications bind to this address. Is this a host change or 
> an application requirement ?
> 
> When we say we dont want host change, as I see it, we are not 
> requiring changes to the earlier specified IETF protocol 
> specifications, it does count an application requirement.
> 
> Sri
> 
> 
> 

From: sgundave at cisco.com (Sri Gundavelli)
Date: Thu, 26 Mar 2009 23:53:14 -0700 (PDT)
Subject: [Netext] Today's BOF Discussion
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Domagoj,

>
>> Now, what is not assured is the aspect of session continuity.
>> Which requires a virtual interface implementation on the
>> host, by binding the address/prefix to a virtual interface
>> and by not exposing the physical interface or by hiding the
>> handoff events from the layer-3 stack.
>
> For me, this is a host change. The host needs to be aware of the PMIPv6
> service in the network (how?) so that it knows that it needs to instantiate
> the virtual interface and assign the address to the virtual interface
> instead of assigning it to a physical interface. And then some sort of
> connection manager is neccessary that takes care that the virtual interface
> is associated with the right physical interface (the active one) as the MN
> moves across access networks.
>

The piece of software that is required on the host for supporting this
capability, is not changing "any of the IETF RFC's", 4861, 4862, ... name
it. To qualify this, all OS's provide software SDK to implement this. So,
application requirement does not imply host change.

If you install a IPsec client on a host, it creates a virtual adapter, the
VPN address is bound to the adapter and all applications bind to this
address. Is this a host change or an application requirement ?

When we say we dont want host change, as I see it, we are not requiring
changes to the earlier specified IETF protocol specifications, it does
count an application requirement.

Sri

From: domagoj.premec.ext at nsn.com (Domagoj Premec)
Date: Thu, 26 Mar 2009 23:41:27 -0700
Subject: [Netext] Today's BOF Discussion
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Sri,

> The network when it projects prefixes on a given interfaces, 
> it withdraws the same from the other interface. So, the 

How does the network know that the host doesn't want to be multihomed? 

> Now, what is not assured is the aspect of session continuity.
> Which requires a virtual interface implementation on the 
> host, by binding the address/prefix to a virtual interface 
> and by not exposing the physical interface or by hiding the 
> handoff events from the layer-3 stack.

For me, this is a host change. The host needs to be aware of the PMIPv6
service in the network (how?) so that it knows that it needs to instantiate
the virtual interface and assign the address to the virtual interface
instead of assigning it to a physical interface. And then some sort of
connection manager is neccessary that takes care that the virtual interface
is associated with the right physical interface (the active one) as the MN
moves across access networks.  

domagoj

> -----Original Message-----
> From: netext-bounces at mail.mobileip.jp 
> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext Sri 
> Gundavelli
> Sent: 26. ozujak 2009 22:03
> To: netext at mail.mobileip.jp
> Cc: dthaler at windows.microsoft.com
> Subject: [Netext] Today's BOF Discussion
> 
> I'm still wondering how we ended up spending 95% of the BOF 
> time discussing the issues related to supporting the same IP 
> address simultaneously on two interfaces, the scenario that 
> we don't even support in the base spec. 
> 
> Couple of points:
> 
> 1. RFC-5213 supports handoff between two interfaces. The 
> ability to move prefixes between interfaces. In other words 
> address continuity is assured with any IPv6 host on the 
> planet and with absolutely no changes. 
> 
> The network when it projects prefixes on a given interfaces, 
> it withdraws the same from the other interface. So, the 
> prefixes are only one interface at a point of time. This 
> meets even Dave's comment, that "no changes to any IETF 
> RFC's.". Now, what is not assured is the aspect of session continuity.
> Which requires a virtual interface implementation on the 
> host, by binding the address/prefix to a virtual interface 
> and by not exposing the physical interface or by hiding the 
> handoff events from the layer-3 stack.
> 
> In essence, we need an informational specification which 
> provides some general guidance to how to leverage the feature 
> support provided in RFC-5213, along the lines of:
> 
> 1. 
> http://tools.ietf.org/html/draft-yokota-netlmm-pmipv6-mn-itho-
> support-00
> 2. Please see the attached paper, a simple example using 
> bridge control interface
>    on Linux.
> 
> In the absence of such document, vendors may still achieve 
> this, but a document will relieve them from some pain. This 
> is not introducing any changes on the host, this is about how 
> to use Windows adapter API, or Linux Netlink interface to 
> support session continuity, by creating virtual interfaces.
> IPsec
> client or L2TP client all do  this. No one should have a 
> problem with this work item, hopefully.
> 
> 
> Regards
> Sri
> 
> 
> 
> 
> 

From: sgundave at cisco.com (Sri Gundavelli)
Date: Thu, 26 Mar 2009 22:42:33 -0700
Subject: [Netext] Charter Scope and Work Items
Message-ID: <[email-masked]>

IMHO, there are number of extensions to Proxy Mobile IPv6 that we need for 
successful deployment of the protocol in any system architecture. To most
part these are minor extensions that we need them for addressing a
deployment
problem, alignment with other protocols such as GTP, add a minor missing
feature useful in optimizations, or some thing that helps in
implementations.

I've identified some work items, that we discussed in the past. This is just
my opinion. Welcome to dispute. Also, Where ever we do this work, netext,
netlmm,
mext or mipshop, is not my interest, but we need these extensions. Thats the
only part I care. If this was discussed in the past, fine, but this is my 
list as I see it, bear with me.

All the items listed here do not require host stack changes, except the
following immediate list which may in some cases:

- Multi-homing Support, when sharing the same address on two interfaces
- Handoff triggers from the mobile node
- Flow Management, when not moved as a group associated to a prefix
- Prefix coloring via RA extensions

I really hope the charter will consider most of the work items listed
below.

1. Dynamic LMA Assignment

In blade architecture systems or in a load balancer configuration, the PDNGW
should have the ability to dynamically assign a LMA on the fly, along the 
lines of Mobile IPv4 Dynamic Home Agent Address Assignment support
[RFC-4433].
Currently, GTP provides such semantics and this is a important requirement
for deployment. Here the goal is to 

a.) Expose a single IP address to the SGW
b.) The exposed IP address should not be in path once the assignment is
done.

[LMA1]---
  |      |
[LMA2]--[LMA]==========[MAG]
  |      |
[LMA3]---

Along the lines of:

http://tools.ietf.org/html/draft-korhonen-netext-redirect-01

2. Multicast Support in Proxy Mobile IPv6

We need an informational specification on how multicast support can be
enabled in Proxy Mobile IPv6 environment. Behcet has done extensive analysis
on
this. This is required and critical for enabling any multicast services.
However,
Behcet may disagree with the scope of the work. 

3. Bulk Registration Support

This is a simple extension which helps in signaling optimization, along the
lines of:

http://tools.ietf.org/html/draft-premec-netlmm-bulk-re-registration-02

4. Partial Failover Support

We need a mechanism to notify the peer on revoke a partial set of bindings.

http://tools.ietf.org/id/draft-koodli-netlmm-path-and-session-management-00.
txt

5. Group Identifier Support for Proxy Mobile IPv6

This provides a simple and a generic semantic for assigning a group
identifier
to a mobile node's binding. GTP has very similar semantics, Connexion Set
Id.
Both #3 and #4 can leverage this. Additionally, in load balancer systems
where
the load balancer is in path for all signaling messages, it can use this as
a
tag for redirecting the message.

http://tools.ietf.org/html/draft-gundavelli-netext-mn-groupid-option-00

6. Virtual-Interface Support on IP host for supporting Inter-tech handoffs:

RFC-5213 supports handoff between two interfaces. The ability to move
prefixes between interfaces. In other words address continuity is assured
with any IPv6 host on the planet and with absolutely no changes. This meets
even Dave's comment, that "no changes to any IETF RFC's.". Now, what is
not assured is the aspect of session continuity. Which requires a virtual
interface implementation on the host, by binding the address/prefix to a
virtual interface and by not exposing the physical interface or by hiding
the handoff events from the layer-3 stack.

In essence, we need an informational specification which provides some
general guidance to how to leverage the feature support provided in
RFC-5213,
along the lines of:

http://tools.ietf.org/html/draft-yokota-netlmm-pmipv6-mn-itho-support-00

7. Route Optimization for Proxy Mobile IPv6

There were atleast 4 drafts in this area on Route Optimization. Marco
Liebsch
analyzed this exensively:

http://tools.ietf.org/html/draft-liebsch-netext-pmip6-ro-ps-00
http://www.ietf.org/internet-drafts/draft-koodli-netext-local-forwarding-00.
txt

8. Prefix Management in Proxy Mobile IPv6 support
 
Proxy Mobile IPv6 allows the assignment of multiple home network prefixes
to a given mobile node's interface. It might be useful to specify how the 
LMA manages this aspects. It can potentially use DHCP PD, Local Pools or
AAA to manage this aspect. Behcet has one draft on this.

9. Partial Handoff Support

We are missing some semantics in 5213 for moving a subset of the prefixes
between interfaces as part of the inter-tech handoff. This is about defining
a new handoff value. This allows partial flow management, but moving the
flows associated to a prefix, as a whole group.

http://tools.ietf.org/html/draft-jeyatharan-netext-pmip-partial-handoff-00

10. CMIPv4/PMIP Interworking

This is probably required to specify how an IPv4-only can move between 
CMIP and PMIP environments.

http://sunsite.mff.cuni.cz/MIRRORS/ftp.rfc-editor.org/internet-drafts/draft-
meghana-netlmm-pmipv6-mipv4-00.txt

11. NEMO/Prefix delegation to Mobile Node in Proxy Mobile IPv6

 

From: ryuji.wakikawa at gmail.com (Ryuji Wakikawa)
Date: Thu, 26 Mar 2009 22:31:12 -0700
Subject: [Netext] Today's BOF Discussion
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi,

About the paper Sri sent, we didn't run PMIP for the evaluation.
Just checking the node behavior when a node receives RA including the  
same prefix at virtual interface over two physical interfaces.
But we have another paper (under reviewing and cannot open it now) to  
evaluate PMIP with virtual interface.

When we implemented and evaluated PMIP and IPv6 node with virtual  
interface,
Linux IPv6 host just worked without any modification for inter-tech  
handover.
#We observed some PBU race conditions between two MAGs though. LMA can  
handle this.
We even didn't touch PMIP protocol.

I agree that it is useful to write down the use of virtual interface  
for inter-tech handover,
but we should not explain how to use virtual interface per  
implementation.

regards,
ryuji

On 2009/03/26, at 22:03, Sri Gundavelli wrote:

> I'm still wondering how we ended up spending 95% of the BOF time  
> discussing
> the issues related to supporting the same IP address simultaneously  
> on two
> interfaces, the scenario that we don't even support in the base spec.
>
> Couple of points:
>
> 1. RFC-5213 supports handoff between two interfaces. The ability to  
> move
> prefixes between interfaces. In other words address continuity is  
> assured
> with any IPv6 host on the planet and with absolutely no changes.
>
> The network when it projects prefixes on a given interfaces, it  
> withdraws
> the same from the other interface. So, the prefixes are only one  
> interface
> at a point of time. This meets even Dave's comment, that "no changes  
> to any
> IETF RFC's.". Now, what is not assured is the aspect of session  
> continuity.
> Which requires a virtual interface implementation on the host, by  
> binding
> the address/prefix to a virtual interface and by not exposing the  
> physical
> interface or by hiding the handoff events from the layer-3 stack.
>
> In essence, we need an informational specification which provides some
> general guidance to how to leverage the feature support provided in
> RFC-5213,
> along the lines of:
>
> 1. http://tools.ietf.org/html/draft-yokota-netlmm-pmipv6-mn-itho-support-00
> 2. Please see the attached paper, a simple example using bridge  
> control
> interface
>   on Linux.
>
> In the absence of such document, vendors may still achieve this, but a
> document will relieve them from some pain. This is not introducing any
> changes
> on the host, this is about how to use Windows adapter API, or Linux  
> Netlink
> interface to support session continuity, by creating virtual  
> interfaces.
> IPsec
> client or L2TP client all do  this. No one should have a problem  
> with this
> work
> item, hopefully.
>
>
> Regards
> Sri
>
>
>
>
> <mobiworld.pdf>_______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext

From: sgundave at cisco.com (Sri Gundavelli)
Date: Thu, 26 Mar 2009 22:03:06 -0700
Subject: [Netext] Today's BOF Discussion
Message-ID: <[email-masked]>

I'm still wondering how we ended up spending 95% of the BOF time discussing
the issues related to supporting the same IP address simultaneously on two
interfaces, the scenario that we don't even support in the base spec. 

Couple of points:

1. RFC-5213 supports handoff between two interfaces. The ability to move
prefixes between interfaces. In other words address continuity is assured
with any IPv6 host on the planet and with absolutely no changes. 

The network when it projects prefixes on a given interfaces, it withdraws
the same from the other interface. So, the prefixes are only one interface
at a point of time. This meets even Dave's comment, that "no changes to any
IETF RFC's.". Now, what is not assured is the aspect of session continuity.
Which requires a virtual interface implementation on the host, by binding
the address/prefix to a virtual interface and by not exposing the physical
interface or by hiding the handoff events from the layer-3 stack.

In essence, we need an informational specification which provides some
general guidance to how to leverage the feature support provided in
RFC-5213,
along the lines of:

1. http://tools.ietf.org/html/draft-yokota-netlmm-pmipv6-mn-itho-support-00
2. Please see the attached paper, a simple example using bridge control
interface
   on Linux.

In the absence of such document, vendors may still achieve this, but a
document will relieve them from some pain. This is not introducing any
changes
on the host, this is about how to use Windows adapter API, or Linux Netlink
interface to support session continuity, by creating virtual interfaces.
IPsec
client or L2TP client all do  this. No one should have a problem with this
work
item, hopefully.

Regards
Sri

-------------- next part --------------
A non-text attachment was scrubbed...
Name: mobiworld.pdf
Type: application/pdf
Size: 525168 bytes
Desc: not available
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090326/52caf619/attachment-0001.pdf>

From: sunseawq at huawei.com (Qin Wu)
Date: Thu, 26 Mar 2009 18:02:05 -0700
Subject: [Netext] First Problem Statement about Localized Routing in	PMIPv6 submitted
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi:
Our draft on local routing optimization has already addressed this issue in the section 8. The URL link for this internet draft can be found in:
http://tools.ietf.org/html/draft-wu-netext-local-ro-00
The two possible scenarios are:
a.MN is IPv4 enabled and receives IPv4 home address 
b.and the transport network between the LMA and the MAG is an IPv4 network.
Also to my point, the Localized routing as addressed in the PS document is quite similar to Local routing as described in the RFC5213 and we don't need to restrict the correspondent node as a mobile node, in this sense, Shall we align with the definition of local routing and have reference to the RFC5213 in this current PS document.

Regards! 
-Qin

----- Original Message ----- 
From: "Sangjin Jeong" <sjjeong at gmail.com>
To: "Marco Liebsch" <liebsch at nw.neclab.eu>
Cc: <netext at mail.mobileip.jp>
Sent: Thursday, March 26, 2009 4:36 PM
Subject: Re: [Netext] First Problem Statement about Localized Routing in PMIPv6 submitted

Hi Marco,

Thanks for developing the RO PS document. It seems that the RO application
scenarios in the current document does not explicitly mention IPv4
support cases.
When a PMIP6 domain supports IPv4, the IPv4 support scenario of RO may be
divided into following possible subcases.

(1) a MN and a CN IPv4 home address mobility
(2) a MN and a CN belong to different MAGs and both MAGs support IPv4 transport
to the same LMA
(3) a MN and a CN belong to different MAGs and the MAGs support
different IP version
transport to the same LMA

I think that it is worthwhile to investigate each subcase so as to
decide which subcase
should be included in the scope and/or whether there is any issue to
be resolved.

Regards,
Sangjin

On Thu, Feb 5, 2009 at 7:33 AM, Marco Liebsch <liebsch at nw.neclab.eu> wrote:
> Hi all,
>
> please find the link to a first version of a Localized Routing Problem
> Statement below.
> The abstract of the PS document is as follows:
>
> Abstract:
>
> Proxy Mobile IPv6 is the IETF standard for network-based localized
> mobility management. In Proxy Mobile IPv6, mobile nodes are
> topologically anchored at a Local Mobility Anchor, which forwards all
> data for registered mobile nodes. The set up and support for
> localized routing, which allows forwarding of data packets between
> mobile nodes and correspondent nodes directly without traversing an
> LMA, is not considered. This document describes the problem space of
> localized routing in Proxy Mobile IPv6.
>
>
> Any comments to this version of the problem statement are welcome.
>
> http://www.ietf.org/internet-drafts/draft-liebsch-netext-pmip6-ro-ps-00.txt
>
> Best regards,
> marco
>
>
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
>

_______________________________________________
NetExt mailing list
NetExt at mail.mobileip.jp
http://www.mobileip.jp/mailman/listinfo/netext

From: sjjeong at gmail.com (Sangjin Jeong)
Date: Thu, 26 Mar 2009 16:36:42 -0700
Subject: [Netext] First Problem Statement about Localized Routing in PMIPv6 submitted
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi Marco,

Thanks for developing the RO PS document. It seems that the RO application
scenarios in the current document does not explicitly mention IPv4
support cases.
When a PMIP6 domain supports IPv4, the IPv4 support scenario of RO may be
divided into following possible subcases.

(1) a MN and a CN IPv4 home address mobility
(2) a MN and a CN belong to different MAGs and both MAGs support IPv4 transport
to the same LMA
(3) a MN and a CN belong to different MAGs and the MAGs support
different IP version
transport to the same LMA

I think that it is worthwhile to investigate each subcase so as to
decide which subcase
should be included in the scope and/or whether there is any issue to
be resolved.

Regards,
Sangjin

On Thu, Feb 5, 2009 at 7:33 AM, Marco Liebsch <liebsch at nw.neclab.eu> wrote:
> Hi all,
>
> please find the link to a first version of a Localized Routing Problem
> Statement below.
> The abstract of the PS document is as follows:
>
> Abstract:
>
> ?Proxy Mobile IPv6 is the IETF standard for network-based localized
> ?mobility management. ?In Proxy Mobile IPv6, mobile nodes are
> ?topologically anchored at a Local Mobility Anchor, which forwards all
> ?data for registered mobile nodes. ?The set up and support for
> ?localized routing, which allows forwarding of data packets between
> ?mobile nodes and correspondent nodes directly without traversing an
> ?LMA, is not considered. ?This document describes the problem space of
> ?localized routing in Proxy Mobile IPv6.
>
>
> Any comments to this version of the problem statement are welcome.
>
> http://www.ietf.org/internet-drafts/draft-liebsch-netext-pmip6-ro-ps-00.txt
>
> Best regards,
> marco
>
>
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
>

From: Basavaraj.Patil at nokia.com (Basavaraj.Patil at nokia.com)
Date: Mon, 23 Mar 2009 17:20:12 +0100
Subject: [Netext] BoF Charter and Agenda
Message-ID: <[email-masked]>

Are posted at:

http://people.nokia.net/~patil/IETF74/Netext/

-Chairs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090323/a9603e63/attachment.html>

From: Basavaraj.Patil at nokia.com (Basavaraj.Patil at nokia.com)
Date: Mon, 23 Mar 2009 17:16:51 +0100
Subject: [Netext] Netext BoF agenda
Message-ID: <[email-masked]>

Network-based Mobility Extensions (NetExt) Bof
THURSDAY, March 26, 2009
1300-1500 Afternoon Session I in Imperial A

Bof chairs: Rajeev Koodli <rkoodli at starentnetworks dot com>
            Basavaraj Patil <basavaraj dot patil at nokia dot com>

Mailing list: http://www.mobileip.jp/mailman/listinfo/netext

---------------------------------------

Agenda:

1. Administrivia (Bluesheets, Notes takers)

2. Bof overview, scope and objectives (chairs/AD)   15 Mins

3. Problem statement discussions - 60 Mins

   a. Multihoming <draft-jeyatharan-netext-multihoming-ps-01>
   Presenter: Vijay Devarapalli (10 Mins for PS presentations and 10 Mins for discussion)

   b. Localized Routing <draft-liebsch-netext-pmip6-ro-ps-00>
   Presenter: Marco Liebsch (10 Mins for PS presentations and 10 Mins for
   discussion)

   c. Inter technology handovers <draft-krishnan-netext-intertech-ps-00>
   Presenter: Suresh Krishnan (10 Mins for PS presentations and 10 Mins for
   discussion)

4. Deployment related topics  15 Mins (for PS and discussion)

   d. Bulk refresh <draft-premec-netlmm-bulk-re-registration-02>
   e. PMIP6 Redirect <draft-korhonen-netext-redirect-ps-00>

5. Open discussion of proposed charter and work items (20 Mins)

6. Conclusion/Next steps 5 Mins (Chairs/AD)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090323/3884ac8c/attachment.html>

From: marco.liebsch at nw.neclab.eu (Marco Liebsch)
Date: Thu, 19 Mar 2009 10:44:29 +0100
Subject: [Netext] PMIPv6 Multiple Interface support
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Vijay,

Vijay Devarapalli schrieb:
> Hi Marco,
>
> Marco Liebsch wrote:
>   
>> Hi Vijay,
>>
>> a very useful document to understand the impact of some multi-homing
>>     
> and
>   
>> handover use cases to the mobile. Please find below a few comments to
>>     
> the
>   
>> current version of the draft.
>>
>> 3.3 sais that the LMA maintains only a single BCE in case of shared
>> addresses. This assumes that the HNP is the same for both interfaces,
>> but the link layer ID may be different. 
>>     
>
> Much more than that. Section 3.3 talks about the same address being 
> assigned to more than one interface. The actual flows are routed based 
> on the flow filters in the proxy binding cache entry. The flow filter 
> would identify which MAG to tunnel the packets to.
>   
Yes, I understand and support the use case. My point was only that for 
the LMA,
only the HNP is relevant, not the full address. But at least in a 
multi-homing scenario
with two interfaces sharing IP address, the LMA may have two separated 
BCEs for
this MN to reflect separate mobility sessions, where both entries have 
the same HNP
info, but differ in other IDs, such as technology, link ID, etc. Sure, 
you need flow
filters to take forwarding decisions.
>   
>> A lookup in the BC can be
>> performed on the link layer ID, which allows also existence of
>> different BCEs for this case. In my opinion an implementation
>> detail, which should not be written in the draft.
>>     
>
> Sure, the language can be relaxed to say, "for example, one could do 
> this...."
>   
Ok.
>   
>> The same section refers to the use of service identifiers to select
>> flow filters on the LMA. It should not be a MUST condition here,
>> as there are other possibilities to enforce flow filters on the LMA.
>> This brings up the next question: Is this an analysis document or a
>> specifcation? In the latter case you could of course mandate a
>> particular mechanism. I think an analysis of the impact and
>> requirements is more useful at this point.
>>     
>
> The document looks at the scenarios and suggests possible solutions too.
>
> Note that this was written two years ago. I was just collecting all my 
> thoughts on multiple interface support into one document. :)
>   
Yes, right. And I think it's a valuable document to discuss impact of 
some PMIPv6
extensions to the host. Many of these things have not been looked at in 
detail
yet during the last 2 years...:-)
>   
>> 4.2 sais the virtual interface hides existence of multiple interfaces.
>> Yes, it hides to the applications, but not to the network. Well,
>>     
> depends
>   
>> on how much you break the existing system on a mobile. Virtual
>>     
> interfaces
>   
>> are very useful to solve local routing issues when sending uplink 
>> traffic in
>> such scenarios, as having the same IP address configured at multiple
>> interfaces screws up the local routing table. At least on a Linux
>>     
> system.
>   
>> I see the role of the virtual interface less for downlink traffic, as 
>> the network
>> takes care about forwarding to the right interface, which works also 
>> without
>> virtual interface.
>>     
>
> The biggest advantage of having a virtual interface is to avoid 
> complications from withdrawing an address from an interface and 
> assigning the same address to another interface. This is not trivial in 
> most host implementations. As far as the network is concerned, it sees 
> only one physical interface of the mobile node at a time. But the LMA 
> would assign the same HNP/address to the two interfaces because it only 
> sees the interface identifier associated with the virtual interface.
>   
Since 4.2 talks about handover, maybe. Depends how the network 
identifies an interface and/or
technology change. If you make the interface ID the same or, as far as I 
understand, you propose
to use only one interface ID at all, which is the one from the virtual 
one, the interfaces
do not differ from network point of view.  In my opinion, you don't need 
to keep physical interfaces
that transparent to the network and can solve some issues on the mobile 
differently. I agree that
using the same IP address on multiple interfaces is difficult in some 
systems. That you may
solve with a virtual interface. But I would not overload the role of the 
virtual interface here.
>   
>> 4.3 last paragraph sais that the mobile must move the prefix to the
>> target interface. I think it's more useful to write that the mobile
>>     
> must
>   
>> move the address suffix being used on the source interface to the
>> target interface, as the HNP for the target interface is notified by
>>     
> the
>   
>> target MAG as result of the registration. Using the HNP on the
>> target interface rather must be authorized by the network.
>>     
>
> It is assumed that the network is able to assign the same HNP to if2, 
> i.e., it is treated as a handover. Moving the suffix (or the interface 
> identifier) part of the address from if1 and if2 would also be required,
> if the sessions  on the mobile node are supposed to survive. This would
> be true for any handovers that involves two interfaces.
>   
Yes, the assumption is correct and obviuos to support session 
continuity. But still the
MN should wait for an indication from the network to set and activate 
the prefix
on the target interface.

marco

> Vijay
>
>   
>> marco
>>
>>
>>
>> Vijay Devarapalli schrieb:
>>     
>>> Hello folks,
>>>
>>> I updated the draft on multiple interface support for PMIPv6. It used
>>>       
> to
>   
>>> be draft-devarapalli-netlmm-multihoming earlier. Comments are
>>>       
> welcome.
>   
>>> Vijay
>>> -----Original Message-----
>>> From: IETF I-D Submission Tool [mailto:idsubmission at ietf.org] Sent: 
>>> Tuesday, March 03, 2009 10:02 PM
>>> To: Vijay Devarapalli
>>> Subject: New Version Notification for
>>> draft-devarapalli-netext-multi-interface-support-00
>>>
>>> A new version of I-D,
>>> draft-devarapalli-netext-multi-interface-support-00.txt has been
>>> successfuly submitted by Vijay Devarapalli and posted to the IETF
>>> repository.
>>>
>>> Filename:     draft-devarapalli-netext-multi-interface-support
>>> Revision:     00
>>> Title:         Multiple Interface Support with Proxy Mobile IPv6
>>> Creation_date:     2009-03-03
>>> WG ID:         Independent Submission
>>> Number_of_pages: 14
>>>
>>> Abstract:
>>> Proxy Mobile IPv6 enables network-based mobility for a regular IPv6
>>> mobile node with no mobility management protocol.  It makes it appear
>>> to the mobile node that its IP address does not change as the mobile
>>> node moves across the Proxy Mobile IPv6 domain.  There have been some
>>> issues identified with supporting a host with multiple interfaces
>>> attaching to the Proxy Mobile IPv6 domain.  This document describes
>>> and analyzes some of the scenarios associated with this.  It also
>>> describes the requirements for a handover across interfaces using
>>> Proxy Mobile IPv6.
>>>  
>>>
>>>
>>>
>>> The IETF Secretariat.
>>>
>>>
>>>
>>> _______________________________________________
>>> NetExt mailing list
>>> NetExt at mail.mobileip.jp
>>> http://www.mobileip.jp/mailman/listinfo/netext
>>>   
>>>       
>>     
>
>
>   

From: vijay at wichorus.com (Vijay Devarapalli)
Date: Wed, 18 Mar 2009 23:14:54 -0400
Subject: [Netext] PMIPv6 Multiple Interface support
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Marco,

Marco Liebsch wrote:
> Hi Vijay,
> 
> a very useful document to understand the impact of some multi-homing
and
> handover use cases to the mobile. Please find below a few comments to
the
> current version of the draft.
> 
> 3.3 sais that the LMA maintains only a single BCE in case of shared
> addresses. This assumes that the HNP is the same for both interfaces,
> but the link layer ID may be different. 

Much more than that. Section 3.3 talks about the same address being 
assigned to more than one interface. The actual flows are routed based 
on the flow filters in the proxy binding cache entry. The flow filter 
would identify which MAG to tunnel the packets to.

> A lookup in the BC can be
> performed on the link layer ID, which allows also existence of
> different BCEs for this case. In my opinion an implementation
> detail, which should not be written in the draft.

Sure, the language can be relaxed to say, "for example, one could do 
this...."

> The same section refers to the use of service identifiers to select
> flow filters on the LMA. It should not be a MUST condition here,
> as there are other possibilities to enforce flow filters on the LMA.
> This brings up the next question: Is this an analysis document or a
> specifcation? In the latter case you could of course mandate a
> particular mechanism. I think an analysis of the impact and
> requirements is more useful at this point.

The document looks at the scenarios and suggests possible solutions too.

Note that this was written two years ago. I was just collecting all my 
thoughts on multiple interface support into one document. :)

> 4.2 sais the virtual interface hides existence of multiple interfaces.
> Yes, it hides to the applications, but not to the network. Well,
depends
> on how much you break the existing system on a mobile. Virtual
interfaces
> are very useful to solve local routing issues when sending uplink 
> traffic in
> such scenarios, as having the same IP address configured at multiple
> interfaces screws up the local routing table. At least on a Linux
system.
> I see the role of the virtual interface less for downlink traffic, as 
> the network
> takes care about forwarding to the right interface, which works also 
> without
> virtual interface.

The biggest advantage of having a virtual interface is to avoid 
complications from withdrawing an address from an interface and 
assigning the same address to another interface. This is not trivial in 
most host implementations. As far as the network is concerned, it sees 
only one physical interface of the mobile node at a time. But the LMA 
would assign the same HNP/address to the two interfaces because it only 
sees the interface identifier associated with the virtual interface.

> 4.3 last paragraph sais that the mobile must move the prefix to the
> target interface. I think it's more useful to write that the mobile
must
> move the address suffix being used on the source interface to the
> target interface, as the HNP for the target interface is notified by
the
> target MAG as result of the registration. Using the HNP on the
> target interface rather must be authorized by the network.

It is assumed that the network is able to assign the same HNP to if2, 
i.e., it is treated as a handover. Moving the suffix (or the interface 
identifier) part of the address from if1 and if2 would also be required,
if the sessions  on the mobile node are supposed to survive. This would
be true for any handovers that involves two interfaces.

Vijay

> 
> marco
> 
> 
> 
> Vijay Devarapalli schrieb:
>> Hello folks,
>>
>> I updated the draft on multiple interface support for PMIPv6. It used
to
>> be draft-devarapalli-netlmm-multihoming earlier. Comments are
welcome.
>>
>> Vijay
>> -----Original Message-----
>> From: IETF I-D Submission Tool [mailto:idsubmission at ietf.org] Sent: 
>> Tuesday, March 03, 2009 10:02 PM
>> To: Vijay Devarapalli
>> Subject: New Version Notification for
>> draft-devarapalli-netext-multi-interface-support-00
>>
>> A new version of I-D,
>> draft-devarapalli-netext-multi-interface-support-00.txt has been
>> successfuly submitted by Vijay Devarapalli and posted to the IETF
>> repository.
>>
>> Filename:     draft-devarapalli-netext-multi-interface-support
>> Revision:     00
>> Title:         Multiple Interface Support with Proxy Mobile IPv6
>> Creation_date:     2009-03-03
>> WG ID:         Independent Submission
>> Number_of_pages: 14
>>
>> Abstract:
>> Proxy Mobile IPv6 enables network-based mobility for a regular IPv6
>> mobile node with no mobility management protocol.  It makes it appear
>> to the mobile node that its IP address does not change as the mobile
>> node moves across the Proxy Mobile IPv6 domain.  There have been some
>> issues identified with supporting a host with multiple interfaces
>> attaching to the Proxy Mobile IPv6 domain.  This document describes
>> and analyzes some of the scenarios associated with this.  It also
>> describes the requirements for a handover across interfaces using
>> Proxy Mobile IPv6.
>>  
>>
>>
>>
>> The IETF Secretariat.
>>
>>
>>
>> _______________________________________________
>> NetExt mailing list
>> NetExt at mail.mobileip.jp
>> http://www.mobileip.jp/mailman/listinfo/netext
>>   
> 
> 

From: domagoj.premec.ext at nsn.com (Domagoj Premec)
Date: Fri, 13 Mar 2009 14:08:58 +0100
Subject: [Netext] Comments on draft-premec-netlmm-bulk-re-registration-02.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Vijay,

> >> Is the new LMA supposed to group all the mobile nodes in 
> one PBU into 
> >> a new bulk re-registration set?
> > 
> > It doesn't need to be new, it could be an exisitng one.
> 
> But this a new LMA that the MAG is contacting. How can the 
> mobile nodes attached to this MAG be grouped into an existing 
> bulk re-registration set on the new LMA? It has to be a new 
> set, right?

I misunderstood you, I thought you were asking if each PBU creates its own
bulk set.

But even in the recovery case, it is possible that the MNs from the failed
LMA get added to the exiting bulk set. The LMA maintains bulk set(s) per MAG
and the very first PBU from a particular MAG results in a new bulk set being
created at the LMA. In the recovery scenario, it is possible that the new
LMA already had some PMIP sessions with the MAG prior to the failure of the
other LMA. When the MAG registers the MNs from the failed LMA with the new
LMA, they might get added to the existing bulk set associated with that MAG.

As to the new status code "Accepted but bulk re-registration not
permitted"... my original thinking was that the LMA would signal this by
simply omitting the bulk flag in the PBAck, but having explicit indicaiton
is probably better. I'll add it in the next revision.

domagoj

> -----Original Message-----
> From: ext Vijay Devarapalli [mailto:vijay at wichorus.com] 
> Sent: 12. ozujak 2009 21:01
> To: Domagoj Premec
> Cc: draft-premec-netlmm-bulk-re-registration at tools.ietf.org; 
> netext at mail.mobileip.jp
> Subject: Re: Comments on 
> draft-premec-netlmm-bulk-re-registration-02.txt
> 
> Hi Domagoj,
> 
> Domagoj Premec wrote:
> 
> >> It is not clear how bulk registration when the LMA fails 
> is supposed 
> >> to work.
> >>
> >>    If the bulk registration message is being sent to 
> recover from an 
> >> LMA
> >>
> >>    failure the MAG MUST explicitly identify all the MNs that are 
> >>    included in the bulk registration set and provide all 
> the mobility 
> >>    options that need to be included in an initial PBU. Due to the 
> >> size
> >>    of these options, the MAG may not be able to fit all the MNs 
> >> attached
> >>
> >>    to it into a single PBU. In this case the MAG will 
> split the MNs 
> >>    across multiple PBUs. The receiving LMA can use the information 
> >>    included in these bulk PBUs to recreate the bulk 
> registration set, 
> >> so
> >>
> >>    that the MAG can renew the MNs' lifetimes later with a 
> single PBU. 
> >>
> >> Lets say the MAG and the old LMA end up with three bulk 
> >> re-registration sets with 10,000 mobile nodes in each of 
> these sets. 
> >> How do you list each mobile node, with its corresponding mobility 
> >> options in a single PBU to the new LMA? How does this PBU 
> look like? 
> >> Are the MN-ID, MN-HNP, and other options for each mobile 
> node listed 
> >> one after the other?
> >> Something like,
> >>
> >> IPv6 hdr (src=MAG, dst=LMA)
> >> Mobility Header
> >>    PBU (with bulk registration flag set)
> >>    MN1 ID, MN1 options
> >>    MN2 ID, MN2 options
> >>    MN3 ID, MN3 options
> >>    ...
> >>
> >> How is the LMA supposed to process this message? 
> > 
> > I agree that the LMA recovery part needs a more detailed 
> description 
> > then what is currently there in the draft, we need to work 
> on that...
> > 
> >> Is the new LMA supposed to group all the mobile nodes in 
> one PBU into 
> >> a new bulk re-registration set?
> > 
> > It doesn't need to be new, it could be an exisitng one.
> 
> But this a new LMA that the MAG is contacting. How can the 
> mobile nodes attached to this MAG be grouped into an existing 
> bulk re-registration set on the new LMA? It has to be a new 
> set, right?
> 
> >> But if the MNs are
> >> split across multiple PBUs, how does the new LMA group the 
> MNs? Does 
> >> it create one bulk re-registration set per PBU for the MNs 
> listed in 
> >> the PBU?
> > 
> > How the LMA assigns the MNs to bulk sets is a matter of 
> local policy 
> > at the LMA. All the MNs from a single PBU get added to the 
> same bulk 
> > set, but the MNs from other PBUs could also get added to 
> that same bulk set.
> > 
> >> My 2 cents would be to remove the LMA failure scenario altogether. 
> >> The basic feature of being to do bulk re-registration is 
> good. I am 
> >> not sure this needs to be used for LMA failure scenarios.
> > 
> > I agree that the bulk re-registration and the LMA recovery 
> scenarios 
> > are
> > different:
> > 
> > a) bulk re-registration
> > this relies on the previously established state and simply confirms 
> > that the established state is still valid and should be extended
> > 
> > b) LMA recovery
> > the LMA lost its state completely and that state must now get 
> > recreated by sending all the necessary information over to the LMA
> > 
> > Let us (co-authors) think about this... maybe it would make 
> sense to 
> > tackle the LMA recovery case as a standalone document.
> 
> Ok. IMO, quite a bit of work is required to explain how this 
> is supposed to work. I think it is best to remove it and 
> focus on optimizing signaling for just refreshing the 
> existing bindings.
> 
> >> In section 3
> >>
> >>    When requested to add a MN to the bulk re-registration set, the 
> >> LMA
> >>    may reject the request. In this case the LMA processes the PBU 
> >>    message as if the bulk re-registration flag was not set and 
> >> responds
> >>    with PBAck message where the bulk re-registration flag 
> is set to 
> >> 0.
> >>
> >> I think you need a new status code here to reject the PBU. An LMA 
> >> that does not implement draft-premec-netlmm-bulk-re-registration 
> >> would not even know about the new flag and ignore it. If 
> you want the 
> >> MAG to be able to distinguish between rejecting the request to add 
> >> the MN to the bulk re-registration set and not supporting bulk 
> >> re-registrations at all, you need the new PBAck status code.
> > 
> > The intended meaning was not to reject the complete PBU, 
> but only the 
> > "adding to the bulk set" part. I need to reformulate this 
> to make it 
> > clearer.
> 
> This is easy to fix. You need to pick a status value from 
> 0-127. These are "success" status values. Currently we have 
> the following success status values.
> 
> 0      Binding Update accepted                   [RFC3775]
> 1      Accepted but prefix discovery necessary   [RFC3775]
> 
> You can define
> 
> 2      Accepted but bulk re-registration not permitted
> 
> You probably need to add some text that says this status 
> value in the Proxy Binding Ack means that the bulk 
> re-registration is not permitted just for the particular 
> mobile node. Not in general.
> 
> >> The IANA considerations section says "None" right now. You are 
> >> defining one new flag and one new mobility option. These 
> need to be 
> >> listed.
> > 
> > yes... need to take care of this, too.
> 
> Ok.
> 
> Vijay
> 

From: vijay at wichorus.com (Vijay Devarapalli)
Date: Thu, 12 Mar 2009 12:00:46 -0800
Subject: [Netext] Comments on draft-premec-netlmm-bulk-re-registration-02.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Domagoj,

Domagoj Premec wrote:

>> It is not clear how bulk registration when the LMA fails is 
>> supposed to work. 
>>
>>    If the bulk registration message is being sent to recover 
>> from an LMA
>>
>>    failure the MAG MUST explicitly identify all the MNs that are 
>>    included in the bulk registration set and provide all the mobility 
>>    options that need to be included in an initial PBU. Due to 
>> the size 
>>    of these options, the MAG may not be able to fit all the 
>> MNs attached
>>
>>    to it into a single PBU. In this case the MAG will split the MNs 
>>    across multiple PBUs. The receiving LMA can use the information 
>>    included in these bulk PBUs to recreate the bulk 
>> registration set, so
>>
>>    that the MAG can renew the MNs' lifetimes later with a single PBU. 
>>
>> Lets say the MAG and the old LMA end up with three bulk 
>> re-registration sets with 10,000 mobile nodes in each of 
>> these sets. How do you list each mobile node, with its 
>> corresponding mobility options in a single PBU to the new 
>> LMA? How does this PBU look like? Are the MN-ID, MN-HNP, and 
>> other options for each mobile node listed one after the other?
>> Something like, 
>>
>> IPv6 hdr (src=MAG, dst=LMA)
>> Mobility Header
>>    PBU (with bulk registration flag set)
>>    MN1 ID, MN1 options
>>    MN2 ID, MN2 options
>>    MN3 ID, MN3 options
>>    ...
>>
>> How is the LMA supposed to process this message? 
> 
> I agree that the LMA recovery part needs a more detailed description then
> what is currently there in the draft, we need to work on that...
> 
>> Is the new LMA supposed to group all the mobile nodes in one 
>> PBU into a new bulk re-registration set?
> 
> It doesn't need to be new, it could be an exisitng one.

But this a new LMA that the MAG is contacting. How can the mobile nodes 
attached to this MAG be grouped into an existing bulk re-registration 
set on the new LMA? It has to be a new set, right?

>> But if the MNs are 
>> split across multiple PBUs, how does the new LMA group the 
>> MNs? Does it create one bulk re-registration set per PBU for 
>> the MNs listed in the PBU?
> 
> How the LMA assigns the MNs to bulk sets is a matter of local policy at the
> LMA. All the MNs from a single PBU get added to the same bulk set, but the
> MNs from other PBUs could also get added to that same bulk set.
> 
>> My 2 cents would be to remove the LMA failure scenario 
>> altogether. The basic feature of being to do bulk 
>> re-registration is good. I am not sure this needs to be used 
>> for LMA failure scenarios.
> 
> I agree that the bulk re-registration and the LMA recovery scenarios are
> different:
> 
> a) bulk re-registration
> this relies on the previously established state and simply confirms that the
> established state is still valid and should be extended
> 
> b) LMA recovery
> the LMA lost its state completely and that state must now get recreated by
> sending all the necessary information over to the LMA
> 
> Let us (co-authors) think about this... maybe it would make sense to tackle
> the LMA recovery case as a standalone document.

Ok. IMO, quite a bit of work is required to explain how this is supposed 
to work. I think it is best to remove it and focus on optimizing 
signaling for just refreshing the existing bindings.

>> In section 3
>>
>>    When requested to add a MN to the bulk re-registration 
>> set, the LMA 
>>    may reject the request. In this case the LMA processes the PBU 
>>    message as if the bulk re-registration flag was not set 
>> and responds 
>>    with PBAck message where the bulk re-registration flag is 
>> set to 0. 
>>
>> I think you need a new status code here to reject the PBU. An 
>> LMA that does not implement 
>> draft-premec-netlmm-bulk-re-registration would not even know 
>> about the new flag and ignore it. If you want the MAG to be 
>> able to distinguish between rejecting the request to add the 
>> MN to the bulk re-registration set and not supporting bulk 
>> re-registrations at all, you need the new PBAck status code.
> 
> The intended meaning was not to reject the complete PBU, but only the
> "adding to the bulk set" part. I need to reformulate this to make it
> clearer. 

This is easy to fix. You need to pick a status value from 0-127. These 
are "success" status values. Currently we have the following success 
status values.

0      Binding Update accepted                   [RFC3775]
1      Accepted but prefix discovery necessary   [RFC3775]

You can define

2      Accepted but bulk re-registration not permitted

You probably need to add some text that says this status value in the 
Proxy Binding Ack means that the bulk re-registration is not permitted 
just for the particular mobile node. Not in general.

>> The IANA considerations section says "None" right now. You 
>> are defining one new flag and one new mobility option. These 
>> need to be listed.
> 
> yes... need to take care of this, too.

Ok.

Vijay

From: marco.liebsch at nw.neclab.eu (Marco Liebsch)
Date: Thu, 12 Mar 2009 16:52:22 +0100
Subject: [Netext] PMIPv6 Multiple Interface support
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi Vijay,

a very useful document to understand the impact of some multi-homing and
handover use cases to the mobile. Please find below a few comments to the
current version of the draft.

3.3 sais that the LMA maintains only a single BCE in case of shared
addresses. This assumes that the HNP is the same for both interfaces,
but the link layer ID may be different. A lookup in the BC can be
performed on the link layer ID, which allows also existence of
different BCEs for this case. In my opinion an implementation
detail, which should not be written in the draft.

The same section refers to the use of service identifiers to select
flow filters on the LMA. It should not be a MUST condition here,
as there are other possibilities to enforce flow filters on the LMA.
This brings up the next question: Is this an analysis document or a
specifcation? In the latter case you could of course mandate a
particular mechanism. I think an analysis of the impact and
requirements is more useful at this point.

4.2 sais the virtual interface hides existence of multiple interfaces.
Yes, it hides to the applications, but not to the network. Well, depends
on how much you break the existing system on a mobile. Virtual interfaces
are very useful to solve local routing issues when sending uplink traffic in
such scenarios, as having the same IP address configured at multiple
interfaces screws up the local routing table. At least on a Linux system.
I see the role of the virtual interface less for downlink traffic, as 
the network
takes care about forwarding to the right interface, which works also without
virtual interface.

4.3 last paragraph sais that the mobile must move the prefix to the
target interface. I think it's more useful to write that the mobile must
move the address suffix being used on the source interface to the
target interface, as the HNP for the target interface is notified by the
target MAG as result of the registration. Using the HNP on the
target interface rather must be authorized by the network.

marco

Vijay Devarapalli schrieb:
> Hello folks,
>
> I updated the draft on multiple interface support for PMIPv6. It used to
> be draft-devarapalli-netlmm-multihoming earlier. Comments are welcome.
>
> Vijay 
>
> -----Original Message-----
> From: IETF I-D Submission Tool [mailto:idsubmission at ietf.org] 
> Sent: Tuesday, March 03, 2009 10:02 PM
> To: Vijay Devarapalli
> Subject: New Version Notification for
> draft-devarapalli-netext-multi-interface-support-00 
>
>
> A new version of I-D,
> draft-devarapalli-netext-multi-interface-support-00.txt has been
> successfuly submitted by Vijay Devarapalli and posted to the IETF
> repository.
>
> Filename:	 draft-devarapalli-netext-multi-interface-support
> Revision:	 00
> Title:		 Multiple Interface Support with Proxy Mobile IPv6
> Creation_date:	 2009-03-03
> WG ID:		 Independent Submission
> Number_of_pages: 14
>
> Abstract:
> Proxy Mobile IPv6 enables network-based mobility for a regular IPv6
> mobile node with no mobility management protocol.  It makes it appear
> to the mobile node that its IP address does not change as the mobile
> node moves across the Proxy Mobile IPv6 domain.  There have been some
> issues identified with supporting a host with multiple interfaces
> attaching to the Proxy Mobile IPv6 domain.  This document describes
> and analyzes some of the scenarios associated with this.  It also
> describes the requirements for a handover across interfaces using
> Proxy Mobile IPv6.
>  
>
>
>
> The IETF Secretariat.
>
>
>
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
>   

From: domagoj.premec.ext at nsn.com (Domagoj Premec)
Date: Thu, 12 Mar 2009 15:33:35 +0100
Subject: [Netext] Comments on draft-premec-netlmm-bulk-re-registration-02.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Vijay,

Thanks for looking at the draft, please see some responses inline...

> -----Original Message-----
> From: ext Vijay Devarapalli [mailto:vijay at wichorus.com] 
> Sent: 12. ozujak 2009 02:11
> To: draft-premec-netlmm-bulk-re-registration at tools.ietf.org
> Cc: netext at mail.mobileip.jp
> Subject: Comments on draft-premec-netlmm-bulk-re-registration-02.txt
> 
> Hello,
> 
> I briefly read through the document. It is a well written 
> document. It mostly looks good, but have a few comments. 

thanks :)

> 
> It is not clear how bulk registration when the LMA fails is 
> supposed to work. 
> 
>    If the bulk registration message is being sent to recover 
> from an LMA
> 
>    failure the MAG MUST explicitly identify all the MNs that are 
>    included in the bulk registration set and provide all the mobility 
>    options that need to be included in an initial PBU. Due to 
> the size 
>    of these options, the MAG may not be able to fit all the 
> MNs attached
> 
>    to it into a single PBU. In this case the MAG will split the MNs 
>    across multiple PBUs. The receiving LMA can use the information 
>    included in these bulk PBUs to recreate the bulk 
> registration set, so
> 
>    that the MAG can renew the MNs' lifetimes later with a single PBU. 
> 
> Lets say the MAG and the old LMA end up with three bulk 
> re-registration sets with 10,000 mobile nodes in each of 
> these sets. How do you list each mobile node, with its 
> corresponding mobility options in a single PBU to the new 
> LMA? How does this PBU look like? Are the MN-ID, MN-HNP, and 
> other options for each mobile node listed one after the other?
> Something like, 
> 
> IPv6 hdr (src=MAG, dst=LMA)
> Mobility Header
>    PBU (with bulk registration flag set)
>    MN1 ID, MN1 options
>    MN2 ID, MN2 options
>    MN3 ID, MN3 options
>    ...
> 
> How is the LMA supposed to process this message? 

I agree that the LMA recovery part needs a more detailed description then
what is currently there in the draft, we need to work on that...

> 
> Is the new LMA supposed to group all the mobile nodes in one 
> PBU into a new bulk re-registration set?

It doesn't need to be new, it could be an exisitng one.

> But if the MNs are 
> split across multiple PBUs, how does the new LMA group the 
> MNs? Does it create one bulk re-registration set per PBU for 
> the MNs listed in the PBU?

How the LMA assigns the MNs to bulk sets is a matter of local policy at the
LMA. All the MNs from a single PBU get added to the same bulk set, but the
MNs from other PBUs could also get added to that same bulk set.

> 
> My 2 cents would be to remove the LMA failure scenario 
> altogether. The basic feature of being to do bulk 
> re-registration is good. I am not sure this needs to be used 
> for LMA failure scenarios.

I agree that the bulk re-registration and the LMA recovery scenarios are
different:

a) bulk re-registration
this relies on the previously established state and simply confirms that the
established state is still valid and should be extended

b) LMA recovery
the LMA lost its state completely and that state must now get recreated by
sending all the necessary information over to the LMA

Let us (co-authors) think about this... maybe it would make sense to tackle
the LMA recovery case as a standalone document.

> 
> In section 3
> 
>    When requested to add a MN to the bulk re-registration 
> set, the LMA 
>    may reject the request. In this case the LMA processes the PBU 
>    message as if the bulk re-registration flag was not set 
> and responds 
>    with PBAck message where the bulk re-registration flag is 
> set to 0. 
> 
> I think you need a new status code here to reject the PBU. An 
> LMA that does not implement 
> draft-premec-netlmm-bulk-re-registration would not even know 
> about the new flag and ignore it. If you want the MAG to be 
> able to distinguish between rejecting the request to add the 
> MN to the bulk re-registration set and not supporting bulk 
> re-registrations at all, you need the new PBAck status code.

The intended meaning was not to reject the complete PBU, but only the
"adding to the bulk set" part. I need to reformulate this to make it
clearer. 

> 
> The IANA considerations section says "None" right now. You 
> are defining one new flag and one new mobility option. These 
> need to be listed.

yes... need to take care of this, too.

domagoj

> 
> Vijay
> 
> > -----Original Message-----
> > From: netext-bounces at mail.mobileip.jp 
> > [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of Domagoj Premec
> > Sent: Monday, March 09, 2009 7:53 AM
> > To: netext at mail.mobileip.jp
> > Subject: [Netext] FW: 
> > I-DAction:draft-premec-netlmm-bulk-re-registration-02.txt
> > 
> > Hello,
> > 
> > This is the revised version of the bulk registrations in the
> > PMIPv6 domain.
> > 
> > domagoj
> >  
> > 
> > -----Original Message-----
> > From: i-d-announce-bounces at ietf.org
> > [mailto:i-d-announce-bounces at ietf.org]
> > On Behalf Of ext Internet-Drafts at ietf.org
> > Sent: 09. ozujak 2009 15:00
> > To: i-d-announce at ietf.org
> > Subject: I-D Action:draft-premec-netlmm-bulk-re-registration-02.txt
> > 
> > A New Internet-Draft is available from the on-line Internet-Drafts 
> > directories.
> > 
> > 	Title           : Bulk Re-registration for Proxy Mobile IPv6
> > 	Author(s)       : D. Premec, et al.
> > 	Filename        : 
> > draft-premec-netlmm-bulk-re-registration-02.txt
> > 	Pages           : 13
> > 	Date            : 2009-03-09
> > 
> > The Proxy Mobile IPv6 specification requires the Mobile 
> Access Gateway 
> > (MAG) to send a separate Proxy Binding Update (PBU) message to the 
> > Local Mobility Agent (LMA) for each mobile node (MN) to 
> renew the MN's 
> > mobility binding.
> > This document defines a mechanism by which a MAG can update the 
> > mobility bindings of multiple MNs attached to it with a single PBU 
> > message to the serving LMA. This mechanism is also intended 
> to be used 
> > by a MAG to re-establish bindings at a new LMA when its old 
> LMA fails.
> > 
> >  
> > 
> > Conventions used in this document
> > 
> > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
> > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 
> "OPTIONAL" in this 
> > document are to be interpreted as described in [RFC2119].
> > 
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-premec-netlmm-bulk-r
> > e-registration
> > -02.txt
> > 
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> > 
> > Below is the data which will enable a MIME compliant mail reader 
> > implementation to automatically retrieve the ASCII version of the 
> > Internet-Draft.
> > 
> > _______________________________________________
> > NetExt mailing list
> > NetExt at mail.mobileip.jp
> > http://www.mobileip.jp/mailman/listinfo/netext
> > 
> 

From: vijay at wichorus.com (Vijay Devarapalli)
Date: Wed, 11 Mar 2009 21:11:00 -0400
Subject: [Netext] Comments on draft-premec-netlmm-bulk-re-registration-02.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hello,

I briefly read through the document. It is a well written document. It
mostly looks good, but have a few comments. 

It is not clear how bulk registration when the LMA fails is supposed to
work. 

   If the bulk registration message is being sent to recover from an LMA

   failure the MAG MUST explicitly identify all the MNs that are 
   included in the bulk registration set and provide all the mobility 
   options that need to be included in an initial PBU. Due to the size 
   of these options, the MAG may not be able to fit all the MNs attached

   to it into a single PBU. In this case the MAG will split the MNs 
   across multiple PBUs. The receiving LMA can use the information 
   included in these bulk PBUs to recreate the bulk registration set, so

   that the MAG can renew the MNs' lifetimes later with a single PBU. 

Lets say the MAG and the old LMA end up with three bulk re-registration
sets with 10,000 mobile nodes in each of these sets. How do you list
each mobile node, with its corresponding mobility options in a single
PBU to the new LMA? How does this PBU look like? Are the MN-ID, MN-HNP,
and other options for each mobile node listed one after the other?
Something like, 

IPv6 hdr (src=MAG, dst=LMA)
Mobility Header
   PBU (with bulk registration flag set)
   MN1 ID, MN1 options
   MN2 ID, MN2 options
   MN3 ID, MN3 options
   ...

How is the LMA supposed to process this message? 

Is the new LMA supposed to group all the mobile nodes in one PBU into a
new bulk re-registration set? But if the MNs are split across multiple
PBUs, how does the new LMA group the MNs? Does it create one bulk
re-registration set per PBU for the MNs listed in the PBU?

My 2 cents would be to remove the LMA failure scenario altogether. The
basic feature of being to do bulk re-registration is good. I am not sure
this needs to be used for LMA failure scenarios.

In section 3

   When requested to add a MN to the bulk re-registration set, the LMA 
   may reject the request. In this case the LMA processes the PBU 
   message as if the bulk re-registration flag was not set and responds 
   with PBAck message where the bulk re-registration flag is set to 0. 

I think you need a new status code here to reject the PBU. An LMA that
does not implement draft-premec-netlmm-bulk-re-registration would not
even know about the new flag and ignore it. If you want the MAG to be
able to distinguish between rejecting the request to add the MN to the
bulk re-registration set and not supporting bulk re-registrations at
all, you need the new PBAck status code.

The IANA considerations section says "None" right now. You are defining
one new flag and one new mobility option. These need to be listed.

Vijay

> -----Original Message-----
> From: netext-bounces at mail.mobileip.jp 
> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of Domagoj Premec
> Sent: Monday, March 09, 2009 7:53 AM
> To: netext at mail.mobileip.jp
> Subject: [Netext] FW: 
> I-DAction:draft-premec-netlmm-bulk-re-registration-02.txt
> 
> Hello,
> 
> This is the revised version of the bulk registrations in the 
> PMIPv6 domain.
> 
> domagoj
>  
> 
> -----Original Message-----
> From: i-d-announce-bounces at ietf.org 
> [mailto:i-d-announce-bounces at ietf.org]
> On Behalf Of ext Internet-Drafts at ietf.org
> Sent: 09. ozujak 2009 15:00
> To: i-d-announce at ietf.org
> Subject: I-D Action:draft-premec-netlmm-bulk-re-registration-02.txt 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> 
> 	Title           : Bulk Re-registration for Proxy Mobile IPv6
> 	Author(s)       : D. Premec, et al.
> 	Filename        : 
> draft-premec-netlmm-bulk-re-registration-02.txt
> 	Pages           : 13
> 	Date            : 2009-03-09
> 
> The Proxy Mobile IPv6 specification requires the Mobile 
> Access Gateway (MAG)
> to send a separate Proxy Binding Update (PBU) message to the 
> Local Mobility
> Agent (LMA) for each mobile node (MN) to renew the MN's 
> mobility binding.
> This document defines a mechanism by which a MAG can update 
> the mobility
> bindings of multiple MNs attached to it with a single PBU 
> message to the
> serving LMA. This mechanism is also intended to be used by a MAG to
> re-establish bindings at a new LMA when its old LMA fails. 
> 
>  
> 
> Conventions used in this document 
> 
> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
> document are to be interpreted as described in [RFC2119].
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-premec-netlmm-bulk-r
> e-registration
> -02.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
> 

From: Mohana.Jeyatharan at sg.panasonic.com (Mohana Jeyatharan)
Date: Thu, 12 Mar 2009 08:32:23 +0800
Subject: [Netext] draft-jeyatharan-netext-multihoming-ps-01.txt
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Hi David,

Thanks. Please see replies in-line.

BR,
Mohana

-----Original Message-----
From: David Cypher [mailto:david.cypher at nist.gov] 
Sent: Wednesday, March 11, 2009 9:54 PM
To: Mohana Jeyatharan; netext at mail.mobileip.jp
Subject: RE: [Netext] draft-jeyatharan-netext-multihoming-ps-01.txt

Mohana,

At 08:41 PM 3/10/2009, Mohana Jeyatharan wrote:
>Hi David,
>
>Thanks for your comments.
>
>Thanks Rajeev for all replies. Just want to add in some thing small.
>
>Please see.
>BR,
>Mohana
>
>-----Original Message-----
>From: netext-bounces at mail.mobileip.jp
>[mailto:netext-bounces at mail.mobileip.jp] On Behalf Of David Cypher
>Sent: Wednesday, March 11, 2009 2:35 AM
>To: netext at mail.mobileip.jp
>Subject: Re: [Netext] draft-jeyatharan-netext-multihoming-ps-01.txt
>
>Comments on version 1 of the multihoming PS
>
>2.1
>One way (stateless) or another (stateful or manual) in RFC 5213 the
>list of home Network prefixes (HNP) is fixed.
>There is no requirement that the mobile use all of its HNPs once they
>are assigned.  I do not see the problem, especially after reading the
>motivation.  The motivation described the ability of the mobile node
>to decide when it needs a prefix and when to use it.  As I see it,
>the mobile node has that now.  The mobile node receives P1, P2, and
>P3 at the start. The mobile node can use P1 and P2 whenever it wants
>and can stop using them and chose to use P3 at any time.  PMIP does
>not care and no change to the mobile node is required.
>
>Are you thinking more on the lines of selectively moving HNP(s) from
>one interface to another (or sharing selective HNP(s) across multiple
>interface)?
>[Mohana] I think Rajeev has explained in previous mails. But dynamic
>creation is 1) dynamically creating session for a given interface by
>allocating new prefixes and dynamically creating session associated
with
>another interface using some prefixes from a given iterface. These are
>the cases handled under dynamic creation. Moving prefixes from one
>interface to another is also the dynamic state. Agree with you.

He might have, but these are not captured in the new PS.
[Mohana] I think we have mentioned about it in section 2 prolem
statement.
I am pasting that here. Please see.
o  Problem

      In PMIPv6 protocol, when a mobile node powers on a new interface,
      the new mobile access gateway sets the handoff indication option
      value to '2'.  All the prefixes that are assigned to the
      previously attached interface are then transferred to the new
      interface.  When such transfer takes place, the binding cache
      entry of one interface is updated with the new binding cache entry
      created for the new interface.  This is inflexible, as it cannot
      support the case where only some (but not all) prefixes that are
      assigned to one interface are transferred to a newly powered on
      interface, or transferred to an already connected interface.
>4
>The statement about "the assumption that each of the interfaces is
>attached to a different mobile access gateway." I do not agree
>with.  Reference is given as 5.3.1, but this is just the tip of a
>very complicated decision tree based on the contents of the PBU and
>the existence (and comparison of contents to the PBU) or non
>existence of a BCE at the LMA.
>The creation of the PBU is based on the BUL at the MAG detecting the
>mobile node / interface, as well as the mobile node's policy
>profile.  One of the required parameters in the PBU is the Handoff
>Indicator field, which can be set according to the following:
>
>RFC 5213, 6.9.1.1, bullet 5, second star bullet, page 50
>"
>          *  Some link layers have link-layer identifiers that can be
>used
>             to distinguish (a) the movement of a particular interface
to
>             a new attachment from (b) the attachment of a new
interface
>             from the same host.  Option value 3 (Handoff between
mobile
>             access gateways for the same interface) is appropriate in
>             case (a) and a value of 1 (Attachment over a new
interface)
>             in case (b).
>"
>Case (b) in my reading permits the mobile node to be attached to the
>same MAG with two interfaces.
>
>Therefore the assumption statement in the PS does not hold true.  Does
>it?
>Perhaps you can provide the contents of BCE at the LMA, BUL at the
>MAG, mobile node policy profile, and the PBU that supports your
>assumption and reference 5.3.1.
>Or modify the statement to be more specific about which case of
>multiple interfaces.
>[Mohana] Ok, let me quote the reference. It is in page 20 section
5.3.1.
>
>13.  Considerations specified in Section 5.4.1 MUST be applied for
>         performing the Binding Cache entry existence test.  If those
>         checks specified in Section 5.4.1 result in associating the
>         received Proxy Binding Update message to a new mobility
session
>         creation request, considerations from Section 5.3.2 (Initial
>         Binding Registration - New Mobility Session), MUST be applied.
>         If those checks result in associating the request to an
existing
>         mobility session, the following checks determine the next set
of
>         processing rules that need to be applied.
>
>
>
>
>Gundavelli, et al.          Standards Track                    [Page
21]
>
>RFC 5213                   Proxy Mobile IPv6                 August
2008
>
>
>         *  If the received Proxy Binding Update message has the
lifetime
>            value of zero, considerations from Section 5.3.5 (Binding
De-
>            Registration) MUST be applied.
>
>         *  If the Proxy-CoA in the Binding Cache entry matches the
>            source address of the request (or the address in the
>            Alternate Care-of Address option, if the option is
present),
>            considerations from Section 5.3.3 (Binding LIfetime
Extension
>            - No handoff) MUST be applied.
>
>         *  For all other cases, considerations from Section 5.3.4
>            (Binding Lifetime Extension - After handoff) MUST be
applied.

Since you included the three starred bullet, I must assume that the 
procedures of 5.4.1, which address multihoming,
returned values such that only these are valid options because if the 
procedures of 5.4.1 did not, then these three starred bullets would 
not apply.  As I said, 5.3.1 is a tip of a complicated decision 
tree.  One needs to know all of the exact details to know which 
branch you are choosing.   So my question to you is what were the 
details that permitted the procedures of 5.4.1 to return such that 
the three starred bullet items are valid options?

[Mohana] Ok, as you say the three bullets are processed only when the
binding cache existense test says that this is an existing session. So
existense test will identify a vertical handoff operation as existing
cache and after that the processing loop will branch off to these
procedures. Before writing these did take a close look at the draft. Let
me know your further views. This is how I understood. 

>David Cypher
>
>
>_______________________________________________
>NetExt mailing list
>NetExt at mail.mobileip.jp
>http://www.mobileip.jp/mailman/listinfo/netext

From: Mohana.Jeyatharan at sg.panasonic.com (Mohana Jeyatharan)
Date: Thu, 12 Mar 2009 08:24:20 +0800
Subject: [Netext] Comments on draft-jeyatharan-netext-multihoming-ps-01.txt
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Hi Telemaco,

Thanks for your comments on this draft. Please see replies in line.

BR,

Mohana

 

________________________________

From: netext-bounces at mail.mobileip.jp
[mailto:netext-bounces at mail.mobileip.jp] On Behalf Of MELIA TELEMACO
Sent: Wednesday, March 11, 2009 6:15 PM
To: netext at mail.mobileip.jp
Subject: [Netext] Comments on
draft-jeyatharan-netext-multihoming-ps-01.txt

Hello, 

Thanks for the update, here few more comments. 

Section 2.1 
=========== 
While I agree that this extension is very useful, I wonder if the
multihoming PS doc is the right place to deal with. IMO if we consider
multihoming issues as in draft-ietf-monami6-multiplecoa probably it is
not. With this I am not saying Netext should not work on the subject.

[Mohana] I think the comparison with monami6-multicoa draft is a
natural. But that draft is sepcifically for one home address(one home
network prefix). Thus monami6 draft focus is getting multiple care of
addresses associated with different interfaces bound to a home address.
However, that draft also supports multiple careof addresses bound to the
same interface. In that sense, it can be mapped to this PMIP multihoming
case where we want to assign HNPs dynamically. 

Section 2.2 
=========== 
I think you should simply state that we need to enable a mobility
session to spam across multiple interfaces. 

[Mohana] Ok, if we are going to update this draft further will
incorporate this. Thanks.

Section 3 
========= 
I would expect more discussion on the MN limitations. The optimizations
we are aiming at can work if the MN can deal with them.

[Mohana] In this section and also in the appendix section there is
description of the MN changes to achieve this. Thus this explains what a
leagcy MN should have.

But again, we can discuss the legacy MN operation and what we should add
in....We just want to keep the draft a bit simple at this stage. Lets
see we may need to update it at another stage.

Section 4 
========= 
I agree the scenario is interesting but if we enable a mobility session
to manage multiple interfaces did we solve the problem already?

[Mohana] Not very clear about your comment. But, here you can still have
multiple mobility sessions for each interface. Same mobilitysession
canbe used if the bindings for both interfaces are created at the same
time. Sometimes this wont happen and hence separate is ideal. 

What do you think? 

[Mohana] Thanks, for reading and commenting. It helps all of us.

-telemaco 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090312/f56e6cac/attachment.html>

From: david.cypher at nist.gov (David Cypher)
Date: Wed, 11 Mar 2009 09:53:42 -0400
Subject: [Netext] draft-jeyatharan-netext-multihoming-ps-01.txt
In-Reply-To: <[email-masked] l>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Mohana,

At 08:41 PM 3/10/2009, Mohana Jeyatharan wrote:
>Hi David,
>
>Thanks for your comments.
>
>Thanks Rajeev for all replies. Just want to add in some thing small.
>
>Please see.
>BR,
>Mohana
>
>-----Original Message-----
>From: netext-bounces at mail.mobileip.jp
>[mailto:netext-bounces at mail.mobileip.jp] On Behalf Of David Cypher
>Sent: Wednesday, March 11, 2009 2:35 AM
>To: netext at mail.mobileip.jp
>Subject: Re: [Netext] draft-jeyatharan-netext-multihoming-ps-01.txt
>
>Comments on version 1 of the multihoming PS
>
>2.1
>One way (stateless) or another (stateful or manual) in RFC 5213 the
>list of home Network prefixes (HNP) is fixed.
>There is no requirement that the mobile use all of its HNPs once they
>are assigned.  I do not see the problem, especially after reading the
>motivation.  The motivation described the ability of the mobile node
>to decide when it needs a prefix and when to use it.  As I see it,
>the mobile node has that now.  The mobile node receives P1, P2, and
>P3 at the start. The mobile node can use P1 and P2 whenever it wants
>and can stop using them and chose to use P3 at any time.  PMIP does
>not care and no change to the mobile node is required.
>
>Are you thinking more on the lines of selectively moving HNP(s) from
>one interface to another (or sharing selective HNP(s) across multiple
>interface)?
>[Mohana] I think Rajeev has explained in previous mails. But dynamic
>creation is 1) dynamically creating session for a given interface by
>allocating new prefixes and dynamically creating session associated with
>another interface using some prefixes from a given iterface. These are
>the cases handled under dynamic creation. Moving prefixes from one
>interface to another is also the dynamic state. Agree with you.

He might have, but these are not captured in the new PS.

>4
>The statement about "the assumption that each of the interfaces is
>attached to a different mobile access gateway." I do not agree
>with.  Reference is given as 5.3.1, but this is just the tip of a
>very complicated decision tree based on the contents of the PBU and
>the existence (and comparison of contents to the PBU) or non
>existence of a BCE at the LMA.
>The creation of the PBU is based on the BUL at the MAG detecting the
>mobile node / interface, as well as the mobile node's policy
>profile.  One of the required parameters in the PBU is the Handoff
>Indicator field, which can be set according to the following:
>
>RFC 5213, 6.9.1.1, bullet 5, second star bullet, page 50
>"
>          *  Some link layers have link-layer identifiers that can be
>used
>             to distinguish (a) the movement of a particular interface to
>             a new attachment from (b) the attachment of a new interface
>             from the same host.  Option value 3 (Handoff between mobile
>             access gateways for the same interface) is appropriate in
>             case (a) and a value of 1 (Attachment over a new interface)
>             in case (b).
>"
>Case (b) in my reading permits the mobile node to be attached to the
>same MAG with two interfaces.
>
>Therefore the assumption statement in the PS does not hold true.  Does
>it?
>Perhaps you can provide the contents of BCE at the LMA, BUL at the
>MAG, mobile node policy profile, and the PBU that supports your
>assumption and reference 5.3.1.
>Or modify the statement to be more specific about which case of
>multiple interfaces.
>[Mohana] Ok, let me quote the reference. It is in page 20 section 5.3.1.
>
>13.  Considerations specified in Section 5.4.1 MUST be applied for
>         performing the Binding Cache entry existence test.  If those
>         checks specified in Section 5.4.1 result in associating the
>         received Proxy Binding Update message to a new mobility session
>         creation request, considerations from Section 5.3.2 (Initial
>         Binding Registration - New Mobility Session), MUST be applied.
>         If those checks result in associating the request to an existing
>         mobility session, the following checks determine the next set of
>         processing rules that need to be applied.
>
>
>
>
>Gundavelli, et al.          Standards Track                    [Page 21]
>
>RFC 5213                   Proxy Mobile IPv6                 August 2008
>
>
>         *  If the received Proxy Binding Update message has the lifetime
>            value of zero, considerations from Section 5.3.5 (Binding De-
>            Registration) MUST be applied.
>
>         *  If the Proxy-CoA in the Binding Cache entry matches the
>            source address of the request (or the address in the
>            Alternate Care-of Address option, if the option is present),
>            considerations from Section 5.3.3 (Binding LIfetime Extension
>            - No handoff) MUST be applied.
>
>         *  For all other cases, considerations from Section 5.3.4
>            (Binding Lifetime Extension - After handoff) MUST be applied.

Since you included the three starred bullet, I must assume that the 
procedures of 5.4.1, which address multihoming,
returned values such that only these are valid options because if the 
procedures of 5.4.1 did not, then these three starred bullets would 
not apply.  As I said, 5.3.1 is a tip of a complicated decision 
tree.  One needs to know all of the exact details to know which 
branch you are choosing.   So my question to you is what were the 
details that permitted the procedures of 5.4.1 to return such that 
the three starred bullet items are valid options?

>David Cypher
>
>
>_______________________________________________
>NetExt mailing list
>NetExt at mail.mobileip.jp
>http://www.mobileip.jp/mailman/listinfo/netext

From: Telemaco.Melia at alcatel-lucent.com (MELIA TELEMACO)
Date: Wed, 11 Mar 2009 11:14:45 +0100
Subject: [Netext] Comments on draft-jeyatharan-netext-multihoming-ps-01.txt
Message-ID: <[email-masked]>

Hello,

Thanks for the update, here few more comments.

Section 2.1
===========
While I agree that this extension is very useful, I wonder if the
multihoming PS doc is the right place to deal with. IMO if we consider
multihoming issues as in draft-ietf-monami6-multiplecoa probably it is
not. With this I am not saying Netext should not work on the subject.

Section 2.2
===========
I think you should simply state that we need to enable a mobility
session to spam across multiple interfaces.

Section 3
=========
I would expect more discussion on the MN limitations. The optimizations
we are aiming at can work if the MN can deal with them.

Section 4
=========
I agree the scenario is interesting but if we enable a mobility session
to manage multiple interfaces did we solve the problem already?

What do you think?

-telemaco

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090311/fa609cca/attachment.html>

From: Mohana.Jeyatharan at sg.panasonic.com (Mohana Jeyatharan)
Date: Wed, 11 Mar 2009 08:41:17 +0800
Subject: [Netext] draft-jeyatharan-netext-multihoming-ps-01.txt
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Hi David,

Thanks for your comments.

Thanks Rajeev for all replies. Just want to add in some thing small.

Please see.
BR,
Mohana

-----Original Message-----
From: netext-bounces at mail.mobileip.jp
[mailto:netext-bounces at mail.mobileip.jp] On Behalf Of David Cypher
Sent: Wednesday, March 11, 2009 2:35 AM
To: netext at mail.mobileip.jp
Subject: Re: [Netext] draft-jeyatharan-netext-multihoming-ps-01.txt

Comments on version 1 of the multihoming PS

2.1
One way (stateless) or another (stateful or manual) in RFC 5213 the 
list of home Network prefixes (HNP) is fixed.
There is no requirement that the mobile use all of its HNPs once they 
are assigned.  I do not see the problem, especially after reading the 
motivation.  The motivation described the ability of the mobile node 
to decide when it needs a prefix and when to use it.  As I see it, 
the mobile node has that now.  The mobile node receives P1, P2, and 
P3 at the start. The mobile node can use P1 and P2 whenever it wants 
and can stop using them and chose to use P3 at any time.  PMIP does 
not care and no change to the mobile node is required.

Are you thinking more on the lines of selectively moving HNP(s) from 
one interface to another (or sharing selective HNP(s) across multiple 
interface)?
[Mohana] I think Rajeev has explained in previous mails. But dynamic
creation is 1) dynamically creating session for a given interface by
allocating new prefixes and dynamically creating session associated with
another interface using some prefixes from a given iterface. These are
the cases handled under dynamic creation. Moving prefixes from one
interface to another is also the dynamic state. Agree with you. 

4
The statement about "the assumption that each of the interfaces is 
attached to a different mobile access gateway." I do not agree 
with.  Reference is given as 5.3.1, but this is just the tip of a 
very complicated decision tree based on the contents of the PBU and 
the existence (and comparison of contents to the PBU) or non 
existence of a BCE at the LMA.
The creation of the PBU is based on the BUL at the MAG detecting the 
mobile node / interface, as well as the mobile node's policy 
profile.  One of the required parameters in the PBU is the Handoff 
Indicator field, which can be set according to the following:

RFC 5213, 6.9.1.1, bullet 5, second star bullet, page 50
"
         *  Some link layers have link-layer identifiers that can be
used
            to distinguish (a) the movement of a particular interface to
            a new attachment from (b) the attachment of a new interface
            from the same host.  Option value 3 (Handoff between mobile
            access gateways for the same interface) is appropriate in
            case (a) and a value of 1 (Attachment over a new interface)
            in case (b).
"
Case (b) in my reading permits the mobile node to be attached to the 
same MAG with two interfaces.

Therefore the assumption statement in the PS does not hold true.  Does
it?
Perhaps you can provide the contents of BCE at the LMA, BUL at the 
MAG, mobile node policy profile, and the PBU that supports your 
assumption and reference 5.3.1.
Or modify the statement to be more specific about which case of 
multiple interfaces.
[Mohana] Ok, let me quote the reference. It is in page 20 section 5.3.1.

13.  Considerations specified in Section 5.4.1 MUST be applied for
        performing the Binding Cache entry existence test.  If those
        checks specified in Section 5.4.1 result in associating the
        received Proxy Binding Update message to a new mobility session
        creation request, considerations from Section 5.3.2 (Initial
        Binding Registration - New Mobility Session), MUST be applied.
        If those checks result in associating the request to an existing
        mobility session, the following checks determine the next set of
        processing rules that need to be applied.

Gundavelli, et al.          Standards Track                    [Page 21]
 
RFC 5213                   Proxy Mobile IPv6                 August 2008

        *  If the received Proxy Binding Update message has the lifetime
           value of zero, considerations from Section 5.3.5 (Binding De-
           Registration) MUST be applied.

        *  If the Proxy-CoA in the Binding Cache entry matches the
           source address of the request (or the address in the
           Alternate Care-of Address option, if the option is present),
           considerations from Section 5.3.3 (Binding LIfetime Extension
           - No handoff) MUST be applied.

        *  For all other cases, considerations from Section 5.3.4
           (Binding Lifetime Extension - After handoff) MUST be applied.

David Cypher

_______________________________________________
NetExt mailing list
NetExt at mail.mobileip.jp
http://www.mobileip.jp/mailman/listinfo/netext

From: rkoodli at starentnetworks.com (Koodli, Rajeev)
Date: Tue, 10 Mar 2009 19:34:34 -0400
Subject: [Netext] draft-jeyatharan-netext-multihoming-ps-01.txt
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Hi David,

> >Why should prefix exchange be limited to to the start? Why can't you 
> >exchange prefixes like in IPv6 ND?
> 
> Doesn't IPv6 ND indicate that there is something new (i.e., a 
> change in the network)?

It's just an RA with a new prefix, either sent unsolicited or as a
response to RS.

> What is changing in PMIP?  PMIP is a total solution unto 
> itself.  Is it not?

Matter of perspective, I guess :-)

> If PMIP intends to provide an unchanging view as a mobile 
> node moves, why would this be dynamic?

My point is that a MN could initiate a new session, i.e., we need to be
able to dynamically assign HNPs, not just at the "start". There are
deployments in the emerging 4G systems that would need this.

> It seems that the original premise and purpose of PMIP is no 
> longer enough and needs to be dramatically changed.  If so, 
> that is what I think we all need to understand.  That is what 
> precisely are the new services?
> 

Please remember that this BOF is about Improvements, Deployment
Considerations and Deficiencies. 
We are not always bound by the limitations of design. Also see my note
above on how one could apply the enhancements to emerging systems.

> >
> >This is for link layers that have link-layer identifiers. What about 
> >others (such as 3G/4G)?
> 
> Yes, I agree. But this does not support the statement about 
> the assumption that each interface is attached to a different 
> MAG.  The text cited from RFC5213 shows that this is a false 
> statement as it stands.  As I previously suggested remove 
> this statement or further qualify it to specifically state 
> the case you want.

Revisions are okay, but you could have simultaneous attachment to
different interfaces connected to different MAGs. 

-Rajeev

> 
> 
> >Regards,
> >
> >-Rajeev
> >
> >
> > > Therefore the assumption statement in the PS does not hold true.  
> > > Does it?
> > > Perhaps you can provide the contents of BCE at the LMA, 
> BUL at the 
> > > MAG, mobile node policy profile, and the PBU that supports your 
> > > assumption and reference 5.3.1.
> > > Or modify the statement to be more specific about which case of 
> > > multiple interfaces.
> > >
> > > David Cypher
> 
> Me again
> 
> > >
> > >
> > > _______________________________________________
> > > NetExt mailing list
> > > NetExt at mail.mobileip.jp
> > > http://www.mobileip.jp/mailman/listinfo/netext
> > >
> >
> >_______________________________________________
> >NetExt mailing list
> >NetExt at mail.mobileip.jp
> >http://www.mobileip.jp/mailman/listinfo/netext
> 
> 
> 

From: david.cypher at nist.gov (David Cypher)
Date: Tue, 10 Mar 2009 18:18:12 -0400
Subject: [Netext] draft-jeyatharan-netext-multihoming-ps-01.txt
In-Reply-To: <[email-masked] tnetworks.com>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Rajeev,

Thanks for your thoughts.

At 04:18 PM 3/10/2009, Koodli, Rajeev wrote:
>
>Hi David,
>
>Some thoughts below..
>
>
> > 2.1
> > One way (stateless) or another (stateful or manual) in RFC
> > 5213 the list of home Network prefixes (HNP) is fixed.
> > There is no requirement that the mobile use all of its HNPs
> > once they are assigned.  I do not see the problem, especially
> > after reading the motivation.  The motivation described the
> > ability of the mobile node to decide when it needs a prefix
> > and when to use it.  As I see it, the mobile node has that
> > now.  The mobile node receives P1, P2, and
> > P3 at the start.
>             ^^^^^
>Why should prefix exchange be limited to to the start? Why can't you
>exchange prefixes like in IPv6 ND?

Doesn't IPv6 ND indicate that there is something new (i.e., a change 
in the network)?
What is changing in PMIP?  PMIP is a total solution unto itself.  Is it not?
If PMIP intends to provide an unchanging view as a mobile node moves, 
why would this be dynamic?
It seems that the original premise and purpose of PMIP is no longer 
enough and needs to be dramatically
changed.  If so, that is what I think we all need to 
understand.  That is what precisely are the new services?

> > The mobile node can use P1 and P2 whenever
> > it wants and can stop using them and chose to use P3 at any
> > time.  PMIP does not care and no change to the mobile node is
> > required.
> >
> > Are you thinking more on the lines of selectively moving
> > HNP(s) from one interface to another (or sharing selective
> > HNP(s) across multiple interface)?
> >
>
>This is something that should be supported IMO.

So be it, but is not this more clearer than the example and description given?

> > 4
> > The statement about "the assumption that each of the interfaces is
> > attached to a different mobile access gateway." I do not agree
> > with.  Reference is given as 5.3.1, but this is just the tip of a
> > very complicated decision tree based on the contents of the PBU and
> > the existence (and comparison of contents to the PBU) or non
> > existence of a BCE at the LMA.
> > The creation of the PBU is based on the BUL at the MAG detecting the
> > mobile node / interface, as well as the mobile node's policy
> > profile.  One of the required parameters in the PBU is the Handoff
> > Indicator field, which can be set according to the following:
> >
> > RFC 5213, 6.9.1.1, bullet 5, second star bullet, page 50
> > "
> >          *  Some link layers have link-layer identifiers that
> > can be used to distinguish (a) the movement of a particular
> > interface to a new attachment from (b) the attachment of a new
> > interface from the same host.  Option value 3 (Handoff between mobile
> > access gateways for the same interface) is appropriate in case (a) and
>
> > a value of 1 (Attachment over a new interface) in case (b).
> > "
> > Case (b) in my reading permits the mobile node to be attached to the
> > same MAG with two interfaces.
> >
>
>This is for link layers that have link-layer identifiers. What about
>others
>(such as 3G/4G)?

Yes, I agree. But this does not support the statement about the 
assumption that each interface is attached to a different MAG.  The 
text cited from RFC5213 shows that this is a false statement as it 
stands.  As I previously suggested remove this statement or further 
qualify it to specifically state the case you want.

>Regards,
>
>-Rajeev
>
>
> > Therefore the assumption statement in the PS does not hold
> > true.  Does it?
> > Perhaps you can provide the contents of BCE at the LMA, BUL at the
> > MAG, mobile node policy profile, and the PBU that supports your
> > assumption and reference 5.3.1.
> > Or modify the statement to be more specific about which case of
> > multiple interfaces.
> >
> > David Cypher

Me again

> >
> >
> > _______________________________________________
> > NetExt mailing list
> > NetExt at mail.mobileip.jp
> > http://www.mobileip.jp/mailman/listinfo/netext
> >
>
>_______________________________________________
>NetExt mailing list
>NetExt at mail.mobileip.jp
>http://www.mobileip.jp/mailman/listinfo/netext

From: rkoodli at starentnetworks.com (Koodli, Rajeev)
Date: Tue, 10 Mar 2009 16:18:47 -0400
Subject: [Netext] draft-jeyatharan-netext-multihoming-ps-01.txt
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Hi David,

Some thoughts below..

> 2.1
> One way (stateless) or another (stateful or manual) in RFC 
> 5213 the list of home Network prefixes (HNP) is fixed.
> There is no requirement that the mobile use all of its HNPs 
> once they are assigned.  I do not see the problem, especially 
> after reading the motivation.  The motivation described the 
> ability of the mobile node to decide when it needs a prefix 
> and when to use it.  As I see it, the mobile node has that 
> now.  The mobile node receives P1, P2, and
> P3 at the start. 
            ^^^^^
Why should prefix exchange be limited to to the start? Why can't you
exchange prefixes like in IPv6 ND?

> The mobile node can use P1 and P2 whenever 
> it wants and can stop using them and chose to use P3 at any 
> time.  PMIP does not care and no change to the mobile node is 
> required.
> 
> Are you thinking more on the lines of selectively moving 
> HNP(s) from one interface to another (or sharing selective 
> HNP(s) across multiple interface)?
> 

This is something that should be supported IMO.

> 4
> The statement about "the assumption that each of the interfaces is 
> attached to a different mobile access gateway." I do not agree 
> with.  Reference is given as 5.3.1, but this is just the tip of a 
> very complicated decision tree based on the contents of the PBU and 
> the existence (and comparison of contents to the PBU) or non 
> existence of a BCE at the LMA.
> The creation of the PBU is based on the BUL at the MAG detecting the 
> mobile node / interface, as well as the mobile node's policy 
> profile.  One of the required parameters in the PBU is the Handoff 
> Indicator field, which can be set according to the following:
> 
> RFC 5213, 6.9.1.1, bullet 5, second star bullet, page 50
> "
>          *  Some link layers have link-layer identifiers that 
> can be used to distinguish (a) the movement of a particular 
> interface to a new attachment from (b) the attachment of a new 
> interface from the same host.  Option value 3 (Handoff between mobile 
> access gateways for the same interface) is appropriate in case (a) and

> a value of 1 (Attachment over a new interface) in case (b).
> "
> Case (b) in my reading permits the mobile node to be attached to the 
> same MAG with two interfaces.
> 

This is for link layers that have link-layer identifiers. What about
others
(such as 3G/4G)?

Regards,

-Rajeev

> Therefore the assumption statement in the PS does not hold 
> true.  Does it?
> Perhaps you can provide the contents of BCE at the LMA, BUL at the 
> MAG, mobile node policy profile, and the PBU that supports your 
> assumption and reference 5.3.1.
> Or modify the statement to be more specific about which case of 
> multiple interfaces.
> 
> David Cypher
> 
> 
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
> 

From: david.cypher at nist.gov (David Cypher)
Date: Tue, 10 Mar 2009 14:34:42 -0400
Subject: [Netext] draft-jeyatharan-netext-multihoming-ps-01.txt
Message-ID: <[email-masked]>

Comments on version 1 of the multihoming PS

2.1
One way (stateless) or another (stateful or manual) in RFC 5213 the 
list of home Network prefixes (HNP) is fixed.
There is no requirement that the mobile use all of its HNPs once they 
are assigned.  I do not see the problem, especially after reading the 
motivation.  The motivation described the ability of the mobile node 
to decide when it needs a prefix and when to use it.  As I see it, 
the mobile node has that now.  The mobile node receives P1, P2, and 
P3 at the start. The mobile node can use P1 and P2 whenever it wants 
and can stop using them and chose to use P3 at any time.  PMIP does 
not care and no change to the mobile node is required.

Are you thinking more on the lines of selectively moving HNP(s) from 
one interface to another (or sharing selective HNP(s) across multiple 
interface)?

4
The statement about "the assumption that each of the interfaces is 
attached to a different mobile access gateway." I do not agree 
with.  Reference is given as 5.3.1, but this is just the tip of a 
very complicated decision tree based on the contents of the PBU and 
the existence (and comparison of contents to the PBU) or non 
existence of a BCE at the LMA.
The creation of the PBU is based on the BUL at the MAG detecting the 
mobile node / interface, as well as the mobile node's policy 
profile.  One of the required parameters in the PBU is the Handoff 
Indicator field, which can be set according to the following:

RFC 5213, 6.9.1.1, bullet 5, second star bullet, page 50
"
         *  Some link layers have link-layer identifiers that can be used
            to distinguish (a) the movement of a particular interface to
            a new attachment from (b) the attachment of a new interface
            from the same host.  Option value 3 (Handoff between mobile
            access gateways for the same interface) is appropriate in
            case (a) and a value of 1 (Attachment over a new interface)
            in case (b).
"
Case (b) in my reading permits the mobile node to be attached to the 
same MAG with two interfaces.

Therefore the assumption statement in the PS does not hold true.  Does it?
Perhaps you can provide the contents of BCE at the LMA, BUL at the 
MAG, mobile node policy profile, and the PBU that supports your 
assumption and reference 5.3.1.
Or modify the statement to be more specific about which case of 
multiple interfaces.

David Cypher

From: Mohana.Jeyatharan at sg.panasonic.com (Mohana Jeyatharan)
Date: Tue, 10 Mar 2009 08:48:55 +0800
Subject: [Netext] FW: I-D Action:draft-jeyatharan-netext-multihoming-ps-01.txt
Message-ID: <[email-masked]>

Hi All,

We have revised the Multihoming PS draft based on all comments and
suggestions received. Thanks everyone. It is version 1 now. 

Pls. have a look.

BR,
Mohana
-----Original Message-----
From: i-d-announce-bounces at ietf.org
[mailto:i-d-announce-bounces at ietf.org] On Behalf Of
Internet-Drafts at ietf.org
Sent: Monday, March 09, 2009 4:45 PM
To: i-d-announce at ietf.org
Subject: I-D Action:draft-jeyatharan-netext-multihoming-ps-01.txt 

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title           : Multihoming Problem Statement in NetLMM
	Author(s)       : M. Jeyatharan, C. Ng
	Filename        : draft-jeyatharan-netext-multihoming-ps-01.txt
	Pages           : 16
	Date            : 2009-03-09

The Proxy Mobile Internet Protocol version 6 (PMIPv6) supports
multihoming whereby a mobile node (1) gets assigned prefixes by the
local mobility anchor which are associated with an interface of a
mobile node and are managed by the PMIPv6 elements as a single IP
mobility session, and (2) can connect to a Proxy Mobile IPv6 domain
through multiple interfaces for simultaneous access and get assigned
a different set of prefix(es) per interface, since being each
interface managed via an independent mobility session.  However,
PMIPv6 needs multihoming enhancements such that it needs the ability
to instantiate additional IP mobility sessions associated with an
already active interface or a secondary interface of the mobile node
which has an established IP mobility session at a local mobility
anchor (LMA), the ability to selectively share home network
prefix(es) across access technology types and extended support for
multiple IP mobility sessions in a scenario where multiple interfaces
of the mobile node are connected to a single mobile access gateway
(MAG).  This memo highlights such required enhancements to PMIPv6
multihoming with respect to improved operations and extended
applicability to different deployment scenarios.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-jeyatharan-netext-multihoming-
ps-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: draft-jeyatharan-netext-multihoming-ps-01.URL
Type: application/octet-stream
Size: 106 bytes
Desc: draft-jeyatharan-netext-multihoming-ps-01.URL
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090310/f14fea78/attachment.obj>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ATT5410851.txt
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090310/f14fea78/attachment.txt>

From: cjbc at it.uc3m.es (Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano)
Date: Mon, 09 Mar 2009 21:17:36 +0100
Subject: [Netext] Inter-technology handovers PS considering Multihoming	PS and Localized Routing PS
In-Reply-To: <[email-masked]>
References: <[email-masked]> <1235994124.5456.37.camel@localhost> <[email-masked]> <1236067992.4950.7.camel@localhost> <[email-masked]>
Message-ID: <1236629856.4581.219.camel@localhost>

Hi David,

El lun, 09-03-2009 a las 11:09 -0400, David Cypher escribi?:
> Carlos,
> 
> At 04:13 AM 3/3/2009, Carlos Jes?s Bernardos Cano wrote:
> >Hi David,
> >
> >         Thanks for your answers. Some comments inline below.
> >
> >El lun, 02-03-2009 a las 12:43 -0500, David Cypher escribi?:
> > > Carlos,
> > >
> > >     Thanks for your comments and questions.  I
> > > hope that my answers are acceptable.
> > >
> > > At 06:42 AM 3/2/2009, Carlos Jes?s Bernardos Cano wrote:
> > > >Hi David,
> > > >
> > > >         Two quick questions/comments:
> > > >
> > > >         - do you think multihoming only deals with configuring the same
> > > >address on different interfaces of the MN? I don't this has to be
> > > >necessarily the case.
> > >
> > > I do not believe that multihoming in the general
> > > sense only deals with same address on different interfaces.
> > > However here is what I based it on directly from RFC 5213.
> > >
> > > For PMIP the definition of mulihoming support is given in 5.4
> > > 5.4.  Multihoming Support
> > >
> > > "   This specification allows mobile nodes to connect to a Proxy Mobile
> > >     IPv6 domain through multiple interfaces for simultaneous access.  The
> > >     following are the key aspects of this multihoming support.
> > >
> > >     o  When a mobile node connects to a Proxy Mobile IPv6 domain through
> > >        multiple interfaces for simultaneous access, the local mobility
> > >        anchor MUST allocate a mobility session for each of the attached
> > >        interfaces.  Each mobility session should be managed under a
> > >        separate Binding Cache entry and with its own lifetime.
> > >
> > >     o  The local mobility anchor MAY allocate more than one home network
> > >        prefix for a given interface of the mobile node.  However, all the
> > >        prefixes associated with a given interface MUST be managed as part
> > >        of one mobility session, associated with that interface.
> > >
> > >     o  The local mobility anchor MUST allow for a handoff between two
> > >        different interfaces of a mobile node.  In such a scenario, all
> > >        the home network prefixes associated with one interface (part of
> > >        one mobility session) will be associated with a different
> > >        interface of the mobile node.  The decision on when to create a
> > >        new mobility session and when to update an existing mobility
> > >        session MUST be based on the Handover hint present in the Proxy
> > >        Binding Update message and under the considerations specified in
> > >        this section. "
> > >
> > > The first bullet implies multiple interfaces with different prefixes.
> > > The last bullet implies same prefix on different interfaces.
> > >
> > > So out of these three bullet items, which 
> > cannot be handled "today" by PMIP?
> > > If they are all handled, then instead of fixing
> > > an existing problem, the NETEXT multihoming PS is asking for new services.
> >
> >Well, I think PMIPv6 is missing the functionality of controlling
> >multiple interfaces with a single mobility session, for example.
> 
> I read your response as a new service is being requested.
> You want PMIPv6 to also support multiple 
> interfaces as a single mobility session, which is 
> not one of the three bullet items.
> 
> My problems with these are that once PMIPv6 
> provides multiple services for which the mobile node can use;
> How does the mobile node make its choice, and
> How does the PMIP make the choice for the mobile node?

I think this is something NETEXT should address.

> 
> It is nice to have PMIP have multiple functions, 
> but it gets harder to "proxy" for the mobile node 
> when there is no communications to provide the 
> "proxy" function from the mobile node.
> 
> If there is but one PMIP service, it is easier to 
> see how the network can "proxy" for the mobile node.
> 
> > >
> > > Another document that I have read on multihoming
> > > is draft-ieft-monami6-mipv6-analysis-05 (now expired)
> > >
> > >
> > > >         - in local routing, not sure if the optimization would have to
> > > >consider which is the best interface of the MN to achieve the shortest
> > > >path. This would require involving the MN, and I'd prefer involving only
> > > >the network there.
> > > So if I understand your point, the Network would
> > > make the entire determination of which
> > > interface(s) to provide route optimization
> > > for.  In what manner would this be done?  For
> > > every route?  For selective routes?  If so, what
> > > would be the criteria?  If the goal is to not
> > > involve the mobile node as the original PMIP
> > > design, then as a network under what network ONLY
> > > criteria would be used to justify route optimization?
> > > It seems to me that the criteria is the
> > > application that the mobile node is using, but
> > > since we do not involve the mobile node how can
> > > the network know that something should be route optimized?
> >
> >My point is that the "end-points" of route optimisation should be MAGs
> >and LMAs, that is, without even considering which are the interfaces
> >used by the MNs. This would be a simpler scenario that would avoid the
> >involvement of the MN. Future work might include the MN and the
> >considerations about the interfaces. I think for now netext is only
> >aiming at working on local routing, not on route optimisation as we
> >understand it in MIPv6.
> 
> I do not understand your point.  Why would the 
> tunnel between a MAG and its LMA not be optimized already?
> In other words how would another route from MAG to LMA be shorter?
> My understanding was trying to short cut the MAG 
> to LMA and LMA to CN by going MAG to CN and 
> bypass the LMA (is this what you are calling 
> route optimization in MIPv6?).  After reading a 
> recent draft, it is not even this, but short 
> cutting MAG (MN) to MAG (CN) with perhaps 
> information from the LMA (is this local 
> routing?  Common LMA for both MN and CN).

Yes, this is what I understand as local routing and I think it's the
only thing within current charter of NETEXT. The MAG to CN optimization
is seen as RO and not in current charter, I think.

Kind Regards,

Carlos

> 
> Thanks
> David Cypher
> 
> >Thanks,
> >
> >Carlos
> >
> > >
> > > David Cypher
> > >
> > > >         Kind Regards,
> > > >
> > > >         Carlos
> > > >
> > > >El jue, 26-02-2009 a las 11:20 -0500, David Cypher escribi?:
> > > > > Taking a look at the other two problem statements in terms of
> > > > > existing services and new services,
> > > > > I do not think that any of the three problem statements can really be
> > > > > addressed in isolation.
> > > > >
> > > > > Multihoming Problem Statement
> > > > > Mobile node should be able to have more 
> > than one interface to the network
> > > > > - same access technology interfaces
> > > > >       i) same IPv6 address    (not supported in RFC 5213)
> > > > >       ii) different IPv6 address (supported)
> > > > > - different access technology interfaces
> > > > >       i) same IPv6 address    (supported but
> > > > only for handover (temporarily))
> > > > >       ii) different IPv6 address      (supported)
> > > > >
> > > > > NEW SERVICE being requested
> > > > > - A) the ability to have the same IPv6 address on more than one
> > > > > interface (whether the access technology is the same or different)
> > > > > for a long period of time (i.e., not part of a handover/handoff).
> > > > >
> > > > >
> > > > > Route optimization (RO) Problem statement
> > > > > NEW SERVICES being requested
> > > > > - A ) the ability to discover if a route between MN(MAG) and CN is
> > > > > better than the existing route between MN (LMA) and CN and
> > > > > - B) the ability to use the route if found.
> > > > >
> > > > > What interface will be used to find this optimized route if multiple
> > > > > accesses exist and multihoming is truly provided?
> > > > > All of them?  One of them?  Which one?  Will there be a primary
> > > > > access interface or MN-HNP needed?
> > > > >
> > > > >
> > > > > SUMMARY of the three problem statements
> > > > > ======================================
> > > > > Inter-technology and multihoming problem statements appear to be
> > > > > interrelated.  Inter-technology (2.2) claims that there are problems
> > > > > with mobile nodes' operating systems that do not permit multihoming
> > > > > (same address on multiple interfaces), which is what the Multihoming
> > > > > Problem statement is wanting.
> > > > >
> > > > > Inter-technology PS 3.2 needs to be able to distinguish between
> > > > > handover and multiple interfaces.  This is another issue related to
> > > > > Multihoming (multiple interfaces)
> > > > >
> > > > > Cannot look at inter-technology and multihoming as separate problem
> > > > > statements.  Instead perhaps the problem statements should be written
> > > > > from a NEW SERVICE being requested.
> > > > >
> > > > > Cannot look at route optimization and multihoming as separate
> > > > > problems since the route optimized is dependent upon the attachment
> > > > > point and the address used for that attachment.
> > > > >
> > > > > For example from the original PMIP the services were
> > > > > - to supply the mobile node with a single set of MN-HNPs as it moved
> > > > > throughout the PMIP domain while maintaining only one active
> > > > > interface at a time or temporarily two during a handover.  (a single
> > > > > set of MN-HNPs for all of the mobile node's interfaces provided only
> > > > > one interface active at a time and used for handover only between two
> > > > > interfaces)
> > > > > - to supply the mobile node with a single set of MN-HNPs per
> > > > > interface, if more than one interface was attached to the PMIP
> > > > > domain. (a different set of MN-HNPs for each interface)
> > > > >
> > > > >
> > > > > SUMMARY of new services:
> > > > > =============================================
> > > > > The NEW SERVICES being requested by the three PSs are:
> > > > > - multiple interfaces active at the same time and not part of handover
> > > > >       i) using the same MN-HNPs
> > > > >       ii) using different MN-HNPs
> > > > > - a method for determining which service(s) the mobile node wants
> > > > > - a method for determining the mobile node's intended usage of the
> > > > > multiple connections
> > > > > - a method for determining the mobile node's capabilities to support
> > > > > PMIP services.
> > > > > - the ability to discover if a route between MN(MAG) (on which
> > > > > interface) and CN is better than the existing route between MN (LMA)
> > > > > (on which interface) and CN and
> > > > > - the ability to use the route if found.
> > > > >
> > > > > David Cypher
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > NetExt mailing list
> > > > > NetExt at mail.mobileip.jp
> > > > > http://www.mobileip.jp/mailman/listinfo/netext
> > > >--
> > > >  Carlos Jes?s Bernardos Cano     http://www.netcoms.net
> > > >  GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
> > > >++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > > >   WEEDEV 2009: 2nd Workshop on Experimental Evaluation and
> > > >         Deployment Experiences on Vehicular networks
> > > >                   http://www.weedev.org/
> > > >++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > >
> > >
> >--
> >  Carlos Jes?s Bernardos Cano     http://www.netcoms.net
> >  GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
> >++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >   WEEDEV 2009: 2nd Workshop on Experimental Evaluation and
> >         Deployment Experiences on Vehicular networks
> >                   http://www.weedev.org/
> >++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 
> 
-- 
 Carlos Jes?s Bernardos Cano     http://www.netcoms.net
 GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  WEEDEV 2009: 2nd Workshop on Experimental Evaluation and
        Deployment Experiences on Vehicular networks
                  http://www.weedev.org/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Esta parte del mensaje est? firmada	digitalmente
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090309/cf8ecede/attachment-0001.bin>

From: jouni.nospam at gmail.com (jouni korhonen)
Date: Mon, 9 Mar 2009 19:37:36 +0200
Subject: [Netext] New I-D Action:draft-korhonen-netext-redirect-01.txt
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi all,

This is a revision of the PMIPv6 redirect functionality & mobility  
option solution draft. The draft has now some more background data.

Cheers,
	Jouni

Begin forwarded message:

> From: Internet-Drafts at ietf.org
> Date: March 9, 2009 6:45:01 PM GMT+02:00
> To: i-d-announce at ietf.org
> Subject: I-D Action:draft-korhonen-netext-redirect-01.txt
> Reply-To: internet-drafts at ietf.org
>
> A New Internet-Draft is available from the on-line Internet-Drafts  
> directories.
>
> 	Title           : Redirect Option for Proxy Mobile IPv6
> 	Author(s)       : J. Korhonen
> 	Filename        : draft-korhonen-netext-redirect-01.txt
> 	Pages           : 9
> 	Date            : 2009-03-09
>
> This document describes a Redirect mobility option and redirect
> functionality for Proxy Mobile IPv6.  The redirection takes place
> during a Proxy Binding Update and Acknowledgement messages exchange.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-korhonen-netext-redirect-01.txt

From: domagoj.premec.ext at nsn.com (Domagoj Premec)
Date: Mon, 9 Mar 2009 16:53:18 +0100
Subject: [Netext] FW: I-D Action:draft-premec-netlmm-bulk-re-registration-02.txt
Message-ID: <[email-masked]>

Hello,

This is the revised version of the bulk registrations in the PMIPv6 domain.

domagoj

-----Original Message-----
From: i-d-announce-bounces at ietf.org [mailto:i-d-announce-bounces at ietf.org]
On Behalf Of ext Internet-Drafts at ietf.org
Sent: 09. ozujak 2009 15:00
To: i-d-announce at ietf.org
Subject: I-D Action:draft-premec-netlmm-bulk-re-registration-02.txt 

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title           : Bulk Re-registration for Proxy Mobile IPv6
	Author(s)       : D. Premec, et al.
	Filename        : draft-premec-netlmm-bulk-re-registration-02.txt
	Pages           : 13
	Date            : 2009-03-09

The Proxy Mobile IPv6 specification requires the Mobile Access Gateway (MAG)
to send a separate Proxy Binding Update (PBU) message to the Local Mobility
Agent (LMA) for each mobile node (MN) to renew the MN's mobility binding.
This document defines a mechanism by which a MAG can update the mobility
bindings of multiple MNs attached to it with a single PBU message to the
serving LMA. This mechanism is also intended to be used by a MAG to
re-establish bindings at a new LMA when its old LMA fails. 

Conventions used in this document 

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-premec-netlmm-bulk-re-registration
-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

From: domagoj.premec.ext at nsn.com (Domagoj Premec)
Date: Mon, 9 Mar 2009 16:50:10 +0100
Subject: [Netext] FW: I-D Action:draft-premec-netlmm-intertech-handover-01.txt
Message-ID: <[email-masked]>

Hello,

The draft discusses the inter-access handovers in the PMIPv6 domain, the
need for the MN involvement and various aspects of such handover on the MN
side. 

domagoj

-----Original Message-----
From: i-d-announce-bounces at ietf.org [mailto:i-d-announce-bounces at ietf.org]
On Behalf Of ext Internet-Drafts at ietf.org
Sent: 09. ozujak 2009 14:00
To: i-d-announce at ietf.org
Subject: I-D Action:draft-premec-netlmm-intertech-handover-01.txt 

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title           : Inter-technology handover in PMIPv6 domain
	Author(s)       : D. Premec, T. Savolainen
	Filename        : draft-premec-netlmm-intertech-handover-01.txt
	Pages           : 18
	Date            : 2009-03-09

Proxy Mobile IPv6 [RFC5213] is a network based mobility management protocol
which provides IP mobility service to a host in a way which is transparent
to the host itself. This document analyses the scenario in which the mobile
node equipped with multiple network interfaces roams in a Proxy Mobile IPv6
domain consisting of multiple access networks. If the mobile node wants to
preserve IP session continuity across different network interfaces as it
moves from one access network to another it needs to be enhanced with a new,
PMIPv6- specific functionality. 

Conventions used in this document 

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-premec-netlmm-intertech-handover-0
1.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

From: david.cypher at nist.gov (David Cypher)
Date: Mon, 09 Mar 2009 11:09:27 -0400
Subject: [Netext] Inter-technology handovers PS considering Multihoming PS and Localized Routing PS
In-Reply-To: <1236067992.4950.7.camel@localhost>
References: <[email-masked]> <1235994124.5456.37.camel@localhost> <[email-masked]> <1236067992.4950.7.camel@localhost>
Message-ID: <[email-masked]>

Carlos,

At 04:13 AM 3/3/2009, Carlos Jes?s Bernardos Cano wrote:
>Hi David,
>
>         Thanks for your answers. Some comments inline below.
>
>El lun, 02-03-2009 a las 12:43 -0500, David Cypher escribi?:
> > Carlos,
> >
> >     Thanks for your comments and questions.  I
> > hope that my answers are acceptable.
> >
> > At 06:42 AM 3/2/2009, Carlos Jes?s Bernardos Cano wrote:
> > >Hi David,
> > >
> > >         Two quick questions/comments:
> > >
> > >         - do you think multihoming only deals with configuring the same
> > >address on different interfaces of the MN? I don't this has to be
> > >necessarily the case.
> >
> > I do not believe that multihoming in the general
> > sense only deals with same address on different interfaces.
> > However here is what I based it on directly from RFC 5213.
> >
> > For PMIP the definition of mulihoming support is given in 5.4
> > 5.4.  Multihoming Support
> >
> > "   This specification allows mobile nodes to connect to a Proxy Mobile
> >     IPv6 domain through multiple interfaces for simultaneous access.  The
> >     following are the key aspects of this multihoming support.
> >
> >     o  When a mobile node connects to a Proxy Mobile IPv6 domain through
> >        multiple interfaces for simultaneous access, the local mobility
> >        anchor MUST allocate a mobility session for each of the attached
> >        interfaces.  Each mobility session should be managed under a
> >        separate Binding Cache entry and with its own lifetime.
> >
> >     o  The local mobility anchor MAY allocate more than one home network
> >        prefix for a given interface of the mobile node.  However, all the
> >        prefixes associated with a given interface MUST be managed as part
> >        of one mobility session, associated with that interface.
> >
> >     o  The local mobility anchor MUST allow for a handoff between two
> >        different interfaces of a mobile node.  In such a scenario, all
> >        the home network prefixes associated with one interface (part of
> >        one mobility session) will be associated with a different
> >        interface of the mobile node.  The decision on when to create a
> >        new mobility session and when to update an existing mobility
> >        session MUST be based on the Handover hint present in the Proxy
> >        Binding Update message and under the considerations specified in
> >        this section. "
> >
> > The first bullet implies multiple interfaces with different prefixes.
> > The last bullet implies same prefix on different interfaces.
> >
> > So out of these three bullet items, which 
> cannot be handled "today" by PMIP?
> > If they are all handled, then instead of fixing
> > an existing problem, the NETEXT multihoming PS is asking for new services.
>
>Well, I think PMIPv6 is missing the functionality of controlling
>multiple interfaces with a single mobility session, for example.

I read your response as a new service is being requested.
You want PMIPv6 to also support multiple 
interfaces as a single mobility session, which is 
not one of the three bullet items.

My problems with these are that once PMIPv6 
provides multiple services for which the mobile node can use;
How does the mobile node make its choice, and
How does the PMIP make the choice for the mobile node?

It is nice to have PMIP have multiple functions, 
but it gets harder to "proxy" for the mobile node 
when there is no communications to provide the 
"proxy" function from the mobile node.

If there is but one PMIP service, it is easier to 
see how the network can "proxy" for the mobile node.

> >
> > Another document that I have read on multihoming
> > is draft-ieft-monami6-mipv6-analysis-05 (now expired)
> >
> >
> > >         - in local routing, not sure if the optimization would have to
> > >consider which is the best interface of the MN to achieve the shortest
> > >path. This would require involving the MN, and I'd prefer involving only
> > >the network there.
> > So if I understand your point, the Network would
> > make the entire determination of which
> > interface(s) to provide route optimization
> > for.  In what manner would this be done?  For
> > every route?  For selective routes?  If so, what
> > would be the criteria?  If the goal is to not
> > involve the mobile node as the original PMIP
> > design, then as a network under what network ONLY
> > criteria would be used to justify route optimization?
> > It seems to me that the criteria is the
> > application that the mobile node is using, but
> > since we do not involve the mobile node how can
> > the network know that something should be route optimized?
>
>My point is that the "end-points" of route optimisation should be MAGs
>and LMAs, that is, without even considering which are the interfaces
>used by the MNs. This would be a simpler scenario that would avoid the
>involvement of the MN. Future work might include the MN and the
>considerations about the interfaces. I think for now netext is only
>aiming at working on local routing, not on route optimisation as we
>understand it in MIPv6.

I do not understand your point.  Why would the 
tunnel between a MAG and its LMA not be optimized already?
In other words how would another route from MAG to LMA be shorter?
My understanding was trying to short cut the MAG 
to LMA and LMA to CN by going MAG to CN and 
bypass the LMA (is this what you are calling 
route optimization in MIPv6?).  After reading a 
recent draft, it is not even this, but short 
cutting MAG (MN) to MAG (CN) with perhaps 
information from the LMA (is this local 
routing?  Common LMA for both MN and CN).

Thanks
David Cypher

>Thanks,
>
>Carlos
>
> >
> > David Cypher
> >
> > >         Kind Regards,
> > >
> > >         Carlos
> > >
> > >El jue, 26-02-2009 a las 11:20 -0500, David Cypher escribi?:
> > > > Taking a look at the other two problem statements in terms of
> > > > existing services and new services,
> > > > I do not think that any of the three problem statements can really be
> > > > addressed in isolation.
> > > >
> > > > Multihoming Problem Statement
> > > > Mobile node should be able to have more 
> than one interface to the network
> > > > - same access technology interfaces
> > > >       i) same IPv6 address    (not supported in RFC 5213)
> > > >       ii) different IPv6 address (supported)
> > > > - different access technology interfaces
> > > >       i) same IPv6 address    (supported but
> > > only for handover (temporarily))
> > > >       ii) different IPv6 address      (supported)
> > > >
> > > > NEW SERVICE being requested
> > > > - A) the ability to have the same IPv6 address on more than one
> > > > interface (whether the access technology is the same or different)
> > > > for a long period of time (i.e., not part of a handover/handoff).
> > > >
> > > >
> > > > Route optimization (RO) Problem statement
> > > > NEW SERVICES being requested
> > > > - A ) the ability to discover if a route between MN(MAG) and CN is
> > > > better than the existing route between MN (LMA) and CN and
> > > > - B) the ability to use the route if found.
> > > >
> > > > What interface will be used to find this optimized route if multiple
> > > > accesses exist and multihoming is truly provided?
> > > > All of them?  One of them?  Which one?  Will there be a primary
> > > > access interface or MN-HNP needed?
> > > >
> > > >
> > > > SUMMARY of the three problem statements
> > > > ======================================
> > > > Inter-technology and multihoming problem statements appear to be
> > > > interrelated.  Inter-technology (2.2) claims that there are problems
> > > > with mobile nodes' operating systems that do not permit multihoming
> > > > (same address on multiple interfaces), which is what the Multihoming
> > > > Problem statement is wanting.
> > > >
> > > > Inter-technology PS 3.2 needs to be able to distinguish between
> > > > handover and multiple interfaces.  This is another issue related to
> > > > Multihoming (multiple interfaces)
> > > >
> > > > Cannot look at inter-technology and multihoming as separate problem
> > > > statements.  Instead perhaps the problem statements should be written
> > > > from a NEW SERVICE being requested.
> > > >
> > > > Cannot look at route optimization and multihoming as separate
> > > > problems since the route optimized is dependent upon the attachment
> > > > point and the address used for that attachment.
> > > >
> > > > For example from the original PMIP the services were
> > > > - to supply the mobile node with a single set of MN-HNPs as it moved
> > > > throughout the PMIP domain while maintaining only one active
> > > > interface at a time or temporarily two during a handover.  (a single
> > > > set of MN-HNPs for all of the mobile node's interfaces provided only
> > > > one interface active at a time and used for handover only between two
> > > > interfaces)
> > > > - to supply the mobile node with a single set of MN-HNPs per
> > > > interface, if more than one interface was attached to the PMIP
> > > > domain. (a different set of MN-HNPs for each interface)
> > > >
> > > >
> > > > SUMMARY of new services:
> > > > =============================================
> > > > The NEW SERVICES being requested by the three PSs are:
> > > > - multiple interfaces active at the same time and not part of handover
> > > >       i) using the same MN-HNPs
> > > >       ii) using different MN-HNPs
> > > > - a method for determining which service(s) the mobile node wants
> > > > - a method for determining the mobile node's intended usage of the
> > > > multiple connections
> > > > - a method for determining the mobile node's capabilities to support
> > > > PMIP services.
> > > > - the ability to discover if a route between MN(MAG) (on which
> > > > interface) and CN is better than the existing route between MN (LMA)
> > > > (on which interface) and CN and
> > > > - the ability to use the route if found.
> > > >
> > > > David Cypher
> > > >
> > > >
> > > > _______________________________________________
> > > > NetExt mailing list
> > > > NetExt at mail.mobileip.jp
> > > > http://www.mobileip.jp/mailman/listinfo/netext
> > >--
> > >  Carlos Jes?s Bernardos Cano     http://www.netcoms.net
> > >  GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
> > >++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > >   WEEDEV 2009: 2nd Workshop on Experimental Evaluation and
> > >         Deployment Experiences on Vehicular networks
> > >                   http://www.weedev.org/
> > >++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >
> >
>--
>  Carlos Jes?s Bernardos Cano     http://www.netcoms.net
>  GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>   WEEDEV 2009: 2nd Workshop on Experimental Evaluation and
>         Deployment Experiences on Vehicular networks
>                   http://www.weedev.org/
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

From: rkoodli at starentnetworks.com (Koodli, Rajeev)
Date: Thu, 5 Mar 2009 14:25:49 -0500
Subject: [Netext] Inter-technology handover PS
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

 
> For the purpose of this BOF here:
> 
> 1. We are starting with the premise that we need to work on 
           ^NOT

> MN involvement. We will work on the proposed items.

Sorry about that..

-Rajeev

From: Basavaraj.Patil at nokia.com (Basavaraj.Patil at nokia.com)
Date: Thu, 5 Mar 2009 20:19:43 +0100
Subject: [Netext] Inter-technology handover PS
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Hi Marco,

On 3/5/09 10:09 AM, "ext Marco Liebsch" <liebsch at nw.neclab.eu> wrote:

> Hello,
>
> please find a few thoughts below.
>
> Koodli, Rajeev wrote:
>>
>> Hi Domagoj,
>>
>>
>>> WiMAX Forum is working on enabling the WiMAX-WiFi
>>> interworking and one of the requirements for WiFi interworking says:
>>>
>>> "Network based IP mobility SHALL be supported for the purpose
>>> of interworking."
>>>
>>> so we shouldn't exclude the WiFi access when considering
>>> possible deployments.
>>>
>>>
>>
>> Yes, we should not rule out WiFi. At the same time, I am not sure if it
>> serves as the best example scenario for our purpose here.
>>
>> I think the way forward should be a) to identify where MN involvement may be
>> necessary, if any, and b) discuss where (i.e., access technology, IP) such
>> participation (if any) is best done.
>>
> I agree that such analysis about the MN's role and what we gain in case
> the MN can signal
> in this context to the access is a good first task.
>
> Just a remark about the mentioned possibilities to signal between the MN
> and the access:
> There is something in between link layer signaling and a new IP
> protocol, which is
> the re-use of existing protocols, which are used by MNs, such as
> neighbor discovery.
> AFAIK, there was a draft about extensions to router discovery to convey
> some information
> for handover. Maybe such an approach is sufficient and also acceptable
> for NetExt.

That is a possible approach. We can consider reusing things like ND or
others to accomplish the task of sending some indications. I don't think we
are ruling it out.

>
> What's not so clear to me is when the conclusion from the analysis is
> that we do not need
> or work on IP signaling between the MN and the access in this context.
> What will
> the group work on for inter-technology handover? For work on link
> mechanisms,
> the IETF may be not the right place. Solutions and extensions to PMIPv6
> to improve
> handover performance are available and in scope of other WGs. Will the
> analysis be the only output then?

The IETF will not work on any specific link layer technology. Two
possibiliies:
1. We can provide input to other SDOs where these technologies are defined.
2. Consider solving it using L3 or above protocols with intent on reusing
existing mechanisms rather than specifying a new protocol

We would consider (2) only as the last resort.

-Raj

>
> marco
>
>> Regards,
>>
>> -Rajeev
>>
>>
>>
>>
>>> domagoj
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: netext-bounces at mail.mobileip.jp
>>>> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext Koodli,
>>>> Rajeev
>>>> Sent: 27. veljaca 2009 17:38
>>>> To: netext at mail.mobileip.jp
>>>> Subject: Re: [Netext] Inter-technology handover PS
>>>>
>>>>
>>>>
>>>>
>>>> Hi Domagoj,
>>>>
>>>>
>>>>> Extending the access system signaling may not be always
>>>>>
>>>> possible and
>>>>
>>>>> in such cases the IP layer mechanism would get used.
>>>>>
>>>> Considering the
>>>>
>>>>> already deployed WiFi equipement as an example, even if
>>>>>
>>> the 802.11
>>>
>>>>> would be extended to provide support for PMIP6 hints, is it
>>>>>
>>>> realistic
>>>>
>>>>> to expect the existing APs to be upgraded?
>>>>>
>>>> WiFi is not a good example here IMHO. One of the emphasis
>>>>
>>> in NetExt is
>>>
>>>> to consider possible deployment scenarios. So, either a candidate
>>>> access deployment already has or willing to define the necessary
>>>> extensions or expresses need to have an IP-based mechanism.
>>>>
>>>>
>>>>>> How does handover work in Wimax today without indication
>>>>>>
>>>>> from the MN
>>>>>
>>>>>> at the IP layer?
>>>>>>
>>>>> Curretnly it doesn't work (the inter-tech HO), this is an
>>>>>
>>>> open issue.
>>>>
>>>>> Link layer extensions are not an option as the
>>>>> .16 version upon which the NWG Rel
>>>>> 1.5 is based is closed for changes.
>>>>>
>>>>>
>>>> Good to know. We will need further discussion to go over this.
>>>>
>>>>
>>>>>> To be clear, I do not wish to start from a point where
>>>>>>
>>> we assume
>>>
>>>>>> that MN involvement at the IP layer is necessary;
>>>>>>
>>>> at least for this BOF.
>>>>
>>>>> Is MN involvement at the link layer less of a concern then the MN
>>>>> involvement at the IP layer? It should not be.
>>>>>
>>>> Yes, it is less of a concern for _this BOF_ because this
>>>>
>>> BoF is about
>>>
>>>> working on some problems related to network-based mobility
>>>>
>>> where we do
>>>
>>>> not want to start from making changes to the MN. As I
>>>>
>>> mentioned in my
>>>
>>>> e-mail, defining an IP layer mechanism which an access
>>>>
>>> system already
>>>
>>>> has or will define will be redundant and ignored.
>>>>
>>>>
>>>>
>>>>> Ideally, the MN is not involved at all at any layer. My
>>>>> thinking is that, if it must be involved, it makes sense to
>>>>> address those changes at the IP layer - once and for all.
>>>>>
>>>>>
>>>> As a general design guideline yes. It's not easy for this BOF.
>>>>
>>>>
>>>>
>>>>>> The focus of this effort is to identify the problems
>>>>>>
>>>> which need to be
>>>>
>>>>>> solved. During the process, we can list what works and
>>>>>>
>>>> what doesn't as
>>>>
>>>>>> it is, without MN involvement; it needs to be done thoroughly.
>>>>>>
>>>>> ok, let's try to see first what scenarios can be addressed
>>>>> without the MN involvement.
>>>>>
>>>>>
>>>> Good. I want to start with the clear understanding that we
>>>> are _not_ starting with defining MN involvement (at IP
>>>> layer). Once we get chartered (hopefully), we can have a
>>>> discussion on the topic as part of Inter-tech handovers and
>>>> arrive at consensus.
>>>>
>>>>
>>>>>> But, the starting point is not "we need MN involvement".
>>>>>>
>>>>> I would just like the term "MN involvement" to include the
>>>>> link layer extensions as well. Otherwise we're sweeping the
>>>>> problem under the rug.
>>>>>
>>>>>
>>>> Sure. One thing we can do is to clearly list where MN
>>>> participation is necessary.
>>>> Whether this would be done by L2 or IP is another thing.
>>>>
>>>> Thanks,
>>>>
>>>> -Rajeev
>>>>
>>>>
>>>>
>>>>> domagoj
>>>>>
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: netext-bounces at mail.mobileip.jp
>>>>>> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of
>>>>>>
>>> ext Koodli,
>>>
>>>>>> Rajeev
>>>>>> Sent: 26. veljaca 2009 19:38
>>>>>> To: netext at mail.mobileip.jp
>>>>>> Subject: Re: [Netext] Inter-technology handover PS
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hi Domagoj,
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Using access specific mechanims is fine for the cases where
>>>>>>>
>>>>>> the access
>>>>>>
>>>>>>> system actually provides the needed functionality.
>>>>>>>
>>>>>> Good. My reasoning is that if there is a functionality which is
>>>>>> crucial to an access system, it will provide it. We defining a
>>>>>> mechanism at IP layer, which I would prefer as well, will
>>>>>>
>>>>> turn out to
>>>>>
>>>>>> be redundant and ignored.
>>>>>>
>>>>>>
>>>>>>
>>>>>>> I don't think that we can expect every access system
>>>>>>>
>>> to readily
>>>
>>>>>>> support whatever is needed by PMIP6 (WiMAX being one
>>>>>>>
>>>>>> example of such
>>>>>>
>>>>>>> access system, it doesn't provide any clue about the
>>>>>>>
>>>> HI). In such
>>>>
>>>>>>> cases it makes sense to put the additional functionality
>>>>>>>
>>>>> at the IP
>>>>>
>>>>>>> layer, i.e. at the MAG/LMA/MN as they need to be updated
>>>>>>>
>>>>> anyway to
>>>>>
>>>>>>> support inter-tech handover. Such add-on at the
>>>>>>>
>>>> IP-layer could be
>>>>
>>>>>>> reused without modifications with any access system which
>>>>>>>
>>>>> does not
>>>>>
>>>>>>> provide the appropriate L2 hints.
>>>>>>>
>>>>>> How does handover work in Wimax today without indication
>>>>>>
>>>>> from the MN
>>>>>
>>>>>> at the IP layer?
>>>>>>
>>>>>> To be clear, I do not wish to start from a point where we
>>>>>>
>>>>> assume that
>>>>>
>>>>>> MN involvement at the IP layer is necessary; at least for
>>>>>>
>>>> this BOF.
>>>>
>>>>>> The focus of this effort is to identify the problems which
>>>>>>
>>>>> need to be
>>>>>
>>>>>> solved. During the process, we can list what works and what
>>>>>>
>>>>> doesn't as
>>>>>
>>>>>> it is, without MN involvement; it needs to be done thoroughly.
>>>>>> But, the starting point is not "we need MN involvement".
>>>>>>
>>>>>> -Rajeev
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> domagoj
>>>>>>>
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: netext-bounces at mail.mobileip.jp
>>>>>>>> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of
>>>>>>>>
>>>>> ext Koodli,
>>>>>
>>>>>>>> Rajeev
>>>>>>>> Sent: 24. veljaca 2009 23:01
>>>>>>>> To: netext at mail.mobileip.jp
>>>>>>>> Subject: Re: [Netext] Inter-technology handover PS
>>>>>>>>
>>>>>>>>
>>>>>>>> Hello folks,
>>>>>>>>
>>>>>>>> Few thoughts on what we may need to focus here..
>>>>>>>>
>>>>>>>> 1. For the purposes of this ID (i.e., inter-tech
>>>>>>>>
>>>>>>> handovers), what is
>>>>>>>
>>>>>>>> most relevant here? What breaks today? Or, what we can
>>>>>>>>
>>>>>> improve? The
>>>>>>
>>>>>>>> breakdown of issues is a good start, but we need to tie
>>>>>>>>
>>>>>> it together
>>>>>>
>>>>>>>> for the problem at hand - inter-tech handovers.
>>>>>>>>
>>>>>>>> 2. What _requires_ an IP protocol support on the MN side?
>>>>>>>> Could this be done in an access-specific way? For instance,
>>>>>>>>
>>>>>>> the HI in
>>>>>>>
>>>>>>>> PMIP6 is left up to the access system to determine,
>>>>>>>>
>>> based on
>>>
>>>>>>>> access-specific means where MN does take part. We
>>>>>>>>
>>>> need to ask a
>>>>
>>>>>>>> similar question here: if MN involvement is necessary, why
>>>>>>>>
>>>>>>> couldn't we
>>>>>>>
>>>>>>>> let an access system provide the functionality?
>>>>>>>>
>>>>>>>> 3. Assuming specific mechanisms (e.g., IEEE 802.21
>>>>>>>>
>>>> etc.) is not
>>>>
>>>>>>>> necessary. Folks can use whatever they want, but specifying
>>>>>>>> dependencies needs to be avoided.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> -Rajeev
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: netext-bounces at mail.mobileip.jp
>>>>>>>>> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of
>>>>>>>>>
>>>>>>>> Suresh Krishnan
>>>>>>>>
>>>>>>>>> Sent: Thursday, February 19, 2009 3:19 PM
>>>>>>>>> To: cjbc at it.uc3m.es
>>>>>>>>> Cc: netext at mail.mobileip.jp
>>>>>>>>> Subject: Re: [Netext] Inter-technology handover PS
>>>>>>>>>
>>>>>>>>> Hi Carlos,
>>>>>>>>>    Thanks for your comments. Please find responses inline
>>>>>>>>>
>>>>>>>>> On 16/02/09 02:01 PM, Carlos Jes?s Bernardos Cano wrote:
>>>>>>>>>
>>>>>>>>>> * PGP Signed by an unknown key
>>>>>>>>>>
>>>>>>>>>> Hi Suresh,
>>>>>>>>>>
>>>>>>>>>>       Thanks for the draft. I think it's
>>>>>>>>>>
>>> short and clear.
>>>
>>>>>>>>> Some comments
>>>>>>>>>
>>>>>>>>>> below:
>>>>>>>>>>
>>>>>>>>>>       - Section 2.1. Formation of interface
>>>>>>>>>>
>>> identifier. The
>>>
>>>>>>>>> issue described
>>>>>>>>>
>>>>>>>>>> there only applies if SLAAC is used, right? If DHCP is
>>>>>>>>>>
>>>>>>>>> used, the issue
>>>>>>>>>
>>>>>>>>>> is then on the network side, to ensure that the address
>>>>>>>>>>
>>>>>>>> provided to
>>>>>>>>
>>>>>>>>>> the new interface of the MN is the same that it was (or
>>>>>>>>>>
>>>>>>> is still)
>>>>>>>
>>>>>>>>>> using on the previous interface, right?
>>>>>>>>>>
>>>>>>>>> Yes. This is correct. I can probably add a new section on
>>>>>>>>>
>>>>>>>> the network
>>>>>>>>
>>>>>>>>> side about the DHCPv6 issue
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>       - Section 2.2 Usage of the same address
>>>>>>>>>>
>>> on multiple
>>>
>>>>>>>>> interfaces. Since
>>>>>>>>>
>>>>>>>>>> it seems that we cannot assume that is safe to
>>>>>>>>>>
>>>> use the same
>>>>
>>>>>>>>> address on
>>>>>>>>>
>>>>>>>>>> multiple interfaces (without requiring changes on the MN
>>>>>>>>>>
>>>>>>>>> side), this
>>>>>>>>>
>>>>>>>>>> implies that: a) if NETEXT work is restricted to work on
>>>>>>>>>>
>>>>>>>> solutions
>>>>>>>>
>>>>>>>>>> that do not impose changes on the MN, use cases
>>>>>>>>>>
>>> requiring
>>>
>>>>>>>> the MN to
>>>>>>>>
>>>>>>>>>> use the same address simultaneously are out of
>>>>>>>>>>
>>>> the scope of
>>>>
>>>>>>>>> NETEXT, b)
>>>>>>>>>
>>>>>>>>>> we allow for changes on the MN side.
>>>>>>>>>>
>>>> Additionally, it might
>>>>
>>>>>>>>> be good to
>>>>>>>>>
>>>>>>>>>> analyse if it is OK for the MN to receive (and send)
>>>>>>>>>>
>>>>>>>>> traffic addressed
>>>>>>>>>
>>>>>>>>>> to the IPv6 address of one interface through a different
>>>>>>>>>>
>>>>>>>> interface
>>>>>>>>
>>>>>>>>>> (weak end-system model defined in RFC 1122 or
>>>>>>>>>>
>>>>>>>>> draft-thaler-ip-model-evolution).
>>>>>>>>>
>>>>>>>>> While I agree with your analysis of the problem, are we
>>>>>>>>>
>>>>>>> delving too
>>>>>>>
>>>>>>>>> much into the solution space by adding any such text?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>       - IMHO, it'd be good to explicitly
>>>>>>>>>>
>>> describe what a
>>>
>>>>>>>>> "change on the MN"
>>>>>>>>>
>>>>>>>>>> within the scope of NETEXT. For example, is it fine
>>>>>>>>>>
>>>>>>> assuming IEEE
>>>>>>>
>>>>>>>>>> 802.21 support on the MN or is this "a change
>>>>>>>>>>
>>> on the MN"?
>>>
>>>>>>>>> Probably something to add to the charter?
>>>>>>>>>
>>>>>>>>> Cheers
>>>>>>>>> Suresh
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> NetExt mailing list
>>>>>>>>> NetExt at mail.mobileip.jp
>>>>>>>>> http://www.mobileip.jp/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
>>>>>>>> postmaster at starentnetworks.com -- and destroy all
>>>>>>>>
>>>>> copies of this
>>>>>
>>>>>>>> message and any attachments without reading or
>>>>>>>>
>>>> disclosing their
>>>>
>>>>>>>> contents. Thank you.
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> NetExt mailing list
>>>>>>>> NetExt at mail.mobileip.jp
>>>>>>>> http://www.mobileip.jp/mailman/listinfo/netext
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>> _______________________________________________
>>>>>> NetExt mailing list
>>>>>> NetExt at mail.mobileip.jp
>>>>>> http://www.mobileip.jp/mailman/listinfo/netext
>>>>>>
>>>>>>
>>>>>
>>>> _______________________________________________
>>>> NetExt mailing list
>>>> NetExt at mail.mobileip.jp
>>>> http://www.mobileip.jp/mailman/listinfo/netext
>>>>
>>>>
>>>
>>
>> _______________________________________________
>> NetExt mailing list
>> NetExt at mail.mobileip.jp
>> http://www.mobileip.jp/mailman/listinfo/netext
>>
>
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext

From: rkoodli at starentnetworks.com (Koodli, Rajeev)
Date: Thu, 5 Mar 2009 14:14:32 -0500
Subject: [Netext] Inter-technology handover PS
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

> > I think the way forward should be a) to identify where MN 
> involvement may be necessary, if any, and b) discuss where 
> (i.e., access technology, IP) such participation (if any) is 
> best done.
> >   
> I agree that such analysis about the MN's role and what we 
> gain in case the MN can signal in this context to the access 
> is a good first task.

Good.

> 
> Just a remark about the mentioned possibilities to signal 
> between the MN and the access:
> There is something in between link layer signaling and a new 
> IP protocol, which is the re-use of existing protocols, which 
> are used by MNs, such as neighbor discovery.
> AFAIK, there was a draft about extensions to router discovery 
> to convey some information for handover. Maybe such an 
> approach is sufficient and also acceptable for NetExt.
> 

Could well be.

> What's not so clear to me is when the conclusion from the 
> analysis is that we do not need or work on IP signaling 
> between the MN and the access in this context. 
> What will
> the group work on for inter-technology handover? For work on 
> link mechanisms, the IETF may be not the right place. 
> Solutions and extensions to PMIPv6 to improve handover 
> performance are available and in scope of other WGs. Will the 
> analysis be the only output then?

There are multiple possibilities, as you can surmise. It's too early to decide which way to go.

For the purpose of this BOF here:

1. We are starting with the premise that we need to work on MN involvement. We will work on the proposed items.

2. During the development of protocols, 
   A.) we will look at what will break if the MN involvement is missing.
   B.) discuss why a non-access mechanism is necessary (i.e., why we couldn't rely on access technologies to solve the problem identified, if any)
   C.) consider the solution the group needs to develop, if any.

So, it is kind of early to look into C.) now.

Regards,

-Rajeev

> 
> marco
> 
> > Regards,
> >
> > -Rajeev
> >   
> >
> >
> >   
> >> domagoj
> >>
> >>
> >>     
> >>> -----Original Message-----
> >>> From: netext-bounces at mail.mobileip.jp 
> >>> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext Koodli, 
> >>> Rajeev
> >>> Sent: 27. veljaca 2009 17:38
> >>> To: netext at mail.mobileip.jp
> >>> Subject: Re: [Netext] Inter-technology handover PS
> >>>
> >>>
> >>>  
> >>>
> >>> Hi Domagoj,
> >>>
> >>>       
> >>>> Extending the access system signaling may not be always
> >>>>         
> >>> possible and
> >>>       
> >>>> in such cases the IP layer mechanism would get used. 
> >>>>         
> >>> Considering the
> >>>       
> >>>> already deployed WiFi equipement as an example, even if
> >>>>         
> >> the 802.11
> >>     
> >>>> would be extended to provide support for PMIP6 hints, is it
> >>>>         
> >>> realistic
> >>>       
> >>>> to expect the existing APs to be upgraded?
> >>>>         
> >>> WiFi is not a good example here IMHO. One of the emphasis
> >>>       
> >> in NetExt is
> >>     
> >>> to consider possible deployment scenarios. So, either a candidate 
> >>> access deployment already has or willing to define the necessary 
> >>> extensions or expresses need to have an IP-based mechanism.
> >>>
> >>>       
> >>>>> How does handover work in Wimax today without indication
> >>>>>           
> >>>> from the MN
> >>>>         
> >>>>> at the IP layer?
> >>>>>           
> >>>> Curretnly it doesn't work (the inter-tech HO), this is an
> >>>>         
> >>> open issue. 
> >>>       
> >>>> Link layer extensions are not an option as the
> >>>> .16 version upon which the NWG Rel
> >>>> 1.5 is based is closed for changes.
> >>>>
> >>>>         
> >>> Good to know. We will need further discussion to go over this.
> >>>
> >>>       
> >>>>> To be clear, I do not wish to start from a point where
> >>>>>           
> >> we assume
> >>     
> >>>>> that MN involvement at the IP layer is necessary;
> >>>>>           
> >>> at least for this BOF.
> >>>       
> >>>> Is MN involvement at the link layer less of a concern 
> then the MN 
> >>>> involvement at the IP layer? It should not be.
> >>>>         
> >>> Yes, it is less of a concern for _this BOF_ because this
> >>>       
> >> BoF is about
> >>     
> >>> working on some problems related to network-based mobility
> >>>       
> >> where we do
> >>     
> >>> not want to start from making changes to the MN. As I
> >>>       
> >> mentioned in my
> >>     
> >>> e-mail, defining an IP layer mechanism which an access
> >>>       
> >> system already
> >>     
> >>> has or will define will be redundant and ignored.
> >>>
> >>>
> >>>       
> >>>> Ideally, the MN is not involved at all at any layer. My 
> thinking is 
> >>>> that, if it must be involved, it makes sense to address those 
> >>>> changes at the IP layer - once and for all.
> >>>>
> >>>>         
> >>> As a general design guideline yes. It's not easy for this BOF.
> >>>
> >>>
> >>>       
> >>>>> The focus of this effort is to identify the problems
> >>>>>           
> >>> which need to be
> >>>       
> >>>>> solved. During the process, we can list what works and
> >>>>>           
> >>> what doesn't as
> >>>       
> >>>>> it is, without MN involvement; it needs to be done thoroughly.
> >>>>>           
> >>>> ok, let's try to see first what scenarios can be 
> addressed without 
> >>>> the MN involvement.
> >>>>
> >>>>         
> >>> Good. I want to start with the clear understanding that 
> we are _not_ 
> >>> starting with defining MN involvement (at IP layer). Once we get 
> >>> chartered (hopefully), we can have a discussion on the 
> topic as part 
> >>> of Inter-tech handovers and arrive at consensus.
> >>>
> >>>       
> >>>>> But, the starting point is not "we need MN involvement".  
> >>>>>           
> >>>> I would just like the term "MN involvement" to include the link 
> >>>> layer extensions as well. Otherwise we're sweeping the problem 
> >>>> under the rug.
> >>>>
> >>>>         
> >>> Sure. One thing we can do is to clearly list where MN 
> participation 
> >>> is necessary.
> >>> Whether this would be done by L2 or IP is another thing. 
> >>>
> >>> Thanks,
> >>>
> >>> -Rajeev
> >>>
> >>>
> >>>       
> >>>> domagoj
> >>>>
> >>>>
> >>>>         
> >>>>> -----Original Message-----
> >>>>> From: netext-bounces at mail.mobileip.jp 
> >>>>> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of
> >>>>>           
> >> ext Koodli,
> >>     
> >>>>> Rajeev
> >>>>> Sent: 26. veljaca 2009 19:38
> >>>>> To: netext at mail.mobileip.jp
> >>>>> Subject: Re: [Netext] Inter-technology handover PS
> >>>>>
> >>>>>
> >>>>>  
> >>>>> Hi Domagoj,
> >>>>>
> >>>>>
> >>>>>           
> >>>>>> Using access specific mechanims is fine for the cases where
> >>>>>>             
> >>>>> the access
> >>>>>           
> >>>>>> system actually provides the needed functionality.
> >>>>>>             
> >>>>> Good. My reasoning is that if there is a functionality which is 
> >>>>> crucial to an access system, it will provide it. We defining a 
> >>>>> mechanism at IP layer, which I would prefer as well, will
> >>>>>           
> >>>> turn out to
> >>>>         
> >>>>> be redundant and ignored.
> >>>>>
> >>>>>
> >>>>>           
> >>>>>> I don't think that we can expect every access system
> >>>>>>             
> >> to readily
> >>     
> >>>>>> support whatever is needed by PMIP6 (WiMAX being one
> >>>>>>             
> >>>>> example of such
> >>>>>           
> >>>>>> access system, it doesn't provide any clue about the
> >>>>>>             
> >>> HI). In such
> >>>       
> >>>>>> cases it makes sense to put the additional functionality
> >>>>>>             
> >>>> at the IP
> >>>>         
> >>>>>> layer, i.e. at the MAG/LMA/MN as they need to be updated
> >>>>>>             
> >>>> anyway to
> >>>>         
> >>>>>> support inter-tech handover. Such add-on at the
> >>>>>>             
> >>> IP-layer could be
> >>>       
> >>>>>> reused without modifications with any access system which
> >>>>>>             
> >>>> does not
> >>>>         
> >>>>>> provide the appropriate L2 hints.
> >>>>>>             
> >>>>> How does handover work in Wimax today without indication
> >>>>>           
> >>>> from the MN
> >>>>         
> >>>>> at the IP layer?
> >>>>>
> >>>>> To be clear, I do not wish to start from a point where we
> >>>>>           
> >>>> assume that
> >>>>         
> >>>>> MN involvement at the IP layer is necessary; at least for
> >>>>>           
> >>> this BOF. 
> >>>       
> >>>>> The focus of this effort is to identify the problems which
> >>>>>           
> >>>> need to be
> >>>>         
> >>>>> solved. During the process, we can list what works and what
> >>>>>           
> >>>> doesn't as
> >>>>         
> >>>>> it is, without MN involvement; it needs to be done thoroughly.
> >>>>> But, the starting point is not "we need MN involvement". 
> >>>>>
> >>>>> -Rajeev
> >>>>>
> >>>>>
> >>>>>
> >>>>>           
> >>>>>> domagoj
> >>>>>>
> >>>>>>             
> >>>>>>> -----Original Message-----
> >>>>>>> From: netext-bounces at mail.mobileip.jp 
> >>>>>>> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of
> >>>>>>>               
> >>>> ext Koodli,
> >>>>         
> >>>>>>> Rajeev
> >>>>>>> Sent: 24. veljaca 2009 23:01
> >>>>>>> To: netext at mail.mobileip.jp
> >>>>>>> Subject: Re: [Netext] Inter-technology handover PS
> >>>>>>>
> >>>>>>>
> >>>>>>> Hello folks,
> >>>>>>>
> >>>>>>> Few thoughts on what we may need to focus here..
> >>>>>>>
> >>>>>>> 1. For the purposes of this ID (i.e., inter-tech
> >>>>>>>               
> >>>>>> handovers), what is
> >>>>>>             
> >>>>>>> most relevant here? What breaks today? Or, what we can
> >>>>>>>               
> >>>>> improve? The
> >>>>>           
> >>>>>>> breakdown of issues is a good start, but we need to tie
> >>>>>>>               
> >>>>> it together
> >>>>>           
> >>>>>>> for the problem at hand - inter-tech handovers.
> >>>>>>>
> >>>>>>> 2. What _requires_ an IP protocol support on the MN side? 
> >>>>>>> Could this be done in an access-specific way? For instance,
> >>>>>>>               
> >>>>>> the HI in
> >>>>>>             
> >>>>>>> PMIP6 is left up to the access system to determine,
> >>>>>>>               
> >> based on
> >>     
> >>>>>>> access-specific means where MN does take part. We
> >>>>>>>               
> >>> need to ask a
> >>>       
> >>>>>>> similar question here: if MN involvement is necessary, why
> >>>>>>>               
> >>>>>> couldn't we
> >>>>>>             
> >>>>>>> let an access system provide the functionality?
> >>>>>>>
> >>>>>>> 3. Assuming specific mechanisms (e.g., IEEE 802.21
> >>>>>>>               
> >>> etc.) is not
> >>>       
> >>>>>>> necessary. Folks can use whatever they want, but specifying 
> >>>>>>> dependencies needs to be avoided.
> >>>>>>>
> >>>>>>> Regards,
> >>>>>>>
> >>>>>>> -Rajeev
> >>>>>>>  
> >>>>>>>
> >>>>>>>               
> >>>>>>>> -----Original Message-----
> >>>>>>>> From: netext-bounces at mail.mobileip.jp 
> >>>>>>>> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of
> >>>>>>>>                 
> >>>>>>> Suresh Krishnan
> >>>>>>>               
> >>>>>>>> Sent: Thursday, February 19, 2009 3:19 PM
> >>>>>>>> To: cjbc at it.uc3m.es
> >>>>>>>> Cc: netext at mail.mobileip.jp
> >>>>>>>> Subject: Re: [Netext] Inter-technology handover PS
> >>>>>>>>
> >>>>>>>> Hi Carlos,
> >>>>>>>>    Thanks for your comments. Please find responses inline
> >>>>>>>>
> >>>>>>>> On 16/02/09 02:01 PM, Carlos Jes?s Bernardos Cano wrote:
> >>>>>>>>                 
> >>>>>>>>> * PGP Signed by an unknown key
> >>>>>>>>>
> >>>>>>>>> Hi Suresh,
> >>>>>>>>>
> >>>>>>>>> 	Thanks for the draft. I think it's
> >>>>>>>>>                   
> >> short and clear. 
> >>     
> >>>>>>>> Some comments
> >>>>>>>>                 
> >>>>>>>>> below:
> >>>>>>>>>
> >>>>>>>>> 	- Section 2.1. Formation of interface
> >>>>>>>>>                   
> >> identifier. The
> >>     
> >>>>>>>> issue described
> >>>>>>>>                 
> >>>>>>>>> there only applies if SLAAC is used, right? If DHCP is
> >>>>>>>>>                   
> >>>>>>>> used, the issue
> >>>>>>>>                 
> >>>>>>>>> is then on the network side, to ensure that the address
> >>>>>>>>>                   
> >>>>>>> provided to
> >>>>>>>               
> >>>>>>>>> the new interface of the MN is the same that it was (or
> >>>>>>>>>                   
> >>>>>> is still)
> >>>>>>             
> >>>>>>>>> using on the previous interface, right?
> >>>>>>>>>                   
> >>>>>>>> Yes. This is correct. I can probably add a new section on
> >>>>>>>>                 
> >>>>>>> the network
> >>>>>>>               
> >>>>>>>> side about the DHCPv6 issue
> >>>>>>>>
> >>>>>>>>                 
> >>>>>>>>> 	- Section 2.2 Usage of the same address
> >>>>>>>>>                   
> >> on multiple
> >>     
> >>>>>>>> interfaces. Since
> >>>>>>>>                 
> >>>>>>>>> it seems that we cannot assume that is safe to
> >>>>>>>>>                   
> >>> use the same
> >>>       
> >>>>>>>> address on
> >>>>>>>>                 
> >>>>>>>>> multiple interfaces (without requiring changes on the MN
> >>>>>>>>>                   
> >>>>>>>> side), this
> >>>>>>>>                 
> >>>>>>>>> implies that: a) if NETEXT work is restricted to work on
> >>>>>>>>>                   
> >>>>>>> solutions
> >>>>>>>               
> >>>>>>>>> that do not impose changes on the MN, use cases
> >>>>>>>>>                   
> >> requiring
> >>     
> >>>>>>> the MN to
> >>>>>>>               
> >>>>>>>>> use the same address simultaneously are out of
> >>>>>>>>>                   
> >>> the scope of
> >>>       
> >>>>>>>> NETEXT, b)
> >>>>>>>>                 
> >>>>>>>>> we allow for changes on the MN side. 
> >>>>>>>>>                   
> >>> Additionally, it might
> >>>       
> >>>>>>>> be good to
> >>>>>>>>                 
> >>>>>>>>> analyse if it is OK for the MN to receive (and send)
> >>>>>>>>>                   
> >>>>>>>> traffic addressed
> >>>>>>>>                 
> >>>>>>>>> to the IPv6 address of one interface through a different
> >>>>>>>>>                   
> >>>>>>> interface
> >>>>>>>               
> >>>>>>>>> (weak end-system model defined in RFC 1122 or
> >>>>>>>>>                   
> >>>>>>>> draft-thaler-ip-model-evolution).
> >>>>>>>>
> >>>>>>>> While I agree with your analysis of the problem, are we
> >>>>>>>>                 
> >>>>>> delving too
> >>>>>>             
> >>>>>>>> much into the solution space by adding any such text?
> >>>>>>>>
> >>>>>>>>                 
> >>>>>>>>> 	- IMHO, it'd be good to explicitly
> >>>>>>>>>                   
> >> describe what a
> >>     
> >>>>>>>> "change on the MN"
> >>>>>>>>                 
> >>>>>>>>> within the scope of NETEXT. For example, is it fine
> >>>>>>>>>                   
> >>>>>> assuming IEEE
> >>>>>>             
> >>>>>>>>> 802.21 support on the MN or is this "a change
> >>>>>>>>>                   
> >> on the MN"?
> >>     
> >>>>>>>> Probably something to add to the charter?
> >>>>>>>>
> >>>>>>>> Cheers
> >>>>>>>> Suresh
> >>>>>>>>
> >>>>>>>> _______________________________________________
> >>>>>>>> NetExt mailing list
> >>>>>>>> NetExt at mail.mobileip.jp
> >>>>>>>> http://www.mobileip.jp/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 
> >>>>>>> postmaster at starentnetworks.com -- and destroy all
> >>>>>>>               
> >>>> copies of this
> >>>>         
> >>>>>>> message and any attachments without reading or
> >>>>>>>               
> >>> disclosing their
> >>>       
> >>>>>>> contents. Thank you.
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> NetExt mailing list
> >>>>>>> NetExt at mail.mobileip.jp
> >>>>>>> http://www.mobileip.jp/mailman/listinfo/netext
> >>>>>>>
> >>>>>>>               
> >>>>>>             
> >>>>> _______________________________________________
> >>>>> NetExt mailing list
> >>>>> NetExt at mail.mobileip.jp
> >>>>> http://www.mobileip.jp/mailman/listinfo/netext
> >>>>>
> >>>>>           
> >>>>         
> >>> _______________________________________________
> >>> NetExt mailing list
> >>> NetExt at mail.mobileip.jp
> >>> http://www.mobileip.jp/mailman/listinfo/netext
> >>>
> >>>       
> >>     
> >
> > _______________________________________________
> > NetExt mailing list
> > NetExt at mail.mobileip.jp
> > http://www.mobileip.jp/mailman/listinfo/netext
> >   
> 
> 

From: liebsch at nw.neclab.eu (Marco Liebsch)
Date: Thu, 05 Mar 2009 17:09:18 +0100
Subject: [Netext] Inter-technology handover PS
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hello,

please find a few thoughts below.

Koodli, Rajeev wrote:
>  
> Hi Domagoj,
>
>   
>> WiMAX Forum is working on enabling the WiMAX-WiFi 
>> interworking and one of the requirements for WiFi interworking says:
>>
>> "Network based IP mobility SHALL be supported for the purpose 
>> of interworking."
>>
>> so we shouldn't exclude the WiFi access when considering 
>> possible deployments.
>>
>>     
>
> Yes, we should not rule out WiFi. At the same time, I am not sure if it serves as the best example scenario for our purpose here.
>
> I think the way forward should be a) to identify where MN involvement may be necessary, if any, and b) discuss where (i.e., access technology, IP) such participation (if any) is best done.
>   
I agree that such analysis about the MN's role and what we gain in case 
the MN can signal
in this context to the access is a good first task.

Just a remark about the mentioned possibilities to signal between the MN 
and the access:
There is something in between link layer signaling and a new IP 
protocol, which is
the re-use of existing protocols, which are used by MNs, such as 
neighbor discovery.
AFAIK, there was a draft about extensions to router discovery to convey 
some information
for handover. Maybe such an approach is sufficient and also acceptable 
for NetExt.

What's not so clear to me is when the conclusion from the analysis is 
that we do not need
or work on IP signaling between the MN and the access in this context. 
What will
the group work on for inter-technology handover? For work on link 
mechanisms,
the IETF may be not the right place. Solutions and extensions to PMIPv6 
to improve
handover performance are available and in scope of other WGs. Will the
analysis be the only output then?

marco

> Regards,
>
> -Rajeev
>   
>
>
>   
>> domagoj
>>
>>
>>     
>>> -----Original Message-----
>>> From: netext-bounces at mail.mobileip.jp 
>>> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext Koodli, 
>>> Rajeev
>>> Sent: 27. veljaca 2009 17:38
>>> To: netext at mail.mobileip.jp
>>> Subject: Re: [Netext] Inter-technology handover PS
>>>
>>>
>>>  
>>>
>>> Hi Domagoj,
>>>
>>>       
>>>> Extending the access system signaling may not be always
>>>>         
>>> possible and
>>>       
>>>> in such cases the IP layer mechanism would get used. 
>>>>         
>>> Considering the
>>>       
>>>> already deployed WiFi equipement as an example, even if 
>>>>         
>> the 802.11 
>>     
>>>> would be extended to provide support for PMIP6 hints, is it
>>>>         
>>> realistic
>>>       
>>>> to expect the existing APs to be upgraded?
>>>>         
>>> WiFi is not a good example here IMHO. One of the emphasis 
>>>       
>> in NetExt is 
>>     
>>> to consider possible deployment scenarios. So, either a candidate 
>>> access deployment already has or willing to define the necessary 
>>> extensions or expresses need to have an IP-based mechanism.
>>>
>>>       
>>>>> How does handover work in Wimax today without indication
>>>>>           
>>>> from the MN
>>>>         
>>>>> at the IP layer?
>>>>>           
>>>> Curretnly it doesn't work (the inter-tech HO), this is an
>>>>         
>>> open issue. 
>>>       
>>>> Link layer extensions are not an option as the
>>>> .16 version upon which the NWG Rel
>>>> 1.5 is based is closed for changes.
>>>>
>>>>         
>>> Good to know. We will need further discussion to go over this.
>>>
>>>       
>>>>> To be clear, I do not wish to start from a point where 
>>>>>           
>> we assume 
>>     
>>>>> that MN involvement at the IP layer is necessary;
>>>>>           
>>> at least for this BOF.
>>>       
>>>> Is MN involvement at the link layer less of a concern then the MN 
>>>> involvement at the IP layer? It should not be.
>>>>         
>>> Yes, it is less of a concern for _this BOF_ because this 
>>>       
>> BoF is about 
>>     
>>> working on some problems related to network-based mobility 
>>>       
>> where we do 
>>     
>>> not want to start from making changes to the MN. As I 
>>>       
>> mentioned in my 
>>     
>>> e-mail, defining an IP layer mechanism which an access 
>>>       
>> system already 
>>     
>>> has or will define will be redundant and ignored.
>>>
>>>
>>>       
>>>> Ideally, the MN is not involved at all at any layer. My 
>>>> thinking is that, if it must be involved, it makes sense to 
>>>> address those changes at the IP layer - once and for all.
>>>>
>>>>         
>>> As a general design guideline yes. It's not easy for this BOF.
>>>
>>>
>>>       
>>>>> The focus of this effort is to identify the problems 
>>>>>           
>>> which need to be 
>>>       
>>>>> solved. During the process, we can list what works and 
>>>>>           
>>> what doesn't as 
>>>       
>>>>> it is, without MN involvement; it needs to be done thoroughly.
>>>>>           
>>>> ok, let's try to see first what scenarios can be addressed 
>>>> without the MN involvement.
>>>>
>>>>         
>>> Good. I want to start with the clear understanding that we 
>>> are _not_ starting with defining MN involvement (at IP 
>>> layer). Once we get chartered (hopefully), we can have a 
>>> discussion on the topic as part of Inter-tech handovers and 
>>> arrive at consensus. 
>>>
>>>       
>>>>> But, the starting point is not "we need MN involvement".  
>>>>>           
>>>> I would just like the term "MN involvement" to include the 
>>>> link layer extensions as well. Otherwise we're sweeping the 
>>>> problem under the rug.
>>>>
>>>>         
>>> Sure. One thing we can do is to clearly list where MN 
>>> participation is necessary.
>>> Whether this would be done by L2 or IP is another thing. 
>>>
>>> Thanks,
>>>
>>> -Rajeev
>>>
>>>
>>>       
>>>> domagoj
>>>>
>>>>
>>>>         
>>>>> -----Original Message-----
>>>>> From: netext-bounces at mail.mobileip.jp 
>>>>> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of 
>>>>>           
>> ext Koodli, 
>>     
>>>>> Rajeev
>>>>> Sent: 26. veljaca 2009 19:38
>>>>> To: netext at mail.mobileip.jp
>>>>> Subject: Re: [Netext] Inter-technology handover PS
>>>>>
>>>>>
>>>>>  
>>>>> Hi Domagoj,
>>>>>
>>>>>
>>>>>           
>>>>>> Using access specific mechanims is fine for the cases where
>>>>>>             
>>>>> the access
>>>>>           
>>>>>> system actually provides the needed functionality.
>>>>>>             
>>>>> Good. My reasoning is that if there is a functionality which is 
>>>>> crucial to an access system, it will provide it. We defining a 
>>>>> mechanism at IP layer, which I would prefer as well, will 
>>>>>           
>>>> turn out to 
>>>>         
>>>>> be redundant and ignored.
>>>>>
>>>>>
>>>>>           
>>>>>> I don't think that we can expect every access system 
>>>>>>             
>> to readily 
>>     
>>>>>> support whatever is needed by PMIP6 (WiMAX being one
>>>>>>             
>>>>> example of such
>>>>>           
>>>>>> access system, it doesn't provide any clue about the 
>>>>>>             
>>> HI). In such 
>>>       
>>>>>> cases it makes sense to put the additional functionality 
>>>>>>             
>>>> at the IP 
>>>>         
>>>>>> layer, i.e. at the MAG/LMA/MN as they need to be updated 
>>>>>>             
>>>> anyway to 
>>>>         
>>>>>> support inter-tech handover. Such add-on at the 
>>>>>>             
>>> IP-layer could be 
>>>       
>>>>>> reused without modifications with any access system which 
>>>>>>             
>>>> does not 
>>>>         
>>>>>> provide the appropriate L2 hints.
>>>>>>             
>>>>> How does handover work in Wimax today without indication 
>>>>>           
>>>> from the MN 
>>>>         
>>>>> at the IP layer?
>>>>>
>>>>> To be clear, I do not wish to start from a point where we 
>>>>>           
>>>> assume that 
>>>>         
>>>>> MN involvement at the IP layer is necessary; at least for 
>>>>>           
>>> this BOF. 
>>>       
>>>>> The focus of this effort is to identify the problems which 
>>>>>           
>>>> need to be 
>>>>         
>>>>> solved. During the process, we can list what works and what 
>>>>>           
>>>> doesn't as 
>>>>         
>>>>> it is, without MN involvement; it needs to be done thoroughly.
>>>>> But, the starting point is not "we need MN involvement". 
>>>>>
>>>>> -Rajeev
>>>>>
>>>>>
>>>>>
>>>>>           
>>>>>> domagoj
>>>>>>
>>>>>>             
>>>>>>> -----Original Message-----
>>>>>>> From: netext-bounces at mail.mobileip.jp 
>>>>>>> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of 
>>>>>>>               
>>>> ext Koodli, 
>>>>         
>>>>>>> Rajeev
>>>>>>> Sent: 24. veljaca 2009 23:01
>>>>>>> To: netext at mail.mobileip.jp
>>>>>>> Subject: Re: [Netext] Inter-technology handover PS
>>>>>>>
>>>>>>>
>>>>>>> Hello folks,
>>>>>>>
>>>>>>> Few thoughts on what we may need to focus here..
>>>>>>>
>>>>>>> 1. For the purposes of this ID (i.e., inter-tech
>>>>>>>               
>>>>>> handovers), what is
>>>>>>             
>>>>>>> most relevant here? What breaks today? Or, what we can
>>>>>>>               
>>>>> improve? The
>>>>>           
>>>>>>> breakdown of issues is a good start, but we need to tie
>>>>>>>               
>>>>> it together
>>>>>           
>>>>>>> for the problem at hand - inter-tech handovers.
>>>>>>>
>>>>>>> 2. What _requires_ an IP protocol support on the MN side? 
>>>>>>> Could this be done in an access-specific way? For instance,
>>>>>>>               
>>>>>> the HI in
>>>>>>             
>>>>>>> PMIP6 is left up to the access system to determine, 
>>>>>>>               
>> based on 
>>     
>>>>>>> access-specific means where MN does take part. We 
>>>>>>>               
>>> need to ask a 
>>>       
>>>>>>> similar question here: if MN involvement is necessary, why
>>>>>>>               
>>>>>> couldn't we
>>>>>>             
>>>>>>> let an access system provide the functionality?
>>>>>>>
>>>>>>> 3. Assuming specific mechanisms (e.g., IEEE 802.21 
>>>>>>>               
>>> etc.) is not 
>>>       
>>>>>>> necessary. Folks can use whatever they want, but specifying 
>>>>>>> dependencies needs to be avoided.
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> -Rajeev
>>>>>>>  
>>>>>>>
>>>>>>>               
>>>>>>>> -----Original Message-----
>>>>>>>> From: netext-bounces at mail.mobileip.jp 
>>>>>>>> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of
>>>>>>>>                 
>>>>>>> Suresh Krishnan
>>>>>>>               
>>>>>>>> Sent: Thursday, February 19, 2009 3:19 PM
>>>>>>>> To: cjbc at it.uc3m.es
>>>>>>>> Cc: netext at mail.mobileip.jp
>>>>>>>> Subject: Re: [Netext] Inter-technology handover PS
>>>>>>>>
>>>>>>>> Hi Carlos,
>>>>>>>>    Thanks for your comments. Please find responses inline
>>>>>>>>
>>>>>>>> On 16/02/09 02:01 PM, Carlos Jes?s Bernardos Cano wrote:
>>>>>>>>                 
>>>>>>>>> * PGP Signed by an unknown key
>>>>>>>>>
>>>>>>>>> Hi Suresh,
>>>>>>>>>
>>>>>>>>> 	Thanks for the draft. I think it's 
>>>>>>>>>                   
>> short and clear. 
>>     
>>>>>>>> Some comments
>>>>>>>>                 
>>>>>>>>> below:
>>>>>>>>>
>>>>>>>>> 	- Section 2.1. Formation of interface 
>>>>>>>>>                   
>> identifier. The
>>     
>>>>>>>> issue described
>>>>>>>>                 
>>>>>>>>> there only applies if SLAAC is used, right? If DHCP is
>>>>>>>>>                   
>>>>>>>> used, the issue
>>>>>>>>                 
>>>>>>>>> is then on the network side, to ensure that the address
>>>>>>>>>                   
>>>>>>> provided to
>>>>>>>               
>>>>>>>>> the new interface of the MN is the same that it was (or
>>>>>>>>>                   
>>>>>> is still)
>>>>>>             
>>>>>>>>> using on the previous interface, right?
>>>>>>>>>                   
>>>>>>>> Yes. This is correct. I can probably add a new section on
>>>>>>>>                 
>>>>>>> the network
>>>>>>>               
>>>>>>>> side about the DHCPv6 issue
>>>>>>>>
>>>>>>>>                 
>>>>>>>>> 	- Section 2.2 Usage of the same address 
>>>>>>>>>                   
>> on multiple
>>     
>>>>>>>> interfaces. Since
>>>>>>>>                 
>>>>>>>>> it seems that we cannot assume that is safe to 
>>>>>>>>>                   
>>> use the same
>>>       
>>>>>>>> address on
>>>>>>>>                 
>>>>>>>>> multiple interfaces (without requiring changes on the MN
>>>>>>>>>                   
>>>>>>>> side), this
>>>>>>>>                 
>>>>>>>>> implies that: a) if NETEXT work is restricted to work on
>>>>>>>>>                   
>>>>>>> solutions
>>>>>>>               
>>>>>>>>> that do not impose changes on the MN, use cases 
>>>>>>>>>                   
>> requiring
>>     
>>>>>>> the MN to
>>>>>>>               
>>>>>>>>> use the same address simultaneously are out of 
>>>>>>>>>                   
>>> the scope of
>>>       
>>>>>>>> NETEXT, b)
>>>>>>>>                 
>>>>>>>>> we allow for changes on the MN side. 
>>>>>>>>>                   
>>> Additionally, it might
>>>       
>>>>>>>> be good to
>>>>>>>>                 
>>>>>>>>> analyse if it is OK for the MN to receive (and send)
>>>>>>>>>                   
>>>>>>>> traffic addressed
>>>>>>>>                 
>>>>>>>>> to the IPv6 address of one interface through a different
>>>>>>>>>                   
>>>>>>> interface
>>>>>>>               
>>>>>>>>> (weak end-system model defined in RFC 1122 or
>>>>>>>>>                   
>>>>>>>> draft-thaler-ip-model-evolution).
>>>>>>>>
>>>>>>>> While I agree with your analysis of the problem, are we
>>>>>>>>                 
>>>>>> delving too
>>>>>>             
>>>>>>>> much into the solution space by adding any such text?
>>>>>>>>
>>>>>>>>                 
>>>>>>>>> 	- IMHO, it'd be good to explicitly 
>>>>>>>>>                   
>> describe what a
>>     
>>>>>>>> "change on the MN"
>>>>>>>>                 
>>>>>>>>> within the scope of NETEXT. For example, is it fine
>>>>>>>>>                   
>>>>>> assuming IEEE
>>>>>>             
>>>>>>>>> 802.21 support on the MN or is this "a change 
>>>>>>>>>                   
>> on the MN"?
>>     
>>>>>>>> Probably something to add to the charter?
>>>>>>>>
>>>>>>>> Cheers
>>>>>>>> Suresh
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> NetExt mailing list
>>>>>>>> NetExt at mail.mobileip.jp
>>>>>>>> http://www.mobileip.jp/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 
>>>>>>> postmaster at starentnetworks.com -- and destroy all 
>>>>>>>               
>>>> copies of this 
>>>>         
>>>>>>> message and any attachments without reading or 
>>>>>>>               
>>> disclosing their 
>>>       
>>>>>>> contents. Thank you.
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> NetExt mailing list
>>>>>>> NetExt at mail.mobileip.jp
>>>>>>> http://www.mobileip.jp/mailman/listinfo/netext
>>>>>>>
>>>>>>>               
>>>>>>             
>>>>> _______________________________________________
>>>>> NetExt mailing list
>>>>> NetExt at mail.mobileip.jp
>>>>> http://www.mobileip.jp/mailman/listinfo/netext
>>>>>
>>>>>           
>>>>         
>>> _______________________________________________
>>> NetExt mailing list
>>> NetExt at mail.mobileip.jp
>>> http://www.mobileip.jp/mailman/listinfo/netext
>>>
>>>       
>>     
>
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
>   

From: xiayangsong at huawei.com (Frank Xia)
Date: Wed, 4 Mar 2009 19:52:25 -0600
Subject: [Netext] New Version Notification for draft-xia-netext-tunnel-negotiation-01
Message-ID: <[email-masked]>

Hi all

We updated the draft based on some reviews
http://www.ietf.org/internet-drafts/draft-xia-netext-tunnel-negotiation-01.txt

Comments are very welcome.

BR
Frank

----- Original Message ----- 
From: "IETF I-D Submission Tool" <idsubmission at ietf.org>
To: <xiayangsong at huawei.com>
Cc: <yokota at kddilabs.jp>; <suresh.krishnan at ericsson.com>
Sent: Wednesday, March 04, 2009 7:46 PM
Subject: New Version Notification for draft-xia-netext-tunnel-negotiation-01

>
> A new version of I-D, draft-xia-netext-tunnel-negotiation-01.txt has been 
> successfuly submitted by Frank Xia and posted to the IETF repository.
>
> Filename: draft-xia-netext-tunnel-negotiation
> Revision: 01
> Title: Tunnel Negotiation for Proxy Mobile IPv6
> Creation_date: 2009-03-05
> WG ID: Independent Submission
> Number_of_pages: 8
>
> Abstract:
> Proxy Mobile IPv6 allows a mobile node's IPv4 and IPv6 traffic
> between a Local Mobility Anchor(LMA) and a Mobile Access Gateway
> (MAG) to be tunneled using IPv6, IPv4 ,IPv4-UDP, or GRE encapsulation
> headers.  In this document, a new mobility option is specified for
> tunnel negotiation between the LMA and MAG.
>
>
>
> The IETF Secretariat.
>
> 

From: Mohana.Jeyatharan at sg.panasonic.com (Mohana Jeyatharan)
Date: Thu, 5 Mar 2009 08:25:59 +0800
Subject: [Netext] FW: I-D Action:draft-jeyatharan-netext-pmip-partial-handoff-00.txt
Message-ID: <[email-masked]>

Hi All,

We have sumitted this draft on partial handoff involving multiple
interfaces in PMIPv6. Your comments are appreciated.

BR,
Mohana
-----Original Message-----
From: i-d-announce-bounces at ietf.org
[mailto:i-d-announce-bounces at ietf.org] On Behalf Of
Internet-Drafts at ietf.org
Sent: Wednesday, March 04, 2009 2:15 PM
To: i-d-announce at ietf.org
Subject: I-D Action:draft-jeyatharan-netext-pmip-partial-handoff-00.txt 

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title           : Partial Handoff Support in PMIPv6
	Author(s)       : M. Jeyatharan, et al.
	Filename        :
draft-jeyatharan-netext-pmip-partial-handoff-00.txt
	Pages           : 17
	Date            : 2009-03-03

Proxy Mobile IPv6 (PMIPv6) only supports session continuity for one
basic scenario of vertical handoff -- the transfer of all prefixes
assigned from one interface to another.  However, there are some
other advanced scenarios associated with vertical handoff that
involves only transferring one (or some, but not all) of the prefixes
that are allocated to an existing interface to a newly powered on
interface.  This draft outlines extensions to PMIPv6 protocol in
order for a multiple interfaced mobile node to achieve such partial
vertical handoff of selected prefix(es).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-jeyatharan-netext-pmip-partial
-handoff-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: draft-jeyatharan-netext-pmip-partial-handoff-00.URL
Type: application/octet-stream
Size: 112 bytes
Desc: draft-jeyatharan-netext-pmip-partial-handoff-00.URL
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090305/9913f191/attachment.obj>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ATT3139535.txt
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090305/9913f191/attachment.txt>

From: vijay at wichorus.com (Vijay Devarapalli)
Date: Wed, 4 Mar 2009 17:23:15 -0500
Subject: [Netext] PMIPv6 Multiple Interface support
Message-ID: <[email-masked]>

Hello folks,

I updated the draft on multiple interface support for PMIPv6. It used to
be draft-devarapalli-netlmm-multihoming earlier. Comments are welcome.

Vijay 

-----Original Message-----
From: IETF I-D Submission Tool [mailto:idsubmission at ietf.org] 
Sent: Tuesday, March 03, 2009 10:02 PM
To: Vijay Devarapalli
Subject: New Version Notification for
draft-devarapalli-netext-multi-interface-support-00 

A new version of I-D,
draft-devarapalli-netext-multi-interface-support-00.txt has been
successfuly submitted by Vijay Devarapalli and posted to the IETF
repository.

Filename:	 draft-devarapalli-netext-multi-interface-support
Revision:	 00
Title:		 Multiple Interface Support with Proxy Mobile IPv6
Creation_date:	 2009-03-03
WG ID:		 Independent Submission
Number_of_pages: 14

Abstract:
Proxy Mobile IPv6 enables network-based mobility for a regular IPv6
mobile node with no mobility management protocol.  It makes it appear
to the mobile node that its IP address does not change as the mobile
node moves across the Proxy Mobile IPv6 domain.  There have been some
issues identified with supporting a host with multiple interfaces
attaching to the Proxy Mobile IPv6 domain.  This document describes
and analyzes some of the scenarios associated with this.  It also
describes the requirements for a handover across interfaces using
Proxy Mobile IPv6.

The IETF Secretariat.

From: liebsch at nw.neclab.eu (Marco Liebsch)
Date: Wed, 04 Mar 2009 17:29:19 +0100
Subject: [Netext] comments to the redirection PS
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Jouni,

please see inline for my feedback.

jouni korhonen wrote:
> Hi Marco,
>
> Thanks for the review. I have some responses inline.
>
> On Mar 4, 2009, at 1:05 PM, Marco Liebsch wrote:
>
>> Hi Jouni,
>>
>> please find some comments to the PMIPv6 Redirection PS below.
>>
>> In general, I think the redirect function is very useful.
>
> Good ;)
>
>
>> Regarding the problem statement document:
>>
>> My feeling is that the PS implies a solution. In particular I am
>> not so happy with text in section 4 about sending a PBU from a
>> MAG to one LMA but receiving the PBA from another, the
>> redirected LMA.
>
> I admit the scope gets narrow when you want a solution that is not 
> dependent of external infrastructures. Another motivation is to define 
> a support for anycast addresses. Sending a PBA to a MAG from an 
> anycast address makes little sense.
But then I think a first step is to define the scope of a solution. I'd 
rather say a
single and powerful solution is preferable to multiple tailor-made ones 
with small
scope. But if there are good reasons to specify this as extension to 
PMIPv6 for
some specific use cases, well, I am ok.

>
>
>> Even if performing the redirection with a PBU/PBA handshake
>> is motivated in the doc, I don't see a real costs issue with using
>> out of band signaling (i.e. not using PMIPv6 signaling).
>> In any case, if initial LMA assignment relies on the AAA
>> infrastructure, I don't get the point why the AAA should not
>> be involved in the redirection process?
>
> Typically AAA would return a FQDN to the MAG during the initial attach 
> and the MAG would then resolve that FQDN to a set of IP addresses. We 
> know few facts of e.g. DNS based load balancing.. like that is hard to 
> keep it up to date with load situation and MAGs may well cache IPs 
> beyond the life time of the DNS response. Therefore, you don't 
> necessarily even get a chance to "select" a new least loaded LMA for a 
> MN.
Not sure I understand, but in the procedure you describe, I think the 
AAA should
be responsible to select the right LMA. That means the FQDN is unique 
and points
to a single LMA. Referring to a different LMA means providing a 
different FQDN
as absolute address. Hence, there is nothing about load balancing in the 
DNS.

>
> Another point related to AAA is keeping the AAA server updated e.g. 
> with the load status. That potentially means the cluster of LMAs doing 
> periodic updates to a cluster of AAA servers. I really don't like that 
> approach.
Ok, maybe we focus too much on the AAA. Could be some other non-PMIPv6 
component
who's in charge of the load situation. But in the end, I think the AAA 
knows about the
MN's serving LMA.

>
>
>> In general, I don't see the redirect will happen too often. If we
>> talk about a load distribution use case, this will happen at the
>
> yes. Agree.
>
>> initial registration. I don't think an LMA will take a decision on
>> its own to refer to another LMA. If we talk about a failure handling
>> use case, well, the rfLMA may be dead already, hence, no way to
>> refer to an alternative LMA. I think the role of the backend is still 
>> important.
>
> I think there are multiple deployment options here regarding what 
> constitutes a LMA. One physical LMA may well show outside world as a 
> number of distinct LMAs. Or a LMA showing one address may well be a 
> number of distinct LMAs.
>
> I do agree with the importance of the backend. Though, it does not 
> make harm to reduce all possible extra signaling there as well. I 
> would even see that as an important topic (see deployment related 
> topics in the proposed charter).
Depends on what costs you save compared to the costs you buy and 
flexibility you
lose with other solutions.

>
>>
>> Another use case may be a "scope" motivation, hence the LMA may
>> change as the MN moves into an area, which may be assigned to
>> another (set of) LMA(s). This may be independent of the scope
>> of a PMIPv6 domain. But also here, I see the backend playing
>> a major role (AAA etc.).
>
> In a case LMA changes, yes, then a lot more needs to be done.
right.

>
>>
>>
>> What do you think about including some more use cases into the
>> PS, talking about 'why' redirection may be needed? I think
>> this could help to derive some more functional and also non-functional
>> requirements for a protocol design.
>
> Could do that. However, that would be more clarifying the existing use 
> cases of not depending on external infrastructures. I should probably 
> mention anycast somewhere ;)
well, what I meant above is that the current use case (section 4.1) may
be no use case but a high-level solution ;-) I thought about the description
of different use cases (or better scenarios?) to define the scope of the 
solution.
Without writing about who's sending which signaling where.
That helps to write design goals or requirements, which again help to 
design the
protocol solution. But that's my personal opinion.

Cheers,
marco

>
> Cheers,
> Jouni
>
>
>>
>>
>> marco
>>
>>
>>
>

From: desire.oulai at ericsson.com (Desire Oulai)
Date: Wed, 4 Mar 2009 11:28:40 -0500
Subject: [Netext] FW: New Version Notification for draft-oulai-netext-opt-local-routing-00
Message-ID: <[email-masked]>

Hi all,

  We have submitted an ID on Local Routing. It proposes a Local Routing
initiation method and fast handover mechanisms for PMIPv6 Local Routing.

Thanks for your comments!

Regards

Desire

> -----Original Message-----
> From: IETF I-D Submission Tool [mailto:idsubmission at ietf.org]
> Sent: March 4, 2009 10:57 AM
> To: Desire Oulai
> Cc: Suresh Krishnan
> Subject: New Version Notification for 
> draft-oulai-netext-opt-local-routing-00
> 
> 
> A new version of I-D,
> draft-oulai-netext-opt-local-routing-00.txt has been successfuly 
> submitted by Desire Oulai and posted to the IETF repository.
> 
> Filename:	 draft-oulai-netext-opt-local-routing
> Revision:	 00
> Title:		 Optimized Local Routing for PMIPv6
> Creation_date:	 2009-03-04
> WG ID:		 Independent Submission
> Number_of_pages: 19
> 
> Abstract:
> Base Proxy Mobile IPv6 requires all communications to go through the 
> local mobility anchor.  As this can be suboptimal, local routing has 
> been defined to allow mobile nodes attached to the same or different 
> mobile access gateways to exchange traffic by using local forwarding 
> or a direct tunnel between the gateways.  This document proposes an 
> initiation method and fast handover mechanisms for local routing.
> The solutions aim at reducing handover delay and packet loss.
>                                                               
>                     
> 
> 
> The IETF Secretariat.
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090304/9fca0a36/attachment.html>

From: jouni.nospam at gmail.com (jouni korhonen)
Date: Wed, 4 Mar 2009 13:54:32 +0200
Subject: [Netext] comments to the redirection PS
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi Marco,

Thanks for the review. I have some responses inline.

On Mar 4, 2009, at 1:05 PM, Marco Liebsch wrote:

> Hi Jouni,
>
> please find some comments to the PMIPv6 Redirection PS below.
>
> In general, I think the redirect function is very useful.

Good ;)

> Regarding the problem statement document:
>
> My feeling is that the PS implies a solution. In particular I am
> not so happy with text in section 4 about sending a PBU from a
> MAG to one LMA but receiving the PBA from another, the
> redirected LMA.

I admit the scope gets narrow when you want a solution that is not  
dependent of external infrastructures. Another motivation is to define  
a support for anycast addresses. Sending a PBA to a MAG from an  
anycast address makes little sense.

> Even if performing the redirection with a PBU/PBA handshake
> is motivated in the doc, I don't see a real costs issue with using
> out of band signaling (i.e. not using PMIPv6 signaling).
> In any case, if initial LMA assignment relies on the AAA
> infrastructure, I don't get the point why the AAA should not
> be involved in the redirection process?

Typically AAA would return a FQDN to the MAG during the initial attach  
and the MAG would then resolve that FQDN to a set of IP addresses. We  
know few facts of e.g. DNS based load balancing.. like that is hard to  
keep it up to date with load situation and MAGs may well cache IPs  
beyond the life time of the DNS response. Therefore, you don't  
necessarily even get a chance to "select" a new least loaded LMA for a  
MN.

Another point related to AAA is keeping the AAA server updated e.g.  
with the load status. That potentially means the cluster of LMAs doing  
periodic updates to a cluster of AAA servers. I really don't like that  
approach.

> In general, I don't see the redirect will happen too often. If we
> talk about a load distribution use case, this will happen at the

yes. Agree.

> initial registration. I don't think an LMA will take a decision on
> its own to refer to another LMA. If we talk about a failure handling
> use case, well, the rfLMA may be dead already, hence, no way to
> refer to an alternative LMA. I think the role of the backend is  
> still important.

I think there are multiple deployment options here regarding what  
constitutes a LMA. One physical LMA may well show outside world as a  
number of distinct LMAs. Or a LMA showing one address may well be a  
number of distinct LMAs.

I do agree with the importance of the backend. Though, it does not  
make harm to reduce all possible extra signaling there as well. I  
would even see that as an important topic (see deployment related  
topics in the proposed charter).

>
> Another use case may be a "scope" motivation, hence the LMA may
> change as the MN moves into an area, which may be assigned to
> another (set of) LMA(s). This may be independent of the scope
> of a PMIPv6 domain. But also here, I see the backend playing
> a major role (AAA etc.).

In a case LMA changes, yes, then a lot more needs to be done.

>
>
> What do you think about including some more use cases into the
> PS, talking about 'why' redirection may be needed? I think
> this could help to derive some more functional and also non-functional
> requirements for a protocol design.

Could do that. However, that would be more clarifying the existing use  
cases of not depending on external infrastructures. I should probably  
mention anycast somewhere ;)

Cheers,
	Jouni

>
>
> marco
>
>
>

From: liebsch at nw.neclab.eu (Marco Liebsch)
Date: Wed, 04 Mar 2009 12:05:21 +0100
Subject: [Netext] comments to the redirection PS
Message-ID: <[email-masked]>

Hi Jouni,

please find some comments to the PMIPv6 Redirection PS below.

In general, I think the redirect function is very useful.

Regarding the problem statement document:

My feeling is that the PS implies a solution. In particular I am
not so happy with text in section 4 about sending a PBU from a
MAG to one LMA but receiving the PBA from another, the
redirected LMA.

Even if performing the redirection with a PBU/PBA handshake
is motivated in the doc, I don't see a real costs issue with using
out of band signaling (i.e. not using PMIPv6 signaling).
In any case, if initial LMA assignment relies on the AAA
infrastructure, I don't get the point why the AAA should not
be involved in the redirection process?

In general, I don't see the redirect will happen too often. If we
talk about a load distribution use case, this will happen at the
initial registration. I don't think an LMA will take a decision on
its own to refer to another LMA. If we talk about a failure handling
use case, well, the rfLMA may be dead already, hence, no way to
refer to an alternative LMA. I think the role of the backend is still 
important.

Another use case may be a "scope" motivation, hence the LMA may
change as the MN moves into an area, which may be assigned to
another (set of) LMA(s). This may be independent of the scope
of a PMIPv6 domain. But also here, I see the backend playing
a major role (AAA etc.).

What do you think about including some more use cases into the
PS, talking about 'why' redirection may be needed? I think
this could help to derive some more functional and also non-functional
requirements for a protocol design.

marco

From: sunseawq at huawei.com (Qin Wu)
Date: Wed, 04 Mar 2009 17:29:54 +0800
Subject: [Netext] New Version Notification for draft-wu-netext-local-ro-00
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi,all:
We have just submitted a draft on
"Proxy MIP extension for local routing optimization"
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-wu-netext-local-ro-00.txt
Your comments are welcome!

-Qin
----- Original Message ----- 
From: "IETF I-D Submission Tool" <idsubmission at ietf.org>
To: <sunseawq at huawei.com>
Cc: <sunseawq at huawei.com>; <sarikaya at ieee.org>
Sent: Wednesday, March 04, 2009 5:14 PM
Subject: New Version Notification for draft-wu-netext-local-ro-00

> 
> A new version of I-D, draft-wu-netext-local-ro-00.txt has been successfuly submitted by Wenson Wu and posted to the IETF repository.
> 
> Filename: draft-wu-netext-local-ro
> Revision: 00
> Title: Proxy MIP extension for local routing optimization
> Creation_date: 2009-03-04
> WG ID: Independent Submission
> Number_of_pages: 17
> 
> Abstract:
> Proxy Mobile IPv6 allows the Mobility Access Gateway (MAG) to 
> optimize the media delivery by locally routing the packets within one 
> MAG, However it does not support optimization of the media delivery 
> by locally routing the packets between MAGs sharing the same LMA. 
> This document specifies extensions for Proxy MIP to support local 
> routing optimization through the interaction between the MAG and the 
> LMA.
>                                                                                  
> 
> 
> The IETF Secretariat.
> 
>

From: xiayangsong at huawei.com (Frank Xia)
Date: Tue, 03 Mar 2009 14:34:43 -0600
Subject: [Netext] Flow Binding in Proxy Mobile IPv6 (Frank Xia)
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi Joy

Thank you for your valuable review!

I aslo received the similar question from Pierrick in offlist discussion.

In multihoming scenario, there are several addressing models as following,
and this draft is not limited to any of these:
1) Different interfaces have different addresses.

  These two layers encapuslation is needed. I assume mobile node
  is a normal IPv6 node which is equiped with capability to deal with
  IP-in-IP encapsulation.  

  Anyway, we should define mobile node capability, or there is no 
  any foundation to discuss.  IMO, Multiple Interfaces BOF (MIF)
 (http://trac.tools.ietf.org/bof/trac/wiki)
  is trying.

2)Different interfaces share the same address.
  No additional encapsulation is required.

BR
Frank
  ----- Original Message ----- 
  From: zhou.xingyue at zte.com.cn 
  To: xiayangsong at huawei.com 
  Cc: netext at mail.mobileip.jp 
  Sent: Monday, March 02, 2009 8:19 PM
  Subject: Re:Flow Binding in Proxy Mobile IPv6 (Frank Xia)

  Hi Frank, 
  According to the description of in section 4, all the offloaded packets with SIP as destination are redirected to the TMAG by the LMA which have had two layer encapsulations after the procedure in step 10, and then the TMAG strips the outer layer encapsulation and forwards the packets to the MN. 
  That means the MN MUST have capability to process the packets with outer header which has with SIP as the destination address. 
  It seems not proper to require the MN to be able to deal with the encapsulated packets. 
  Is there some more information about it in detail? 

  Best wishes. 

  Joy 
  ---------------------------------------------------------------------- 
  Send NetExt mailing list submissions to
                  netext at mail.mobileip.jp

  To subscribe or unsubscribe via the World Wide Web, visit
                  http://www.mobileip.jp/mailman/listinfo/netext
  or, via email, send a message with subject or body 'help' to
                  netext-request at mail.mobileip.jp

  You can reach the person managing the list at
                  netext-owner at mail.mobileip.jp

  When replying, please edit your Subject line so it is more specific
  than "Re: Contents of NetExt digest..."

  Today's Topics:

    1.  Flow Binding in Proxy Mobile IPv6 (Frank Xia)

  ----------------------------------------------------------------------

  Message: 1
  Date: Wed, 18 Feb 2009 20:00:22 -0600
  From: "Frank Xia" <xiayangsong at huawei.com>
  Subject: [Netext]  Flow Binding in Proxy Mobile IPv6
  To: <netext at mail.mobileip.jp>
  Message-ID: <004a01c99235$d50730b0$0401a8c0 at china.huawei.com>
  Content-Type: text/plain; charset="gb2312"

  Hi Folks

  I have drafted the document. Comments are welcome!
  http://www.ietf.org/internet-drafts/draft-xia-netext-flow-binding-00.txt.

  Abstract
   This document introduces extensions to Proxy
   Mobile IPv6 that allows networks dynamically 
   binding 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090303/c1c88ef0/attachment.html>

From: jouni.nospam at gmail.com (jouni korhonen)
Date: Tue, 3 Mar 2009 12:08:46 +0200
Subject: [Netext] Redirection Problem Statement
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Bechet,

On Feb 27, 2009, at 7:45 PM, Behcet Sarikaya wrote:

> Hi Jouni,
>   My comments inline.
>
> Regards,
>
> --behcet
>
> From: jouni korhonen <jouni.nospam at gmail.com>
> To: Behcet Sarikaya <sarikaya at ieee.org>
> Cc: netext at mail.mobileip.jp
> Sent: Friday, February 27, 2009 6:49:24 AM
> Subject: Re: [Netext] Redirection Problem Statement
>
>
> Hi Bechet,
>
> On Feb 26, 2009, at 5:21 PM, Behcet Sarikaya wrote:
>
> > Hi Jouni,
> >  Have you read HA Reliability draft:
> > http://tools.ietf.org/html/draft-ietf-mip6-hareliability-04
> > Ryuji and I discussed a couple of times issuing PMIPv6 version of  
> HA Reliability. He seems to be too busy these days to do that.
> >  I think PMIPv6 HA Or LMA reliability solves the problem you  
> described.
>
> Yes, I have read the I-D.. but not the latest revision though. The I- 
> D contains functionality that could be usable for the redirection of  
> the established mobility session, not really for the initial  
> attachment time redirection.
> [behcet] Initial attachment time redirection would not be in the  
> scope of LMA reliability so yes you are right.
> However I would question such a problem because AAA can easily solve  
> it, I think.

The PS document seeks for solutions that would not be dependent on  
external infrastructures such as AAA.

Cheers,
	Jouni

>
>
> Cheers,
>     Jouni
>
>
> >
> > Regards,
> >
> > Behcet
> >
> > From: jouni korhonen <jouni.nospam at gmail.com>
> > To: netext at mail.mobileip.jp
> > Sent: Thursday, February 26, 2009 3:51:51 AM
> > Subject: [Netext] Redirection Problem Statement
> >
> > Hi all,
> >
> > It seems my previous mail went to void or something. This short PS  
> document discusses about redirection functionality for the PMIP6  
> base protocol that could be part of the PBU/PBA exchange. There are  
> obvious use cases for the redirection such as load balancing, LMA  
> maintenance and signaling reduction within a PMIPv6 domain (during  
> redirection or moving MNs under other LMAs). The problem scope falls  
> under the improvements and/or deployment considerations in the  
> current proposed charter.
> >
> > The document is available here:
> > http://www.ietf.org/internet-drafts/draft-korhonen-netext-redirect-ps-00.txt
> >
> > Comments are welcome.
> >
> > Cheers,
> >    Jouni
> > _______________________________________________
> > NetExt mailing list
> > NetExt at mail.mobileip.jp
> > http://www.mobileip.jp/mailman/listinfo/netext
> >
> >
>
>
>

From: cjbc at it.uc3m.es (Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano)
Date: Tue, 03 Mar 2009 09:13:12 +0100
Subject: [Netext] Inter-technology handovers PS considering Multihoming	PS and Localized Routing PS
In-Reply-To: <[email-masked]>
References: <[email-masked]> <1235994124.5456.37.camel@localhost> <[email-masked]>
Message-ID: <1236067992.4950.7.camel@localhost>

Hi David,

	Thanks for your answers. Some comments inline below.

El lun, 02-03-2009 a las 12:43 -0500, David Cypher escribi?:
> Carlos,
> 
>     Thanks for your comments and questions.  I 
> hope that my answers are acceptable.
> 
> At 06:42 AM 3/2/2009, Carlos Jes?s Bernardos Cano wrote:
> >Hi David,
> >
> >         Two quick questions/comments:
> >
> >         - do you think multihoming only deals with configuring the same
> >address on different interfaces of the MN? I don't this has to be
> >necessarily the case.
> 
> I do not believe that multihoming in the general 
> sense only deals with same address on different interfaces.
> However here is what I based it on directly from RFC 5213.
> 
> For PMIP the definition of mulihoming support is given in 5.4
> 5.4.  Multihoming Support
> 
> "   This specification allows mobile nodes to connect to a Proxy Mobile
>     IPv6 domain through multiple interfaces for simultaneous access.  The
>     following are the key aspects of this multihoming support.
> 
>     o  When a mobile node connects to a Proxy Mobile IPv6 domain through
>        multiple interfaces for simultaneous access, the local mobility
>        anchor MUST allocate a mobility session for each of the attached
>        interfaces.  Each mobility session should be managed under a
>        separate Binding Cache entry and with its own lifetime.
> 
>     o  The local mobility anchor MAY allocate more than one home network
>        prefix for a given interface of the mobile node.  However, all the
>        prefixes associated with a given interface MUST be managed as part
>        of one mobility session, associated with that interface.
> 
>     o  The local mobility anchor MUST allow for a handoff between two
>        different interfaces of a mobile node.  In such a scenario, all
>        the home network prefixes associated with one interface (part of
>        one mobility session) will be associated with a different
>        interface of the mobile node.  The decision on when to create a
>        new mobility session and when to update an existing mobility
>        session MUST be based on the Handover hint present in the Proxy
>        Binding Update message and under the considerations specified in
>        this section. "
> 
> The first bullet implies multiple interfaces with different prefixes.
> The last bullet implies same prefix on different interfaces.
> 
> So out of these three bullet items, which cannot be handled "today" by PMIP?
> If they are all handled, then instead of fixing 
> an existing problem, the NETEXT multihoming PS is asking for new services.

Well, I think PMIPv6 is missing the functionality of controlling
multiple interfaces with a single mobility session, for example.

> 
> Another document that I have read on multihoming 
> is draft-ieft-monami6-mipv6-analysis-05 (now expired)
> 
> 
> >         - in local routing, not sure if the optimization would have to
> >consider which is the best interface of the MN to achieve the shortest
> >path. This would require involving the MN, and I'd prefer involving only
> >the network there.
> So if I understand your point, the Network would 
> make the entire determination of which 
> interface(s) to provide route optimization 
> for.  In what manner would this be done?  For 
> every route?  For selective routes?  If so, what 
> would be the criteria?  If the goal is to not 
> involve the mobile node as the original PMIP 
> design, then as a network under what network ONLY 
> criteria would be used to justify route optimization?
> It seems to me that the criteria is the 
> application that the mobile node is using, but 
> since we do not involve the mobile node how can 
> the network know that something should be route optimized?

My point is that the "end-points" of route optimisation should be MAGs
and LMAs, that is, without even considering which are the interfaces
used by the MNs. This would be a simpler scenario that would avoid the
involvement of the MN. Future work might include the MN and the
considerations about the interfaces. I think for now netext is only
aiming at working on local routing, not on route optimisation as we
understand it in MIPv6.

Thanks,

Carlos

> 
> David Cypher
> 
> >         Kind Regards,
> >
> >         Carlos
> >
> >El jue, 26-02-2009 a las 11:20 -0500, David Cypher escribi?:
> > > Taking a look at the other two problem statements in terms of
> > > existing services and new services,
> > > I do not think that any of the three problem statements can really be
> > > addressed in isolation.
> > >
> > > Multihoming Problem Statement
> > > Mobile node should be able to have more than one interface to the network
> > > - same access technology interfaces
> > >       i) same IPv6 address    (not supported in RFC 5213)
> > >       ii) different IPv6 address (supported)
> > > - different access technology interfaces
> > >       i) same IPv6 address    (supported but 
> > only for handover (temporarily))
> > >       ii) different IPv6 address      (supported)
> > >
> > > NEW SERVICE being requested
> > > - A) the ability to have the same IPv6 address on more than one
> > > interface (whether the access technology is the same or different)
> > > for a long period of time (i.e., not part of a handover/handoff).
> > >
> > >
> > > Route optimization (RO) Problem statement
> > > NEW SERVICES being requested
> > > - A ) the ability to discover if a route between MN(MAG) and CN is
> > > better than the existing route between MN (LMA) and CN and
> > > - B) the ability to use the route if found.
> > >
> > > What interface will be used to find this optimized route if multiple
> > > accesses exist and multihoming is truly provided?
> > > All of them?  One of them?  Which one?  Will there be a primary
> > > access interface or MN-HNP needed?
> > >
> > >
> > > SUMMARY of the three problem statements
> > > ======================================
> > > Inter-technology and multihoming problem statements appear to be
> > > interrelated.  Inter-technology (2.2) claims that there are problems
> > > with mobile nodes' operating systems that do not permit multihoming
> > > (same address on multiple interfaces), which is what the Multihoming
> > > Problem statement is wanting.
> > >
> > > Inter-technology PS 3.2 needs to be able to distinguish between
> > > handover and multiple interfaces.  This is another issue related to
> > > Multihoming (multiple interfaces)
> > >
> > > Cannot look at inter-technology and multihoming as separate problem
> > > statements.  Instead perhaps the problem statements should be written
> > > from a NEW SERVICE being requested.
> > >
> > > Cannot look at route optimization and multihoming as separate
> > > problems since the route optimized is dependent upon the attachment
> > > point and the address used for that attachment.
> > >
> > > For example from the original PMIP the services were
> > > - to supply the mobile node with a single set of MN-HNPs as it moved
> > > throughout the PMIP domain while maintaining only one active
> > > interface at a time or temporarily two during a handover.  (a single
> > > set of MN-HNPs for all of the mobile node's interfaces provided only
> > > one interface active at a time and used for handover only between two
> > > interfaces)
> > > - to supply the mobile node with a single set of MN-HNPs per
> > > interface, if more than one interface was attached to the PMIP
> > > domain. (a different set of MN-HNPs for each interface)
> > >
> > >
> > > SUMMARY of new services:
> > > =============================================
> > > The NEW SERVICES being requested by the three PSs are:
> > > - multiple interfaces active at the same time and not part of handover
> > >       i) using the same MN-HNPs
> > >       ii) using different MN-HNPs
> > > - a method for determining which service(s) the mobile node wants
> > > - a method for determining the mobile node's intended usage of the
> > > multiple connections
> > > - a method for determining the mobile node's capabilities to support
> > > PMIP services.
> > > - the ability to discover if a route between MN(MAG) (on which
> > > interface) and CN is better than the existing route between MN (LMA)
> > > (on which interface) and CN and
> > > - the ability to use the route if found.
> > >
> > > David Cypher
> > >
> > >
> > > _______________________________________________
> > > NetExt mailing list
> > > NetExt at mail.mobileip.jp
> > > http://www.mobileip.jp/mailman/listinfo/netext
> >--
> >  Carlos Jes?s Bernardos Cano     http://www.netcoms.net
> >  GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
> >++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >   WEEDEV 2009: 2nd Workshop on Experimental Evaluation and
> >         Deployment Experiences on Vehicular networks
> >                   http://www.weedev.org/
> >++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 
> 
-- 
 Carlos Jes?s Bernardos Cano     http://www.netcoms.net
 GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  WEEDEV 2009: 2nd Workshop on Experimental Evaluation and
        Deployment Experiences on Vehicular networks
                  http://www.weedev.org/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Esta parte del mensaje est? firmada	digitalmente
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090303/4f452378/attachment.bin>

From: zhou.xingyue at zte.com.cn (zhou.xingyue at zte.com.cn)
Date: Tue, 3 Mar 2009 10:19:28 +0800
Subject: [Netext] Flow Binding in Proxy Mobile IPv6 (Frank Xia)
Message-ID: <[email-masked]>

Hi Frank,
According to the description of in section 4, all the offloaded packets 
with SIP as destination are redirected to the TMAG by the LMA which have 
had two layer encapsulations after the procedure in step 10, and then the 
TMAG strips the outer layer encapsulation and forwards the packets to the 
MN. 
That means the MN MUST have capability to process the packets with outer 
header which has with SIP as the destination address.
It seems not proper to require the MN to be able to deal with the 
encapsulated packets.
Is there some more information about it in detail?

Best wishes.

Joy
----------------------------------------------------------------------
Send NetExt mailing list submissions to
                 netext at mail.mobileip.jp

To subscribe or unsubscribe via the World Wide Web, visit
                 http://www.mobileip.jp/mailman/listinfo/netext
or, via email, send a message with subject or body 'help' to
                 netext-request at mail.mobileip.jp

You can reach the person managing the list at
                 netext-owner at mail.mobileip.jp

When replying, please edit your Subject line so it is more specific
than "Re: Contents of NetExt digest..."

Today's Topics:

   1.  Flow Binding in Proxy Mobile IPv6 (Frank Xia)

----------------------------------------------------------------------

Message: 1
Date: Wed, 18 Feb 2009 20:00:22 -0600
From: "Frank Xia" <xiayangsong at huawei.com>
Subject: [Netext]  Flow Binding in Proxy Mobile IPv6
To: <netext at mail.mobileip.jp>
Message-ID: <004a01c99235$d50730b0$0401a8c0 at china.huawei.com>
Content-Type: text/plain; charset="gb2312"

Hi Folks

I have drafted the document. Comments are welcome!
http://www.ietf.org/internet-drafts/draft-xia-netext-flow-binding-00.txt.

Abstract
  This document introduces extensions to Proxy
  Mobile IPv6 that allows networks dynamically 
  binding 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090303/a94d6c65/attachment-0001.html>

From: david.cypher at nist.gov (David Cypher)
Date: Mon, 02 Mar 2009 12:43:59 -0500
Subject: [Netext] Inter-technology handovers PS considering Multihoming PS and Localized Routing PS
In-Reply-To: <1235994124.5456.37.camel@localhost>
References: <[email-masked]> <1235994124.5456.37.camel@localhost>
Message-ID: <[email-masked]>

Carlos,

    Thanks for your comments and questions.  I 
hope that my answers are acceptable.

At 06:42 AM 3/2/2009, Carlos Jes?s Bernardos Cano wrote:
>Hi David,
>
>         Two quick questions/comments:
>
>         - do you think multihoming only deals with configuring the same
>address on different interfaces of the MN? I don't this has to be
>necessarily the case.

I do not believe that multihoming in the general 
sense only deals with same address on different interfaces.
However here is what I based it on directly from RFC 5213.

For PMIP the definition of mulihoming support is given in 5.4
5.4.  Multihoming Support

"   This specification allows mobile nodes to connect to a Proxy Mobile
    IPv6 domain through multiple interfaces for simultaneous access.  The
    following are the key aspects of this multihoming support.

    o  When a mobile node connects to a Proxy Mobile IPv6 domain through
       multiple interfaces for simultaneous access, the local mobility
       anchor MUST allocate a mobility session for each of the attached
       interfaces.  Each mobility session should be managed under a
       separate Binding Cache entry and with its own lifetime.

    o  The local mobility anchor MAY allocate more than one home network
       prefix for a given interface of the mobile node.  However, all the
       prefixes associated with a given interface MUST be managed as part
       of one mobility session, associated with that interface.

    o  The local mobility anchor MUST allow for a handoff between two
       different interfaces of a mobile node.  In such a scenario, all
       the home network prefixes associated with one interface (part of
       one mobility session) will be associated with a different
       interface of the mobile node.  The decision on when to create a
       new mobility session and when to update an existing mobility
       session MUST be based on the Handover hint present in the Proxy
       Binding Update message and under the considerations specified in
       this section. "

The first bullet implies multiple interfaces with different prefixes.
The last bullet implies same prefix on different interfaces.

So out of these three bullet items, which cannot be handled "today" by PMIP?
If they are all handled, then instead of fixing 
an existing problem, the NETEXT multihoming PS is asking for new services.

Another document that I have read on multihoming 
is draft-ieft-monami6-mipv6-analysis-05 (now expired)

>         - in local routing, not sure if the optimization would have to
>consider which is the best interface of the MN to achieve the shortest
>path. This would require involving the MN, and I'd prefer involving only
>the network there.
So if I understand your point, the Network would 
make the entire determination of which 
interface(s) to provide route optimization 
for.  In what manner would this be done?  For 
every route?  For selective routes?  If so, what 
would be the criteria?  If the goal is to not 
involve the mobile node as the original PMIP 
design, then as a network under what network ONLY 
criteria would be used to justify route optimization?
It seems to me that the criteria is the 
application that the mobile node is using, but 
since we do not involve the mobile node how can 
the network know that something should be route optimized?

David Cypher

>         Kind Regards,
>
>         Carlos
>
>El jue, 26-02-2009 a las 11:20 -0500, David Cypher escribi?:
> > Taking a look at the other two problem statements in terms of
> > existing services and new services,
> > I do not think that any of the three problem statements can really be
> > addressed in isolation.
> >
> > Multihoming Problem Statement
> > Mobile node should be able to have more than one interface to the network
> > - same access technology interfaces
> >       i) same IPv6 address    (not supported in RFC 5213)
> >       ii) different IPv6 address (supported)
> > - different access technology interfaces
> >       i) same IPv6 address    (supported but 
> only for handover (temporarily))
> >       ii) different IPv6 address      (supported)
> >
> > NEW SERVICE being requested
> > - A) the ability to have the same IPv6 address on more than one
> > interface (whether the access technology is the same or different)
> > for a long period of time (i.e., not part of a handover/handoff).
> >
> >
> > Route optimization (RO) Problem statement
> > NEW SERVICES being requested
> > - A ) the ability to discover if a route between MN(MAG) and CN is
> > better than the existing route between MN (LMA) and CN and
> > - B) the ability to use the route if found.
> >
> > What interface will be used to find this optimized route if multiple
> > accesses exist and multihoming is truly provided?
> > All of them?  One of them?  Which one?  Will there be a primary
> > access interface or MN-HNP needed?
> >
> >
> > SUMMARY of the three problem statements
> > ======================================
> > Inter-technology and multihoming problem statements appear to be
> > interrelated.  Inter-technology (2.2) claims that there are problems
> > with mobile nodes' operating systems that do not permit multihoming
> > (same address on multiple interfaces), which is what the Multihoming
> > Problem statement is wanting.
> >
> > Inter-technology PS 3.2 needs to be able to distinguish between
> > handover and multiple interfaces.  This is another issue related to
> > Multihoming (multiple interfaces)
> >
> > Cannot look at inter-technology and multihoming as separate problem
> > statements.  Instead perhaps the problem statements should be written
> > from a NEW SERVICE being requested.
> >
> > Cannot look at route optimization and multihoming as separate
> > problems since the route optimized is dependent upon the attachment
> > point and the address used for that attachment.
> >
> > For example from the original PMIP the services were
> > - to supply the mobile node with a single set of MN-HNPs as it moved
> > throughout the PMIP domain while maintaining only one active
> > interface at a time or temporarily two during a handover.  (a single
> > set of MN-HNPs for all of the mobile node's interfaces provided only
> > one interface active at a time and used for handover only between two
> > interfaces)
> > - to supply the mobile node with a single set of MN-HNPs per
> > interface, if more than one interface was attached to the PMIP
> > domain. (a different set of MN-HNPs for each interface)
> >
> >
> > SUMMARY of new services:
> > =============================================
> > The NEW SERVICES being requested by the three PSs are:
> > - multiple interfaces active at the same time and not part of handover
> >       i) using the same MN-HNPs
> >       ii) using different MN-HNPs
> > - a method for determining which service(s) the mobile node wants
> > - a method for determining the mobile node's intended usage of the
> > multiple connections
> > - a method for determining the mobile node's capabilities to support
> > PMIP services.
> > - the ability to discover if a route between MN(MAG) (on which
> > interface) and CN is better than the existing route between MN (LMA)
> > (on which interface) and CN and
> > - the ability to use the route if found.
> >
> > David Cypher
> >
> >
> > _______________________________________________
> > NetExt mailing list
> > NetExt at mail.mobileip.jp
> > http://www.mobileip.jp/mailman/listinfo/netext
>--
>  Carlos Jes?s Bernardos Cano     http://www.netcoms.net
>  GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>   WEEDEV 2009: 2nd Workshop on Experimental Evaluation and
>         Deployment Experiences on Vehicular networks
>                   http://www.weedev.org/
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

From: rkoodli at starentnetworks.com (Koodli, Rajeev)
Date: Mon, 2 Mar 2009 11:23:22 -0500
Subject: [Netext] Inter-technology handover PS
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Hi Domagoj,

> WiMAX Forum is working on enabling the WiMAX-WiFi 
> interworking and one of the requirements for WiFi interworking says:
> 
> "Network based IP mobility SHALL be supported for the purpose 
> of interworking."
> 
> so we shouldn't exclude the WiFi access when considering 
> possible deployments.
> 

Yes, we should not rule out WiFi. At the same time, I am not sure if it serves as the best example scenario for our purpose here.

I think the way forward should be a) to identify where MN involvement may be necessary, if any, and b) discuss where (i.e., access technology, IP) such participation (if any) is best done.

Regards,

-Rajeev

> domagoj
> 
> 
> > -----Original Message-----
> > From: netext-bounces at mail.mobileip.jp 
> > [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext Koodli, 
> > Rajeev
> > Sent: 27. veljaca 2009 17:38
> > To: netext at mail.mobileip.jp
> > Subject: Re: [Netext] Inter-technology handover PS
> > 
> > 
> >  
> > 
> > Hi Domagoj,
> > 
> > > Extending the access system signaling may not be always
> > possible and
> > > in such cases the IP layer mechanism would get used. 
> > Considering the
> > > already deployed WiFi equipement as an example, even if 
> the 802.11 
> > > would be extended to provide support for PMIP6 hints, is it
> > realistic
> > > to expect the existing APs to be upgraded?
> > 
> > WiFi is not a good example here IMHO. One of the emphasis 
> in NetExt is 
> > to consider possible deployment scenarios. So, either a candidate 
> > access deployment already has or willing to define the necessary 
> > extensions or expresses need to have an IP-based mechanism.
> > 
> > > 
> > > > How does handover work in Wimax today without indication
> > > from the MN
> > > > at the IP layer?
> > > 
> > > Curretnly it doesn't work (the inter-tech HO), this is an
> > open issue. 
> > > Link layer extensions are not an option as the
> > > .16 version upon which the NWG Rel
> > > 1.5 is based is closed for changes.
> > > 
> > 
> > Good to know. We will need further discussion to go over this.
> > 
> > > > 
> > > > To be clear, I do not wish to start from a point where 
> we assume 
> > > > that MN involvement at the IP layer is necessary;
> > at least for this BOF.
> > > 
> > > Is MN involvement at the link layer less of a concern then the MN 
> > > involvement at the IP layer? It should not be.
> > 
> > Yes, it is less of a concern for _this BOF_ because this 
> BoF is about 
> > working on some problems related to network-based mobility 
> where we do 
> > not want to start from making changes to the MN. As I 
> mentioned in my 
> > e-mail, defining an IP layer mechanism which an access 
> system already 
> > has or will define will be redundant and ignored.
> > 
> > 
> > > Ideally, the MN is not involved at all at any layer. My 
> > > thinking is that, if it must be involved, it makes sense to 
> > > address those changes at the IP layer - once and for all.
> > > 
> > 
> > As a general design guideline yes. It's not easy for this BOF.
> > 
> > 
> > > > The focus of this effort is to identify the problems 
> > which need to be 
> > > > solved. During the process, we can list what works and 
> > what doesn't as 
> > > > it is, without MN involvement; it needs to be done thoroughly.
> > > 
> > > ok, let's try to see first what scenarios can be addressed 
> > > without the MN involvement.
> > > 
> > 
> > Good. I want to start with the clear understanding that we 
> > are _not_ starting with defining MN involvement (at IP 
> > layer). Once we get chartered (hopefully), we can have a 
> > discussion on the topic as part of Inter-tech handovers and 
> > arrive at consensus. 
> > 
> > > > But, the starting point is not "we need MN involvement".  
> > > 
> > > I would just like the term "MN involvement" to include the 
> > > link layer extensions as well. Otherwise we're sweeping the 
> > > problem under the rug.
> > > 
> > 
> > Sure. One thing we can do is to clearly list where MN 
> > participation is necessary.
> > Whether this would be done by L2 or IP is another thing. 
> > 
> > Thanks,
> > 
> > -Rajeev
> > 
> > 
> > > domagoj
> > > 
> > > 
> > > > -----Original Message-----
> > > > From: netext-bounces at mail.mobileip.jp 
> > > > [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of 
> ext Koodli, 
> > > > Rajeev
> > > > Sent: 26. veljaca 2009 19:38
> > > > To: netext at mail.mobileip.jp
> > > > Subject: Re: [Netext] Inter-technology handover PS
> > > > 
> > > > 
> > > >  
> > > > Hi Domagoj,
> > > > 
> > > > 
> > > > > 
> > > > > Using access specific mechanims is fine for the cases where
> > > > the access
> > > > > system actually provides the needed functionality.
> > > > 
> > > > Good. My reasoning is that if there is a functionality which is 
> > > > crucial to an access system, it will provide it. We defining a 
> > > > mechanism at IP layer, which I would prefer as well, will 
> > > turn out to 
> > > > be redundant and ignored.
> > > > 
> > > > 
> > > > > I don't think that we can expect every access system 
> to readily 
> > > > > support whatever is needed by PMIP6 (WiMAX being one
> > > > example of such
> > > > > access system, it doesn't provide any clue about the 
> > HI). In such 
> > > > > cases it makes sense to put the additional functionality 
> > > at the IP 
> > > > > layer, i.e. at the MAG/LMA/MN as they need to be updated 
> > > anyway to 
> > > > > support inter-tech handover. Such add-on at the 
> > IP-layer could be 
> > > > > reused without modifications with any access system which 
> > > does not 
> > > > > provide the appropriate L2 hints.
> > > > 
> > > > How does handover work in Wimax today without indication 
> > > from the MN 
> > > > at the IP layer?
> > > > 
> > > > To be clear, I do not wish to start from a point where we 
> > > assume that 
> > > > MN involvement at the IP layer is necessary; at least for 
> > this BOF. 
> > > > The focus of this effort is to identify the problems which 
> > > need to be 
> > > > solved. During the process, we can list what works and what 
> > > doesn't as 
> > > > it is, without MN involvement; it needs to be done thoroughly.
> > > > But, the starting point is not "we need MN involvement". 
> > > > 
> > > > -Rajeev
> > > > 
> > > > 
> > > > 
> > > > > 
> > > > > domagoj
> > > > > 
> > > > > > -----Original Message-----
> > > > > > From: netext-bounces at mail.mobileip.jp 
> > > > > > [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of 
> > > ext Koodli, 
> > > > > > Rajeev
> > > > > > Sent: 24. veljaca 2009 23:01
> > > > > > To: netext at mail.mobileip.jp
> > > > > > Subject: Re: [Netext] Inter-technology handover PS
> > > > > > 
> > > > > > 
> > > > > > Hello folks,
> > > > > > 
> > > > > > Few thoughts on what we may need to focus here..
> > > > > > 
> > > > > > 1. For the purposes of this ID (i.e., inter-tech
> > > > > handovers), what is
> > > > > > most relevant here? What breaks today? Or, what we can
> > > > improve? The
> > > > > > breakdown of issues is a good start, but we need to tie
> > > > it together
> > > > > > for the problem at hand - inter-tech handovers.
> > > > > > 
> > > > > > 2. What _requires_ an IP protocol support on the MN side? 
> > > > > > Could this be done in an access-specific way? For instance,
> > > > > the HI in
> > > > > > PMIP6 is left up to the access system to determine, 
> based on 
> > > > > > access-specific means where MN does take part. We 
> > need to ask a 
> > > > > > similar question here: if MN involvement is necessary, why
> > > > > couldn't we
> > > > > > let an access system provide the functionality?
> > > > > > 
> > > > > > 3. Assuming specific mechanisms (e.g., IEEE 802.21 
> > etc.) is not 
> > > > > > necessary. Folks can use whatever they want, but specifying 
> > > > > > dependencies needs to be avoided.
> > > > > > 
> > > > > > Regards,
> > > > > > 
> > > > > > -Rajeev
> > > > > >  
> > > > > > 
> > > > > > > -----Original Message-----
> > > > > > > From: netext-bounces at mail.mobileip.jp 
> > > > > > > [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of
> > > > > > Suresh Krishnan
> > > > > > > Sent: Thursday, February 19, 2009 3:19 PM
> > > > > > > To: cjbc at it.uc3m.es
> > > > > > > Cc: netext at mail.mobileip.jp
> > > > > > > Subject: Re: [Netext] Inter-technology handover PS
> > > > > > > 
> > > > > > > Hi Carlos,
> > > > > > >    Thanks for your comments. Please find responses inline
> > > > > > > 
> > > > > > > On 16/02/09 02:01 PM, Carlos Jes?s Bernardos Cano wrote:
> > > > > > > > * PGP Signed by an unknown key
> > > > > > > > 
> > > > > > > > Hi Suresh,
> > > > > > > > 
> > > > > > > > 	Thanks for the draft. I think it's 
> short and clear. 
> > > > > > > Some comments
> > > > > > > > below:
> > > > > > > > 
> > > > > > > > 	- Section 2.1. Formation of interface 
> identifier. The
> > > > > > > issue described
> > > > > > > > there only applies if SLAAC is used, right? If DHCP is
> > > > > > > used, the issue
> > > > > > > > is then on the network side, to ensure that the address
> > > > > > provided to
> > > > > > > > the new interface of the MN is the same that it was (or
> > > > > is still)
> > > > > > > > using on the previous interface, right?
> > > > > > > 
> > > > > > > Yes. This is correct. I can probably add a new section on
> > > > > > the network
> > > > > > > side about the DHCPv6 issue
> > > > > > > 
> > > > > > > > 
> > > > > > > > 	- Section 2.2 Usage of the same address 
> on multiple
> > > > > > > interfaces. Since
> > > > > > > > it seems that we cannot assume that is safe to 
> > use the same
> > > > > > > address on
> > > > > > > > multiple interfaces (without requiring changes on the MN
> > > > > > > side), this
> > > > > > > > implies that: a) if NETEXT work is restricted to work on
> > > > > > solutions
> > > > > > > > that do not impose changes on the MN, use cases 
> requiring
> > > > > > the MN to
> > > > > > > > use the same address simultaneously are out of 
> > the scope of
> > > > > > > NETEXT, b)
> > > > > > > > we allow for changes on the MN side. 
> > Additionally, it might
> > > > > > > be good to
> > > > > > > > analyse if it is OK for the MN to receive (and send)
> > > > > > > traffic addressed
> > > > > > > > to the IPv6 address of one interface through a different
> > > > > > interface
> > > > > > > > (weak end-system model defined in RFC 1122 or
> > > > > > > draft-thaler-ip-model-evolution).
> > > > > > > 
> > > > > > > While I agree with your analysis of the problem, are we
> > > > > delving too
> > > > > > > much into the solution space by adding any such text?
> > > > > > > 
> > > > > > > > 
> > > > > > > > 	- IMHO, it'd be good to explicitly 
> describe what a
> > > > > > > "change on the MN"
> > > > > > > > within the scope of NETEXT. For example, is it fine
> > > > > assuming IEEE
> > > > > > > > 802.21 support on the MN or is this "a change 
> on the MN"?
> > > > > > > 
> > > > > > > Probably something to add to the charter?
> > > > > > > 
> > > > > > > Cheers
> > > > > > > Suresh
> > > > > > > 
> > > > > > > _______________________________________________
> > > > > > > NetExt mailing list
> > > > > > > NetExt at mail.mobileip.jp
> > > > > > > http://www.mobileip.jp/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 
> > > > > > postmaster at starentnetworks.com -- and destroy all 
> > > copies of this 
> > > > > > message and any attachments without reading or 
> > disclosing their 
> > > > > > contents. Thank you.
> > > > > > 
> > > > > > _______________________________________________
> > > > > > NetExt mailing list
> > > > > > NetExt at mail.mobileip.jp
> > > > > > http://www.mobileip.jp/mailman/listinfo/netext
> > > > > > 
> > > > > 
> > > > > 
> > > > 
> > > > _______________________________________________
> > > > NetExt mailing list
> > > > NetExt at mail.mobileip.jp
> > > > http://www.mobileip.jp/mailman/listinfo/netext
> > > > 
> > > 
> > > 
> > 
> > _______________________________________________
> > NetExt mailing list
> > NetExt at mail.mobileip.jp
> > http://www.mobileip.jp/mailman/listinfo/netext
> > 
> 
> 

From: gerardog at qualcomm.com (Giaretta, Gerardo)
Date: Mon, 2 Mar 2009 08:08:20 -0800
Subject: [Netext] Inter-technology handover PS
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Domagoj,

I understand this is what WiMAX Forum would like but it is really far ahead in terms of deployment. A WiFi interworking solution needs to take into account of the high number of deployments out there where WiFi boxes do not implement any network based mobility protocol, any MN-MAG protocol or any strong authentication mechanism that are needed for that. This is also the understanding of 3GPP which specified only a client MIP-based solution for interworking with WiFi.

Therefore I strongly agree with Rajeev that WiFi is not a good example here. And this boils down to the previous discussion: for a PMIPv6 based solution, we should consider some support for the access specific protocol. This is the only way PMIPv6 is going to be implemented in a reasonable timeframe (as done in 3GPP and eHRPD accesses)

Gerardo

> -----Original Message-----
> From: netext-bounces at mail.mobileip.jp [mailto:netext-bounces at mail.mobileip.jp]
> On Behalf Of Domagoj Premec
> Sent: Monday, March 02, 2009 5:53 AM
> To: 'ext Koodli, Rajeev'; netext at mail.mobileip.jp
> Subject: Re: [Netext] Inter-technology handover PS
> 
> Rajeev,
> 
> > WiFi is not a good example here IMHO. One of the emphasis in
> > NetExt is to consider possible deployment scenarios.
> 
> WiMAX Forum is working on enabling the WiMAX-WiFi interworking and one of
> the requirements for WiFi interworking says:
> 
> "Network based IP mobility SHALL be supported for the purpose of
> interworking."
> 
> so we shouldn't exclude the WiFi access when considering possible
> deployments.
> 
> domagoj
> 
> 
> > -----Original Message-----
> > From: netext-bounces at mail.mobileip.jp
> > [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext
> > Koodli, Rajeev
> > Sent: 27. veljaca 2009 17:38
> > To: netext at mail.mobileip.jp
> > Subject: Re: [Netext] Inter-technology handover PS
> >
> >
> >
> >
> > Hi Domagoj,
> >
> > > Extending the access system signaling may not be always
> > possible and
> > > in such cases the IP layer mechanism would get used.
> > Considering the
> > > already deployed WiFi equipement as an example, even if the 802.11
> > > would be extended to provide support for PMIP6 hints, is it
> > realistic
> > > to expect the existing APs to be upgraded?
> >
> > WiFi is not a good example here IMHO. One of the emphasis in
> > NetExt is to consider possible deployment scenarios. So,
> > either a candidate access deployment already has or willing
> > to define the necessary extensions or expresses need to have
> > an IP-based mechanism.
> >
> > >
> > > > How does handover work in Wimax today without indication
> > > from the MN
> > > > at the IP layer?
> > >
> > > Curretnly it doesn't work (the inter-tech HO), this is an
> > open issue.
> > > Link layer extensions are not an option as the
> > > .16 version upon which the NWG Rel
> > > 1.5 is based is closed for changes.
> > >
> >
> > Good to know. We will need further discussion to go over this.
> >
> > > >
> > > > To be clear, I do not wish to start from a point where we
> > > > assume that MN involvement at the IP layer is necessary;
> > at least for this BOF.
> > >
> > > Is MN involvement at the link layer less of a concern then
> > > the MN involvement at the IP layer? It should not be.
> >
> > Yes, it is less of a concern for _this BOF_ because this BoF
> > is about working on some problems related to network-based
> > mobility where we do not want to start from making changes to
> > the MN. As I mentioned in my e-mail, defining an IP layer
> > mechanism which an access system already has or will define
> > will be redundant and ignored.
> >
> >
> > > Ideally, the MN is not involved at all at any layer. My
> > > thinking is that, if it must be involved, it makes sense to
> > > address those changes at the IP layer - once and for all.
> > >
> >
> > As a general design guideline yes. It's not easy for this BOF.
> >
> >
> > > > The focus of this effort is to identify the problems
> > which need to be
> > > > solved. During the process, we can list what works and
> > what doesn't as
> > > > it is, without MN involvement; it needs to be done thoroughly.
> > >
> > > ok, let's try to see first what scenarios can be addressed
> > > without the MN involvement.
> > >
> >
> > Good. I want to start with the clear understanding that we
> > are _not_ starting with defining MN involvement (at IP
> > layer). Once we get chartered (hopefully), we can have a
> > discussion on the topic as part of Inter-tech handovers and
> > arrive at consensus.
> >
> > > > But, the starting point is not "we need MN involvement".
> > >
> > > I would just like the term "MN involvement" to include the
> > > link layer extensions as well. Otherwise we're sweeping the
> > > problem under the rug.
> > >
> >
> > Sure. One thing we can do is to clearly list where MN
> > participation is necessary.
> > Whether this would be done by L2 or IP is another thing.
> >
> > Thanks,
> >
> > -Rajeev
> >
> >
> > > domagoj
> > >
> > >
> > > > -----Original Message-----
> > > > From: netext-bounces at mail.mobileip.jp
> > > > [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext Koodli,
> > > > Rajeev
> > > > Sent: 26. veljaca 2009 19:38
> > > > To: netext at mail.mobileip.jp
> > > > Subject: Re: [Netext] Inter-technology handover PS
> > > >
> > > >
> > > >
> > > > Hi Domagoj,
> > > >
> > > >
> > > > >
> > > > > Using access specific mechanims is fine for the cases where
> > > > the access
> > > > > system actually provides the needed functionality.
> > > >
> > > > Good. My reasoning is that if there is a functionality which is
> > > > crucial to an access system, it will provide it. We defining a
> > > > mechanism at IP layer, which I would prefer as well, will
> > > turn out to
> > > > be redundant and ignored.
> > > >
> > > >
> > > > > I don't think that we can expect every access system to readily
> > > > > support whatever is needed by PMIP6 (WiMAX being one
> > > > example of such
> > > > > access system, it doesn't provide any clue about the
> > HI). In such
> > > > > cases it makes sense to put the additional functionality
> > > at the IP
> > > > > layer, i.e. at the MAG/LMA/MN as they need to be updated
> > > anyway to
> > > > > support inter-tech handover. Such add-on at the
> > IP-layer could be
> > > > > reused without modifications with any access system which
> > > does not
> > > > > provide the appropriate L2 hints.
> > > >
> > > > How does handover work in Wimax today without indication
> > > from the MN
> > > > at the IP layer?
> > > >
> > > > To be clear, I do not wish to start from a point where we
> > > assume that
> > > > MN involvement at the IP layer is necessary; at least for
> > this BOF.
> > > > The focus of this effort is to identify the problems which
> > > need to be
> > > > solved. During the process, we can list what works and what
> > > doesn't as
> > > > it is, without MN involvement; it needs to be done thoroughly.
> > > > But, the starting point is not "we need MN involvement".
> > > >
> > > > -Rajeev
> > > >
> > > >
> > > >
> > > > >
> > > > > domagoj
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: netext-bounces at mail.mobileip.jp
> > > > > > [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of
> > > ext Koodli,
> > > > > > Rajeev
> > > > > > Sent: 24. veljaca 2009 23:01
> > > > > > To: netext at mail.mobileip.jp
> > > > > > Subject: Re: [Netext] Inter-technology handover PS
> > > > > >
> > > > > >
> > > > > > Hello folks,
> > > > > >
> > > > > > Few thoughts on what we may need to focus here..
> > > > > >
> > > > > > 1. For the purposes of this ID (i.e., inter-tech
> > > > > handovers), what is
> > > > > > most relevant here? What breaks today? Or, what we can
> > > > improve? The
> > > > > > breakdown of issues is a good start, but we need to tie
> > > > it together
> > > > > > for the problem at hand - inter-tech handovers.
> > > > > >
> > > > > > 2. What _requires_ an IP protocol support on the MN side?
> > > > > > Could this be done in an access-specific way? For instance,
> > > > > the HI in
> > > > > > PMIP6 is left up to the access system to determine, based on
> > > > > > access-specific means where MN does take part. We
> > need to ask a
> > > > > > similar question here: if MN involvement is necessary, why
> > > > > couldn't we
> > > > > > let an access system provide the functionality?
> > > > > >
> > > > > > 3. Assuming specific mechanisms (e.g., IEEE 802.21
> > etc.) is not
> > > > > > necessary. Folks can use whatever they want, but specifying
> > > > > > dependencies needs to be avoided.
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > -Rajeev
> > > > > >
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: netext-bounces at mail.mobileip.jp
> > > > > > > [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of
> > > > > > Suresh Krishnan
> > > > > > > Sent: Thursday, February 19, 2009 3:19 PM
> > > > > > > To: cjbc at it.uc3m.es
> > > > > > > Cc: netext at mail.mobileip.jp
> > > > > > > Subject: Re: [Netext] Inter-technology handover PS
> > > > > > >
> > > > > > > Hi Carlos,
> > > > > > >    Thanks for your comments. Please find responses inline
> > > > > > >
> > > > > > > On 16/02/09 02:01 PM, Carlos Jes?s Bernardos Cano wrote:
> > > > > > > > * PGP Signed by an unknown key
> > > > > > > >
> > > > > > > > Hi Suresh,
> > > > > > > >
> > > > > > > > 	Thanks for the draft. I think it's short and clear.
> > > > > > > Some comments
> > > > > > > > below:
> > > > > > > >
> > > > > > > > 	- Section 2.1. Formation of interface identifier. The
> > > > > > > issue described
> > > > > > > > there only applies if SLAAC is used, right? If DHCP is
> > > > > > > used, the issue
> > > > > > > > is then on the network side, to ensure that the address
> > > > > > provided to
> > > > > > > > the new interface of the MN is the same that it was (or
> > > > > is still)
> > > > > > > > using on the previous interface, right?
> > > > > > >
> > > > > > > Yes. This is correct. I can probably add a new section on
> > > > > > the network
> > > > > > > side about the DHCPv6 issue
> > > > > > >
> > > > > > > >
> > > > > > > > 	- Section 2.2 Usage of the same address on multiple
> > > > > > > interfaces. Since
> > > > > > > > it seems that we cannot assume that is safe to
> > use the same
> > > > > > > address on
> > > > > > > > multiple interfaces (without requiring changes on the MN
> > > > > > > side), this
> > > > > > > > implies that: a) if NETEXT work is restricted to work on
> > > > > > solutions
> > > > > > > > that do not impose changes on the MN, use cases requiring
> > > > > > the MN to
> > > > > > > > use the same address simultaneously are out of
> > the scope of
> > > > > > > NETEXT, b)
> > > > > > > > we allow for changes on the MN side.
> > Additionally, it might
> > > > > > > be good to
> > > > > > > > analyse if it is OK for the MN to receive (and send)
> > > > > > > traffic addressed
> > > > > > > > to the IPv6 address of one interface through a different
> > > > > > interface
> > > > > > > > (weak end-system model defined in RFC 1122 or
> > > > > > > draft-thaler-ip-model-evolution).
> > > > > > >
> > > > > > > While I agree with your analysis of the problem, are we
> > > > > delving too
> > > > > > > much into the solution space by adding any such text?
> > > > > > >
> > > > > > > >
> > > > > > > > 	- IMHO, it'd be good to explicitly describe what a
> > > > > > > "change on the MN"
> > > > > > > > within the scope of NETEXT. For example, is it fine
> > > > > assuming IEEE
> > > > > > > > 802.21 support on the MN or is this "a change on the MN"?
> > > > > > >
> > > > > > > Probably something to add to the charter?
> > > > > > >
> > > > > > > Cheers
> > > > > > > Suresh
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > NetExt mailing list
> > > > > > > NetExt at mail.mobileip.jp
> > > > > > > http://www.mobileip.jp/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
> > > > > > postmaster at starentnetworks.com -- and destroy all
> > > copies of this
> > > > > > message and any attachments without reading or
> > disclosing their
> > > > > > contents. Thank you.
> > > > > >
> > > > > > _______________________________________________
> > > > > > NetExt mailing list
> > > > > > NetExt at mail.mobileip.jp
> > > > > > http://www.mobileip.jp/mailman/listinfo/netext
> > > > > >
> > > > >
> > > > >
> > > >
> > > > _______________________________________________
> > > > NetExt mailing list
> > > > NetExt at mail.mobileip.jp
> > > > http://www.mobileip.jp/mailman/listinfo/netext
> > > >
> > >
> > >
> >
> > _______________________________________________
> > NetExt mailing list
> > NetExt at mail.mobileip.jp
> > http://www.mobileip.jp/mailman/listinfo/netext
> >
> 
> 
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext

From: domagoj.premec.ext at nsn.com (Domagoj Premec)
Date: Mon, 2 Mar 2009 14:53:26 +0100
Subject: [Netext] Inter-technology handover PS
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Rajeev,

> WiFi is not a good example here IMHO. One of the emphasis in 
> NetExt is to consider possible deployment scenarios.

WiMAX Forum is working on enabling the WiMAX-WiFi interworking and one of
the requirements for WiFi interworking says:

"Network based IP mobility SHALL be supported for the purpose of
interworking."

so we shouldn't exclude the WiFi access when considering possible
deployments.

domagoj

> -----Original Message-----
> From: netext-bounces at mail.mobileip.jp 
> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext 
> Koodli, Rajeev
> Sent: 27. veljaca 2009 17:38
> To: netext at mail.mobileip.jp
> Subject: Re: [Netext] Inter-technology handover PS
> 
> 
>  
> 
> Hi Domagoj,
> 
> > Extending the access system signaling may not be always 
> possible and 
> > in such cases the IP layer mechanism would get used. 
> Considering the 
> > already deployed WiFi equipement as an example, even if the 802.11 
> > would be extended to provide support for PMIP6 hints, is it 
> realistic 
> > to expect the existing APs to be upgraded?
> 
> WiFi is not a good example here IMHO. One of the emphasis in 
> NetExt is to consider possible deployment scenarios. So, 
> either a candidate access deployment already has or willing 
> to define the necessary extensions or expresses need to have 
> an IP-based mechanism. 
> 
> > 
> > > How does handover work in Wimax today without indication
> > from the MN
> > > at the IP layer?
> > 
> > Curretnly it doesn't work (the inter-tech HO), this is an 
> open issue. 
> > Link layer extensions are not an option as the
> > .16 version upon which the NWG Rel
> > 1.5 is based is closed for changes.
> > 
> 
> Good to know. We will need further discussion to go over this.
> 
> > > 
> > > To be clear, I do not wish to start from a point where we 
> > > assume that MN involvement at the IP layer is necessary; 
> at least for this BOF.
> > 
> > Is MN involvement at the link layer less of a concern then 
> > the MN involvement at the IP layer? It should not be. 
> 
> Yes, it is less of a concern for _this BOF_ because this BoF 
> is about working on some problems related to network-based 
> mobility where we do not want to start from making changes to 
> the MN. As I mentioned in my e-mail, defining an IP layer 
> mechanism which an access system already has or will define 
> will be redundant and ignored.
> 
> 
> > Ideally, the MN is not involved at all at any layer. My 
> > thinking is that, if it must be involved, it makes sense to 
> > address those changes at the IP layer - once and for all.
> > 
> 
> As a general design guideline yes. It's not easy for this BOF.
> 
> 
> > > The focus of this effort is to identify the problems 
> which need to be 
> > > solved. During the process, we can list what works and 
> what doesn't as 
> > > it is, without MN involvement; it needs to be done thoroughly.
> > 
> > ok, let's try to see first what scenarios can be addressed 
> > without the MN involvement.
> > 
> 
> Good. I want to start with the clear understanding that we 
> are _not_ starting with defining MN involvement (at IP 
> layer). Once we get chartered (hopefully), we can have a 
> discussion on the topic as part of Inter-tech handovers and 
> arrive at consensus. 
> 
> > > But, the starting point is not "we need MN involvement".  
> > 
> > I would just like the term "MN involvement" to include the 
> > link layer extensions as well. Otherwise we're sweeping the 
> > problem under the rug.
> > 
> 
> Sure. One thing we can do is to clearly list where MN 
> participation is necessary.
> Whether this would be done by L2 or IP is another thing. 
> 
> Thanks,
> 
> -Rajeev
> 
> 
> > domagoj
> > 
> > 
> > > -----Original Message-----
> > > From: netext-bounces at mail.mobileip.jp 
> > > [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext Koodli, 
> > > Rajeev
> > > Sent: 26. veljaca 2009 19:38
> > > To: netext at mail.mobileip.jp
> > > Subject: Re: [Netext] Inter-technology handover PS
> > > 
> > > 
> > >  
> > > Hi Domagoj,
> > > 
> > > 
> > > > 
> > > > Using access specific mechanims is fine for the cases where
> > > the access
> > > > system actually provides the needed functionality.
> > > 
> > > Good. My reasoning is that if there is a functionality which is 
> > > crucial to an access system, it will provide it. We defining a 
> > > mechanism at IP layer, which I would prefer as well, will 
> > turn out to 
> > > be redundant and ignored.
> > > 
> > > 
> > > > I don't think that we can expect every access system to readily 
> > > > support whatever is needed by PMIP6 (WiMAX being one
> > > example of such
> > > > access system, it doesn't provide any clue about the 
> HI). In such 
> > > > cases it makes sense to put the additional functionality 
> > at the IP 
> > > > layer, i.e. at the MAG/LMA/MN as they need to be updated 
> > anyway to 
> > > > support inter-tech handover. Such add-on at the 
> IP-layer could be 
> > > > reused without modifications with any access system which 
> > does not 
> > > > provide the appropriate L2 hints.
> > > 
> > > How does handover work in Wimax today without indication 
> > from the MN 
> > > at the IP layer?
> > > 
> > > To be clear, I do not wish to start from a point where we 
> > assume that 
> > > MN involvement at the IP layer is necessary; at least for 
> this BOF. 
> > > The focus of this effort is to identify the problems which 
> > need to be 
> > > solved. During the process, we can list what works and what 
> > doesn't as 
> > > it is, without MN involvement; it needs to be done thoroughly.
> > > But, the starting point is not "we need MN involvement". 
> > > 
> > > -Rajeev
> > > 
> > > 
> > > 
> > > > 
> > > > domagoj
> > > > 
> > > > > -----Original Message-----
> > > > > From: netext-bounces at mail.mobileip.jp 
> > > > > [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of 
> > ext Koodli, 
> > > > > Rajeev
> > > > > Sent: 24. veljaca 2009 23:01
> > > > > To: netext at mail.mobileip.jp
> > > > > Subject: Re: [Netext] Inter-technology handover PS
> > > > > 
> > > > > 
> > > > > Hello folks,
> > > > > 
> > > > > Few thoughts on what we may need to focus here..
> > > > > 
> > > > > 1. For the purposes of this ID (i.e., inter-tech
> > > > handovers), what is
> > > > > most relevant here? What breaks today? Or, what we can
> > > improve? The
> > > > > breakdown of issues is a good start, but we need to tie
> > > it together
> > > > > for the problem at hand - inter-tech handovers.
> > > > > 
> > > > > 2. What _requires_ an IP protocol support on the MN side? 
> > > > > Could this be done in an access-specific way? For instance,
> > > > the HI in
> > > > > PMIP6 is left up to the access system to determine, based on 
> > > > > access-specific means where MN does take part. We 
> need to ask a 
> > > > > similar question here: if MN involvement is necessary, why
> > > > couldn't we
> > > > > let an access system provide the functionality?
> > > > > 
> > > > > 3. Assuming specific mechanisms (e.g., IEEE 802.21 
> etc.) is not 
> > > > > necessary. Folks can use whatever they want, but specifying 
> > > > > dependencies needs to be avoided.
> > > > > 
> > > > > Regards,
> > > > > 
> > > > > -Rajeev
> > > > >  
> > > > > 
> > > > > > -----Original Message-----
> > > > > > From: netext-bounces at mail.mobileip.jp 
> > > > > > [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of
> > > > > Suresh Krishnan
> > > > > > Sent: Thursday, February 19, 2009 3:19 PM
> > > > > > To: cjbc at it.uc3m.es
> > > > > > Cc: netext at mail.mobileip.jp
> > > > > > Subject: Re: [Netext] Inter-technology handover PS
> > > > > > 
> > > > > > Hi Carlos,
> > > > > >    Thanks for your comments. Please find responses inline
> > > > > > 
> > > > > > On 16/02/09 02:01 PM, Carlos Jes?s Bernardos Cano wrote:
> > > > > > > * PGP Signed by an unknown key
> > > > > > > 
> > > > > > > Hi Suresh,
> > > > > > > 
> > > > > > > 	Thanks for the draft. I think it's short and clear. 
> > > > > > Some comments
> > > > > > > below:
> > > > > > > 
> > > > > > > 	- Section 2.1. Formation of interface identifier. The
> > > > > > issue described
> > > > > > > there only applies if SLAAC is used, right? If DHCP is
> > > > > > used, the issue
> > > > > > > is then on the network side, to ensure that the address
> > > > > provided to
> > > > > > > the new interface of the MN is the same that it was (or
> > > > is still)
> > > > > > > using on the previous interface, right?
> > > > > > 
> > > > > > Yes. This is correct. I can probably add a new section on
> > > > > the network
> > > > > > side about the DHCPv6 issue
> > > > > > 
> > > > > > > 
> > > > > > > 	- Section 2.2 Usage of the same address on multiple
> > > > > > interfaces. Since
> > > > > > > it seems that we cannot assume that is safe to 
> use the same
> > > > > > address on
> > > > > > > multiple interfaces (without requiring changes on the MN
> > > > > > side), this
> > > > > > > implies that: a) if NETEXT work is restricted to work on
> > > > > solutions
> > > > > > > that do not impose changes on the MN, use cases requiring
> > > > > the MN to
> > > > > > > use the same address simultaneously are out of 
> the scope of
> > > > > > NETEXT, b)
> > > > > > > we allow for changes on the MN side. 
> Additionally, it might
> > > > > > be good to
> > > > > > > analyse if it is OK for the MN to receive (and send)
> > > > > > traffic addressed
> > > > > > > to the IPv6 address of one interface through a different
> > > > > interface
> > > > > > > (weak end-system model defined in RFC 1122 or
> > > > > > draft-thaler-ip-model-evolution).
> > > > > > 
> > > > > > While I agree with your analysis of the problem, are we
> > > > delving too
> > > > > > much into the solution space by adding any such text?
> > > > > > 
> > > > > > > 
> > > > > > > 	- IMHO, it'd be good to explicitly describe what a
> > > > > > "change on the MN"
> > > > > > > within the scope of NETEXT. For example, is it fine
> > > > assuming IEEE
> > > > > > > 802.21 support on the MN or is this "a change on the MN"?
> > > > > > 
> > > > > > Probably something to add to the charter?
> > > > > > 
> > > > > > Cheers
> > > > > > Suresh
> > > > > > 
> > > > > > _______________________________________________
> > > > > > NetExt mailing list
> > > > > > NetExt at mail.mobileip.jp
> > > > > > http://www.mobileip.jp/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 
> > > > > postmaster at starentnetworks.com -- and destroy all 
> > copies of this 
> > > > > message and any attachments without reading or 
> disclosing their 
> > > > > contents. Thank you.
> > > > > 
> > > > > _______________________________________________
> > > > > NetExt mailing list
> > > > > NetExt at mail.mobileip.jp
> > > > > http://www.mobileip.jp/mailman/listinfo/netext
> > > > > 
> > > > 
> > > > 
> > > 
> > > _______________________________________________
> > > NetExt mailing list
> > > NetExt at mail.mobileip.jp
> > > http://www.mobileip.jp/mailman/listinfo/netext
> > > 
> > 
> > 
> 
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
> 

From: cjbc at it.uc3m.es (Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano)
Date: Mon, 02 Mar 2009 12:42:04 +0100
Subject: [Netext] Inter-technology handovers PS considering Multihoming	PS and Localized Routing PS
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <1235994124.5456.37.camel@localhost>

Hi David,

	Two quick questions/comments:

        - do you think multihoming only deals with configuring the same
address on different interfaces of the MN? I don't this has to be
necessarily the case.

        - in local routing, not sure if the optimization would have to
consider which is the best interface of the MN to achieve the shortest
path. This would require involving the MN, and I'd prefer involving only
the network there.

	Kind Regards,

	Carlos

El jue, 26-02-2009 a las 11:20 -0500, David Cypher escribi?:
> Taking a look at the other two problem statements in terms of 
> existing services and new services,
> I do not think that any of the three problem statements can really be 
> addressed in isolation.
> 
> Multihoming Problem Statement
> Mobile node should be able to have more than one interface to the network
> - same access technology interfaces
> 	i) same IPv6 address	(not supported in RFC 5213)
> 	ii) different IPv6 address (supported)
> - different access technology interfaces
> 	i) same IPv6 address	(supported but only for handover (temporarily))
> 	ii) different IPv6 address	(supported)
> 
> NEW SERVICE being requested
> - A) the ability to have the same IPv6 address on more than one 
> interface (whether the access technology is the same or different) 
> for a long period of time (i.e., not part of a handover/handoff).
> 
> 
> Route optimization (RO) Problem statement
> NEW SERVICES being requested
> - A ) the ability to discover if a route between MN(MAG) and CN is 
> better than the existing route between MN (LMA) and CN and
> - B) the ability to use the route if found.
> 
> What interface will be used to find this optimized route if multiple 
> accesses exist and multihoming is truly provided?
> All of them?  One of them?  Which one?  Will there be a primary 
> access interface or MN-HNP needed?
> 
> 
> SUMMARY of the three problem statements
> ======================================
> Inter-technology and multihoming problem statements appear to be 
> interrelated.  Inter-technology (2.2) claims that there are problems 
> with mobile nodes' operating systems that do not permit multihoming 
> (same address on multiple interfaces), which is what the Multihoming 
> Problem statement is wanting.
> 
> Inter-technology PS 3.2 needs to be able to distinguish between 
> handover and multiple interfaces.  This is another issue related to 
> Multihoming (multiple interfaces)
> 
> Cannot look at inter-technology and multihoming as separate problem 
> statements.  Instead perhaps the problem statements should be written 
> from a NEW SERVICE being requested.
> 
> Cannot look at route optimization and multihoming as separate 
> problems since the route optimized is dependent upon the attachment 
> point and the address used for that attachment.
> 
> For example from the original PMIP the services were
> - to supply the mobile node with a single set of MN-HNPs as it moved 
> throughout the PMIP domain while maintaining only one active 
> interface at a time or temporarily two during a handover.  (a single 
> set of MN-HNPs for all of the mobile node's interfaces provided only 
> one interface active at a time and used for handover only between two 
> interfaces)
> - to supply the mobile node with a single set of MN-HNPs per 
> interface, if more than one interface was attached to the PMIP 
> domain. (a different set of MN-HNPs for each interface)
> 
> 
> SUMMARY of new services:
> =============================================
> The NEW SERVICES being requested by the three PSs are:
> - multiple interfaces active at the same time and not part of handover
> 	i) using the same MN-HNPs
> 	ii) using different MN-HNPs
> - a method for determining which service(s) the mobile node wants
> - a method for determining the mobile node's intended usage of the 
> multiple connections
> - a method for determining the mobile node's capabilities to support 
> PMIP services.
> - the ability to discover if a route between MN(MAG) (on which 
> interface) and CN is better than the existing route between MN (LMA) 
> (on which interface) and CN and
> - the ability to use the route if found.
> 
> David Cypher
> 
> 
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
-- 
 Carlos Jes?s Bernardos Cano     http://www.netcoms.net
 GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  WEEDEV 2009: 2nd Workshop on Experimental Evaluation and
        Deployment Experiences on Vehicular networks
                  http://www.weedev.org/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Esta parte del mensaje est? firmada	digitalmente
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090302/4a425d19/attachment.bin>

From: xiayangsong at huawei.com (Frank Xia)
Date: Sat, 28 Feb 2009 11:37:16 -0600
Subject: [Netext]   Tunnel Negotiation for Proxy Mobile IPv6
Message-ID: <[email-masked]>

Hi Folks

We just submitted the draft
http://www.ietf.org/internet-drafts/draft-xia-netext-tunnel-negotiation-00.txt.

Comments are most welcome.

BR
Frank

----- Original Message ----- 
From: "IETF I-D Submission Tool" <idsubmission at ietf.org>
To: <xiayangsong at huawei.com>
Cc: <yokota at kddilabs.jp>; <suresh.krishnan at ericsson.com>
Sent: Saturday, February 28, 2009 11:05 AM
Subject: New Version Notification for draft-xia-netext-tunnel-negotiation-00

 A new version of I-D, draft-xia-netext-tunnel-negotiation-00.txt has been 
successfuly submitted by Frank Xia and posted to the IETF repository.

 Filename: draft-xia-netext-tunnel-negotiation
 Revision: 00
 Title: Tunnel Negotiation for Proxy Mobile IPv6
 Creation_date: 2009-02-28
 WG ID: Independent Submission
 Number_of_pages: 8

 Abstract:
 Proxy Mobile IPv6 allows a mobile node's IPv4 and IPv6 traffic
 between a Local Mobility Anchor(LMA) and a Mobile Access Gateway
 (MAG) to be tunneled using IPv6, IPv4 ,IPv4-UDP, or GRE encapsulation
 headers.  In this document, a new mobility option is specified for
 tunnel negotiation between the LMA and MAG.

 The IETF Secretariat.