From: pierrick.seite at orange-ftgroup.com (pierrick.seite at orange-ftgroup.com) Date: Tue, 31 Mar 2009 15:08:35 +0200 Subject: [Netext] Charter Scope and Work Items In-Reply-To: <000401c9ae9e$d3fbf360$d6f6200a@amer.cisco.com> References: <000401c9ae9e$d3fbf360$d6f6200a@amer.cisco.com> Message-ID: 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: References: <000001c9ae99$53062230$d6f6200a@amer.cisco.com> <8F14D833258240D792DC830659F30E3E@ww300.siemens.net> <78798470F7F74EF090EA0826AE024A37@ww300.siemens.net> Message-ID: <773DF405808F4DADBE0570C557C7FC9F@ww300.siemens.net> 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: <8F14D833258240D792DC830659F30E3E@ww300.siemens.net> References: <000001c9ae99$53062230$d6f6200a@amer.cisco.com> <8F14D833258240D792DC830659F30E3E@ww300.siemens.net> Message-ID: 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: <78798470F7F74EF090EA0826AE024A37@ww300.siemens.net> References: <000001c9ae99$53062230$d6f6200a@amer.cisco.com> <8F14D833258240D792DC830659F30E3E@ww300.siemens.net> <78798470F7F74EF090EA0826AE024A37@ww300.siemens.net> Message-ID: 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: <777914.27727.qm@web111411.mail.gq1.yahoo.com> Message-ID: <5F09D220B62F79418461A978CA0921BD033F78D5@pslexc01.psl.local> 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 To: ext Sri Gundavelli 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: <78798470F7F74EF090EA0826AE024A37@ww300.siemens.net> References: <000001c9ae99$53062230$d6f6200a@amer.cisco.com> <8F14D833258240D792DC830659F30E3E@ww300.siemens.net> <78798470F7F74EF090EA0826AE024A37@ww300.siemens.net> Message-ID: <777914.27727.qm@web111411.mail.gq1.yahoo.com> 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 To: ext Sri Gundavelli 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: From: rkoodli at starentnetworks.com (Koodli, Rajeev) Date: Mon, 30 Mar 2009 13:05:03 -0400 Subject: [Netext] Today's BOF Discussion References: <000001c9ae99$53062230$d6f6200a@amer.cisco.com><8F14D833258240D792DC830659F30E3E@ww300.siemens.net> <78798470F7F74EF090EA0826AE024A37@ww300.siemens.net> Message-ID: <4D35478224365146822AE9E3AD4A2666035AAA6C@exchtewks3.starentnetworks.com> 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: References: <000001c9ae99$53062230$d6f6200a@amer.cisco.com> <8F14D833258240D792DC830659F30E3E@ww300.siemens.net> Message-ID: <78798470F7F74EF090EA0826AE024A37@ww300.siemens.net> 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: <8F14D833258240D792DC830659F30E3E@ww300.siemens.net> References: <000001c9ae99$53062230$d6f6200a@amer.cisco.com> <8F14D833258240D792DC830659F30E3E@ww300.siemens.net> Message-ID: 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: <000001c9ae99$53062230$d6f6200a@amer.cisco.com> References: <000001c9ae99$53062230$d6f6200a@amer.cisco.com> Message-ID: <8F14D833258240D792DC830659F30E3E@ww300.siemens.net> 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: <000401c9ae9e$d3fbf360$d6f6200a@amer.cisco.com> 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: <000001c9ae99$53062230$d6f6200a@amer.cisco.com> References: <000001c9ae99$53062230$d6f6200a@amer.cisco.com> Message-ID: <0D8EA455-00F3-452C-9079-2F4736A16D4F@gmail.com> 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 > > > > > _______________________________________________ > 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: <000001c9ae99$53062230$d6f6200a@amer.cisco.com> 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: 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: <498AF8B1.1020303@nw.neclab.eu> <4e6e9dc70903261636r9b29634u79a28749ead2e427@mail.gmail.com> Message-ID: <0b6a01c9ae77$a5f11030$c8168182@china.huawei.com> 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" To: "Marco Liebsch" Cc: 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 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: <498AF8B1.1020303@nw.neclab.eu> References: <498AF8B1.1020303@nw.neclab.eu> Message-ID: <4e6e9dc70903261636r9b29634u79a28749ead2e427@mail.gmail.com> 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 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: Are posted at: http://people.nokia.net/~patil/IETF74/Netext/ -Chairs -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: Network-based Mobility Extensions (NetExt) Bof THURSDAY, March 26, 2009 1300-1500 Afternoon Session I in Imperial A Bof chairs: Rajeev Koodli Basavaraj Patil 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 Presenter: Vijay Devarapalli (10 Mins for PS presentations and 10 Mins for discussion) b. Localized Routing Presenter: Marco Liebsch (10 Mins for PS presentations and 10 Mins for discussion) c. Inter technology handovers 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 e. PMIP6 Redirect 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: 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: References: <49B92FB6.70408@nw.neclab.eu> Message-ID: <49C213FD.9010306@nw.neclab.eu> 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: <49B92FB6.70408@nw.neclab.eu> References: <49B92FB6.70408@nw.neclab.eu> Message-ID: 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: <49B969EE.9020609@wichorus.com> References: <42D58C72A6CF4C8894B4CC4E0C64284D@ww300.siemens.net> <732E1377AA984AFEB503979F1C510032@ww300.siemens.net> <49B969EE.9020609@wichorus.com> Message-ID: 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: <732E1377AA984AFEB503979F1C510032@ww300.siemens.net> References: <42D58C72A6CF4C8894B4CC4E0C64284D@ww300.siemens.net> <732E1377AA984AFEB503979F1C510032@ww300.siemens.net> Message-ID: <49B969EE.9020609@wichorus.com> 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: References: Message-ID: <49B92FB6.70408@nw.neclab.eu> 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: References: <42D58C72A6CF4C8894B4CC4E0C64284D@ww300.siemens.net> Message-ID: <732E1377AA984AFEB503979F1C510032@ww300.siemens.net> 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: <42D58C72A6CF4C8894B4CC4E0C64284D@ww300.siemens.net> References: <42D58C72A6CF4C8894B4CC4E0C64284D@ww300.siemens.net> Message-ID: 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: <7.0.1.0.2.20090311092505.02355de0@nist.gov> Message-ID: <5F09D220B62F79418461A978CA0921BD0333680F@pslexc01.psl.local> 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: <853DD750D9C3724FBF2DF7164FCF641C02AB219F@FRVELSMBS14.ad2.ad.alcatel.com> Message-ID: <5F09D220B62F79418461A978CA0921BD0333680A@pslexc01.psl.local> 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: 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: <5F09D220B62F79418461A978CA0921BD033365BC@pslexc01.psl.loca l> References: <7.0.1.0.2.20090310130241.02502c30@nist.gov> <5F09D220B62F79418461A978CA0921BD033365BC@pslexc01.psl.local> Message-ID: <7.0.1.0.2.20090311092505.02355de0@nist.gov> 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: <853DD750D9C3724FBF2DF7164FCF641C02AB219F@FRVELSMBS14.ad2.ad.alcatel.com> 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: 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: <7.0.1.0.2.20090310130241.02502c30@nist.gov> Message-ID: <5F09D220B62F79418461A978CA0921BD033365BC@pslexc01.psl.local> 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: <7.0.1.0.2.20090310180333.02569228@nist.gov> Message-ID: <4D35478224365146822AE9E3AD4A266607120F1D@exchtewks3.starentnetworks.com> 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: <4D35478224365146822AE9E3AD4A266607120CB7@exchtewks3.staren tnetworks.com> References: <7.0.1.0.2.20090310130241.02502c30@nist.gov> <4D35478224365146822AE9E3AD4A266607120CB7@exchtewks3.starentnetworks.com> Message-ID: <7.0.1.0.2.20090310180333.02569228@nist.gov> 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: <7.0.1.0.2.20090310130241.02502c30@nist.gov> Message-ID: <4D35478224365146822AE9E3AD4A266607120CB7@exchtewks3.starentnetworks.com> 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: <7.0.1.0.2.20090310130241.02502c30@nist.gov> 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: <5F09D220B62F79418461A978CA0921BD033363CA@pslexc01.psl.local> 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: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ATT5410851.txt URL: 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: <7.0.1.0.2.20090309095008.0240be88@nist.gov> References: <7.0.1.0.2.20090226105312.0230d868@nist.gov> <1235994124.5456.37.camel@localhost> <7.0.1.0.2.20090302091923.023b0470@nist.gov> <1236067992.4950.7.camel@localhost> <7.0.1.0.2.20090309095008.0240be88@nist.gov> 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: 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: <20090309164501.5AC743A69BD@core3.amsl.com> Message-ID: 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: <42D58C72A6CF4C8894B4CC4E0C64284D@ww300.siemens.net> 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: <3031BADB5B1C40EB81C8C61C858FE7F2@ww300.siemens.net> 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: <7.0.1.0.2.20090226105312.0230d868@nist.gov> <1235994124.5456.37.camel@localhost> <7.0.1.0.2.20090302091923.023b0470@nist.gov> <1236067992.4950.7.camel@localhost> Message-ID: <7.0.1.0.2.20090309095008.0240be88@nist.gov> 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: <4D35478224365146822AE9E3AD4A266606F3BBB2@exchtewks3.starentnetworks.com> Message-ID: <4D35478224365146822AE9E3AD4A266606F3BBDE@exchtewks3.starentnetworks.com> > 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: <49AFF92E.90302@nw.neclab.eu> Message-ID: Hi Marco, On 3/5/09 10:09 AM, "ext Marco Liebsch" 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: <49AFF92E.90302@nw.neclab.eu> Message-ID: <4D35478224365146822AE9E3AD4A266606F3BBB2@exchtewks3.starentnetworks.com> > > 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: <4D35478224365146822AE9E3AD4A266606DA852E@exchtewks3.starentnetworks.com> References: <4D35478224365146822AE9E3AD4A266606DA852E@exchtewks3.starentnetworks.com> Message-ID: <49AFF92E.90302@nw.neclab.eu> 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: <004b01c99d35$08e2d240$0301a8c0@china.huawei.com> 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" To: Cc: ; 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: <5F09D220B62F79418461A978CA0921BD032F6631@pslexc01.psl.local> 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: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ATT3139535.txt URL: From: vijay at wichorus.com (Vijay Devarapalli) Date: Wed, 4 Mar 2009 17:23:15 -0500 Subject: [Netext] PMIPv6 Multiple Interface support Message-ID: 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: <0C364F3D-9517-4334-8B02-46AA0D5774DF@gmail.com> References: <49AE6071.3020405@nw.neclab.eu> <0C364F3D-9517-4334-8B02-46AA0D5774DF@gmail.com> Message-ID: <49AEAC5F.7050706@nw.neclab.eu> 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: 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: 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: <49AE6071.3020405@nw.neclab.eu> References: <49AE6071.3020405@nw.neclab.eu> Message-ID: <0C364F3D-9517-4334-8B02-46AA0D5774DF@gmail.com> 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: <49AE6071.3020405@nw.neclab.eu> 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: <20090304091400.F3C3228C345@core3.amsl.com> Message-ID: <01fe01c99cab$c6bd3880$1b0ca40a@china.huawei.com> 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" To: Cc: ; 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: Message-ID: <014f01c99c3f$7d1e4be0$420c7c0a@china.huawei.com> 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" Subject: [Netext] Flow Binding in Proxy Mobile IPv6 To: 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: 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: <577640.78776.qm@web111413.mail.gq1.yahoo.com> References: <72EF061C-8076-4AED-8BA4-256B4220133D@gmail.com> <651471.39395.qm@web111409.mail.gq1.yahoo.com> <4EB335FE-B09F-4F03-A2BE-8302097960CB@gmail.com> <577640.78776.qm@web111413.mail.gq1.yahoo.com> Message-ID: <144CECD6-D262-4ABB-8FD9-6685029A6F26@gmail.com> Hi Bechet, On Feb 27, 2009, at 7:45 PM, Behcet Sarikaya wrote: > Hi Jouni, > My comments inline. > > Regards, > > --behcet > > From: jouni korhonen > To: Behcet Sarikaya > 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 > > 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: <7.0.1.0.2.20090302091923.023b0470@nist.gov> References: <7.0.1.0.2.20090226105312.0230d868@nist.gov> <1235994124.5456.37.camel@localhost> <7.0.1.0.2.20090302091923.023b0470@nist.gov> 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: 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: 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" Subject: [Netext] Flow Binding in Proxy Mobile IPv6 To: 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: 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: <7.0.1.0.2.20090226105312.0230d868@nist.gov> <1235994124.5456.37.camel@localhost> Message-ID: <7.0.1.0.2.20090302091923.023b0470@nist.gov> 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: <55D0E968239D40BB939A122625B3006A@ww300.siemens.net> Message-ID: <4D35478224365146822AE9E3AD4A266606DA852E@exchtewks3.starentnetworks.com> 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: <55D0E968239D40BB939A122625B3006A@ww300.siemens.net> References: <4D35478224365146822AE9E3AD4A266606D34389@exchtewks3.starentnetworks.com> <55D0E968239D40BB939A122625B3006A@ww300.siemens.net> Message-ID: <057632CE4CE10D45A1A3D6D19206C3A3DC0473A0@NASANEXMB08.na.qualcomm.com> 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: <4D35478224365146822AE9E3AD4A266606D34389@exchtewks3.starentnetworks.com> References: <4D35478224365146822AE9E3AD4A266606D34389@exchtewks3.starentnetworks.com> Message-ID: <55D0E968239D40BB939A122625B3006A@ww300.siemens.net> 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: <7.0.1.0.2.20090226105312.0230d868@nist.gov> References: <7.0.1.0.2.20090226105312.0230d868@nist.gov> 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: 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: <011c01c999cb$33c63b90$0201a8c0@china.huawei.com> 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" To: Cc: ; 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.