From: behcetsarikaya at yahoo.com (Behcet Sarikaya) Date: Fri, 27 Feb 2009 09:45:33 -0800 (PST) Subject: [Netext] Redirection Problem Statement In-Reply-To: <4EB335FE-B09F-4F03-A2BE-8302097960CB@gmail.com> References: <72EF061C-8076-4AED-8BA4-256B4220133D@gmail.com> <651471.39395.qm@web111409.mail.gq1.yahoo.com> <4EB335FE-B09F-4F03-A2BE-8302097960CB@gmail.com> Message-ID: <577640.78776.qm@web111413.mail.gq1.yahoo.com> 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 [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. ? ? 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 > > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From: rkoodli at starentnetworks.com (Koodli, Rajeev) Date: Fri, 27 Feb 2009 11:38:30 -0500 Subject: [Netext] Inter-technology handover PS In-Reply-To: Message-ID: <4D35478224365146822AE9E3AD4A266606D34389@exchtewks3.starentnetworks.com> 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 > > > > From: jouni.nospam at gmail.com (jouni korhonen) Date: Fri, 27 Feb 2009 14:49:24 +0200 Subject: [Netext] Redirection Problem Statement In-Reply-To: <651471.39395.qm@web111409.mail.gq1.yahoo.com> References: <72EF061C-8076-4AED-8BA4-256B4220133D@gmail.com> <651471.39395.qm@web111409.mail.gq1.yahoo.com> Message-ID: <4EB335FE-B09F-4F03-A2BE-8302097960CB@gmail.com> 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. 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: jouni.nospam at gmail.com (jouni korhonen) Date: Fri, 27 Feb 2009 14:12:42 +0200 Subject: [Netext] Redirection Problem Statement In-Reply-To: References: <72EF061C-8076-4AED-8BA4-256B4220133D@gmail.com> <0DF1178B-7A5A-4228-AA8B-61EC626CC1D0@gmail.com> Message-ID: <0ECC6933-388B-4EDF-B22D-B8683A0EDE7B@gmail.com> Hi Pierrick, [snip] >>> You seem to consider LMA switching only during PBU/PBA exchange. >>> When LMA redirection is expected to take place during an active >>> session, I the LMA should be able to initiate redirection: I mean >>> that the LMA should be able to notify, thanks to a dedicated >>> message, attached MAGs to switch to r2LMA. This feature could be >>> useful when the operator wants to shutdown a LMA for maintenance >>> reason. What do you think? >> >> I am primarily interested in the LMA redirection during the initial >> PBU/PBA exchange. The reason being that there is no state established >> yet on the LMA side (which also means the LMA has not either >> contacted >> the backend system). I would gain a lot in signaling and avoid >> unnecessary setup of state in various places. >> >> The LMA initiated redirection of an existing session is interesting >> and should also be studied. However, it involves a lot more, >> especially if we want to maintain the mobility session. >> > > For sure, LMA initiated redirection leads to a more sophisticated > mechanism; but, depending on the interest of the WG, it could be > interesting to include it in the ps draft. Let's see other comments > on the ML.... There were few I-Ds on this front: o draft-krishnan-mext-ha-redirect-01 o draft-ietf-mip6-hareliability-04 The latter is rather thorough, but does not necessarily fit in PMIP6 context. The PS I-D surfaces the LMA initiated redirect when the mobility session is already up & running but does not go into details such are related context transfer and how to deal with routing (when the HNP gets moved from LMA to another). I am open for proposals. Cheers, Jouni > > > Regards, > Pierrick > >> Cheers, >> Jouni >> From: domagoj.premec.ext at nsn.com (Domagoj Premec) Date: Fri, 27 Feb 2009 11:08:41 +0100 Subject: [Netext] Inter-technology handover PS In-Reply-To: <4D35478224365146822AE9E3AD4A266606D337F6@exchtewks3.starentnetworks.com> References: <4D35478224365146822AE9E3AD4A266606D337F6@exchtewks3.starentnetworks.com> Message-ID: Hi Rajeev, > > 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. 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? > 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. > > 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. 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. > 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. > 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. 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 > From: Telemaco.Melia at alcatel-lucent.com (MELIA TELEMACO) Date: Fri, 27 Feb 2009 10:21:37 +0100 Subject: [Netext] Inter-technology handover PS In-Reply-To: <4D35478224365146822AE9E3AD4A266606D337F6@exchtewks3.starentnetworks.com> References: <4D35478224365146822AE9E3AD4A266606D337F6@exchtewks3.starentnetworks.com> Message-ID: <853DD750D9C3724FBF2DF7164FCF641C029CC9A7@FRVELSMBS14.ad2.ad.alcatel.com> Hi Rajeev, Please see below. telemaco -----Message d'origine----- De : netext-bounces at mail.mobileip.jp [mailto:netext-bounces at mail.mobileip.jp] De la part de Koodli, Rajeev Envoy? : jeudi 26 f?vrier 2009 19:38 ? : netext at mail.mobileip.jp Objet : 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? [TELE] Well people already documented some of the issues in http://tools.ietf.org/html/draft-patil-dhc-apn-attachtype-options-00. I might agree that this is not in scope of netext, but at least we need to clearly identify the issues. 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 From: Mohana.Jeyatharan at sg.panasonic.com (Mohana Jeyatharan) Date: Fri, 27 Feb 2009 08:46:36 +0800 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> Message-ID: <5F09D220B62F79418461A978CA0921BD032F5D7F@pslexc01.psl.local> Hi David, Thanks for you summaries and comparisons. Please see in-line for some of my thoughts. Thanks. BR, Mohana -----Original Message----- From: netext-bounces at mail.mobileip.jp [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of David Cypher Sent: Friday, February 27, 2009 12:20 AM To: netext at mail.mobileip.jp Subject: [Netext] Inter-technology handovers PS considering Multihoming PS and Localized Routing PS 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) [Mohana] RFC 5213 supports same address during inter access technology handoff for session continuity. The multihoming PS is about being able to get packets addressed to a HNP via both the interfaces or a single address via both interfaes for the purpose of flow based routing and simultaneous usage such as being able to utilize multiple inetrfaces for flows that belong to a single HNP. Also, I think our focus is multihoming for different accesstechnology interfaces. 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). [Mohana] Yes, this is multihoming and is different from inter access technology handoff. I agree there is some overlap between multihoming and inter access technology handoff. We are about to have a revised draft soon for multihoming. In that we will classify issues that are tied to simultaneous attachment via different access technology types as main multihoming issues. And issues that are related to one interface connected and another interface involved in handoff as some sub issues. All the rest should be handled in the cateogory of pure inter access technology 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? [Mohana] This is a good point. I think currently the RO preoblem statement is considering route optimization with respect to a single interface. Which interface to use in a simultanously connected MN is not considered. I agree route optimization for multihomined or multiple interfaced Mn is distantly related to multihoming, but it is not really mutilhoming. I mean we cant lump all the issues w.r.t. multiple interfaces into multihoming. In the multihoming PS draft we have kind of defined the issues that are directly related multihoming. 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 From: xiayangsong at huawei.com (Frank Xia) Date: Thu, 26 Feb 2009 17:40:30 -0600 Subject: [Netext] Review of the Multihoming PS I-D References: <4D35478224365146822AE9E3AD4A266606D33B81@exchtewks3.starentnetworks.com> Message-ID: <00e801c9986b$9cbfd4f0$420c7c0a@china.huawei.com> Hi Rajeev I just had a quick look on your draft http://www.ietf.org/internet-drafts/draft-koodli-flow-handover-00.txt. It is great, and I also would appreciate you if you can review my draft http://www.ietf.org/internet-drafts/draft-xia-netext-flow-binding-00.txt which tried to solve the same problems. Just I discussed with Gerardo in the mailing list who I assume is also working on 3GPP 23.861, the motivation of flowing binding is to make full use of precious air resource. IMO, MAGs have more information on the usage of air interface than LMA. Thus, relating to your draft, my points are 1) In most case, MAGs initiate flow binding, which is consistent with MN's behavior in Mobile IPv6 flow binding. 2)T-MAG may be involved in flowing binding decision. S-MAG request offloading some traffic to T-MAG which has right to decide on it's own discretion. 3)Mostly your draft deal with downstreams redirection, while upstreams traffic treatment need more consideration. BR Frank ----- Original Message ----- From: "Koodli, Rajeev" To: Sent: Thursday, February 26, 2009 4:11 PM Subject: Re: [Netext] Review of the Multihoming PS I-D Hi, > IMO, the flow binding( or flow handover/flow mobility) > requirement is not neccessarily tied to address configuration > model of mobile nodes. > > Multiple interface may or may not shared HNP. My point is that when you move a flow (say belonging to HNP-1) from one interface to another (which has, say HNP-2), you can achieve flow mobility. In that sense you share HNP-1 across the two interfaces. Regards, -Rajeev > > BR > Frank > > > ----- Original Message ----- > From: "Koodli, Rajeev" > To: > Sent: Thursday, February 26, 2009 1:22 PM > Subject: Re: [Netext] Review of the Multihoming PS I-D > > > > Hello folks, > > If we allow the same HNP across multiple interfaces (as a form of > multihoming), then moving one or more flows would be a > natural extension I > think. At least, that's my thinking when writing > http://www.ietf.org/internet-drafts/draft-koodli-flow-handover > -00.txt last > year. > > Regards, > > -Rajeev > > > > -----Original Message----- > > From: netext-bounces at mail.mobileip.jp > > [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of Frank Xia > > Sent: Thursday, February 19, 2009 8:42 AM > > To: Giaretta, Gerardo; cjbc at it.uc3m.es; Basavaraj.Patil at nokia.com > > Cc: netext at mail.mobileip.jp; > > Mohana.Jeyatharan at sg.panasonic.com; > Telemaco.Melia at alcatel-lucent.com > > Subject: Re: [Netext] Review of the Multihoming PS I-D > > > > Hi Gerardo > > > > I know there is official requirement from 3GPP, and I am not > > offically asked to push in IETF either :-). > > > > >From business perspective, what operators care is how > > to make full use of their scarce air resource. > > This is one of main motivation to have dual mode terminals > > with 3GPP and WiFi (you can buy one from T-Mobile :-) ). > > > > When the dual mode terminal moves home where WLAN access is > > available, it prefer offloading some low QoS service from > > 3GPP to WiFi. At the same time, high QoS service still > > remains in 3GPP. > > > > BR > > Frank > > > > > > ----- Original Message ----- > > From: "Giaretta, Gerardo" > > To: "Frank Xia" ; ; > > > > Cc: ; ; > > > > Sent: Thursday, February 19, 2009 9:56 AM > > Subject: RE: [Netext] Review of the Multihoming PS I-D > > > > > > Hi Frank, > > > > I am happy if Huawei wants you to push this in the IETF, I > > hope you can make it :-) > > > > I wanted just to provide the indication that there is not any > > official requirement from 3GPP. > > > > We can then discuss about whatever business can drive this > > (what radios do you have in mind when you talk about > > multihoming and flow mobility for PMIP?). > > > > Gerardo > > > > > -----Original Message----- > > > From: Frank Xia [mailto:xiayangsong at huawei.com] > > > Sent: Thursday, February 19, 2009 7:51 AM > > > To: Giaretta, Gerardo; cjbc at it.uc3m.es; Basavaraj.Patil at nokia.com > > > Cc: netext at mail.mobileip.jp; Mohana.Jeyatharan at sg.panasonic.com; > > > Telemaco.Melia at alcatel-lucent.com > > > Subject: Re: [Netext] Review of the Multihoming PS I-D > > > > > > Hi All > > > > > > My 3GPP colleagues also suggested me pushing in IETF community. > > > If we talk about 3GPP requirment, there is even no specific PMIPv6 > > > multi-homing requirement. > > > > > > My point is business driving technical employment. > > > IMO, flow mobility is clearly required in PMIP deployment > > environment. > > > > > > BR > > > Frank > > > > > > ----- Original Message ----- > > > From: "Giaretta, Gerardo" > > > To: ; > > > Cc: ; > ; > > > > > > Sent: Thursday, February 19, 2009 4:16 AM > > > Subject: Re: [Netext] Review of the Multihoming PS I-D > > > > > > > > > Hi all, > > > > > > To clarify flow mobility is not a requirement for PMIPv6 > > right now in > > > 3GPP. > > > There is a study item ongoing but 3GPP has not yet decided > > that flow > > > mobility is needed for PMIPv6. > > > > > > Cheers, > > > Gerardo > > > (from Budapest, 3GPP SA2 meeting) > > > > > > > -----Original Message----- > > > > From: netext-bounces at mail.mobileip.jp > > > > [mailto:netext-bounces at mail.mobileip.jp] > > > > On Behalf Of Carlos Jes?s Bernardos Cano > > > > Sent: Thursday, February 19, 2009 1:21 AM > > > > To: Basavaraj.Patil at nokia.com > > > > Cc: Mohana.Jeyatharan at sg.panasonic.com; > > > > Telemaco.Melia at alcatel-lucent.com; > > > > netext at mail.mobileip.jp > > > > Subject: Re: [Netext] Review of the Multihoming PS I-D > > > > > > > > Hi, > > > > > > > > One question: flow mobility seems to be an interesting > > feature that > > > > is a requirement from 3GPP, it is related with > > multihoming but it is > > > > not strictly a multihoming isse, right? I mean, multihoming > > > > extensions would likely make easier to support flow > mobility, but > > > > would probably require additional mechanisms. How do we capture > > > > this? I'm not sure the multihoming PS is the right place > > for that, > > > > maybe the multihoming PS can point out that, but we need > > an explicit > > > > document (and charter item) for dealing with flow mobility. > > > > What > > > > do others think? > > > > > > > > Thanks! > > > > > > > > Carlos > > > > > > > > El mi?, 18-02-2009 a las 21:39 +0100, Basavaraj.Patil at nokia.com > > > > escribi?: > > > > > It may be of interest in the context of multihoming to > > consider moving > > > > > a flow from one interface to another. A flow which is > > associated with > > > > > an interface on the MN may be moved to another > > interface in the case > > > > > of a multihomed host for various reasons. This may be > > viewed as a > > > > > handover as well from the flow perspective. Multihoming > > enables the > > > > > possibility to move flows between interfaces. I think > > we could keep > > > > > this in the context of the multihoming discussion if there is > > > > > consensus > > > > > on > > > > it. > > > > > > > > > > -Raj > > > > > > > > > > > > > > > On 2/17/09 1:51 AM, "ext Mohana Jeyatharan" > > > > > wrote: > > > > > > > > > > > Hi Hidetoshi, > > > > > > > > > > > > In Multihoming PS ID, there are some handoff > > optimization scenarios > > > > involved. > > > > > > For example optmizing the handoff of a certain > > interface by means of > > > > > > another, and achieving flow mobility via another > > interface during > > > > > > disconnection. These events are triggered due to handoff or > > > > > > disconnection, but the scenarios are associated with > > multihoming. > > > > > > That is being able to receive a flow that is usually > > destined to an > > > > > > interface via another "connected" interface. This is > > where these > > > > > > scenarios are different from normal handoff and more tied to > > > > > > multihoming. > > > > > > > > > > > > However, I agree that these are also tied with > > handoff and some > > > > > > confusion is there. Anyway, we are planning to revise the > > > > > > multihoming PS draft and are thinking of focusing on the > > > > > > disconnection scenario, handoff optimization as less > > focus scenarios > > > > > > and > > > > focus on scenarios that are cateogorized by Raj. > > > > > > > > > > > > BR, > > > > > > Mohana > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Hidetoshi Yokota [mailto:yokota at kddilabs.jp] > > > > > > Sent: Tuesday, February 17, 2009 12:42 PM > > > > > > To: Mohana Jeyatharan > > > > > > Cc: Domagoj Premec; ext MELIA TELEMACO; Marco Liebsch; > > > > > > netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com > > > > > > Subject: Re: [Netext] Review of the Multihoming PS I-D > > > > > > > > > > > > Hi Mohana and all, > > > > > > > > > > > > I think your scenario is viable, but we should probably more > > > > > > carefully clarify the difference between multihoming > > and handover. > > > > > > Assigning the same address to different interfaces on > > the MN for a > > > > > > sufficiently long time sounds like multihoming; > > however, if this > > > > > > situation holds only for a short period of time for > > MN's movement or > > > > > > fail over or for whatever reason, that sounds like > > handover. This > > > > > > difference would affect the behavior of the LMA and MAG(s). > > > > > > > > > > > > In Section 2 of the Multihoming PS document, Issues > related to > > > > > > handoff performance and those related to flow > > mobility during sudden > > > > > > disconnection appear to be categorized into handover. > > If all agree > > > > > > that these issues should also be included in > > multihoming, that's > > > > > > fine. I would just like to make sure of it first of all. > > > > > > > > > > > > Regards, > > > > > > -- > > > > > > Hidetoshi > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > 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/ > > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > > > > > _______________________________________________ > > > 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, 26 Feb 2009 17:11:44 -0500 Subject: [Netext] Review of the Multihoming PS I-D In-Reply-To: <011d01c9984e$86bbdea0$420c7c0a@china.huawei.com> Message-ID: <4D35478224365146822AE9E3AD4A266606D33B81@exchtewks3.starentnetworks.com> Hi, > IMO, the flow binding( or flow handover/flow mobility) > requirement is not neccessarily tied to address configuration > model of mobile nodes. > > Multiple interface may or may not shared HNP. My point is that when you move a flow (say belonging to HNP-1) from one interface to another (which has, say HNP-2), you can achieve flow mobility. In that sense you share HNP-1 across the two interfaces. Regards, -Rajeev > > BR > Frank > > > ----- Original Message ----- > From: "Koodli, Rajeev" > To: > Sent: Thursday, February 26, 2009 1:22 PM > Subject: Re: [Netext] Review of the Multihoming PS I-D > > > > Hello folks, > > If we allow the same HNP across multiple interfaces (as a form of > multihoming), then moving one or more flows would be a > natural extension I > think. At least, that's my thinking when writing > http://www.ietf.org/internet-drafts/draft-koodli-flow-handover > -00.txt last > year. > > Regards, > > -Rajeev > > > > -----Original Message----- > > From: netext-bounces at mail.mobileip.jp > > [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of Frank Xia > > Sent: Thursday, February 19, 2009 8:42 AM > > To: Giaretta, Gerardo; cjbc at it.uc3m.es; Basavaraj.Patil at nokia.com > > Cc: netext at mail.mobileip.jp; > > Mohana.Jeyatharan at sg.panasonic.com; > Telemaco.Melia at alcatel-lucent.com > > Subject: Re: [Netext] Review of the Multihoming PS I-D > > > > Hi Gerardo > > > > I know there is official requirement from 3GPP, and I am not > > offically asked to push in IETF either :-). > > > > >From business perspective, what operators care is how > > to make full use of their scarce air resource. > > This is one of main motivation to have dual mode terminals > > with 3GPP and WiFi (you can buy one from T-Mobile :-) ). > > > > When the dual mode terminal moves home where WLAN access is > > available, it prefer offloading some low QoS service from > > 3GPP to WiFi. At the same time, high QoS service still > > remains in 3GPP. > > > > BR > > Frank > > > > > > ----- Original Message ----- > > From: "Giaretta, Gerardo" > > To: "Frank Xia" ; ; > > > > Cc: ; ; > > > > Sent: Thursday, February 19, 2009 9:56 AM > > Subject: RE: [Netext] Review of the Multihoming PS I-D > > > > > > Hi Frank, > > > > I am happy if Huawei wants you to push this in the IETF, I > > hope you can make it :-) > > > > I wanted just to provide the indication that there is not any > > official requirement from 3GPP. > > > > We can then discuss about whatever business can drive this > > (what radios do you have in mind when you talk about > > multihoming and flow mobility for PMIP?). > > > > Gerardo > > > > > -----Original Message----- > > > From: Frank Xia [mailto:xiayangsong at huawei.com] > > > Sent: Thursday, February 19, 2009 7:51 AM > > > To: Giaretta, Gerardo; cjbc at it.uc3m.es; Basavaraj.Patil at nokia.com > > > Cc: netext at mail.mobileip.jp; Mohana.Jeyatharan at sg.panasonic.com; > > > Telemaco.Melia at alcatel-lucent.com > > > Subject: Re: [Netext] Review of the Multihoming PS I-D > > > > > > Hi All > > > > > > My 3GPP colleagues also suggested me pushing in IETF community. > > > If we talk about 3GPP requirment, there is even no specific PMIPv6 > > > multi-homing requirement. > > > > > > My point is business driving technical employment. > > > IMO, flow mobility is clearly required in PMIP deployment > > environment. > > > > > > BR > > > Frank > > > > > > ----- Original Message ----- > > > From: "Giaretta, Gerardo" > > > To: ; > > > Cc: ; > ; > > > > > > Sent: Thursday, February 19, 2009 4:16 AM > > > Subject: Re: [Netext] Review of the Multihoming PS I-D > > > > > > > > > Hi all, > > > > > > To clarify flow mobility is not a requirement for PMIPv6 > > right now in > > > 3GPP. > > > There is a study item ongoing but 3GPP has not yet decided > > that flow > > > mobility is needed for PMIPv6. > > > > > > Cheers, > > > Gerardo > > > (from Budapest, 3GPP SA2 meeting) > > > > > > > -----Original Message----- > > > > From: netext-bounces at mail.mobileip.jp > > > > [mailto:netext-bounces at mail.mobileip.jp] > > > > On Behalf Of Carlos Jes?s Bernardos Cano > > > > Sent: Thursday, February 19, 2009 1:21 AM > > > > To: Basavaraj.Patil at nokia.com > > > > Cc: Mohana.Jeyatharan at sg.panasonic.com; > > > > Telemaco.Melia at alcatel-lucent.com; > > > > netext at mail.mobileip.jp > > > > Subject: Re: [Netext] Review of the Multihoming PS I-D > > > > > > > > Hi, > > > > > > > > One question: flow mobility seems to be an interesting > > feature that > > > > is a requirement from 3GPP, it is related with > > multihoming but it is > > > > not strictly a multihoming isse, right? I mean, multihoming > > > > extensions would likely make easier to support flow > mobility, but > > > > would probably require additional mechanisms. How do we capture > > > > this? I'm not sure the multihoming PS is the right place > > for that, > > > > maybe the multihoming PS can point out that, but we need > > an explicit > > > > document (and charter item) for dealing with flow mobility. > > > > What > > > > do others think? > > > > > > > > Thanks! > > > > > > > > Carlos > > > > > > > > El mi?, 18-02-2009 a las 21:39 +0100, Basavaraj.Patil at nokia.com > > > > escribi?: > > > > > It may be of interest in the context of multihoming to > > consider moving > > > > > a flow from one interface to another. A flow which is > > associated with > > > > > an interface on the MN may be moved to another > > interface in the case > > > > > of a multihomed host for various reasons. This may be > > viewed as a > > > > > handover as well from the flow perspective. Multihoming > > enables the > > > > > possibility to move flows between interfaces. I think > > we could keep > > > > > this in the context of the multihoming discussion if there is > > > > > consensus > > > > > on > > > > it. > > > > > > > > > > -Raj > > > > > > > > > > > > > > > On 2/17/09 1:51 AM, "ext Mohana Jeyatharan" > > > > > wrote: > > > > > > > > > > > Hi Hidetoshi, > > > > > > > > > > > > In Multihoming PS ID, there are some handoff > > optimization scenarios > > > > involved. > > > > > > For example optmizing the handoff of a certain > > interface by means of > > > > > > another, and achieving flow mobility via another > > interface during > > > > > > disconnection. These events are triggered due to handoff or > > > > > > disconnection, but the scenarios are associated with > > multihoming. > > > > > > That is being able to receive a flow that is usually > > destined to an > > > > > > interface via another "connected" interface. This is > > where these > > > > > > scenarios are different from normal handoff and more tied to > > > > > > multihoming. > > > > > > > > > > > > However, I agree that these are also tied with > > handoff and some > > > > > > confusion is there. Anyway, we are planning to revise the > > > > > > multihoming PS draft and are thinking of focusing on the > > > > > > disconnection scenario, handoff optimization as less > > focus scenarios > > > > > > and > > > > focus on scenarios that are cateogorized by Raj. > > > > > > > > > > > > BR, > > > > > > Mohana > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Hidetoshi Yokota [mailto:yokota at kddilabs.jp] > > > > > > Sent: Tuesday, February 17, 2009 12:42 PM > > > > > > To: Mohana Jeyatharan > > > > > > Cc: Domagoj Premec; ext MELIA TELEMACO; Marco Liebsch; > > > > > > netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com > > > > > > Subject: Re: [Netext] Review of the Multihoming PS I-D > > > > > > > > > > > > Hi Mohana and all, > > > > > > > > > > > > I think your scenario is viable, but we should probably more > > > > > > carefully clarify the difference between multihoming > > and handover. > > > > > > Assigning the same address to different interfaces on > > the MN for a > > > > > > sufficiently long time sounds like multihoming; > > however, if this > > > > > > situation holds only for a short period of time for > > MN's movement or > > > > > > fail over or for whatever reason, that sounds like > > handover. This > > > > > > difference would affect the behavior of the LMA and MAG(s). > > > > > > > > > > > > In Section 2 of the Multihoming PS document, Issues > related to > > > > > > handoff performance and those related to flow > > mobility during sudden > > > > > > disconnection appear to be categorized into handover. > > If all agree > > > > > > that these issues should also be included in > > multihoming, that's > > > > > > fine. I would just like to make sure of it first of all. > > > > > > > > > > > > Regards, > > > > > > -- > > > > > > Hidetoshi > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > 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/ > > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > > > > > _______________________________________________ > > > 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: Thu, 26 Feb 2009 14:12:18 -0600 Subject: [Netext] Review of the Multihoming PS I-D References: <4D35478224365146822AE9E3AD4A266606D338E0@exchtewks3.starentnetworks.com> Message-ID: <011d01c9984e$86bbdea0$420c7c0a@china.huawei.com> Hi Rajeev IMO, the flow binding( or flow handover/flow mobility) requirement is not neccessarily tied to address configuration model of mobile nodes. Multiple interface may or may not shared HNP. BR Frank ----- Original Message ----- From: "Koodli, Rajeev" To: Sent: Thursday, February 26, 2009 1:22 PM Subject: Re: [Netext] Review of the Multihoming PS I-D Hello folks, If we allow the same HNP across multiple interfaces (as a form of multihoming), then moving one or more flows would be a natural extension I think. At least, that's my thinking when writing http://www.ietf.org/internet-drafts/draft-koodli-flow-handover-00.txt last year. Regards, -Rajeev > -----Original Message----- > From: netext-bounces at mail.mobileip.jp > [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of Frank Xia > Sent: Thursday, February 19, 2009 8:42 AM > To: Giaretta, Gerardo; cjbc at it.uc3m.es; Basavaraj.Patil at nokia.com > Cc: netext at mail.mobileip.jp; > Mohana.Jeyatharan at sg.panasonic.com; Telemaco.Melia at alcatel-lucent.com > Subject: Re: [Netext] Review of the Multihoming PS I-D > > Hi Gerardo > > I know there is official requirement from 3GPP, and I am not > offically asked to push in IETF either :-). > > >From business perspective, what operators care is how > to make full use of their scarce air resource. > This is one of main motivation to have dual mode terminals > with 3GPP and WiFi (you can buy one from T-Mobile :-) ). > > When the dual mode terminal moves home where WLAN access is > available, it prefer offloading some low QoS service from > 3GPP to WiFi. At the same time, high QoS service still > remains in 3GPP. > > BR > Frank > > > ----- Original Message ----- > From: "Giaretta, Gerardo" > To: "Frank Xia" ; ; > > Cc: ; ; > > Sent: Thursday, February 19, 2009 9:56 AM > Subject: RE: [Netext] Review of the Multihoming PS I-D > > > Hi Frank, > > I am happy if Huawei wants you to push this in the IETF, I > hope you can make it :-) > > I wanted just to provide the indication that there is not any > official requirement from 3GPP. > > We can then discuss about whatever business can drive this > (what radios do you have in mind when you talk about > multihoming and flow mobility for PMIP?). > > Gerardo > > > -----Original Message----- > > From: Frank Xia [mailto:xiayangsong at huawei.com] > > Sent: Thursday, February 19, 2009 7:51 AM > > To: Giaretta, Gerardo; cjbc at it.uc3m.es; Basavaraj.Patil at nokia.com > > Cc: netext at mail.mobileip.jp; Mohana.Jeyatharan at sg.panasonic.com; > > Telemaco.Melia at alcatel-lucent.com > > Subject: Re: [Netext] Review of the Multihoming PS I-D > > > > Hi All > > > > My 3GPP colleagues also suggested me pushing in IETF community. > > If we talk about 3GPP requirment, there is even no specific PMIPv6 > > multi-homing requirement. > > > > My point is business driving technical employment. > > IMO, flow mobility is clearly required in PMIP deployment > environment. > > > > BR > > Frank > > > > ----- Original Message ----- > > From: "Giaretta, Gerardo" > > To: ; > > Cc: ; ; > > > > Sent: Thursday, February 19, 2009 4:16 AM > > Subject: Re: [Netext] Review of the Multihoming PS I-D > > > > > > Hi all, > > > > To clarify flow mobility is not a requirement for PMIPv6 > right now in > > 3GPP. > > There is a study item ongoing but 3GPP has not yet decided > that flow > > mobility is needed for PMIPv6. > > > > Cheers, > > Gerardo > > (from Budapest, 3GPP SA2 meeting) > > > > > -----Original Message----- > > > From: netext-bounces at mail.mobileip.jp > > > [mailto:netext-bounces at mail.mobileip.jp] > > > On Behalf Of Carlos Jes?s Bernardos Cano > > > Sent: Thursday, February 19, 2009 1:21 AM > > > To: Basavaraj.Patil at nokia.com > > > Cc: Mohana.Jeyatharan at sg.panasonic.com; > > > Telemaco.Melia at alcatel-lucent.com; > > > netext at mail.mobileip.jp > > > Subject: Re: [Netext] Review of the Multihoming PS I-D > > > > > > Hi, > > > > > > One question: flow mobility seems to be an interesting > feature that > > > is a requirement from 3GPP, it is related with > multihoming but it is > > > not strictly a multihoming isse, right? I mean, multihoming > > > extensions would likely make easier to support flow mobility, but > > > would probably require additional mechanisms. How do we capture > > > this? I'm not sure the multihoming PS is the right place > for that, > > > maybe the multihoming PS can point out that, but we need > an explicit > > > document (and charter item) for dealing with flow mobility. > > > What > > > do others think? > > > > > > Thanks! > > > > > > Carlos > > > > > > El mi?, 18-02-2009 a las 21:39 +0100, Basavaraj.Patil at nokia.com > > > escribi?: > > > > It may be of interest in the context of multihoming to > consider moving > > > > a flow from one interface to another. A flow which is > associated with > > > > an interface on the MN may be moved to another > interface in the case > > > > of a multihomed host for various reasons. This may be > viewed as a > > > > handover as well from the flow perspective. Multihoming > enables the > > > > possibility to move flows between interfaces. I think > we could keep > > > > this in the context of the multihoming discussion if there is > > > > consensus > > > > on > > > it. > > > > > > > > -Raj > > > > > > > > > > > > On 2/17/09 1:51 AM, "ext Mohana Jeyatharan" > > > > wrote: > > > > > > > > > Hi Hidetoshi, > > > > > > > > > > In Multihoming PS ID, there are some handoff > optimization scenarios > > > involved. > > > > > For example optmizing the handoff of a certain > interface by means of > > > > > another, and achieving flow mobility via another > interface during > > > > > disconnection. These events are triggered due to handoff or > > > > > disconnection, but the scenarios are associated with > multihoming. > > > > > That is being able to receive a flow that is usually > destined to an > > > > > interface via another "connected" interface. This is > where these > > > > > scenarios are different from normal handoff and more tied to > > > > > multihoming. > > > > > > > > > > However, I agree that these are also tied with > handoff and some > > > > > confusion is there. Anyway, we are planning to revise the > > > > > multihoming PS draft and are thinking of focusing on the > > > > > disconnection scenario, handoff optimization as less > focus scenarios > > > > > and > > > focus on scenarios that are cateogorized by Raj. > > > > > > > > > > BR, > > > > > Mohana > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Hidetoshi Yokota [mailto:yokota at kddilabs.jp] > > > > > Sent: Tuesday, February 17, 2009 12:42 PM > > > > > To: Mohana Jeyatharan > > > > > Cc: Domagoj Premec; ext MELIA TELEMACO; Marco Liebsch; > > > > > netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com > > > > > Subject: Re: [Netext] Review of the Multihoming PS I-D > > > > > > > > > > Hi Mohana and all, > > > > > > > > > > I think your scenario is viable, but we should probably more > > > > > carefully clarify the difference between multihoming > and handover. > > > > > Assigning the same address to different interfaces on > the MN for a > > > > > sufficiently long time sounds like multihoming; > however, if this > > > > > situation holds only for a short period of time for > MN's movement or > > > > > fail over or for whatever reason, that sounds like > handover. This > > > > > difference would affect the behavior of the LMA and MAG(s). > > > > > > > > > > In Section 2 of the Multihoming PS document, Issues related to > > > > > handoff performance and those related to flow > mobility during sudden > > > > > disconnection appear to be categorized into handover. > If all agree > > > > > that these issues should also be included in > multihoming, that's > > > > > fine. I would just like to make sure of it first of all. > > > > > > > > > > Regards, > > > > > -- > > > > > Hidetoshi > > > > > > > > > > > > > > > > > _______________________________________________ > > > > 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/ > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > > > _______________________________________________ > > 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, 26 Feb 2009 14:22:43 -0500 Subject: [Netext] Review of the Multihoming PS I-D In-Reply-To: <00a501c992b0$ef4e3830$420c7c0a@china.huawei.com> Message-ID: <4D35478224365146822AE9E3AD4A266606D338E0@exchtewks3.starentnetworks.com> Hello folks, If we allow the same HNP across multiple interfaces (as a form of multihoming), then moving one or more flows would be a natural extension I think. At least, that's my thinking when writing http://www.ietf.org/internet-drafts/draft-koodli-flow-handover-00.txt last year. Regards, -Rajeev > -----Original Message----- > From: netext-bounces at mail.mobileip.jp > [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of Frank Xia > Sent: Thursday, February 19, 2009 8:42 AM > To: Giaretta, Gerardo; cjbc at it.uc3m.es; Basavaraj.Patil at nokia.com > Cc: netext at mail.mobileip.jp; > Mohana.Jeyatharan at sg.panasonic.com; Telemaco.Melia at alcatel-lucent.com > Subject: Re: [Netext] Review of the Multihoming PS I-D > > Hi Gerardo > > I know there is official requirement from 3GPP, and I am not > offically asked to push in IETF either :-). > > >From business perspective, what operators care is how > to make full use of their scarce air resource. > This is one of main motivation to have dual mode terminals > with 3GPP and WiFi (you can buy one from T-Mobile :-) ). > > When the dual mode terminal moves home where WLAN access is > available, it prefer offloading some low QoS service from > 3GPP to WiFi. At the same time, high QoS service still > remains in 3GPP. > > BR > Frank > > > ----- Original Message ----- > From: "Giaretta, Gerardo" > To: "Frank Xia" ; ; > > Cc: ; ; > > Sent: Thursday, February 19, 2009 9:56 AM > Subject: RE: [Netext] Review of the Multihoming PS I-D > > > Hi Frank, > > I am happy if Huawei wants you to push this in the IETF, I > hope you can make it :-) > > I wanted just to provide the indication that there is not any > official requirement from 3GPP. > > We can then discuss about whatever business can drive this > (what radios do you have in mind when you talk about > multihoming and flow mobility for PMIP?). > > Gerardo > > > -----Original Message----- > > From: Frank Xia [mailto:xiayangsong at huawei.com] > > Sent: Thursday, February 19, 2009 7:51 AM > > To: Giaretta, Gerardo; cjbc at it.uc3m.es; Basavaraj.Patil at nokia.com > > Cc: netext at mail.mobileip.jp; Mohana.Jeyatharan at sg.panasonic.com; > > Telemaco.Melia at alcatel-lucent.com > > Subject: Re: [Netext] Review of the Multihoming PS I-D > > > > Hi All > > > > My 3GPP colleagues also suggested me pushing in IETF community. > > If we talk about 3GPP requirment, there is even no specific PMIPv6 > > multi-homing requirement. > > > > My point is business driving technical employment. > > IMO, flow mobility is clearly required in PMIP deployment > environment. > > > > BR > > Frank > > > > ----- Original Message ----- > > From: "Giaretta, Gerardo" > > To: ; > > Cc: ; ; > > > > Sent: Thursday, February 19, 2009 4:16 AM > > Subject: Re: [Netext] Review of the Multihoming PS I-D > > > > > > Hi all, > > > > To clarify flow mobility is not a requirement for PMIPv6 > right now in > > 3GPP. > > There is a study item ongoing but 3GPP has not yet decided > that flow > > mobility is needed for PMIPv6. > > > > Cheers, > > Gerardo > > (from Budapest, 3GPP SA2 meeting) > > > > > -----Original Message----- > > > From: netext-bounces at mail.mobileip.jp > > > [mailto:netext-bounces at mail.mobileip.jp] > > > On Behalf Of Carlos Jes?s Bernardos Cano > > > Sent: Thursday, February 19, 2009 1:21 AM > > > To: Basavaraj.Patil at nokia.com > > > Cc: Mohana.Jeyatharan at sg.panasonic.com; > > > Telemaco.Melia at alcatel-lucent.com; > > > netext at mail.mobileip.jp > > > Subject: Re: [Netext] Review of the Multihoming PS I-D > > > > > > Hi, > > > > > > One question: flow mobility seems to be an interesting > feature that > > > is a requirement from 3GPP, it is related with > multihoming but it is > > > not strictly a multihoming isse, right? I mean, multihoming > > > extensions would likely make easier to support flow mobility, but > > > would probably require additional mechanisms. How do we capture > > > this? I'm not sure the multihoming PS is the right place > for that, > > > maybe the multihoming PS can point out that, but we need > an explicit > > > document (and charter item) for dealing with flow mobility. > > > What > > > do others think? > > > > > > Thanks! > > > > > > Carlos > > > > > > El mi?, 18-02-2009 a las 21:39 +0100, Basavaraj.Patil at nokia.com > > > escribi?: > > > > It may be of interest in the context of multihoming to > consider moving > > > > a flow from one interface to another. A flow which is > associated with > > > > an interface on the MN may be moved to another > interface in the case > > > > of a multihomed host for various reasons. This may be > viewed as a > > > > handover as well from the flow perspective. Multihoming > enables the > > > > possibility to move flows between interfaces. I think > we could keep > > > > this in the context of the multihoming discussion if there is > > > > consensus > > > > on > > > it. > > > > > > > > -Raj > > > > > > > > > > > > On 2/17/09 1:51 AM, "ext Mohana Jeyatharan" > > > > wrote: > > > > > > > > > Hi Hidetoshi, > > > > > > > > > > In Multihoming PS ID, there are some handoff > optimization scenarios > > > involved. > > > > > For example optmizing the handoff of a certain > interface by means of > > > > > another, and achieving flow mobility via another > interface during > > > > > disconnection. These events are triggered due to handoff or > > > > > disconnection, but the scenarios are associated with > multihoming. > > > > > That is being able to receive a flow that is usually > destined to an > > > > > interface via another "connected" interface. This is > where these > > > > > scenarios are different from normal handoff and more tied to > > > > > multihoming. > > > > > > > > > > However, I agree that these are also tied with > handoff and some > > > > > confusion is there. Anyway, we are planning to revise the > > > > > multihoming PS draft and are thinking of focusing on the > > > > > disconnection scenario, handoff optimization as less > focus scenarios > > > > > and > > > focus on scenarios that are cateogorized by Raj. > > > > > > > > > > BR, > > > > > Mohana > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Hidetoshi Yokota [mailto:yokota at kddilabs.jp] > > > > > Sent: Tuesday, February 17, 2009 12:42 PM > > > > > To: Mohana Jeyatharan > > > > > Cc: Domagoj Premec; ext MELIA TELEMACO; Marco Liebsch; > > > > > netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com > > > > > Subject: Re: [Netext] Review of the Multihoming PS I-D > > > > > > > > > > Hi Mohana and all, > > > > > > > > > > I think your scenario is viable, but we should probably more > > > > > carefully clarify the difference between multihoming > and handover. > > > > > Assigning the same address to different interfaces on > the MN for a > > > > > sufficiently long time sounds like multihoming; > however, if this > > > > > situation holds only for a short period of time for > MN's movement or > > > > > fail over or for whatever reason, that sounds like > handover. This > > > > > difference would affect the behavior of the LMA and MAG(s). > > > > > > > > > > In Section 2 of the Multihoming PS document, Issues related to > > > > > handoff performance and those related to flow > mobility during sudden > > > > > disconnection appear to be categorized into handover. > If all agree > > > > > that these issues should also be included in > multihoming, that's > > > > > fine. I would just like to make sure of it first of all. > > > > > > > > > > Regards, > > > > > -- > > > > > Hidetoshi > > > > > > > > > > > > > > > > > _______________________________________________ > > > > 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/ > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > > > _______________________________________________ > > 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, 26 Feb 2009 14:20:06 -0500 Subject: [Netext] Inter-technology handover PS In-Reply-To: <057632CE4CE10D45A1A3D6D19206C3A3DBEF40A9@NASANEXMB08.na.qualcomm.com> Message-ID: <4D35478224365146822AE9E3AD4A266606D338D4@exchtewks3.starentnetworks.com> Hi Gerardo, I mostly agree with you. But, to be clear, the "gaps" need to be addressed either by the access systems or by the IP layer. Regards, -Rajeev > -----Original Message----- > From: Giaretta, Gerardo [mailto:gerardog at qualcomm.com] > Sent: Thursday, February 26, 2009 10:00 AM > To: MELIA TELEMACO; Domagoj Premec; Koodli, Rajeev; > netext at mail.mobileip.jp > Subject: RE: [Netext] Inter-technology handover PS > > Hi all, > > Sorry jumping into the discussion. I think Rajeev may have a > point here. My understanding is that PMIP makes sense when > the access provides the capability to use it, so there is a > layer 2 signaling which provides the necessary information to the MAG. > > Inventing a layer 3 protocol for handover indication or > similar would mean reinventing the wheel in my opinion. We > have already one protocol which does that and it is MIPv4 in > FA mode :-) > > Cheers > Gerardo > > > > > > -----Original Message----- > From: MELIA TELEMACO > Sent: Thursday, February 26, 2009 9:42 AM > To: Domagoj Premec ; ext Koodli, > Rajeev ; netext at mail.mobileip.jp > > Subject: Re: [Netext] Inter-technology handover PS > > > Hi, > > I could not agree more on this. > > telemaco > > -----Message d'origine----- > De : netext-bounces at mail.mobileip.jp > [mailto:netext-bounces at mail.mobileip.jp] De la part de > Domagoj Premec Envoy? : jeudi 26 f?vrier 2009 13:25 ? : 'ext > Koodli, Rajeev'; netext at mail.mobileip.jp Objet : Re: [Netext] > Inter-technology handover PS > > Hi Rajeev, > > > 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? > > Using access specific mechanims is fine for the cases where > the access system actually provides the needed functionality. > 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. > > 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: rkoodli at starentnetworks.com (Koodli, Rajeev) Date: Thu, 26 Feb 2009 13:38:26 -0500 Subject: [Netext] Inter-technology handover PS In-Reply-To: Message-ID: <4D35478224365146822AE9E3AD4A266606D337F6@exchtewks3.starentnetworks.com> 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 > > > > From: rkoodli at starentnetworks.com (Koodli, Rajeev) Date: Thu, 26 Feb 2009 13:28:27 -0500 Subject: [Netext] Inter-technology handover PS In-Reply-To: <853DD750D9C3724FBF2DF7164FCF641C029CC83D@FRVELSMBS14.ad2.ad.alcatel.com> Message-ID: <4D35478224365146822AE9E3AD4A266606D337C1@exchtewks3.starentnetworks.com> > Hi Rajeev, Hi, > please see below. See my replies.. > [TELE] We have a document in mipshop > (draft-ietf-mipshop-transient-bce-pmipv6) enabling the use of > temporary BCE entries for a MN to optimize handovers. Section > 4.6 specifies what issues are out of scope. I believe we > should start from there and take over this issues in Netext. Yes, and let's leave it in MIPSHOP for now. We are not discussing the solutions. Let's put some focus on problem and arrive at consensus. I believe we are making good progress. > > 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? > > [TELE] There are cases (e.g. WIMAX) where link layer > mechanisms are not sufficient and require extensions at IP > layer. We should take this into account. > How does handover work in Wimax today? -Rajeev > 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 > From: gerardog at qualcomm.com (Giaretta, Gerardo) Date: Thu, 26 Feb 2009 09:59:44 -0800 Subject: [Netext] Inter-technology handover PS Message-ID: <057632CE4CE10D45A1A3D6D19206C3A3DBEF40A9@NASANEXMB08.na.qualcomm.com> Hi all, Sorry jumping into the discussion. I think Rajeev may have a point here. My understanding is that PMIP makes sense when the access provides the capability to use it, so there is a layer 2 signaling which provides the necessary information to the MAG. Inventing a layer 3 protocol for handover indication or similar would mean reinventing the wheel in my opinion. We have already one protocol which does that and it is MIPv4 in FA mode :-) Cheers Gerardo -----Original Message----- From: MELIA TELEMACO Sent: Thursday, February 26, 2009 9:42 AM To: Domagoj Premec ; ext Koodli, Rajeev ; netext at mail.mobileip.jp Subject: Re: [Netext] Inter-technology handover PS Hi, I could not agree more on this. telemaco -----Message d'origine----- De : netext-bounces at mail.mobileip.jp [mailto:netext-bounces at mail.mobileip.jp] De la part de Domagoj Premec Envoy? : jeudi 26 f?vrier 2009 13:25 ? : 'ext Koodli, Rajeev'; netext at mail.mobileip.jp Objet : Re: [Netext] Inter-technology handover PS Hi Rajeev, > 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? Using access specific mechanims is fine for the cases where the access system actually provides the needed functionality. 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. 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: Telemaco.Melia at alcatel-lucent.com (MELIA TELEMACO) Date: Thu, 26 Feb 2009 18:40:30 +0100 Subject: [Netext] Inter-technology handover PS In-Reply-To: References: <499DE8FA.3040803@ericsson.com><4D35478224365146822AE9E3AD4A266606C0EF20@exchtewks3.starentnetworks.com> Message-ID: <853DD750D9C3724FBF2DF7164FCF641C029CC83F@FRVELSMBS14.ad2.ad.alcatel.com> Hi, I could not agree more on this. telemaco -----Message d'origine----- De : netext-bounces at mail.mobileip.jp [mailto:netext-bounces at mail.mobileip.jp] De la part de Domagoj Premec Envoy? : jeudi 26 f?vrier 2009 13:25 ? : 'ext Koodli, Rajeev'; netext at mail.mobileip.jp Objet : Re: [Netext] Inter-technology handover PS Hi Rajeev, > 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? Using access specific mechanims is fine for the cases where the access system actually provides the needed functionality. 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. 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 From: Telemaco.Melia at alcatel-lucent.com (MELIA TELEMACO) Date: Thu, 26 Feb 2009 18:39:11 +0100 Subject: [Netext] Inter-technology handover PS In-Reply-To: <4D35478224365146822AE9E3AD4A266606C0EF20@exchtewks3.starentnetworks.com> References: <499DE8FA.3040803@ericsson.com> <4D35478224365146822AE9E3AD4A266606C0EF20@exchtewks3.starentnetworks.com> Message-ID: <853DD750D9C3724FBF2DF7164FCF641C029CC83D@FRVELSMBS14.ad2.ad.alcatel.com> Hi Rajeev, please see below. Telemaco -----Message d'origine----- De : netext-bounces at mail.mobileip.jp [mailto:netext-bounces at mail.mobileip.jp] De la part de Koodli, Rajeev Envoy? : mardi 24 f?vrier 2009 23:01 ? : netext at mail.mobileip.jp Objet : 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. [TELE] We have a document in mipshop (draft-ietf-mipshop-transient-bce-pmipv6) enabling the use of temporary BCE entries for a MN to optimize handovers. Section 4.6 specifies what issues are out of scope. I believe we should start from there and take over this issues in Netext. 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? [TELE] There are cases (e.g. WIMAX) where link layer mechanisms are not sufficient and require extensions at IP layer. We should take this into account. 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 From: Telemaco.Melia at alcatel-lucent.com (MELIA TELEMACO) Date: Thu, 26 Feb 2009 18:14:24 +0100 Subject: [Netext] Few considerations on the weak/strong host model Message-ID: <853DD750D9C3724FBF2DF7164FCF641C029CC811@FRVELSMBS14.ad2.ad.alcatel.com> Hi all, After the recent discussions on multihoming support (we did write this email before David's review), we decided to have a look on what we can do today without modifying the host. We know this is already digging into the solution space, necessary however to get the complete picture. Here our findings. We have been doing a bit of research on the applicability of the weak model as defined in RFC 1122. [short reminder on what the weak host model is: in the weak host model, an IP host (either IPv4 or IPv6) can send packets on an interface that is not assigned the source IP address of the packet being sent. An IP host can also receive packets on an interface that is not assigned the destination IP address of the packet being received.] It seems that Windows XP and Windows Server 2003 use the weak host model for sends and receives for all IPv4 interfaces and the strong host model for sends and receives for all IPv6 interfaces. This behavior cannot be configured. The Next Generation TCP/IP stack in Windows Vista and Windows Server 2008 should support strong host sends and receives for both IPv4 and IPv6 by default. You can configure the stack to use the weak host send/receive. It seems that Linux uses by default the weak model for IPv4 and IPv6. We've also tried Mac OS X 10.5 (Leopard) and it also seems to use the weak model for both IPv4 and IPv6. In addition we've tested it with a Linux laptop and a macbook pro. The above tests resulted to be quite promising. Of course if people encountered different behaviors they should speak up. We believe the adoption of this solution would help PMIPv6 in multihoming operations by letting the LMA to route packets (flows) to the right interface (same or different HNP). What do people think? Cheers Carlos&Telemaco -------------- next part -------------- An HTML attachment was scrubbed... URL: From: david.cypher at nist.gov (David Cypher) Date: Thu, 26 Feb 2009 11:20:12 -0500 Subject: [Netext] Inter-technology handovers PS considering Multihoming PS and Localized Routing PS Message-ID: <7.0.1.0.2.20090226105312.0230d868@nist.gov> 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 From: david.cypher at nist.gov (David Cypher) Date: Thu, 26 Feb 2009 10:52:10 -0500 Subject: [Netext] Inter-technology handover PS Message-ID: <7.0.1.0.2.20090226102155.02407368@nist.gov> I've taken a different perspective when looking at the "Inter-technology handover Problem Statement." First I looked at what are (were) the services to be provided by the original PMIP defined in RFC 5213 and I arrived at these five services: 1) No requirement for mobile node participation in any mobility-related signalling 2) Mobile Home network prefix (MN-HNP) assigned per interface 3) Each interface considered a separate mobility session 4) Ensures that the mobile node does not detect any change with respect to its layer-3 attachment even after changing its point of attachment in the network. 5) Handoff occurs as two different cases when using - i) different interfaces (same technology or different technology) - ii) same interface different MAGs Second I looked at the issues identified in the Inter-technology handovers Problem statement 2.1 Formation of interface identifier Original PMIP Service Handover between different interfaces may not work if stateless IPv6 auto address configuration is used? This is true by definition of the procedures defined in RFC 4862. If a MN-HNP (with length of 64) is used with stateless IPv6 auto address configuration, then this situation cannot be prevented. Solution: use either DHCP or MN-HNP (with length 128). 2.2 Usage of the same address on multiple interfaces This violates the Original PMIP service definition of MN-HNP being assigned per interface. Except for the short-lived period for handover for one interface to another interface. NEW SERVICE being requested same address on multiple interfaces and not part of a handover. 2.3 Limitiations of interface I do not understand 3.1 Access selection For what purpose does the network want to decide which access technology to let the MN join with? PMIP is to provide access and a single link to the MN. It does this when the mobile node attaches to a MAG. Once the MN is attached, the network knows the access type. Is the network trying to provide predictive handover? 3.2 Detecting handover When a MN only has one interface there is no problem, since it can only connect to one MAG at a time, which indicates handover. When a MN has more than one interface the network has no clue what the intent (two same interfaces, two different interfaces) of the MN is. Currently if a second interface using the same technology attaches to the same MAG or different MAG. It will be treated as a second interface and receive another set of MN-HNPs. Unless the MAG was indicated that it was a handover between interfaces. NEW SERVICE being requested ability to determine the intent (handover or multiple access) of the mobile node when it attaches with a second interface either of the same access technology type or a different access technology type. Since only the mobile node knows what it is intending, this issue has no solution without this information being exchanged from the MN to the network. 3.3 Predictive handover When a MN only has one interface there is no problem. When a MN has more than two interfaces - a) should the PMIP service assume a handover between the two interfaces? (resulting in only one path to the MN over one interface) ? or - b) should the PMIP service assume a second interface (multiple attachments and no handover)? - c) should the PMIP service provide the same MN-HNP? or - d) should the PMIP service provide a different MN-HNP? Using the original service of PMIP for if PMIP receives some indication from somewhere that this is a hand over, then the result is a single path to the MN using the same MN-HNP. Using the original service of PMIP for if PMIP does not receive some indication from somewhere that this is a hand over (it assumes multiple access), then the result is a two separate mobility sessions to the MN using the different MN-HNPs. Are different behaviors wanted than these? It seems so. The third I thought that NETEXT wants to provide new services, instead of noting and fixing existing problems with the PMIP protocol and I arrived at these new services: - A) the ability to know how the MN wants to use multiple interfaces i) redundancy (same address) ii) another connection point (different address) iii) handover (must be same address otherwise IP connection breaks) - B) the ability to use stateless IPv6 address autoconfiguration with a 64bit prefix length and always get the same IPv6 address on every interface. - C) the ability to control which interface the MN uses to access the PMIP ------------------- Conclusion It is evident that PMIP cannot obtain the information from (A) or control (C) of the MN without modification to the mobile node. (B) requires a change of what stateless IPv6 address autoconfiguration (i.e., not possible). David Cypher From: behcetsarikaya at yahoo.com (Behcet Sarikaya) Date: Thu, 26 Feb 2009 07:21:57 -0800 (PST) Subject: [Netext] Redirection Problem Statement In-Reply-To: <72EF061C-8076-4AED-8BA4-256B4220133D@gmail.com> References: <72EF061C-8076-4AED-8BA4-256B4220133D@gmail.com> Message-ID: <651471.39395.qm@web111409.mail.gq1.yahoo.com> 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. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From: pierrick.seite at orange-ftgroup.com (pierrick.seite at orange-ftgroup.com) Date: Thu, 26 Feb 2009 15:17:55 +0100 Subject: [Netext] Redirection Problem Statement In-Reply-To: <0DF1178B-7A5A-4228-AA8B-61EC626CC1D0@gmail.com> References: <72EF061C-8076-4AED-8BA4-256B4220133D@gmail.com> <0DF1178B-7A5A-4228-AA8B-61EC626CC1D0@gmail.com> Message-ID: Hi Jouni, Thanks for the prompt response. Please see inline for comments. PS: I forgot to CC the ML in my first message.... Regards, Pierrick > -----Message d'origine----- > De : jouni korhonen [mailto:jouni.nospam at gmail.com] > Envoy? : jeudi 26 f?vrier 2009 13:56 > ? : SEITE Pierrick RD-RESA-REN > Objet : Re: [Netext] Redirection Problem Statement > > Hi Pierrick, > > Thanks for the review. See my comments inline. > > On Feb 26, 2009, at 2:15 PM, wrote: > > > > > Hello Jouni, > > > > I've read your draft. This draft is very interesting since LMA > > redirection is clearly a key feature for PMIP deployment. Moreover, > > the document is well written and the problem statement is complete > > and comprehensible. However, I've a couple of questions. > > > > Difference between LMA discovery and LMA redirection at initial > > attach is not totally clear for me. When do we need LMA redirection > > at initial attach? One example could be: if MAG finds out LMA via > > AAA infrastructure and if LMA information in MN's profile has not > > been updated, then LMA redirection by rfLMA during PBU/PBA exchange > > could be useful. Is it a correct unrestanding? > > Your described AAA scenario is a good example case. One of the main > motivations is to detach the redirection functionality from external > infrastructures, especially from DNS. For example in load balancing > cases, a LMA or a cluster of LMAs knows the current load situation > best. If the LMA were constantly to update its runtime load situation > to either AAA or DNS infrastructure, it is guaranteed that when a > random MAG learns this updated information, the information is already > outdated. Furthermore, keeping external infrastructures up to date > with e.g. LMA availability and load status would cause excessive > additional signaling. > Ok, it clarifies well the use-case. I agree with you. > > You seem to consider LMA switching only during PBU/PBA exchange. > > When LMA redirection is expected to take place during an active > > session, I the LMA should be able to initiate redirection: I mean > > that the LMA should be able to notify, thanks to a dedicated > > message, attached MAGs to switch to r2LMA. This feature could be > > useful when the operator wants to shutdown a LMA for maintenance > > reason. What do you think? > > I am primarily interested in the LMA redirection during the initial > PBU/PBA exchange. The reason being that there is no state established > yet on the LMA side (which also means the LMA has not either contacted > the backend system). I would gain a lot in signaling and avoid > unnecessary setup of state in various places. > > The LMA initiated redirection of an existing session is interesting > and should also be studied. However, it involves a lot more, > especially if we want to maintain the mobility session. > For sure, LMA initiated redirection leads to a more sophisticated mechanism; but, depending on the interest of the WG, it could be interesting to include it in the ps draft. Let's see other comments on the ML.... Regards, Pierrick > Cheers, > Jouni > > > > > > > Best regards, > > Pierrick > > > >> -----Message d'origine----- > >> De : netext-bounces at mail.mobileip.jp [mailto:netext- > >> bounces at mail.mobileip.jp] De la part de jouni korhonen > >> Envoy? : jeudi 26 f?vrier 2009 10:52 > >> ? : netext at mail.mobileip.jp > >> Objet : [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: domagoj.premec.ext at nsn.com (Domagoj Premec) Date: Thu, 26 Feb 2009 13:25:26 +0100 Subject: [Netext] Inter-technology handover PS In-Reply-To: <4D35478224365146822AE9E3AD4A266606C0EF20@exchtewks3.starentnetworks.com> References: <499DE8FA.3040803@ericsson.com> <4D35478224365146822AE9E3AD4A266606C0EF20@exchtewks3.starentnetworks.com> Message-ID: Hi Rajeev, > 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? Using access specific mechanims is fine for the cases where the access system actually provides the needed functionality. 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. 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 > From: jouni.nospam at gmail.com (jouni korhonen) Date: Thu, 26 Feb 2009 11:51:51 +0200 Subject: [Netext] Redirection Problem Statement Message-ID: <72EF061C-8076-4AED-8BA4-256B4220133D@gmail.com> 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 From: Basavaraj.Patil at nokia.com (Basavaraj.Patil at nokia.com) Date: Thu, 26 Feb 2009 05:35:34 +0100 Subject: [Netext] draft-korhonen-netext-redirect-ps-00 In-Reply-To: <076BDB7F-4E02-4EF5-B4EA-0EBA8E9083C9@gmail.com> Message-ID: Hi Jouni, The redirection capability enhancements to PMIP6 are likely to be useful in deployments. Additionally redirection at initial attach can be considered as a form of achieving loadbalancing. The focus of the discussions in this ML has been on the multihoming and localized routing problem statements. I would encourage people to take a look at the above I-D and provide comments. Loadbalancing is considered in the context of multihoming in the charter. But we could consider loadbalancing enhancements if there is interest as part of the BoF discussion. -Raj On 2/9/09 6:43 AM, "ext jouni korhonen" wrote: > Hi All, > > I wrote a small discussion paper on PMIPv6 redirection functionality. > The aim is to > come up with a good redirection support for the base protocol. Obvious > use cases > are load balancing, signaling reduction within a PMIPv6 Domain and > eventually reduced > latencies during mobility session setup. The problem area falls under > the improvements > and/or deployment considerations in the current proposed charter. > > The I-D can be found here: > http://www.ietf.org/internet-drafts/draft-korhonen-netext-redirect-ps-00.txt > > Comments are welcome! > > Cheers, > Jouni > > > > Begin forwarded message: > >> From: IETF I-D Submission Tool >> Date: February 9, 2009 2:30:00 PM GMT+02:00 >> To: jouni.nospam at gmail.com >> Subject: New Version Notification for draft-korhonen-netext- >> redirect-ps-00 >> >> >> A new version of I-D, draft-korhonen-netext-redirect-ps-00.txt has >> been successfuly submitted by Jouni Korhonen and posted to the IETF >> repository. >> >> Filename: draft-korhonen-netext-redirect-ps >> Revision: 00 >> Title: Proxy Mobile IPv6 Mobility Session Redirection Problem >> Statement >> Creation_date: 2009-02-09 >> WG ID: Independent Submission >> Number_of_pages: 7 >> >> Abstract: >> This document discusses a Proxy Mobile IPv6 mobility session >> redirection functionality at the Proxy Mobile IPv6 base protocol >> level. The redirection functionality would allow a Local Mobility >> Anchor to redirect the Mobile Access Gateway during the Proxy Binding >> Update and Acknowledgement exchange to an alternative Local Mobility >> Anchor. The benefit of redirection at the protocol level is that it >> removes the dependence on having such functionality provided by the >> Authentication, Authorization and, Accounting elements or the Domain >> Name System in a Proxy Mobile IPv6 Domain. Furthermore, doing the >> redirection at the base protocol level reduces the amount of >> signaling, unnecessary costly setup of mobility sessions and >> unnecessary costly interactions with backend systems. >> >> >> >> The IETF Secretariat. >> >> > > _______________________________________________ > NetExt mailing list > NetExt at mail.mobileip.jp > http://www.mobileip.jp/mailman/listinfo/netext From: rkoodli at starentnetworks.com (Koodli, Rajeev) Date: Tue, 24 Feb 2009 17:00:40 -0500 Subject: [Netext] Inter-technology handover PS In-Reply-To: <499DE8FA.3040803@ericsson.com> Message-ID: <4D35478224365146822AE9E3AD4A266606C0EF20@exchtewks3.starentnetworks.com> 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. From: cjbc at it.uc3m.es (Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano) Date: Tue, 24 Feb 2009 19:16:34 +0100 Subject: [Netext] First Problem Statement about Localized Routing in PMIPv6 submitted In-Reply-To: <4D35478224365146822AE9E3AD4A266606C0EB27@exchtewks3.starentnetworks.com> References: <4D35478224365146822AE9E3AD4A266606C0EB27@exchtewks3.starentnetworks.com> Message-ID: <1235499394.5013.106.camel@localhost> OK, fair enough. If we clearly state that we would only focus on deployment scenarios in which all nodes are offered PMIPv6 support, I'm very fine with this. I just wanted to make the scope of the netext work quite clear. Thanks! Carlos El mar, 24-02-2009 a las 13:14 -0500, Koodli, Rajeev escribi?: > Hi, > > > > - If my previous understanding is correct, then RFC5213 > > does not only define any mechanism to perform local routing > > between two MNs connected to the same PMIPv6 domain (not even > > for the case in which both are attached to the same MAG). > > Then, IMHO it would be better to change the terminology in > > the PS and avoid using CN or coming up with different terms > > for a CN that is getting network-based mobility service from > > a CN that is not (i.e. it is just a regular IPv6 node getting > > access from a MAG). > > We should assume, i.e., state in the PS document clearly, that all nodes are offered PMIP6 support. > 5213 may say something else, but for our purposes, at least for now, we should assume that all nodes are "punished" the same way by PMIP6! :-) > > > > > - Currently, the PS only addresses the case of local > > routing between two MNs connected to the same PMIPv6 domain. > > I think the scenario of optimising traffic between an MN and > > a regular IPv6 host that is locally connected to a MAG should > > also be addressed. Not sure the implications on the potential > > solutions, but it might have an impact on the classification > > scheme that is used in the PS now (A[number of MAGs][number of LMAs]). > > > > Please see above. I would not be for this given the issues in detecting who is offered PMIP6 and who is not.. Also see my previous e-mail regarding deployment focus. > > May be we can come back to such extensions later on.. Let's focus on things we can do within a short, reasonable period of time. > > Thanks, > > -Rajeev > > > > Thanks, > > > > Carlos > > > > El jue, 05-02-2009 a las 15:33 +0100, Marco Liebsch escribi?: > > > 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-0 > > > 0.txt > > > > > > Best regards, > > > marco > > > > > > > > > _______________________________________________ > > > 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/ > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > > > > 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. -- 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: rkoodli at starentnetworks.com (Koodli, Rajeev) Date: Tue, 24 Feb 2009 13:14:09 -0500 Subject: [Netext] First Problem Statement about Localized Routing in PMIPv6 submitted In-Reply-To: <1234339777.21602.198.camel@localhost> Message-ID: <4D35478224365146822AE9E3AD4A266606C0EB27@exchtewks3.starentnetworks.com> Hi, > - If my previous understanding is correct, then RFC5213 > does not only define any mechanism to perform local routing > between two MNs connected to the same PMIPv6 domain (not even > for the case in which both are attached to the same MAG). > Then, IMHO it would be better to change the terminology in > the PS and avoid using CN or coming up with different terms > for a CN that is getting network-based mobility service from > a CN that is not (i.e. it is just a regular IPv6 node getting > access from a MAG). We should assume, i.e., state in the PS document clearly, that all nodes are offered PMIP6 support. 5213 may say something else, but for our purposes, at least for now, we should assume that all nodes are "punished" the same way by PMIP6! :-) > > - Currently, the PS only addresses the case of local > routing between two MNs connected to the same PMIPv6 domain. > I think the scenario of optimising traffic between an MN and > a regular IPv6 host that is locally connected to a MAG should > also be addressed. Not sure the implications on the potential > solutions, but it might have an impact on the classification > scheme that is used in the PS now (A[number of MAGs][number of LMAs]). > Please see above. I would not be for this given the issues in detecting who is offered PMIP6 and who is not.. Also see my previous e-mail regarding deployment focus. May be we can come back to such extensions later on.. Let's focus on things we can do within a short, reasonable period of time. Thanks, -Rajeev > Thanks, > > Carlos > > El jue, 05-02-2009 a las 15:33 +0100, Marco Liebsch escribi?: > > 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-0 > > 0.txt > > > > Best regards, > > marco > > > > > > _______________________________________________ > > 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/ > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > 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. From: cjbc at it.uc3m.es (Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano) Date: Tue, 24 Feb 2009 19:13:10 +0100 Subject: [Netext] First Problem Statement about LocalizedRoutingin PMIPv6 submitted In-Reply-To: <4D35478224365146822AE9E3AD4A266606C0EB04@exchtewks3.starentnetworks.com> References: <4D35478224365146822AE9E3AD4A266606C0EB04@exchtewks3.starentnetworks.com> Message-ID: <1235499190.5013.103.camel@localhost> Hi Rajeev, El mar, 24-02-2009 a las 13:04 -0500, Koodli, Rajeev escribi?: > Hi Carlos, > > I seem to have missed a reply.. > > > > What does it mean to say it is not getting network-based > > mobility support? > > > Isn't the whole point of PMIP to make mobility transparent > > to the MN? > > > > I fully agree that the whole point of PMIP is make mobility > > management transparent to the MN. However, as far as I > > understand from my reading of RFC5213, a mobile node attached > > to a PMIPv6 domain might not be entitled to the network-based > > mobility management service, and RFC5213 (section 6.14) still > > support this node to get connectivity (regular > > access) from the MAG. > > I don't quite understand how 5213 provides protocol support to distiniguish between nodes for which mobility support is offered, and those for which it is not offered. I mentioned this in my prvious e-mail.. Well, the network itself (the MAG) can decide whether to provide to a node (upon its attachment) with a prefix anchored at the LMA (in this case the network would provide PMIPv6 support) or with a prefix locally anchored at the MAG (in this case, no mobility support is provided, if the node moves to a different MAG, it will have to configure a new IPv6 address). This is my understanding from RFC5213. > > > > > Related to this, it is also my interpretation of RFC5213 (section > > 6.10.5) that the local routing support provided by the basic > > spec (controlled with the EnableMAGLocalRouting flag) only > > applies to communications between a PMIPv6 MN and a regular > > IPv6 host attached to the same MAG. > > > > If there is no protocol support to differentiate the nodes, the above is moot. As I described above, I think RFC5213 provides support to differentiate the nodes. > > > This is just to try to clarify what RFC5213 provides (actually, very > > little) and what does not in regards to local routing > > support. Do you see my point? > > > > Okay, thanks. For our purposes here, let us assume that we are dealing with a scenario where the PMIP6 is provided to nodes. One of the main emphasis in this BOF effort is to focus on deployment considerations, and I believe addressing the local forwarding for a PMIP6 domain would be worthwhile. Fully agree local routing is quite interesting and should be addressed (I never meant the opposite). Thanks, Carlos > > Later on, we could consider working on other extensions. > > Thanks, > > -Rajeev > > > > Thanks! > > > > Carlos > > > > > > > > > > > > > > > > - If my previous understanding is correct, then RFC5213 > > does not > > > > only define any mechanism to perform local routing > > between two MNs > > > > connected to the same PMIPv6 domain (not even for the > > case in which > > > > both are attached to the same MAG). > > > > Then, IMHO it would be better to change the terminology in the PS > > > > and avoid using CN or coming up with different terms for > > a CN that > > > > is getting network-based mobility service from a CN that is not > > > > (i.e. it is just a regular IPv6 node getting access from a MAG). > > > > > > See above. > > > > > > > > > > > - Currently, the PS only addresses the case of local routing > > > > between two MNs connected to the same PMIPv6 domain. > > > > I think the scenario of optimising traffic between an MN and a > > > > regular IPv6 host that is locally connected to a MAG > > should also be > > > > addressed. Not sure the implications on the potential > > solutions, but > > > > it might have an impact on the classification scheme that > > is used in > > > > the PS now (A[number of MAGs][number of LMAs]). > > > > > > > > > > Our focus should be on solving the problem for nodes > > attached to a PMIP6 domain. > > > > > > Thanks, > > > > > > -Rajeev > > > > > > > > > > Thanks, > > > > > > > > Carlos > > > > > > > > El jue, 05-02-2009 a las 15:33 +0100, Marco Liebsch escribi?: > > > > > 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 > > > > -0 > > > > > 0.txt > > > > > > > > > > Best regards, > > > > > marco > > > > > > > > > > > > > > > _______________________________________________ > > > > > 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/ > > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > > > > > > > > > > > > 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. > > -- > > 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: rkoodli at starentnetworks.com (Koodli, Rajeev) Date: Tue, 24 Feb 2009 13:04:30 -0500 Subject: [Netext] First Problem Statement about LocalizedRoutingin PMIPv6 submitted In-Reply-To: <1234370715.5174.9.camel@localhost> Message-ID: <4D35478224365146822AE9E3AD4A266606C0EB04@exchtewks3.starentnetworks.com> Hi Carlos, I seem to have missed a reply.. > > What does it mean to say it is not getting network-based > mobility support? > > Isn't the whole point of PMIP to make mobility transparent > to the MN? > > I fully agree that the whole point of PMIP is make mobility > management transparent to the MN. However, as far as I > understand from my reading of RFC5213, a mobile node attached > to a PMIPv6 domain might not be entitled to the network-based > mobility management service, and RFC5213 (section 6.14) still > support this node to get connectivity (regular > access) from the MAG. I don't quite understand how 5213 provides protocol support to distiniguish between nodes for which mobility support is offered, and those for which it is not offered. I mentioned this in my prvious e-mail.. > > Related to this, it is also my interpretation of RFC5213 (section > 6.10.5) that the local routing support provided by the basic > spec (controlled with the EnableMAGLocalRouting flag) only > applies to communications between a PMIPv6 MN and a regular > IPv6 host attached to the same MAG. > If there is no protocol support to differentiate the nodes, the above is moot. > This is just to try to clarify what RFC5213 provides (actually, very > little) and what does not in regards to local routing > support. Do you see my point? > Okay, thanks. For our purposes here, let us assume that we are dealing with a scenario where the PMIP6 is provided to nodes. One of the main emphasis in this BOF effort is to focus on deployment considerations, and I believe addressing the local forwarding for a PMIP6 domain would be worthwhile. Later on, we could consider working on other extensions. Thanks, -Rajeev > Thanks! > > Carlos > > > > > > > > > > > - If my previous understanding is correct, then RFC5213 > does not > > > only define any mechanism to perform local routing > between two MNs > > > connected to the same PMIPv6 domain (not even for the > case in which > > > both are attached to the same MAG). > > > Then, IMHO it would be better to change the terminology in the PS > > > and avoid using CN or coming up with different terms for > a CN that > > > is getting network-based mobility service from a CN that is not > > > (i.e. it is just a regular IPv6 node getting access from a MAG). > > > > See above. > > > > > > > > - Currently, the PS only addresses the case of local routing > > > between two MNs connected to the same PMIPv6 domain. > > > I think the scenario of optimising traffic between an MN and a > > > regular IPv6 host that is locally connected to a MAG > should also be > > > addressed. Not sure the implications on the potential > solutions, but > > > it might have an impact on the classification scheme that > is used in > > > the PS now (A[number of MAGs][number of LMAs]). > > > > > > > Our focus should be on solving the problem for nodes > attached to a PMIP6 domain. > > > > Thanks, > > > > -Rajeev > > > > > > > Thanks, > > > > > > Carlos > > > > > > El jue, 05-02-2009 a las 15:33 +0100, Marco Liebsch escribi?: > > > > 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 > > > -0 > > > > 0.txt > > > > > > > > Best regards, > > > > marco > > > > > > > > > > > > _______________________________________________ > > > > 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/ > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > > > > > > > > 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. > -- > 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: cjbc at it.uc3m.es (Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano) Date: Tue, 24 Feb 2009 08:41:46 +0100 Subject: [Netext] Inter-technology handover PS In-Reply-To: <49A331EF.9030403@ericsson.com> References: <49A331EF.9030403@ericsson.com> Message-ID: <1235461306.5013.3.camel@localhost> Hi Suresh, El lun, 23-02-2009 a las 18:31 -0500, Suresh Krishnan escribi?: > Hi Raj, > > On 23/02/09 12:28 AM, Basavaraj.Patil at nokia.com wrote: > > > > > > On 2/19/09 5:19 PM, "Suresh Krishnan" wrote: > > > > > >>> - 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"? > > > > Whether an MN supports 802.21 functionality is not something that can be > > assumed IMO. A change on the MN from the Netext perspective would be some > > new functionality or signaling enhancement that may be specified to > > accomplish a specific goal w.r.t handovers or multihoming. Having said that > > please do note that Netext solutions should not immediately delve into > > specifying changes or solutions that affect the MN. We have to emphasise > > that changes to the host are to be considered *ONLY* when all other means > > are exhausted. > > Even though you quoted me, it was Carlos's text you were responding to > :-). I agree with your assessment. I also agree. My point was to make more clear what we understand in NETEXT by an MN change. > > > > >> Probably something to add to the charter? > > > > We may add some text to the charter to make the view on host changes clear. > > OK. Good, that'd help. Thanks, Carlos > > Cheers > Suresh -- 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: suresh.krishnan at ericsson.com (Suresh Krishnan) Date: Mon, 23 Feb 2009 18:31:59 -0500 Subject: [Netext] Inter-technology handover PS In-Reply-To: References: Message-ID: <49A331EF.9030403@ericsson.com> Hi Raj, On 23/02/09 12:28 AM, Basavaraj.Patil at nokia.com wrote: > > > On 2/19/09 5:19 PM, "Suresh Krishnan" wrote: > > >>> - 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"? > > Whether an MN supports 802.21 functionality is not something that can be > assumed IMO. A change on the MN from the Netext perspective would be some > new functionality or signaling enhancement that may be specified to > accomplish a specific goal w.r.t handovers or multihoming. Having said that > please do note that Netext solutions should not immediately delve into > specifying changes or solutions that affect the MN. We have to emphasise > that changes to the host are to be considered *ONLY* when all other means > are exhausted. Even though you quoted me, it was Carlos's text you were responding to :-). I agree with your assessment. > >> Probably something to add to the charter? > > We may add some text to the charter to make the view on host changes clear. OK. Cheers Suresh From: Basavaraj.Patil at nokia.com (Basavaraj.Patil at nokia.com) Date: Mon, 23 Feb 2009 06:28:06 +0100 Subject: [Netext] Inter-technology handover PS In-Reply-To: <499DE8FA.3040803@ericsson.com> Message-ID: On 2/19/09 5:19 PM, "Suresh Krishnan" wrote: >> - 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"? Whether an MN supports 802.21 functionality is not something that can be assumed IMO. A change on the MN from the Netext perspective would be some new functionality or signaling enhancement that may be specified to accomplish a specific goal w.r.t handovers or multihoming. Having said that please do note that Netext solutions should not immediately delve into specifying changes or solutions that affect the MN. We have to emphasise that changes to the host are to be considered *ONLY* when all other means are exhausted. > > Probably something to add to the charter? We may add some text to the charter to make the view on host changes clear. -Raj > > Cheers > Suresh > > _______________________________________________ > 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: Fri, 20 Feb 2009 09:08:29 +0100 Subject: [Netext] Inter-technology handover PS In-Reply-To: <499DE8FA.3040803@ericsson.com> References: <4990ADEE.8060506@ericsson.com> <1234810902.5187.92.camel@localhost> <499DE8FA.3040803@ericsson.com> Message-ID: <1235117309.4633.3.camel@localhost> Hi Suresh, Thanks for the reply. Some minor comments inline. El jue, 19-02-2009 a las 18:19 -0500, Suresh Krishnan escribi?: > 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 OK. > > > > > - 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? Well, it's true it is borderline. My point was just to try to analyse how much support the MN could probably provide and what is missing. > > > > > - 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? That's a possibility. My point was again to make clear what we understand -- within the scope of NETEXT -- by "MN involvement/changes" Thanks, Carlos > > Cheers > Suresh > -- 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: yokota at kddilabs.jp (Hidetoshi Yokota) Date: Fri, 20 Feb 2009 10:47:08 +0900 Subject: [Netext] Inter-technology handover PS In-Reply-To: <499DE8FA.3040803@ericsson.com> References: <4990ADEE.8060506@ericsson.com> <1234810902.5187.92.camel@localhost> <499DE8FA.3040803@ericsson.com> Message-ID: <499E0B9C.1080805@kddilabs.jp> Hi Carlos and Suresh, Suresh Krishnan wrote: > Hi Carlos, > Thanks for your comments. Please find responses inline > > On 16/02/09 02:01 PM, Carlos Jesu'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 I agree. I think DHCPv6 is as important. We should consider interworking with DHCPv6 server/relay and should mention it in the PS. >> >> - 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? This is a hard question. As Jari suggested in another e-mail, we should try best to find a solution that doesn't require a host change, then to find one with the least impact or change on the host side. In the latter case, we will be spending most of the time to decide whether to make it in or out of scope... >> >> - 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? This is also a hard question, but one of the purposes of NETEXT, I guess. The definition of the change on the MN is a more comprehensive isse, not limited to the inter-technology handover, so I believe that it should be described somewhere in the charter or a more comprehensive PS, if any. Anyway, it's good that you brought it up. Regards, -- Hidetoshi > Cheers > Suresh > > _______________________________________________ > 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: Fri, 20 Feb 2009 08:28:04 +0800 Subject: [Netext] Review of the Multihoming PS I-D In-Reply-To: <853DD750D9C3724FBF2DF7164FCF641C0295A841@FRVELSMBS14.ad2.ad.alcatel.com> Message-ID: <5F09D220B62F79418461A978CA0921BD032B53AA@pslexc01.psl.local> Hi Telemaco, Please see in-line. BR, Mohana -----Original Message----- From: MELIA TELEMACO [mailto:Telemaco.Melia at alcatel-lucent.com] Sent: Thursday, February 19, 2009 4:13 PM To: Mohana Jeyatharan; pierrick.seite at orange-ftgroup.com; liebsch at nw.neclab.eu; yokota at kddilabs.jp Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com Subject: RE: [Netext] Review of the Multihoming PS I-D Hi Mohana, Few comments below: If same address is assigned to different interfaces, MN and LMA need to share routing policy to route each flow to the correct interface. But distribution of policies is an issue; I mean, distribution of policies could be done via an interface between LMA and MN, but it would be a severe violation of PMIP architecture. [Mohana] Distribution of policy can be done by MN-AR interface as well. No need of MN-LMA interaction.... [TELE] About policies distribution: I am not sure what is the feeling of people here, but this thread is very similar to what has been discussed in the MIP4 session last time @Minneapolis on Multiple CoA Support (Sri). The major concern from Jari and Henrik was that policy distribution cannot be ignored and left behind (you can check the minutes), the protocol might become useless otherwise. [Mohana] Yes, true. First simultanoeus reachability for single HNP. Following that it will be at some point, one needs to work of flowbindings etc. So, even if other distribution schemes can be possible, I do not really see why sharing same address on several interfaces can facilitate IP flow mobility. Mainly because routing in that case is a tricky problem. It seems to me that this feature brings more issues than benefits... [Mohana] I am not so sure about the issues you are conecrned with. On the other hand RFC 5213 provides a basic support of IP mobility between different interfaces. But here the issue is on the determination of the "handoff indicator" at the MAG. Don't you think that clarification on the determination of the "handoff indicator" in case of multihoming and IP flow mobility would worth the effort in Netext? [Mohana] Of course for IP flow mobility and multihoming, proper MN-MAG triggers may need to be present. RFC 5213 does not specify how MAGs get the HI indicator options. It canbe via L2 or some other way. But for multihoming host may need to accept packets destined to one interface via another. [TELE] Glad that you mention this, Carlos already did before. I think that this change affects the terminal as much as having the same address configured on two interfaces. The PS document should capture this. [Mohana] In the Multihoming PS document, it is explained that host needs some changes to achieve this. But, there was no dwelling into solution space. Wondering whether this is essential in a PS? What do your'll think? An intelligent client can do this knowing that this is PMIPv6. Anyway, in some SDOs the mobility management mechansims are known to the Mn if it wants to. They do have mobility mode selection kind of methods. Thus such multihoming in PMIPv6 can be achievable without much difficulty. My two cents, Regards, Pierrick > -----Message d'origine----- > De?: netext-bounces at mail.mobileip.jp [mailto:netext- > bounces at mail.mobileip.jp] De la part de MELIA TELEMACO Envoy??: mardi > 17 f?vrier 2009 17:41 ??: Marco Liebsch; Hidetoshi Yokota Cc?: > netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com Objet?: Re: > [Netext] Review of the Multihoming PS I-D > > Hi, > > I guess there are two important emerging aspects out of this discussion: > - involvement of the mobile node in the multihoming process > - transfer of policies, how and where to > > I would like also to stress the fact that we should not necessarily > see multihoming as a solution to optimize mobility. > A node can be multihomed without moving at all (nomadic user) and we > have other documents (transient BCE) looking at how to optimize mobility. > > How folks see things? > > telemaco > > > -----Message d'origine----- > De : Marco Liebsch [mailto:liebsch at nw.neclab.eu] Envoy? : mardi 17 > f?vrier 2009 15:06 ? : Hidetoshi Yokota Cc : netext at mail.mobileip.jp; > MELIA TELEMACO; Basavaraj.Patil at nokia.com Objet : Re: [Netext] Review > of the Multihoming PS I-D > > Hidetoshi Yokota wrote: > > Hi Marco, > > > > Marco Liebsch wrote: > > > >> Hidetoshi, > >> > > > > I'm still talking about definitions and categorization. I'm not > > downplaying any of them. > > > sure. > > > > >> I think we have different opinions on an important aspect: > >> My understanding of your opinion is that as soon as the MN gets > >> (e.g.) HNP1 assigned to interface 1 (IF1) as a result of the > >> registration, it can use the same HNP1 for a different interface, > >> e.g. IF2, without having this HNP1 received from the network as a > >> result of IF2's registration. > >> Correct? > >> > > > > No, I'm not going that far, yet :-). I'm still trying to understand > > what people are thinking about multihoming, handover and IP flow > > mobility, etc. My understanding is that if the MN wants to use HNP1 > > on IF2, it would have to register it with the LMA via the > > corresponding MAG; otherwise, there would be no guarantee that > > packets are coming back > to IF2. > > > Ok. > > > > >> I think the MN can use HNP1 only for IF2, if the LMA assigns the > >> same > >> HNP1 to IF2 during its registration. To result then in the same IP > >> address, it's up to the MN to take the same suffix for both interfaces' > IP address. > >> That's again something where we have the same opinion. > >> > > > > I think this is a sensible behavior. The key thing is to give a hint > > to the LMA on which interface the MN wants to get packets. > > > Well, yes, the LMA needs a hint about the routing policy (which flow > goes which way). But here the MN plays a role and that hint may not > come with > PMIPv6 signaling. > > > > >> So, when we talk about using the same IP address on both > >> interfaces, still the allowed prefix for each interface is network > >> controlled, whereas the MN is free to chose any suffix. That's at least my view. > >> > > > > I personally agree with your view. In addition, the LMA should get > > in sync with the MN especially when those two interfaces are > > connected to different MAGs. > > > Thanks for the clarification. > > Greetings, > marco > > > Regards, > > > > > _______________________________________________ > 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: suresh.krishnan at ericsson.com (Suresh Krishnan) Date: Thu, 19 Feb 2009 18:19:22 -0500 Subject: [Netext] Inter-technology handover PS In-Reply-To: <1234810902.5187.92.camel@localhost> References: <4990ADEE.8060506@ericsson.com> <1234810902.5187.92.camel@localhost> Message-ID: <499DE8FA.3040803@ericsson.com> 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 From: xiayangsong at huawei.com (Frank Xia) Date: Thu, 19 Feb 2009 10:41:37 -0600 Subject: [Netext] Review of the Multihoming PS I-D References: <1235035272.4619.39.camel@localhost> <057632CE4CE10D45A1A3D6D19206C3A3DBFB5EB4@NASANEXMB08.na.qualcomm.com> <002001c992a9$e1202b80$420c7c0a@china.huawei.com> <057632CE4CE10D45A1A3D6D19206C3A3DBFB5ECA@NASANEXMB08.na.qualcomm.com> Message-ID: <00a501c992b0$ef4e3830$420c7c0a@china.huawei.com> Hi Gerardo I know there is official requirement from 3GPP, and I am not offically asked to push in IETF either :-). >From business perspective, what operators care is how to make full use of their scarce air resource. This is one of main motivation to have dual mode terminals with 3GPP and WiFi (you can buy one from T-Mobile :-) ). When the dual mode terminal moves home where WLAN access is available, it prefer offloading some low QoS service from 3GPP to WiFi. At the same time, high QoS service still remains in 3GPP. BR Frank ----- Original Message ----- From: "Giaretta, Gerardo" To: "Frank Xia" ; ; Cc: ; ; Sent: Thursday, February 19, 2009 9:56 AM Subject: RE: [Netext] Review of the Multihoming PS I-D Hi Frank, I am happy if Huawei wants you to push this in the IETF, I hope you can make it :-) I wanted just to provide the indication that there is not any official requirement from 3GPP. We can then discuss about whatever business can drive this (what radios do you have in mind when you talk about multihoming and flow mobility for PMIP?). Gerardo > -----Original Message----- > From: Frank Xia [mailto:xiayangsong at huawei.com] > Sent: Thursday, February 19, 2009 7:51 AM > To: Giaretta, Gerardo; cjbc at it.uc3m.es; Basavaraj.Patil at nokia.com > Cc: netext at mail.mobileip.jp; Mohana.Jeyatharan at sg.panasonic.com; > Telemaco.Melia at alcatel-lucent.com > Subject: Re: [Netext] Review of the Multihoming PS I-D > > Hi All > > My 3GPP colleagues also suggested me pushing in IETF community. > If we talk about 3GPP requirment, there is even no specific PMIPv6 > multi-homing requirement. > > My point is business driving technical employment. > IMO, flow mobility is clearly required in PMIP deployment environment. > > BR > Frank > > ----- Original Message ----- > From: "Giaretta, Gerardo" > To: ; > Cc: ; ; > > Sent: Thursday, February 19, 2009 4:16 AM > Subject: Re: [Netext] Review of the Multihoming PS I-D > > > Hi all, > > To clarify flow mobility is not a requirement for PMIPv6 right now in > 3GPP. > There is a study item ongoing but 3GPP has not yet decided that flow > mobility is needed for PMIPv6. > > Cheers, > Gerardo > (from Budapest, 3GPP SA2 meeting) > > > -----Original Message----- > > From: netext-bounces at mail.mobileip.jp > > [mailto:netext-bounces at mail.mobileip.jp] > > On Behalf Of Carlos Jes?s Bernardos Cano > > Sent: Thursday, February 19, 2009 1:21 AM > > To: Basavaraj.Patil at nokia.com > > Cc: Mohana.Jeyatharan at sg.panasonic.com; > > Telemaco.Melia at alcatel-lucent.com; > > netext at mail.mobileip.jp > > Subject: Re: [Netext] Review of the Multihoming PS I-D > > > > Hi, > > > > One question: flow mobility seems to be an interesting feature that is a > > requirement from 3GPP, it is related with multihoming but it is not > > strictly a > > multihoming isse, right? I mean, multihoming extensions would likely > > make > > easier to support flow mobility, but would probably require additional > > mechanisms. How do we capture this? I'm not sure the multihoming PS is > > the > > right place for that, maybe the multihoming PS can point out that, but > > we > > need > > an explicit document (and charter item) for dealing with flow mobility. > > What > > do others think? > > > > Thanks! > > > > Carlos > > > > El mi?, 18-02-2009 a las 21:39 +0100, Basavaraj.Patil at nokia.com > > escribi?: > > > It may be of interest in the context of multihoming to consider moving > > > a flow from one interface to another. A flow which is associated with > > > an interface on the MN may be moved to another interface in the case > > > of a multihomed host for various reasons. This may be viewed as a > > > handover as well from the flow perspective. Multihoming enables the > > > possibility to move flows between interfaces. I think we could keep > > > this in the context of the multihoming discussion if there is > > > consensus > > > on > > it. > > > > > > -Raj > > > > > > > > > On 2/17/09 1:51 AM, "ext Mohana Jeyatharan" > > > wrote: > > > > > > > Hi Hidetoshi, > > > > > > > > In Multihoming PS ID, there are some handoff optimization scenarios > > involved. > > > > For example optmizing the handoff of a certain interface by means of > > > > another, and achieving flow mobility via another interface during > > > > disconnection. These events are triggered due to handoff or > > > > disconnection, but the scenarios are associated with multihoming. > > > > That is being able to receive a flow that is usually destined to an > > > > interface via another "connected" interface. This is where these > > > > scenarios are different from normal handoff and more tied to > > > > multihoming. > > > > > > > > However, I agree that these are also tied with handoff and some > > > > confusion is there. Anyway, we are planning to revise the > > > > multihoming PS draft and are thinking of focusing on the > > > > disconnection scenario, handoff optimization as less focus scenarios > > > > and > > focus on scenarios that are cateogorized by Raj. > > > > > > > > BR, > > > > Mohana > > > > > > > > > > > > -----Original Message----- > > > > From: Hidetoshi Yokota [mailto:yokota at kddilabs.jp] > > > > Sent: Tuesday, February 17, 2009 12:42 PM > > > > To: Mohana Jeyatharan > > > > Cc: Domagoj Premec; ext MELIA TELEMACO; Marco Liebsch; > > > > netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com > > > > Subject: Re: [Netext] Review of the Multihoming PS I-D > > > > > > > > Hi Mohana and all, > > > > > > > > I think your scenario is viable, but we should probably more > > > > carefully clarify the difference between multihoming and handover. > > > > Assigning the same address to different interfaces on the MN for a > > > > sufficiently long time sounds like multihoming; however, if this > > > > situation holds only for a short period of time for MN's movement or > > > > fail over or for whatever reason, that sounds like handover. This > > > > difference would affect the behavior of the LMA and MAG(s). > > > > > > > > In Section 2 of the Multihoming PS document, Issues related to > > > > handoff performance and those related to flow mobility during sudden > > > > disconnection appear to be categorized into handover. If all agree > > > > that these issues should also be included in multihoming, that's > > > > fine. I would just like to make sure of it first of all. > > > > > > > > Regards, > > > > -- > > > > Hidetoshi > > > > > > > > > > > > > _______________________________________________ > > > 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/ > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > _______________________________________________ > NetExt mailing list > NetExt at mail.mobileip.jp > http://www.mobileip.jp/mailman/listinfo/netext From: gerardog at qualcomm.com (Giaretta, Gerardo) Date: Thu, 19 Feb 2009 07:56:29 -0800 Subject: [Netext] Review of the Multihoming PS I-D In-Reply-To: <002001c992a9$e1202b80$420c7c0a@china.huawei.com> References: <1235035272.4619.39.camel@localhost> <057632CE4CE10D45A1A3D6D19206C3A3DBFB5EB4@NASANEXMB08.na.qualcomm.com> <002001c992a9$e1202b80$420c7c0a@china.huawei.com> Message-ID: <057632CE4CE10D45A1A3D6D19206C3A3DBFB5ECA@NASANEXMB08.na.qualcomm.com> Hi Frank, I am happy if Huawei wants you to push this in the IETF, I hope you can make it :-) I wanted just to provide the indication that there is not any official requirement from 3GPP. We can then discuss about whatever business can drive this (what radios do you have in mind when you talk about multihoming and flow mobility for PMIP?). Gerardo > -----Original Message----- > From: Frank Xia [mailto:xiayangsong at huawei.com] > Sent: Thursday, February 19, 2009 7:51 AM > To: Giaretta, Gerardo; cjbc at it.uc3m.es; Basavaraj.Patil at nokia.com > Cc: netext at mail.mobileip.jp; Mohana.Jeyatharan at sg.panasonic.com; > Telemaco.Melia at alcatel-lucent.com > Subject: Re: [Netext] Review of the Multihoming PS I-D > > Hi All > > My 3GPP colleagues also suggested me pushing in IETF community. > If we talk about 3GPP requirment, there is even no specific PMIPv6 > multi-homing requirement. > > My point is business driving technical employment. > IMO, flow mobility is clearly required in PMIP deployment environment. > > BR > Frank > > ----- Original Message ----- > From: "Giaretta, Gerardo" > To: ; > Cc: ; ; > > Sent: Thursday, February 19, 2009 4:16 AM > Subject: Re: [Netext] Review of the Multihoming PS I-D > > > Hi all, > > To clarify flow mobility is not a requirement for PMIPv6 right now in 3GPP. > There is a study item ongoing but 3GPP has not yet decided that flow > mobility is needed for PMIPv6. > > Cheers, > Gerardo > (from Budapest, 3GPP SA2 meeting) > > > -----Original Message----- > > From: netext-bounces at mail.mobileip.jp > > [mailto:netext-bounces at mail.mobileip.jp] > > On Behalf Of Carlos Jes?s Bernardos Cano > > Sent: Thursday, February 19, 2009 1:21 AM > > To: Basavaraj.Patil at nokia.com > > Cc: Mohana.Jeyatharan at sg.panasonic.com; Telemaco.Melia at alcatel-lucent.com; > > netext at mail.mobileip.jp > > Subject: Re: [Netext] Review of the Multihoming PS I-D > > > > Hi, > > > > One question: flow mobility seems to be an interesting feature that is a > > requirement from 3GPP, it is related with multihoming but it is not > > strictly a > > multihoming isse, right? I mean, multihoming extensions would likely make > > easier to support flow mobility, but would probably require additional > > mechanisms. How do we capture this? I'm not sure the multihoming PS is the > > right place for that, maybe the multihoming PS can point out that, but we > > need > > an explicit document (and charter item) for dealing with flow mobility. > > What > > do others think? > > > > Thanks! > > > > Carlos > > > > El mi?, 18-02-2009 a las 21:39 +0100, Basavaraj.Patil at nokia.com > > escribi?: > > > It may be of interest in the context of multihoming to consider moving > > > a flow from one interface to another. A flow which is associated with > > > an interface on the MN may be moved to another interface in the case > > > of a multihomed host for various reasons. This may be viewed as a > > > handover as well from the flow perspective. Multihoming enables the > > > possibility to move flows between interfaces. I think we could keep > > > this in the context of the multihoming discussion if there is consensus > > > on > > it. > > > > > > -Raj > > > > > > > > > On 2/17/09 1:51 AM, "ext Mohana Jeyatharan" > > > wrote: > > > > > > > Hi Hidetoshi, > > > > > > > > In Multihoming PS ID, there are some handoff optimization scenarios > > involved. > > > > For example optmizing the handoff of a certain interface by means of > > > > another, and achieving flow mobility via another interface during > > > > disconnection. These events are triggered due to handoff or > > > > disconnection, but the scenarios are associated with multihoming. > > > > That is being able to receive a flow that is usually destined to an > > > > interface via another "connected" interface. This is where these > > > > scenarios are different from normal handoff and more tied to > > > > multihoming. > > > > > > > > However, I agree that these are also tied with handoff and some > > > > confusion is there. Anyway, we are planning to revise the > > > > multihoming PS draft and are thinking of focusing on the > > > > disconnection scenario, handoff optimization as less focus scenarios > > > > and > > focus on scenarios that are cateogorized by Raj. > > > > > > > > BR, > > > > Mohana > > > > > > > > > > > > -----Original Message----- > > > > From: Hidetoshi Yokota [mailto:yokota at kddilabs.jp] > > > > Sent: Tuesday, February 17, 2009 12:42 PM > > > > To: Mohana Jeyatharan > > > > Cc: Domagoj Premec; ext MELIA TELEMACO; Marco Liebsch; > > > > netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com > > > > Subject: Re: [Netext] Review of the Multihoming PS I-D > > > > > > > > Hi Mohana and all, > > > > > > > > I think your scenario is viable, but we should probably more > > > > carefully clarify the difference between multihoming and handover. > > > > Assigning the same address to different interfaces on the MN for a > > > > sufficiently long time sounds like multihoming; however, if this > > > > situation holds only for a short period of time for MN's movement or > > > > fail over or for whatever reason, that sounds like handover. This > > > > difference would affect the behavior of the LMA and MAG(s). > > > > > > > > In Section 2 of the Multihoming PS document, Issues related to > > > > handoff performance and those related to flow mobility during sudden > > > > disconnection appear to be categorized into handover. If all agree > > > > that these issues should also be included in multihoming, that's > > > > fine. I would just like to make sure of it first of all. > > > > > > > > Regards, > > > > -- > > > > Hidetoshi > > > > > > > > > > > > > _______________________________________________ > > > 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/ > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > _______________________________________________ > NetExt mailing list > NetExt at mail.mobileip.jp > http://www.mobileip.jp/mailman/listinfo/netext From: xiayangsong at huawei.com (Frank Xia) Date: Thu, 19 Feb 2009 09:50:32 -0600 Subject: [Netext] Review of the Multihoming PS I-D References: <1235035272.4619.39.camel@localhost> <057632CE4CE10D45A1A3D6D19206C3A3DBFB5EB4@NASANEXMB08.na.qualcomm.com> Message-ID: <002001c992a9$e1202b80$420c7c0a@china.huawei.com> Hi All My 3GPP colleagues also suggested me pushing in IETF community. If we talk about 3GPP requirment, there is even no specific PMIPv6 multi-homing requirement. My point is business driving technical employment. IMO, flow mobility is clearly required in PMIP deployment environment. BR Frank ----- Original Message ----- From: "Giaretta, Gerardo" To: ; Cc: ; ; Sent: Thursday, February 19, 2009 4:16 AM Subject: Re: [Netext] Review of the Multihoming PS I-D Hi all, To clarify flow mobility is not a requirement for PMIPv6 right now in 3GPP. There is a study item ongoing but 3GPP has not yet decided that flow mobility is needed for PMIPv6. Cheers, Gerardo (from Budapest, 3GPP SA2 meeting) > -----Original Message----- > From: netext-bounces at mail.mobileip.jp > [mailto:netext-bounces at mail.mobileip.jp] > On Behalf Of Carlos Jes?s Bernardos Cano > Sent: Thursday, February 19, 2009 1:21 AM > To: Basavaraj.Patil at nokia.com > Cc: Mohana.Jeyatharan at sg.panasonic.com; Telemaco.Melia at alcatel-lucent.com; > netext at mail.mobileip.jp > Subject: Re: [Netext] Review of the Multihoming PS I-D > > Hi, > > One question: flow mobility seems to be an interesting feature that is a > requirement from 3GPP, it is related with multihoming but it is not > strictly a > multihoming isse, right? I mean, multihoming extensions would likely make > easier to support flow mobility, but would probably require additional > mechanisms. How do we capture this? I'm not sure the multihoming PS is the > right place for that, maybe the multihoming PS can point out that, but we > need > an explicit document (and charter item) for dealing with flow mobility. > What > do others think? > > Thanks! > > Carlos > > El mi?, 18-02-2009 a las 21:39 +0100, Basavaraj.Patil at nokia.com > escribi?: > > It may be of interest in the context of multihoming to consider moving > > a flow from one interface to another. A flow which is associated with > > an interface on the MN may be moved to another interface in the case > > of a multihomed host for various reasons. This may be viewed as a > > handover as well from the flow perspective. Multihoming enables the > > possibility to move flows between interfaces. I think we could keep > > this in the context of the multihoming discussion if there is consensus > > on > it. > > > > -Raj > > > > > > On 2/17/09 1:51 AM, "ext Mohana Jeyatharan" > > wrote: > > > > > Hi Hidetoshi, > > > > > > In Multihoming PS ID, there are some handoff optimization scenarios > involved. > > > For example optmizing the handoff of a certain interface by means of > > > another, and achieving flow mobility via another interface during > > > disconnection. These events are triggered due to handoff or > > > disconnection, but the scenarios are associated with multihoming. > > > That is being able to receive a flow that is usually destined to an > > > interface via another "connected" interface. This is where these > > > scenarios are different from normal handoff and more tied to > > > multihoming. > > > > > > However, I agree that these are also tied with handoff and some > > > confusion is there. Anyway, we are planning to revise the > > > multihoming PS draft and are thinking of focusing on the > > > disconnection scenario, handoff optimization as less focus scenarios > > > and > focus on scenarios that are cateogorized by Raj. > > > > > > BR, > > > Mohana > > > > > > > > > -----Original Message----- > > > From: Hidetoshi Yokota [mailto:yokota at kddilabs.jp] > > > Sent: Tuesday, February 17, 2009 12:42 PM > > > To: Mohana Jeyatharan > > > Cc: Domagoj Premec; ext MELIA TELEMACO; Marco Liebsch; > > > netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com > > > Subject: Re: [Netext] Review of the Multihoming PS I-D > > > > > > Hi Mohana and all, > > > > > > I think your scenario is viable, but we should probably more > > > carefully clarify the difference between multihoming and handover. > > > Assigning the same address to different interfaces on the MN for a > > > sufficiently long time sounds like multihoming; however, if this > > > situation holds only for a short period of time for MN's movement or > > > fail over or for whatever reason, that sounds like handover. This > > > difference would affect the behavior of the LMA and MAG(s). > > > > > > In Section 2 of the Multihoming PS document, Issues related to > > > handoff performance and those related to flow mobility during sudden > > > disconnection appear to be categorized into handover. If all agree > > > that these issues should also be included in multihoming, that's > > > fine. I would just like to make sure of it first of all. > > > > > > Regards, > > > -- > > > Hidetoshi > > > > > > > > > _______________________________________________ > > 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/ > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ _______________________________________________ NetExt mailing list NetExt at mail.mobileip.jp http://www.mobileip.jp/mailman/listinfo/netext From: gerardog at qualcomm.com (Giaretta, Gerardo) Date: Thu, 19 Feb 2009 02:16:12 -0800 Subject: [Netext] Review of the Multihoming PS I-D In-Reply-To: <1235035272.4619.39.camel@localhost> References: <1235035272.4619.39.camel@localhost> Message-ID: <057632CE4CE10D45A1A3D6D19206C3A3DBFB5EB4@NASANEXMB08.na.qualcomm.com> Hi all, To clarify flow mobility is not a requirement for PMIPv6 right now in 3GPP. There is a study item ongoing but 3GPP has not yet decided that flow mobility is needed for PMIPv6. Cheers, Gerardo (from Budapest, 3GPP SA2 meeting) > -----Original Message----- > From: netext-bounces at mail.mobileip.jp [mailto:netext-bounces at mail.mobileip.jp] > On Behalf Of Carlos Jes?s Bernardos Cano > Sent: Thursday, February 19, 2009 1:21 AM > To: Basavaraj.Patil at nokia.com > Cc: Mohana.Jeyatharan at sg.panasonic.com; Telemaco.Melia at alcatel-lucent.com; > netext at mail.mobileip.jp > Subject: Re: [Netext] Review of the Multihoming PS I-D > > Hi, > > One question: flow mobility seems to be an interesting feature that is a > requirement from 3GPP, it is related with multihoming but it is not strictly a > multihoming isse, right? I mean, multihoming extensions would likely make > easier to support flow mobility, but would probably require additional > mechanisms. How do we capture this? I'm not sure the multihoming PS is the > right place for that, maybe the multihoming PS can point out that, but we need > an explicit document (and charter item) for dealing with flow mobility. What > do others think? > > Thanks! > > Carlos > > El mi?, 18-02-2009 a las 21:39 +0100, Basavaraj.Patil at nokia.com > escribi?: > > It may be of interest in the context of multihoming to consider moving > > a flow from one interface to another. A flow which is associated with > > an interface on the MN may be moved to another interface in the case > > of a multihomed host for various reasons. This may be viewed as a > > handover as well from the flow perspective. Multihoming enables the > > possibility to move flows between interfaces. I think we could keep > > this in the context of the multihoming discussion if there is consensus on > it. > > > > -Raj > > > > > > On 2/17/09 1:51 AM, "ext Mohana Jeyatharan" > > wrote: > > > > > Hi Hidetoshi, > > > > > > In Multihoming PS ID, there are some handoff optimization scenarios > involved. > > > For example optmizing the handoff of a certain interface by means of > > > another, and achieving flow mobility via another interface during > > > disconnection. These events are triggered due to handoff or > > > disconnection, but the scenarios are associated with multihoming. > > > That is being able to receive a flow that is usually destined to an > > > interface via another "connected" interface. This is where these > > > scenarios are different from normal handoff and more tied to multihoming. > > > > > > However, I agree that these are also tied with handoff and some > > > confusion is there. Anyway, we are planning to revise the > > > multihoming PS draft and are thinking of focusing on the > > > disconnection scenario, handoff optimization as less focus scenarios and > focus on scenarios that are cateogorized by Raj. > > > > > > BR, > > > Mohana > > > > > > > > > -----Original Message----- > > > From: Hidetoshi Yokota [mailto:yokota at kddilabs.jp] > > > Sent: Tuesday, February 17, 2009 12:42 PM > > > To: Mohana Jeyatharan > > > Cc: Domagoj Premec; ext MELIA TELEMACO; Marco Liebsch; > > > netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com > > > Subject: Re: [Netext] Review of the Multihoming PS I-D > > > > > > Hi Mohana and all, > > > > > > I think your scenario is viable, but we should probably more > > > carefully clarify the difference between multihoming and handover. > > > Assigning the same address to different interfaces on the MN for a > > > sufficiently long time sounds like multihoming; however, if this > > > situation holds only for a short period of time for MN's movement or > > > fail over or for whatever reason, that sounds like handover. This > > > difference would affect the behavior of the LMA and MAG(s). > > > > > > In Section 2 of the Multihoming PS document, Issues related to > > > handoff performance and those related to flow mobility during sudden > > > disconnection appear to be categorized into handover. If all agree > > > that these issues should also be included in multihoming, that's > > > fine. I would just like to make sure of it first of all. > > > > > > Regards, > > > -- > > > Hidetoshi > > > > > > > > > _______________________________________________ > > 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: liebsch at nw.neclab.eu (Marco Liebsch) Date: Thu, 19 Feb 2009 10:54:23 +0100 Subject: [Netext] Review of the Multihoming PS I-D In-Reply-To: <1235035272.4619.39.camel@localhost> References: <1235035272.4619.39.camel@localhost> Message-ID: <499D2C4F.5090203@nw.neclab.eu> Hi, Carlos Jes?s Bernardos Cano wrote: > Hi, > > One question: flow mobility seems to be an interesting feature that is > a requirement from 3GPP, it is related with multihoming but it is not > strictly a multihoming isse, right? I mean, multihoming extensions would > likely make easier to support flow mobility, but would probably require > additional mechanisms. How do we capture this? I'm not sure the > multihoming PS is the right place for that, maybe the multihoming PS can > point out that, but we need an explicit document (and charter item) for > dealing with flow mobility. What do others think? > As I said already, in my opinion moving flows is a use case for a special multi-homing case, where the MN can use the same address on multiple interfaces. Couple of things need to be done to extend PMIP to support these use cases. Here I see the charter item for NetExt. The actual move of flows is associated with the policy configuration, which is enforced on the LMA for downlink and on the MN for uplink traffic. This goes in my opinion beyond the scope of NetExt, as other components and protocol interfaces may play a role here. Similar to using MIPv6 for mobility management, but using Diameter for authentication, bootstrapping etc. Regarding NetExt, multi-homing and routing policy control are separate things, in my view. marco > Thanks! > > Carlos > > El mi?, 18-02-2009 a las 21:39 +0100, Basavaraj.Patil at nokia.com > escribi?: > >> It may be of interest in the context of multihoming to consider moving a >> flow from one interface to another. A flow which is associated with an >> interface on the MN may be moved to another interface in the case of a >> multihomed host for various reasons. This may be viewed as a handover as >> well from the flow perspective. Multihoming enables the possibility to move >> flows between interfaces. I think we could keep this in the context of the >> multihoming discussion if there is consensus on it. >> >> -Raj >> >> >> On 2/17/09 1:51 AM, "ext Mohana Jeyatharan" >> wrote: >> >> >>> Hi Hidetoshi, >>> >>> In Multihoming PS ID, there are some handoff optimization scenarios involved. >>> For example optmizing the handoff of a certain interface by means of another, >>> and achieving flow mobility via another interface during disconnection. These >>> events are triggered due to handoff or disconnection, but the scenarios are >>> associated with multihoming. That is being able to receive a flow that is >>> usually destined to an interface via another "connected" interface. This is >>> where these scenarios are different from normal handoff and more tied to >>> multihoming. >>> >>> However, I agree that these are also tied with handoff and some confusion is >>> there. Anyway, we are planning to revise the multihoming PS draft and are >>> thinking of focusing on the disconnection scenario, handoff optimization as >>> less focus scenarios and focus on scenarios that are cateogorized by Raj. >>> >>> BR, >>> Mohana >>> >>> >>> -----Original Message----- >>> From: Hidetoshi Yokota [mailto:yokota at kddilabs.jp] >>> Sent: Tuesday, February 17, 2009 12:42 PM >>> To: Mohana Jeyatharan >>> Cc: Domagoj Premec; ext MELIA TELEMACO; Marco Liebsch; >>> netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com >>> Subject: Re: [Netext] Review of the Multihoming PS I-D >>> >>> Hi Mohana and all, >>> >>> I think your scenario is viable, but we should probably more carefully >>> clarify the difference between multihoming and handover. Assigning the >>> same address to different interfaces on the MN for a sufficiently long >>> time sounds like multihoming; however, if this situation holds only for >>> a short period of time for MN's movement or fail over or for whatever >>> reason, that sounds like handover. This difference would affect the >>> behavior of the LMA and MAG(s). >>> >>> In Section 2 of the Multihoming PS document, Issues related to handoff >>> performance and those related to flow mobility during sudden >>> disconnection appear to be categorized into handover. If all agree that >>> these issues should also be included in multihoming, that's fine. I >>> would just like to make sure of it first of all. >>> >>> Regards, >>> -- >>> Hidetoshi >>> >>> >> _______________________________________________ >> 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: Thu, 19 Feb 2009 10:21:12 +0100 Subject: [Netext] Review of the Multihoming PS I-D In-Reply-To: References: Message-ID: <1235035272.4619.39.camel@localhost> Hi, One question: flow mobility seems to be an interesting feature that is a requirement from 3GPP, it is related with multihoming but it is not strictly a multihoming isse, right? I mean, multihoming extensions would likely make easier to support flow mobility, but would probably require additional mechanisms. How do we capture this? I'm not sure the multihoming PS is the right place for that, maybe the multihoming PS can point out that, but we need an explicit document (and charter item) for dealing with flow mobility. What do others think? Thanks! Carlos El mi?, 18-02-2009 a las 21:39 +0100, Basavaraj.Patil at nokia.com escribi?: > It may be of interest in the context of multihoming to consider moving a > flow from one interface to another. A flow which is associated with an > interface on the MN may be moved to another interface in the case of a > multihomed host for various reasons. This may be viewed as a handover as > well from the flow perspective. Multihoming enables the possibility to move > flows between interfaces. I think we could keep this in the context of the > multihoming discussion if there is consensus on it. > > -Raj > > > On 2/17/09 1:51 AM, "ext Mohana Jeyatharan" > wrote: > > > Hi Hidetoshi, > > > > In Multihoming PS ID, there are some handoff optimization scenarios involved. > > For example optmizing the handoff of a certain interface by means of another, > > and achieving flow mobility via another interface during disconnection. These > > events are triggered due to handoff or disconnection, but the scenarios are > > associated with multihoming. That is being able to receive a flow that is > > usually destined to an interface via another "connected" interface. This is > > where these scenarios are different from normal handoff and more tied to > > multihoming. > > > > However, I agree that these are also tied with handoff and some confusion is > > there. Anyway, we are planning to revise the multihoming PS draft and are > > thinking of focusing on the disconnection scenario, handoff optimization as > > less focus scenarios and focus on scenarios that are cateogorized by Raj. > > > > BR, > > Mohana > > > > > > -----Original Message----- > > From: Hidetoshi Yokota [mailto:yokota at kddilabs.jp] > > Sent: Tuesday, February 17, 2009 12:42 PM > > To: Mohana Jeyatharan > > Cc: Domagoj Premec; ext MELIA TELEMACO; Marco Liebsch; > > netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com > > Subject: Re: [Netext] Review of the Multihoming PS I-D > > > > Hi Mohana and all, > > > > I think your scenario is viable, but we should probably more carefully > > clarify the difference between multihoming and handover. Assigning the > > same address to different interfaces on the MN for a sufficiently long > > time sounds like multihoming; however, if this situation holds only for > > a short period of time for MN's movement or fail over or for whatever > > reason, that sounds like handover. This difference would affect the > > behavior of the LMA and MAG(s). > > > > In Section 2 of the Multihoming PS document, Issues related to handoff > > performance and those related to flow mobility during sudden > > disconnection appear to be categorized into handover. If all agree that > > these issues should also be included in multihoming, that's fine. I > > would just like to make sure of it first of all. > > > > Regards, > > -- > > Hidetoshi > > > > > _______________________________________________ > 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: Telemaco.Melia at alcatel-lucent.com (MELIA TELEMACO) Date: Thu, 19 Feb 2009 09:13:14 +0100 Subject: [Netext] Review of the Multihoming PS I-D In-Reply-To: <5F09D220B62F79418461A978CA0921BD032B51DA@pslexc01.psl.local> References: <5F09D220B62F79418461A978CA0921BD032B51DA@pslexc01.psl.local> Message-ID: <853DD750D9C3724FBF2DF7164FCF641C0295A841@FRVELSMBS14.ad2.ad.alcatel.com> Hi Mohana, Few comments below: If same address is assigned to different interfaces, MN and LMA need to share routing policy to route each flow to the correct interface. But distribution of policies is an issue; I mean, distribution of policies could be done via an interface between LMA and MN, but it would be a severe violation of PMIP architecture. [Mohana] Distribution of policy can be done by MN-AR interface as well. No need of MN-LMA interaction.... [TELE] About policies distribution: I am not sure what is the feeling of people here, but this thread is very similar to what has been discussed in the MIP4 session last time @Minneapolis on Multiple CoA Support (Sri). The major concern from Jari and Henrik was that policy distribution cannot be ignored and left behind (you can check the minutes), the protocol might become useless otherwise. So, even if other distribution schemes can be possible, I do not really see why sharing same address on several interfaces can facilitate IP flow mobility. Mainly because routing in that case is a tricky problem. It seems to me that this feature brings more issues than benefits... [Mohana] I am not so sure about the issues you are conecrned with. On the other hand RFC 5213 provides a basic support of IP mobility between different interfaces. But here the issue is on the determination of the "handoff indicator" at the MAG. Don't you think that clarification on the determination of the "handoff indicator" in case of multihoming and IP flow mobility would worth the effort in Netext? [Mohana] Of course for IP flow mobility and multihoming, proper MN-MAG triggers may need to be present. RFC 5213 does not specify how MAGs get the HI indicator options. It canbe via L2 or some other way. But for multihoming host may need to accept packets destined to one interface via another. [TELE] Glad that you mention this, Carlos already did before. I think that this change affects the terminal as much as having the same address configured on two interfaces. The PS document should capture this. An intelligent client can do this knowing that this is PMIPv6. Anyway, in some SDOs the mobility management mechansims are known to the Mn if it wants to. They do have mobility mode selection kind of methods. Thus such multihoming in PMIPv6 can be achievable without much difficulty. My two cents, Regards, Pierrick > -----Message d'origine----- > De?: netext-bounces at mail.mobileip.jp [mailto:netext- > bounces at mail.mobileip.jp] De la part de MELIA TELEMACO Envoy??: mardi > 17 f?vrier 2009 17:41 ??: Marco Liebsch; Hidetoshi Yokota Cc?: > netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com Objet?: Re: > [Netext] Review of the Multihoming PS I-D > > Hi, > > I guess there are two important emerging aspects out of this discussion: > - involvement of the mobile node in the multihoming process > - transfer of policies, how and where to > > I would like also to stress the fact that we should not necessarily > see multihoming as a solution to optimize mobility. > A node can be multihomed without moving at all (nomadic user) and we > have other documents (transient BCE) looking at how to optimize mobility. > > How folks see things? > > telemaco > > > -----Message d'origine----- > De : Marco Liebsch [mailto:liebsch at nw.neclab.eu] Envoy? : mardi 17 > f?vrier 2009 15:06 ? : Hidetoshi Yokota Cc : netext at mail.mobileip.jp; > MELIA TELEMACO; Basavaraj.Patil at nokia.com Objet : Re: [Netext] Review > of the Multihoming PS I-D > > Hidetoshi Yokota wrote: > > Hi Marco, > > > > Marco Liebsch wrote: > > > >> Hidetoshi, > >> > > > > I'm still talking about definitions and categorization. I'm not > > downplaying any of them. > > > sure. > > > > >> I think we have different opinions on an important aspect: > >> My understanding of your opinion is that as soon as the MN gets > >> (e.g.) HNP1 assigned to interface 1 (IF1) as a result of the > >> registration, it can use the same HNP1 for a different interface, > >> e.g. IF2, without having this HNP1 received from the network as a > >> result of IF2's registration. > >> Correct? > >> > > > > No, I'm not going that far, yet :-). I'm still trying to understand > > what people are thinking about multihoming, handover and IP flow > > mobility, etc. My understanding is that if the MN wants to use HNP1 > > on IF2, it would have to register it with the LMA via the > > corresponding MAG; otherwise, there would be no guarantee that > > packets are coming back > to IF2. > > > Ok. > > > > >> I think the MN can use HNP1 only for IF2, if the LMA assigns the > >> same > >> HNP1 to IF2 during its registration. To result then in the same IP > >> address, it's up to the MN to take the same suffix for both interfaces' > IP address. > >> That's again something where we have the same opinion. > >> > > > > I think this is a sensible behavior. The key thing is to give a hint > > to the LMA on which interface the MN wants to get packets. > > > Well, yes, the LMA needs a hint about the routing policy (which flow > goes which way). But here the MN plays a role and that hint may not > come with > PMIPv6 signaling. > > > > >> So, when we talk about using the same IP address on both > >> interfaces, still the allowed prefix for each interface is network > >> controlled, whereas the MN is free to chose any suffix. That's at least my view. > >> > > > > I personally agree with your view. In addition, the LMA should get > > in sync with the MN especially when those two interfaces are > > connected to different MAGs. > > > Thanks for the clarification. > > Greetings, > marco > > > Regards, > > > > > _______________________________________________ > 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: yokota at kddilabs.jp (Hidetoshi Yokota) Date: Thu, 19 Feb 2009 13:40:08 +0900 Subject: [Netext] Review of the Multihoming PS I-D In-Reply-To: References: Message-ID: <499CE2A8.7040707@kddilabs.jp> Hi Raj, Basavaraj.Patil at nokia.com wrote: > It may be of interest in the context of multihoming to consider moving a > flow from one interface to another. A flow which is associated with an > interface on the MN may be moved to another interface in the case of a > multihomed host for various reasons. This may be viewed as a handover as > well from the flow perspective. Multihoming enables the possibility to move > flows between interfaces. I think we could keep this in the context of the > multihoming discussion if there is consensus on it. Ok, but one question: if the flow is moved to another interface by the way that the same address is assigned after releasing it from the old interface, namely, *not* simultaneously (e.g., single radio case), is this type of flow mobility still called multihoming? Or, by definition, a flow mobility can be realized only in the situation where the simultaneous address assignment is feasible? Regards, -- Hidetoshi > -Raj > > > On 2/17/09 1:51 AM, "ext Mohana Jeyatharan" > wrote: > >> Hi Hidetoshi, >> >> In Multihoming PS ID, there are some handoff optimization scenarios involved. >> For example optmizing the handoff of a certain interface by means of another, >> and achieving flow mobility via another interface during disconnection. These >> events are triggered due to handoff or disconnection, but the scenarios are >> associated with multihoming. That is being able to receive a flow that is >> usually destined to an interface via another "connected" interface. This is >> where these scenarios are different from normal handoff and more tied to >> multihoming. >> >> However, I agree that these are also tied with handoff and some confusion is >> there. Anyway, we are planning to revise the multihoming PS draft and are >> thinking of focusing on the disconnection scenario, handoff optimization as >> less focus scenarios and focus on scenarios that are cateogorized by Raj. >> >> BR, >> Mohana >> >> >> -----Original Message----- >> From: Hidetoshi Yokota [mailto:yokota at kddilabs.jp] >> Sent: Tuesday, February 17, 2009 12:42 PM >> To: Mohana Jeyatharan >> Cc: Domagoj Premec; ext MELIA TELEMACO; Marco Liebsch; >> netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com >> Subject: Re: [Netext] Review of the Multihoming PS I-D >> >> Hi Mohana and all, >> >> I think your scenario is viable, but we should probably more carefully >> clarify the difference between multihoming and handover. Assigning the >> same address to different interfaces on the MN for a sufficiently long >> time sounds like multihoming; however, if this situation holds only for >> a short period of time for MN's movement or fail over or for whatever >> reason, that sounds like handover. This difference would affect the >> behavior of the LMA and MAG(s). >> >> In Section 2 of the Multihoming PS document, Issues related to handoff >> performance and those related to flow mobility during sudden >> disconnection appear to be categorized into handover. If all agree that >> these issues should also be included in multihoming, that's fine. I >> would just like to make sure of it first of all. >> >> Regards, >> -- >> Hidetoshi >> > > > > From: xiayangsong at huawei.com (Frank Xia) Date: Wed, 18 Feb 2009 20:00:22 -0600 Subject: [Netext] Flow Binding in Proxy Mobile IPv6 Message-ID: <004a01c99235$d50730b0$0401a8c0@china.huawei.com> 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 IP flows to different interfaces of a mobile node. BR Frank -------------- next part -------------- An HTML attachment was scrubbed... URL: From: Mohana.Jeyatharan at sg.panasonic.com (Mohana Jeyatharan) Date: Thu, 19 Feb 2009 08:38:23 +0800 Subject: [Netext] Review of the Multihoming PS I-D In-Reply-To: Message-ID: <5F09D220B62F79418461A978CA0921BD032B51DA@pslexc01.psl.local> Hi Pierrick, Saw your mail. Some good thoughts in your mail. Please see some in-line ... BR, Mohana -----Original Message----- From: netext-bounces at mail.mobileip.jp [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of pierrick.seite at orange-ftgroup.com Sent: Wednesday, February 18, 2009 6:40 PM To: Telemaco.Melia at alcatel-lucent.com; liebsch at nw.neclab.eu; yokota at kddilabs.jp Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com Subject: Re: [Netext] Review of the Multihoming PS I-D Hi Telemaco, Marco, Hidetoshi and all, Just for a better understanding of this thread. If same address is assigned to different interfaces, MN and LMA need to share routing policy to route each flow to the correct interface. But distribution of policies is an issue; I mean, distribution of policies could be done via an interface between LMA and MN, but it would be a severe violation of PMIP architecture. [Mohana] Distribution of policy can be done by MN-AR interface as well. No need of MN-LMA interaction.... So, even if other distribution schemes can be possible, I do not really see why sharing same address on several interfaces can facilitate IP flow mobility. Mainly because routing in that case is a tricky problem. It seems to me that this feature brings more issues than benefits... [Mohana] I am not so sure about the issues you are conecrned with. On the other hand RFC 5213 provides a basic support of IP mobility between different interfaces. But here the issue is on the determination of the "handoff indicator" at the MAG. Don't you think that clarification on the determination of the "handoff indicator" in case of multihoming and IP flow mobility would worth the effort in Netext? [Mohana] Of course for IP flow mobility and multihoming, proper MN-MAG triggers may need to be present. RFC 5213 does not specify how MAGs get the HI indicator options. It canbe via L2 or some other way. But for multihoming host may need to accept packets destined to one interface via another. An intelligent client can do this knowing that this is PMIPv6. Anyway, in some SDOs the mobility management mechansims are known to the Mn if it wants to. They do have mobility mode selection kind of methods. Thus such multihoming in PMIPv6 can be achievable without much difficulty. My two cents, Regards, Pierrick > -----Message d'origine----- > De?: netext-bounces at mail.mobileip.jp [mailto:netext- > bounces at mail.mobileip.jp] De la part de MELIA TELEMACO > Envoy??: mardi 17 f?vrier 2009 17:41 > ??: Marco Liebsch; Hidetoshi Yokota > Cc?: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com > Objet?: Re: [Netext] Review of the Multihoming PS I-D > > Hi, > > I guess there are two important emerging aspects out of this discussion: > - involvement of the mobile node in the multihoming process > - transfer of policies, how and where to > > I would like also to stress the fact that we should not necessarily see > multihoming as a solution to optimize mobility. > A node can be multihomed without moving at all (nomadic user) and we have > other documents (transient BCE) looking at how to optimize mobility. > > How folks see things? > > telemaco > > > -----Message d'origine----- > De : Marco Liebsch [mailto:liebsch at nw.neclab.eu] > Envoy? : mardi 17 f?vrier 2009 15:06 > ? : Hidetoshi Yokota > Cc : netext at mail.mobileip.jp; MELIA TELEMACO; Basavaraj.Patil at nokia.com > Objet : Re: [Netext] Review of the Multihoming PS I-D > > Hidetoshi Yokota wrote: > > Hi Marco, > > > > Marco Liebsch wrote: > > > >> Hidetoshi, > >> > > > > I'm still talking about definitions and categorization. I'm not > > downplaying any of them. > > > sure. > > > > >> I think we have different opinions on an important aspect: > >> My understanding of your opinion is that as soon as the MN gets > >> (e.g.) HNP1 assigned to interface 1 (IF1) as a result of the > >> registration, it can use the same HNP1 for a different interface, > >> e.g. IF2, without having this HNP1 received from the network as a > >> result of IF2's registration. > >> Correct? > >> > > > > No, I'm not going that far, yet :-). I'm still trying to understand > > what people are thinking about multihoming, handover and IP flow > > mobility, etc. My understanding is that if the MN wants to use HNP1 on > > IF2, it would have to register it with the LMA via the corresponding > > MAG; otherwise, there would be no guarantee that packets are coming back > to IF2. > > > Ok. > > > > >> I think the MN can use HNP1 only for IF2, if the LMA assigns the same > >> HNP1 to IF2 during its registration. To result then in the same IP > >> address, it's up to the MN to take the same suffix for both interfaces' > IP address. > >> That's again something where we have the same opinion. > >> > > > > I think this is a sensible behavior. The key thing is to give a hint > > to the LMA on which interface the MN wants to get packets. > > > Well, yes, the LMA needs a hint about the routing policy (which flow goes > which way). But here the MN plays a role and that hint may not come with > PMIPv6 signaling. > > > > >> So, when we talk about using the same IP address on both interfaces, > >> still the allowed prefix for each interface is network controlled, > >> whereas the MN is free to chose any suffix. That's at least my view. > >> > > > > I personally agree with your view. In addition, the LMA should get in > > sync with the MN especially when those two interfaces are connected to > > different MAGs. > > > Thanks for the clarification. > > Greetings, > marco > > > Regards, > > > > > _______________________________________________ > 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: Mohana.Jeyatharan at sg.panasonic.com (Mohana Jeyatharan) Date: Thu, 19 Feb 2009 08:23:14 +0800 Subject: [Netext] Review of the Multihoming PS I-D In-Reply-To: Message-ID: <5F09D220B62F79418461A978CA0921BD032B51D9@pslexc01.psl.local> Hello Raj, Yes, agree with you. Flow mobility can be achieved by means of multihoming. So the system should support multihoming and flow mobility parameters can be set using some other mechanisms (flow binding). So flow mobility is dependent on multihoming. Thanks. BR, Mohana -----Original Message----- From: Basavaraj.Patil at nokia.com [mailto:Basavaraj.Patil at nokia.com] Sent: Thursday, February 19, 2009 4:39 AM To: Mohana Jeyatharan; yokota at kddilabs.jp Cc: domagoj.premec.ext at nsn.com; Telemaco.Melia at alcatel-lucent.com; marco.liebsch at nw.neclab.eu; netext at mail.mobileip.jp Subject: Re: [Netext] Review of the Multihoming PS I-D It may be of interest in the context of multihoming to consider moving a flow from one interface to another. A flow which is associated with an interface on the MN may be moved to another interface in the case of a multihomed host for various reasons. This may be viewed as a handover as well from the flow perspective. Multihoming enables the possibility to move flows between interfaces. I think we could keep this in the context of the multihoming discussion if there is consensus on it. -Raj On 2/17/09 1:51 AM, "ext Mohana Jeyatharan" wrote: > Hi Hidetoshi, > > In Multihoming PS ID, there are some handoff optimization scenarios involved. > For example optmizing the handoff of a certain interface by means of another, > and achieving flow mobility via another interface during disconnection. These > events are triggered due to handoff or disconnection, but the scenarios are > associated with multihoming. That is being able to receive a flow that is > usually destined to an interface via another "connected" interface. This is > where these scenarios are different from normal handoff and more tied to > multihoming. > > However, I agree that these are also tied with handoff and some confusion is > there. Anyway, we are planning to revise the multihoming PS draft and are > thinking of focusing on the disconnection scenario, handoff optimization as > less focus scenarios and focus on scenarios that are cateogorized by Raj. > > BR, > Mohana > > > -----Original Message----- > From: Hidetoshi Yokota [mailto:yokota at kddilabs.jp] > Sent: Tuesday, February 17, 2009 12:42 PM > To: Mohana Jeyatharan > Cc: Domagoj Premec; ext MELIA TELEMACO; Marco Liebsch; > netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com > Subject: Re: [Netext] Review of the Multihoming PS I-D > > Hi Mohana and all, > > I think your scenario is viable, but we should probably more carefully > clarify the difference between multihoming and handover. Assigning the > same address to different interfaces on the MN for a sufficiently long > time sounds like multihoming; however, if this situation holds only for > a short period of time for MN's movement or fail over or for whatever > reason, that sounds like handover. This difference would affect the > behavior of the LMA and MAG(s). > > In Section 2 of the Multihoming PS document, Issues related to handoff > performance and those related to flow mobility during sudden > disconnection appear to be categorized into handover. If all agree that > these issues should also be included in multihoming, that's fine. I > would just like to make sure of it first of all. > > Regards, > -- > Hidetoshi > From: xiayangsong at huawei.com (Frank Xia) Date: Wed, 18 Feb 2009 15:08:26 -0600 Subject: [Netext] Review of the Multihoming PS I-D References: Message-ID: <004601c9920d$0b1426f0$420c7c0a@china.huawei.com> Hi Raj Flow binding ( or IP flow mobility) is an explicit requirement from 3GPP. It should be included in the context. BR Frank ----- Original Message ----- From: To: ; Cc: ; Sent: Wednesday, February 18, 2009 2:39 PM Subject: Re: [Netext] Review of the Multihoming PS I-D > > It may be of interest in the context of multihoming to consider moving a > flow from one interface to another. A flow which is associated with an > interface on the MN may be moved to another interface in the case of a > multihomed host for various reasons. This may be viewed as a handover as > well from the flow perspective. Multihoming enables the possibility to > move > flows between interfaces. I think we could keep this in the context of the > multihoming discussion if there is consensus on it. > > -Raj > > > On 2/17/09 1:51 AM, "ext Mohana Jeyatharan" > wrote: > >> Hi Hidetoshi, >> >> In Multihoming PS ID, there are some handoff optimization scenarios >> involved. >> For example optmizing the handoff of a certain interface by means of >> another, >> and achieving flow mobility via another interface during disconnection. >> These >> events are triggered due to handoff or disconnection, but the scenarios >> are >> associated with multihoming. That is being able to receive a flow that is >> usually destined to an interface via another "connected" interface. This >> is >> where these scenarios are different from normal handoff and more tied to >> multihoming. >> >> However, I agree that these are also tied with handoff and some confusion >> is >> there. Anyway, we are planning to revise the multihoming PS draft and are >> thinking of focusing on the disconnection scenario, handoff optimization >> as >> less focus scenarios and focus on scenarios that are cateogorized by Raj. >> >> BR, >> Mohana >> >> >> -----Original Message----- >> From: Hidetoshi Yokota [mailto:yokota at kddilabs.jp] >> Sent: Tuesday, February 17, 2009 12:42 PM >> To: Mohana Jeyatharan >> Cc: Domagoj Premec; ext MELIA TELEMACO; Marco Liebsch; >> netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com >> Subject: Re: [Netext] Review of the Multihoming PS I-D >> >> Hi Mohana and all, >> >> I think your scenario is viable, but we should probably more carefully >> clarify the difference between multihoming and handover. Assigning the >> same address to different interfaces on the MN for a sufficiently long >> time sounds like multihoming; however, if this situation holds only for >> a short period of time for MN's movement or fail over or for whatever >> reason, that sounds like handover. This difference would affect the >> behavior of the LMA and MAG(s). >> >> In Section 2 of the Multihoming PS document, Issues related to handoff >> performance and those related to flow mobility during sudden >> disconnection appear to be categorized into handover. If all agree that >> these issues should also be included in multihoming, that's fine. I >> would just like to make sure of it first of all. >> >> Regards, >> -- >> Hidetoshi >> > > > _______________________________________________ > 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: Wed, 18 Feb 2009 21:44:03 +0100 Subject: [Netext] Review of the Multihoming PS I-D In-Reply-To: <499AB4B3.1060709@kddilabs.jp> Message-ID: Hello Yokota san, On 2/17/09 6:59 AM, "ext Hidetoshi Yokota" wrote: > Ok, a handover could be a special case of IP flow mobility. This > handover probably means the switching of interfaces (e.g. due to the > change of access technologies). We should putt aside a "session > handover" for the moment;-). > > I, however, still believe that we should differentiate handover/IP flow > mobility from multihoming. I agree with your comment that multihoming and IP flow mobility are not synonymous. When you have an MN which is multihomed you could achieve IP flow mobility across different interfaces. But lets keep the definition of multihoming clear and not mix it with flow mobility. -Raj > > Regards, > -- > Hidetoshi From: Basavaraj.Patil at nokia.com (Basavaraj.Patil at nokia.com) Date: Wed, 18 Feb 2009 21:39:16 +0100 Subject: [Netext] Review of the Multihoming PS I-D In-Reply-To: <5F09D220B62F79418461A978CA0921BD032B4EDB@pslexc01.psl.local> Message-ID: It may be of interest in the context of multihoming to consider moving a flow from one interface to another. A flow which is associated with an interface on the MN may be moved to another interface in the case of a multihomed host for various reasons. This may be viewed as a handover as well from the flow perspective. Multihoming enables the possibility to move flows between interfaces. I think we could keep this in the context of the multihoming discussion if there is consensus on it. -Raj On 2/17/09 1:51 AM, "ext Mohana Jeyatharan" wrote: > Hi Hidetoshi, > > In Multihoming PS ID, there are some handoff optimization scenarios involved. > For example optmizing the handoff of a certain interface by means of another, > and achieving flow mobility via another interface during disconnection. These > events are triggered due to handoff or disconnection, but the scenarios are > associated with multihoming. That is being able to receive a flow that is > usually destined to an interface via another "connected" interface. This is > where these scenarios are different from normal handoff and more tied to > multihoming. > > However, I agree that these are also tied with handoff and some confusion is > there. Anyway, we are planning to revise the multihoming PS draft and are > thinking of focusing on the disconnection scenario, handoff optimization as > less focus scenarios and focus on scenarios that are cateogorized by Raj. > > BR, > Mohana > > > -----Original Message----- > From: Hidetoshi Yokota [mailto:yokota at kddilabs.jp] > Sent: Tuesday, February 17, 2009 12:42 PM > To: Mohana Jeyatharan > Cc: Domagoj Premec; ext MELIA TELEMACO; Marco Liebsch; > netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com > Subject: Re: [Netext] Review of the Multihoming PS I-D > > Hi Mohana and all, > > I think your scenario is viable, but we should probably more carefully > clarify the difference between multihoming and handover. Assigning the > same address to different interfaces on the MN for a sufficiently long > time sounds like multihoming; however, if this situation holds only for > a short period of time for MN's movement or fail over or for whatever > reason, that sounds like handover. This difference would affect the > behavior of the LMA and MAG(s). > > In Section 2 of the Multihoming PS document, Issues related to handoff > performance and those related to flow mobility during sudden > disconnection appear to be categorized into handover. If all agree that > these issues should also be included in multihoming, that's fine. I > would just like to make sure of it first of all. > > Regards, > -- > Hidetoshi > From: pierrick.seite at orange-ftgroup.com (pierrick.seite at orange-ftgroup.com) Date: Wed, 18 Feb 2009 11:39:32 +0100 Subject: [Netext] Review of the Multihoming PS I-D In-Reply-To: <853DD750D9C3724FBF2DF7164FCF641C0295A101@FRVELSMBS14.ad2.ad.alcatel.com> References: <853DD750D9C3724FBF2DF7164FCF641C0292167E@FRVELSMBS14.ad2.ad.alcatel.com> <49994B20.7010702@nw.neclab.eu><499958D8.50402@kddilabs.jp> <499997D1.4010503@nw.neclab.eu><499A2708.1040709@kddilabs.jp> <499A441B.5080900@kddilabs.jp><499AB687.7070701@nw.neclab.eu> <499ABD0C.4010006@kddilabs.jp><499AC45B.3060500@nw.neclab.eu> <853DD750D9C3724FBF2DF7164FCF641C0295A101@FRVELSMBS14.ad2.ad.alcatel.com> Message-ID: Hi Telemaco, Marco, Hidetoshi and all, Just for a better understanding of this thread. If same address is assigned to different interfaces, MN and LMA need to share routing policy to route each flow to the correct interface. But distribution of policies is an issue; I mean, distribution of policies could be done via an interface between LMA and MN, but it would be a severe violation of PMIP architecture. So, even if other distribution schemes can be possible, I do not really see why sharing same address on several interfaces can facilitate IP flow mobility. Mainly because routing in that case is a tricky problem. It seems to me that this feature brings more issues than benefits... On the other hand RFC 5213 provides a basic support of IP mobility between different interfaces. But here the issue is on the determination of the "handoff indicator" at the MAG. Don't you think that clarification on the determination of the "handoff indicator" in case of multihoming and IP flow mobility would worth the effort in Netext? My two cents, Regards, Pierrick > -----Message d'origine----- > De?: netext-bounces at mail.mobileip.jp [mailto:netext- > bounces at mail.mobileip.jp] De la part de MELIA TELEMACO > Envoy??: mardi 17 f?vrier 2009 17:41 > ??: Marco Liebsch; Hidetoshi Yokota > Cc?: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com > Objet?: Re: [Netext] Review of the Multihoming PS I-D > > Hi, > > I guess there are two important emerging aspects out of this discussion: > - involvement of the mobile node in the multihoming process > - transfer of policies, how and where to > > I would like also to stress the fact that we should not necessarily see > multihoming as a solution to optimize mobility. > A node can be multihomed without moving at all (nomadic user) and we have > other documents (transient BCE) looking at how to optimize mobility. > > How folks see things? > > telemaco > > > -----Message d'origine----- > De : Marco Liebsch [mailto:liebsch at nw.neclab.eu] > Envoy? : mardi 17 f?vrier 2009 15:06 > ? : Hidetoshi Yokota > Cc : netext at mail.mobileip.jp; MELIA TELEMACO; Basavaraj.Patil at nokia.com > Objet : Re: [Netext] Review of the Multihoming PS I-D > > Hidetoshi Yokota wrote: > > Hi Marco, > > > > Marco Liebsch wrote: > > > >> Hidetoshi, > >> > > > > I'm still talking about definitions and categorization. I'm not > > downplaying any of them. > > > sure. > > > > >> I think we have different opinions on an important aspect: > >> My understanding of your opinion is that as soon as the MN gets > >> (e.g.) HNP1 assigned to interface 1 (IF1) as a result of the > >> registration, it can use the same HNP1 for a different interface, > >> e.g. IF2, without having this HNP1 received from the network as a > >> result of IF2's registration. > >> Correct? > >> > > > > No, I'm not going that far, yet :-). I'm still trying to understand > > what people are thinking about multihoming, handover and IP flow > > mobility, etc. My understanding is that if the MN wants to use HNP1 on > > IF2, it would have to register it with the LMA via the corresponding > > MAG; otherwise, there would be no guarantee that packets are coming back > to IF2. > > > Ok. > > > > >> I think the MN can use HNP1 only for IF2, if the LMA assigns the same > >> HNP1 to IF2 during its registration. To result then in the same IP > >> address, it's up to the MN to take the same suffix for both interfaces' > IP address. > >> That's again something where we have the same opinion. > >> > > > > I think this is a sensible behavior. The key thing is to give a hint > > to the LMA on which interface the MN wants to get packets. > > > Well, yes, the LMA needs a hint about the routing policy (which flow goes > which way). But here the MN plays a role and that hint may not come with > PMIPv6 signaling. > > > > >> So, when we talk about using the same IP address on both interfaces, > >> still the allowed prefix for each interface is network controlled, > >> whereas the MN is free to chose any suffix. That's at least my view. > >> > > > > I personally agree with your view. In addition, the LMA should get in > > sync with the MN especially when those two interfaces are connected to > > different MAGs. > > > Thanks for the clarification. > > Greetings, > marco > > > Regards, > > > > > _______________________________________________ > 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: Tue, 17 Feb 2009 17:41:06 +0100 Subject: [Netext] Review of the Multihoming PS I-D In-Reply-To: <499AC45B.3060500@nw.neclab.eu> References: <853DD750D9C3724FBF2DF7164FCF641C0292167E@FRVELSMBS14.ad2.ad.alcatel.com> <49994B20.7010702@nw.neclab.eu> <499958D8.50402@kddilabs.jp> <499997D1.4010503@nw.neclab.eu> <499A2708.1040709@kddilabs.jp> <499A441B.5080900@kddilabs.jp> <499AB687.7070701@nw.neclab.eu> <499ABD0C.4010006@kddilabs.jp> <499AC45B.3060500@nw.neclab.eu> Message-ID: <853DD750D9C3724FBF2DF7164FCF641C0295A101@FRVELSMBS14.ad2.ad.alcatel.com> Hi, I guess there are two important emerging aspects out of this discussion: - involvement of the mobile node in the multihoming process - transfer of policies, how and where to I would like also to stress the fact that we should not necessarily see multihoming as a solution to optimize mobility. A node can be multihomed without moving at all (nomadic user) and we have other documents (transient BCE) looking at how to optimize mobility. How folks see things? telemaco -----Message d'origine----- De : Marco Liebsch [mailto:liebsch at nw.neclab.eu] Envoy? : mardi 17 f?vrier 2009 15:06 ? : Hidetoshi Yokota Cc : netext at mail.mobileip.jp; MELIA TELEMACO; Basavaraj.Patil at nokia.com Objet : Re: [Netext] Review of the Multihoming PS I-D Hidetoshi Yokota wrote: > Hi Marco, > > Marco Liebsch wrote: > >> Hidetoshi, >> > > I'm still talking about definitions and categorization. I'm not > downplaying any of them. > sure. > >> I think we have different opinions on an important aspect: >> My understanding of your opinion is that as soon as the MN gets >> (e.g.) HNP1 assigned to interface 1 (IF1) as a result of the >> registration, it can use the same HNP1 for a different interface, >> e.g. IF2, without having this HNP1 received from the network as a >> result of IF2's registration. >> Correct? >> > > No, I'm not going that far, yet :-). I'm still trying to understand > what people are thinking about multihoming, handover and IP flow > mobility, etc. My understanding is that if the MN wants to use HNP1 on > IF2, it would have to register it with the LMA via the corresponding > MAG; otherwise, there would be no guarantee that packets are coming back to IF2. > Ok. > >> I think the MN can use HNP1 only for IF2, if the LMA assigns the same >> HNP1 to IF2 during its registration. To result then in the same IP >> address, it's up to the MN to take the same suffix for both interfaces' IP address. >> That's again something where we have the same opinion. >> > > I think this is a sensible behavior. The key thing is to give a hint > to the LMA on which interface the MN wants to get packets. > Well, yes, the LMA needs a hint about the routing policy (which flow goes which way). But here the MN plays a role and that hint may not come with PMIPv6 signaling. > >> So, when we talk about using the same IP address on both interfaces, >> still the allowed prefix for each interface is network controlled, >> whereas the MN is free to chose any suffix. That's at least my view. >> > > I personally agree with your view. In addition, the LMA should get in > sync with the MN especially when those two interfaces are connected to > different MAGs. > Thanks for the clarification. Greetings, marco > Regards, > From: liebsch at nw.neclab.eu (Marco Liebsch) Date: Tue, 17 Feb 2009 15:06:19 +0100 Subject: [Netext] Review of the Multihoming PS I-D In-Reply-To: <499ABD0C.4010006@kddilabs.jp> References: <853DD750D9C3724FBF2DF7164FCF641C0292167E@FRVELSMBS14.ad2.ad.alcatel.com> <49994B20.7010702@nw.neclab.eu> <499958D8.50402@kddilabs.jp> <499997D1.4010503@nw.neclab.eu> <499A2708.1040709@kddilabs.jp> <499A441B.5080900@kddilabs.jp> <499AB687.7070701@nw.neclab.eu> <499ABD0C.4010006@kddilabs.jp> Message-ID: <499AC45B.3060500@nw.neclab.eu> Hidetoshi Yokota wrote: > Hi Marco, > > Marco Liebsch wrote: > >> Hidetoshi, >> > > I'm still talking about definitions and categorization. I'm not > downplaying any of them. > sure. > >> I think we have different opinions on an important aspect: >> My understanding of your opinion is that as soon as the MN gets >> (e.g.) HNP1 assigned to interface 1 (IF1) as a result of the registration, >> it can use the same HNP1 for a different interface, e.g. IF2, without >> having this HNP1 received from the network as a result of IF2's >> registration. >> Correct? >> > > No, I'm not going that far, yet :-). I'm still trying to understand what > people are thinking about multihoming, handover and IP flow mobility, > etc. My understanding is that if the MN wants to use HNP1 on IF2, it > would have to register it with the LMA via the corresponding MAG; > otherwise, there would be no guarantee that packets are coming back to IF2. > Ok. > >> I think the MN can use HNP1 only for IF2, if the LMA assigns the same >> HNP1 to IF2 during its registration. To result then in the same IP address, >> it's up to the MN to take the same suffix for both interfaces' IP address. >> That's again something where we have the same opinion. >> > > I think this is a sensible behavior. The key thing is to give a hint to > the LMA on which interface the MN wants to get packets. > Well, yes, the LMA needs a hint about the routing policy (which flow goes which way). But here the MN plays a role and that hint may not come with PMIPv6 signaling. > >> So, when we talk about using the same IP address on both interfaces, >> still the allowed prefix for each interface is network controlled, whereas >> the MN is free to chose any suffix. That's at least my view. >> > > I personally agree with your view. In addition, the LMA should get in > sync with the MN especially when those two interfaces are connected to > different MAGs. > Thanks for the clarification. Greetings, marco > Regards, > From: yokota at kddilabs.jp (Hidetoshi Yokota) Date: Tue, 17 Feb 2009 22:35:08 +0900 Subject: [Netext] Review of the Multihoming PS I-D In-Reply-To: <499AB687.7070701@nw.neclab.eu> References: <853DD750D9C3724FBF2DF7164FCF641C0292167E@FRVELSMBS14.ad2.ad.alcatel.com> <49994B20.7010702@nw.neclab.eu> <499958D8.50402@kddilabs.jp> <499997D1.4010503@nw.neclab.eu> <499A2708.1040709@kddilabs.jp> <499A441B.5080900@kddilabs.jp> <499AB687.7070701@nw.neclab.eu> Message-ID: <499ABD0C.4010006@kddilabs.jp> Hi Marco, Marco Liebsch wrote: > Hidetoshi, I'm still talking about definitions and categorization. I'm not downplaying any of them. > I think we have different opinions on an important aspect: > My understanding of your opinion is that as soon as the MN gets > (e.g.) HNP1 assigned to interface 1 (IF1) as a result of the registration, > it can use the same HNP1 for a different interface, e.g. IF2, without > having this HNP1 received from the network as a result of IF2's > registration. > Correct? No, I'm not going that far, yet :-). I'm still trying to understand what people are thinking about multihoming, handover and IP flow mobility, etc. My understanding is that if the MN wants to use HNP1 on IF2, it would have to register it with the LMA via the corresponding MAG; otherwise, there would be no guarantee that packets are coming back to IF2. > I think the MN can use HNP1 only for IF2, if the LMA assigns the same > HNP1 to IF2 during its registration. To result then in the same IP address, > it's up to the MN to take the same suffix for both interfaces' IP address. > That's again something where we have the same opinion. I think this is a sensible behavior. The key thing is to give a hint to the LMA on which interface the MN wants to get packets. > So, when we talk about using the same IP address on both interfaces, > still the allowed prefix for each interface is network controlled, whereas > the MN is free to chose any suffix. That's at least my view. I personally agree with your view. In addition, the LMA should get in sync with the MN especially when those two interfaces are connected to different MAGs. Regards, -- Hidetoshi > marco > > Hidetoshi Yokota wrote: >> Hi Marco, >> >> My answer to your last comment was a bit off the mark. Regarding the >> mesh-relationship between the interfaces and the assigned addresses, >> this could happen as an extreme case if the same address can be assigned >> to multiple interfaces and one interface can have multiple addresses >> simultaneously. If you think this is too complex and impractical, we >> should narrow down the scope. Do you have any condition to add to avoid >> the mesh-relationship? >> >> Regards, >> > > > > From: liebsch at nw.neclab.eu (Marco Liebsch) Date: Tue, 17 Feb 2009 14:07:19 +0100 Subject: [Netext] Review of the Multihoming PS I-D In-Reply-To: <499A441B.5080900@kddilabs.jp> References: <853DD750D9C3724FBF2DF7164FCF641C0292167E@FRVELSMBS14.ad2.ad.alcatel.com> <49994B20.7010702@nw.neclab.eu> <499958D8.50402@kddilabs.jp> <499997D1.4010503@nw.neclab.eu> <499A2708.1040709@kddilabs.jp> <499A441B.5080900@kddilabs.jp> Message-ID: <499AB687.7070701@nw.neclab.eu> Hidetoshi, I think we have different opinions on an important aspect: My understanding of your opinion is that as soon as the MN gets (e.g.) HNP1 assigned to interface 1 (IF1) as a result of the registration, it can use the same HNP1 for a different interface, e.g. IF2, without having this HNP1 received from the network as a result of IF2's registration. Correct? I think the MN can use HNP1 only for IF2, if the LMA assigns the same HNP1 to IF2 during its registration. To result then in the same IP address, it's up to the MN to take the same suffix for both interfaces' IP address. That's again something where we have the same opinion. So, when we talk about using the same IP address on both interfaces, still the allowed prefix for each interface is network controlled, whereas the MN is free to chose any suffix. That's at least my view. marco Hidetoshi Yokota wrote: > Hi Marco, > > My answer to your last comment was a bit off the mark. Regarding the > mesh-relationship between the interfaces and the assigned addresses, > this could happen as an extreme case if the same address can be assigned > to multiple interfaces and one interface can have multiple addresses > simultaneously. If you think this is too complex and impractical, we > should narrow down the scope. Do you have any condition to add to avoid > the mesh-relationship? > > Regards, > From: yokota at kddilabs.jp (Hidetoshi Yokota) Date: Tue, 17 Feb 2009 21:59:31 +0900 Subject: [Netext] Review of the Multihoming PS I-D In-Reply-To: <1B4A3FB319DC438DBD3741D385276713@ww300.siemens.net> References: <5F09D220B62F79418461A978CA0921BD032B4DDD@pslexc01.psl.local> <499A4010.5050906@kddilabs.jp> <1B4A3FB319DC438DBD3741D385276713@ww300.siemens.net> Message-ID: <499AB4B3.1060709@kddilabs.jp> Hi Domagoj, Domagoj Premec wrote: > Hi Hidetoshi, all, > > In the context of the multi-interfaced host and the IP flow mobility, we could look at handovers as a special case of the IP flow mobility where all the flows are moved to a different interface. The line between the handovers and the IP flow mobility seems to be blurred in this case so we need to set clear boundaries to keep the scenarios apart. Or maybe it would be best to analyse them together? Ok, a handover could be a special case of IP flow mobility. This handover probably means the switching of interfaces (e.g. due to the change of access technologies). We should putt aside a "session handover" for the moment;-). I, however, still believe that we should differentiate handover/IP flow mobility from multihoming. Regards, -- Hidetoshi > domagoj > > >> -----Original Message----- >> From: ext Hidetoshi Yokota [mailto:yokota at kddilabs.jp] >> Sent: 17. velja?a 2009 05:42 >> To: Mohana Jeyatharan >> Cc: Domagoj Premec; ext MELIA TELEMACO; Marco Liebsch; >> netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com >> Subject: Re: [Netext] Review of the Multihoming PS I-D >> >> Hi Mohana and all, >> >> I think your scenario is viable, but we should probably more >> carefully clarify the difference between multihoming and >> handover. Assigning the same address to different interfaces >> on the MN for a sufficiently long time sounds like >> multihoming; however, if this situation holds only for a >> short period of time for MN's movement or fail over or for >> whatever reason, that sounds like handover. This difference >> would affect the behavior of the LMA and MAG(s). >> >> In Section 2 of the Multihoming PS document, Issues related >> to handoff performance and those related to flow mobility >> during sudden disconnection appear to be categorized into >> handover. If all agree that these issues should also be >> included in multihoming, that's fine. I would just like to >> make sure of it first of all. >> >> Regards, >> -- >> Hidetoshi >> >> Mohana Jeyatharan wrote: >>> Hi Domagoj and All, >>> >>> Yes, we too support this. For hosts that want flow mobility >> in PMIPv6 domain, may have to configure same address or at >> least be able to accept packets that are addressed to another >> interface. >>> Moreover, this is extending PMIPv6 for such hosts and it is >> not changing PMIPv6 in anyway. >>> BR, >>> Mohana >>> >>> -----Original Message----- >>> From: netext-bounces at mail.mobileip.jp >>> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of Domagoj Premec >>> Sent: Tuesday, February 17, 2009 6:45 AM >>> To: 'ext MELIA TELEMACO'; 'Hidetoshi Yokota'; 'Marco Liebsch' >>> Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com >>> Subject: Re: [Netext] Review of the Multihoming PS I-D >>> >>> Hi, >>> >>> I share the opinion that having the same address assigned >> to different >>> interfaces is a viable scenario in the context of flow >> mobility and I >>> believe it should be included in the scope of the inter-tech work. >>> >>> domagoj >>> >>> >>> >>> ________________________________ >>> >>> From: netext-bounces at mail.mobileip.jp >>> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext >> MELIA TELEMACO >>> Sent: 16. veljaca 2009 14:14 >>> To: Hidetoshi Yokota; Marco Liebsch >>> Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com >>> Subject: Re: [Netext] Review of the Multihoming PS I-D >>> >>> >>> >>> Hi Hidetoshi, >>> >>> I took the liberty to edit your post according (I hope) >> to what Marco >>> and I have been saying. Here it goes: >>> >>> >>> Session2_CN1 >>> Addr_1 Session1_CN1 >>> IF#1 MAG#1 CN#1 >>> Addr_2 Session1_CN2 >>> >>> MN-ID LMA >>> >>> Addr_1 >>> IF#2 MAG#2 CN#2 >>> Addr_2 Session2_CN2 >>> >>> According to the pic the MN can a) request multiple addresses >>> (depending on the service he might want to get) and b) >> configure the >>> very same address on multiple interfaces to allow flow >> mobility (e.g. >>> Session2_CN1 can be moved to IF#2 Addr_1). If you do not >> configure the >>> same address I wonder how the LMA can route flows since the >> CN1 always >>> send to the same HNP (Addr_1). >>> >>> Marco this is your understanding as well? >>> >>> >>> >>> thanks >>> >>> telemaco >>> >>> >>> >>> -----Message d'origine----- >>> De : Hidetoshi Yokota [mailto:yokota at kddilabs.jp] >>> Envoy? : lundi 16 f?vrier 2009 13:15 >>> A : Marco Liebsch >>> Cc : MELIA TELEMACO; netext at mail.mobileip.jp; >>> Basavaraj.Patil at nokia.com >>> Objet : Re: [Netext] Review of the Multihoming PS I-D >>> >>> Hi Marco, Telemaco, Raj and all, >>> >>> This thread is interesting and important for the start. Let me >>> clarify the problem that we are trying to solve. The MN has >> multiple >>> interfaces and multiple addresses assigned by multiple MAGs and can >>> setup multiple sessions with multiple CNs (either mobile or >> plain IPv6 >>> hosts) simultaneously. However, the MN has only one MN-ID >> and only one >>> LMA (in the scople of the multihoming problem we are >> discussing now). >>> The addresses assigned for the MN can be bound to any >> interface of the >>> MN and the sessions associated with those addresses can go >> through any interface of the MN. >>> Also, those addresses and corresponding sessions can >> migrate to other >>> interfaces of the MN in the middle. The following diagram >> simply shows >>> this >>> situation: >>> >>> /------- MN --------\ >>> Session#1 >>> Addr#1 Session#2 CN#1 >>> IF#1 Addr#2 Session#3 MAG#1 CN#2 >>> MN-ID IF#2 Addr#3 ... MAG#2 LMA ... >>> ... ... ... ... ... >>> IF#J ... ... MAG#M CN#N >>> Addr#K ... >>> Session#L >>> >>> Is this the correct view that we are discussing now? >>> >>> Regards, >>> -- >>> Hidetoshi >>> >>> Marco Liebsch wrote: >>> > Hi, >>> > >>> > I agree that we should consider support of use cases >> where mulitple >>> > interfaces of an MN get the same HNP assiged. One >> step further, the >>> MN >>> > must configure the same suffix to allow flow mobility >> and keep flow >>> > distribution etc. >>> > transparent >>> > to a CN. >>> > >>> > Regarding Raj's comments: I fully agree that we need >> to specify the >>> > scope of what we'll solve in NetExt and my opinion is >> that the >>> focus >>> > should be first on the definition of a set of target >> use cases, as >>> too >>> > many of them are treated under the umbrella of >> multihoming. Then >>> let's >>> > analyze where RFC5213 needs some more work to support them. >>> > >>> > Whereas I think that most of this work will be on the >> LMA to allow >>> the >>> > assignment of the same HNP to multiple interfaces and >> to support >>> > inter-working with policy based forwarding, I do >> *not* think that >>> > PMIPv6 signaling should be extended to support in-band >>> configuration >>> > of such policy routing at the LMA. Hence, we should >> thoroughly >>> define >>> > the scope of the solution space before. >>> > >>> > marco >>> > >>> > >>> > >>> > MELIA TELEMACO schrieb: >>> >> Hello, >>> >> >>> >> In principle I am fine with the 4 points Raj proposed. In >>> addition, I >>> >> would stress scenarios where the same HNP (and same >> IP address) is >>> >> configured across several interfaces. I believe >> these scenarios >>> are >>> >> very useful for flow mobility and flow distributions. >>> >> Comments? >>> >> >>> >> telemaco >>> >> -----Message d'origine----- >>> >> De : netext-bounces at mail.mobileip.jp >>> >> [mailto:netext-bounces at mail.mobileip.jp] De la part de >>> >> Basavaraj.Patil at nokia.com Envoye' : mercredi 4 fe'vrier 2009 >>> 15:56 A` >>> >> : netext at mail.mobileip.jp Cc : >> Basavaraj.Patil at nokia.com Objet : >>> >> [Netext] Review of the Multihoming PS I-D >>> >> >>> >> >>> >> Hello, >>> >> >>> >> I have reviewed the Netext Multihoming PS I-D >>> >> . Thanks >> to Mohana for >>> her >>> >> efforts on getting this I-D ready. >>> >> >>> >> 1. My impression after reading the I-D is that it >> misses the key >>> >> problem of multihoming that we are trying to work >> on. Proxy >>> MIP6 as >>> >> currently specified in RFC5213 has limited support for >>> >> multihoming. It was decided that multihoming >> should be dealt >>> with >>> >> separately in Netlmm during the course discussions on this >>> topic in >>> >> the past. While many of the issues mentioned in >> the I-D are >>> >> relevant I believe that Netext should be working on a more >>> narrow >>> >> scope to enhance PMIP6 to support a few >> multihoming scenarios. >>> >> >>> >> 2. Sec 3 of the I-D which analyses multihoming >> issues in the case >>> of >>> >> PMIP6/CMIP6 coexisting together is really >> misplaced here. I do >>> not >>> >> believe we want to address this topic as part of the >>> multihoming >>> >> work in Netext. This is simply out of scope. >>> >> >>> >> 3. The I-D focuses on the problem of multiplexing >> flows or having >>> >> flows traverse via one interface or another or >> the ability to >>> move >>> >> a flow from one interface to another. While these are all >>> valid >>> >> things to do in PMIP6, I am not convinced that these are >>> >> specifically related to multihoming. >>> >> >>> >> Rajeev and I had a discussion on the scope of >> multihoming and what >>> we >>> >> should really be focusing on. We came up with the following >>> specific >>> >> scenarios which we should address: >>> >> >>> >> a. The multihoming work in Netext should address the >> limitations >>> of >>> >> RFC5213 >>> >> w.r.t multihoming. The issue of having a single >> BCE for an MN >>> >> identified by an MN-ID and attaching via multiple >> interfaces >>> should >>> >> be resolved. >>> >> >>> >> b. The scenario where an MN is connected via a MAG >> to an LMA and >>> the >>> >> ability to establish multiple sessions via the >> same MAG. This >>> is >>> >> the case where the MN is attached via a specific >> access type >>> and >>> >> establishes multiple IP sessions via the MAG. >>> >> >>> >> c. The scenario where an MN attaches via different >> interfaces >>> which >>> >> are of differing access technologies via MAG1 and MAG2 >>> >> simultaneously. The MAG1/MAG2 entities are attached to the >>> same >>> >> LMA. >>> >> >>> >> d. A combination of the scenarios in (b) and (c), i.e having >>> multiple >>> >> sessions via each access type while connected >> thru different >>> MAGs >>> >> simultaneously. >>> >> >>> >> Lets see if we can build some consensus around the >> scope of the >>> problem. >>> >> >>> >> -Raj >>> >> >>> >> _______________________________________________ >>> >> 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: Tue, 17 Feb 2009 13:53:10 +0100 Subject: [Netext] Review of the Multihoming PS I-D In-Reply-To: <1B4A3FB319DC438DBD3741D385276713@ww300.siemens.net> References: <5F09D220B62F79418461A978CA0921BD032B4DDD@pslexc01.psl.local> <499A4010.5050906@kddilabs.jp> <1B4A3FB319DC438DBD3741D385276713@ww300.siemens.net> Message-ID: <499AB336.7050803@nw.neclab.eu> Hi Domagoj, as a step towards clear boundaries, I think we should not speak about flow mobility and flow handover here. As a prerequisite and as actual work item for NetExt, we have to solve a few things on the PMIPv6 level support for multi-homing: Maintain multiple registrations from different interfaces, assignment of the same HNP for these interfaces, inter-working with routing policies. etc. This is also different from basic dual radio handover support, which is considered in RFC5213 already, and relies on a single BCE on the LMA. I think this is what also Hidetoshi referred to. What's needed on the LMA, MAG and for the protocol operation to support our target use cases for multi-homing, this is what we need to find out. I don't think NetExt will solve specific details for flow mobility. marco Domagoj Premec wrote: > Hi Hidetoshi, all, > > In the context of the multi-interfaced host and the IP flow mobility, we could look at handovers as a special case of the IP flow mobility where all the flows are moved to a different interface. The line between the handovers and the IP flow mobility seems to be blurred in this case so we need to set clear boundaries to keep the scenarios apart. Or maybe it would be best to analyse them together? > > domagoj > > > >> -----Original Message----- >> From: ext Hidetoshi Yokota [mailto:yokota at kddilabs.jp] >> Sent: 17. velja?a 2009 05:42 >> To: Mohana Jeyatharan >> Cc: Domagoj Premec; ext MELIA TELEMACO; Marco Liebsch; >> netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com >> Subject: Re: [Netext] Review of the Multihoming PS I-D >> >> Hi Mohana and all, >> >> I think your scenario is viable, but we should probably more >> carefully clarify the difference between multihoming and >> handover. Assigning the same address to different interfaces >> on the MN for a sufficiently long time sounds like >> multihoming; however, if this situation holds only for a >> short period of time for MN's movement or fail over or for >> whatever reason, that sounds like handover. This difference >> would affect the behavior of the LMA and MAG(s). >> >> In Section 2 of the Multihoming PS document, Issues related >> to handoff performance and those related to flow mobility >> during sudden disconnection appear to be categorized into >> handover. If all agree that these issues should also be >> included in multihoming, that's fine. I would just like to >> make sure of it first of all. >> >> Regards, >> -- >> Hidetoshi >> >> Mohana Jeyatharan wrote: >> >>> Hi Domagoj and All, >>> >>> Yes, we too support this. For hosts that want flow mobility >>> >> in PMIPv6 domain, may have to configure same address or at >> least be able to accept packets that are addressed to another >> interface. >> >>> Moreover, this is extending PMIPv6 for such hosts and it is >>> >> not changing PMIPv6 in anyway. >> >>> BR, >>> Mohana >>> >>> -----Original Message----- >>> From: netext-bounces at mail.mobileip.jp >>> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of Domagoj Premec >>> Sent: Tuesday, February 17, 2009 6:45 AM >>> To: 'ext MELIA TELEMACO'; 'Hidetoshi Yokota'; 'Marco Liebsch' >>> Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com >>> Subject: Re: [Netext] Review of the Multihoming PS I-D >>> >>> Hi, >>> >>> I share the opinion that having the same address assigned >>> >> to different >> >>> interfaces is a viable scenario in the context of flow >>> >> mobility and I >> >>> believe it should be included in the scope of the inter-tech work. >>> >>> domagoj >>> >>> >>> >>> ________________________________ >>> >>> From: netext-bounces at mail.mobileip.jp >>> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext >>> >> MELIA TELEMACO >> >>> Sent: 16. veljaca 2009 14:14 >>> To: Hidetoshi Yokota; Marco Liebsch >>> Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com >>> Subject: Re: [Netext] Review of the Multihoming PS I-D >>> >>> >>> >>> Hi Hidetoshi, >>> >>> I took the liberty to edit your post according (I hope) >>> >> to what Marco >> >>> and I have been saying. Here it goes: >>> >>> >>> Session2_CN1 >>> Addr_1 Session1_CN1 >>> IF#1 MAG#1 CN#1 >>> Addr_2 Session1_CN2 >>> >>> MN-ID LMA >>> >>> Addr_1 >>> IF#2 MAG#2 CN#2 >>> Addr_2 Session2_CN2 >>> >>> According to the pic the MN can a) request multiple addresses >>> (depending on the service he might want to get) and b) >>> >> configure the >> >>> very same address on multiple interfaces to allow flow >>> >> mobility (e.g. >> >>> Session2_CN1 can be moved to IF#2 Addr_1). If you do not >>> >> configure the >> >>> same address I wonder how the LMA can route flows since the >>> >> CN1 always >> >>> send to the same HNP (Addr_1). >>> >>> Marco this is your understanding as well? >>> >>> >>> >>> thanks >>> >>> telemaco >>> >>> >>> >>> -----Message d'origine----- >>> De : Hidetoshi Yokota [mailto:yokota at kddilabs.jp] >>> Envoy? : lundi 16 f?vrier 2009 13:15 >>> A : Marco Liebsch >>> Cc : MELIA TELEMACO; netext at mail.mobileip.jp; >>> Basavaraj.Patil at nokia.com >>> Objet : Re: [Netext] Review of the Multihoming PS I-D >>> >>> Hi Marco, Telemaco, Raj and all, >>> >>> This thread is interesting and important for the start. Let me >>> clarify the problem that we are trying to solve. The MN has >>> >> multiple >> >>> interfaces and multiple addresses assigned by multiple MAGs and can >>> setup multiple sessions with multiple CNs (either mobile or >>> >> plain IPv6 >> >>> hosts) simultaneously. However, the MN has only one MN-ID >>> >> and only one >> >>> LMA (in the scople of the multihoming problem we are >>> >> discussing now). >> >>> The addresses assigned for the MN can be bound to any >>> >> interface of the >> >>> MN and the sessions associated with those addresses can go >>> >> through any interface of the MN. >> >>> Also, those addresses and corresponding sessions can >>> >> migrate to other >> >>> interfaces of the MN in the middle. The following diagram >>> >> simply shows >> >>> this >>> situation: >>> >>> /------- MN --------\ >>> Session#1 >>> Addr#1 Session#2 CN#1 >>> IF#1 Addr#2 Session#3 MAG#1 CN#2 >>> MN-ID IF#2 Addr#3 ... MAG#2 LMA ... >>> ... ... ... ... ... >>> IF#J ... ... MAG#M CN#N >>> Addr#K ... >>> Session#L >>> >>> Is this the correct view that we are discussing now? >>> >>> Regards, >>> -- >>> Hidetoshi >>> >>> Marco Liebsch wrote: >>> > Hi, >>> > >>> > I agree that we should consider support of use cases >>> >> where mulitple >> >>> > interfaces of an MN get the same HNP assiged. One >>> >> step further, the >> >>> MN >>> > must configure the same suffix to allow flow mobility >>> >> and keep flow >> >>> > distribution etc. >>> > transparent >>> > to a CN. >>> > >>> > Regarding Raj's comments: I fully agree that we need >>> >> to specify the >> >>> > scope of what we'll solve in NetExt and my opinion is >>> >> that the >> >>> focus >>> > should be first on the definition of a set of target >>> >> use cases, as >> >>> too >>> > many of them are treated under the umbrella of >>> >> multihoming. Then >> >>> let's >>> > analyze where RFC5213 needs some more work to support them. >>> > >>> > Whereas I think that most of this work will be on the >>> >> LMA to allow >> >>> the >>> > assignment of the same HNP to multiple interfaces and >>> >> to support >> >>> > inter-working with policy based forwarding, I do >>> >> *not* think that >> >>> > PMIPv6 signaling should be extended to support in-band >>> configuration >>> > of such policy routing at the LMA. Hence, we should >>> >> thoroughly >> >>> define >>> > the scope of the solution space before. >>> > >>> > marco >>> > >>> > >>> > >>> > MELIA TELEMACO schrieb: >>> >> Hello, >>> >> >>> >> In principle I am fine with the 4 points Raj proposed. In >>> addition, I >>> >> would stress scenarios where the same HNP (and same >>> >> IP address) is >> >>> >> configured across several interfaces. I believe >>> >> these scenarios >> >>> are >>> >> very useful for flow mobility and flow distributions. >>> >> Comments? >>> >> >>> >> telemaco >>> >> -----Message d'origine----- >>> >> De : netext-bounces at mail.mobileip.jp >>> >> [mailto:netext-bounces at mail.mobileip.jp] De la part de >>> >> Basavaraj.Patil at nokia.com Envoye' : mercredi 4 fe'vrier 2009 >>> 15:56 A` >>> >> : netext at mail.mobileip.jp Cc : >>> >> Basavaraj.Patil at nokia.com Objet : >> >>> >> [Netext] Review of the Multihoming PS I-D >>> >> >>> >> >>> >> Hello, >>> >> >>> >> I have reviewed the Netext Multihoming PS I-D >>> >> . Thanks >>> >> to Mohana for >> >>> her >>> >> efforts on getting this I-D ready. >>> >> >>> >> 1. My impression after reading the I-D is that it >>> >> misses the key >> >>> >> problem of multihoming that we are trying to work >>> >> on. Proxy >> >>> MIP6 as >>> >> currently specified in RFC5213 has limited support for >>> >> multihoming. It was decided that multihoming >>> >> should be dealt >> >>> with >>> >> separately in Netlmm during the course discussions on this >>> topic in >>> >> the past. While many of the issues mentioned in >>> >> the I-D are >> >>> >> relevant I believe that Netext should be working on a more >>> narrow >>> >> scope to enhance PMIP6 to support a few >>> >> multihoming scenarios. >> >>> >> >>> >> 2. Sec 3 of the I-D which analyses multihoming >>> >> issues in the case >> >>> of >>> >> PMIP6/CMIP6 coexisting together is really >>> >> misplaced here. I do >> >>> not >>> >> believe we want to address this topic as part of the >>> multihoming >>> >> work in Netext. This is simply out of scope. >>> >> >>> >> 3. The I-D focuses on the problem of multiplexing >>> >> flows or having >> >>> >> flows traverse via one interface or another or >>> >> the ability to >> >>> move >>> >> a flow from one interface to another. While these are all >>> valid >>> >> things to do in PMIP6, I am not convinced that these are >>> >> specifically related to multihoming. >>> >> >>> >> Rajeev and I had a discussion on the scope of >>> >> multihoming and what >> >>> we >>> >> should really be focusing on. We came up with the following >>> specific >>> >> scenarios which we should address: >>> >> >>> >> a. The multihoming work in Netext should address the >>> >> limitations >> >>> of >>> >> RFC5213 >>> >> w.r.t multihoming. The issue of having a single >>> >> BCE for an MN >> >>> >> identified by an MN-ID and attaching via multiple >>> >> interfaces >> >>> should >>> >> be resolved. >>> >> >>> >> b. The scenario where an MN is connected via a MAG >>> >> to an LMA and >> >>> the >>> >> ability to establish multiple sessions via the >>> >> same MAG. This >> >>> is >>> >> the case where the MN is attached via a specific >>> >> access type >> >>> and >>> >> establishes multiple IP sessions via the MAG. >>> >> >>> >> c. The scenario where an MN attaches via different >>> >> interfaces >> >>> which >>> >> are of differing access technologies via MAG1 and MAG2 >>> >> simultaneously. The MAG1/MAG2 entities are attached to the >>> same >>> >> LMA. >>> >> >>> >> d. A combination of the scenarios in (b) and (c), i.e having >>> multiple >>> >> sessions via each access type while connected >>> >> thru different >> >>> MAGs >>> >> simultaneously. >>> >> >>> >> Lets see if we can build some consensus around the >>> >> scope of the >> >>> problem. >>> >> >>> >> -Raj >>> >> >>> >> _______________________________________________ >>> >> 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: Tue, 17 Feb 2009 12:56:58 +0100 Subject: [Netext] Review of the Multihoming PS I-D In-Reply-To: <499A4010.5050906@kddilabs.jp> References: <5F09D220B62F79418461A978CA0921BD032B4DDD@pslexc01.psl.local> <499A4010.5050906@kddilabs.jp> Message-ID: <1B4A3FB319DC438DBD3741D385276713@ww300.siemens.net> Hi Hidetoshi, all, In the context of the multi-interfaced host and the IP flow mobility, we could look at handovers as a special case of the IP flow mobility where all the flows are moved to a different interface. The line between the handovers and the IP flow mobility seems to be blurred in this case so we need to set clear boundaries to keep the scenarios apart. Or maybe it would be best to analyse them together? domagoj > -----Original Message----- > From: ext Hidetoshi Yokota [mailto:yokota at kddilabs.jp] > Sent: 17. velja?a 2009 05:42 > To: Mohana Jeyatharan > Cc: Domagoj Premec; ext MELIA TELEMACO; Marco Liebsch; > netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com > Subject: Re: [Netext] Review of the Multihoming PS I-D > > Hi Mohana and all, > > I think your scenario is viable, but we should probably more > carefully clarify the difference between multihoming and > handover. Assigning the same address to different interfaces > on the MN for a sufficiently long time sounds like > multihoming; however, if this situation holds only for a > short period of time for MN's movement or fail over or for > whatever reason, that sounds like handover. This difference > would affect the behavior of the LMA and MAG(s). > > In Section 2 of the Multihoming PS document, Issues related > to handoff performance and those related to flow mobility > during sudden disconnection appear to be categorized into > handover. If all agree that these issues should also be > included in multihoming, that's fine. I would just like to > make sure of it first of all. > > Regards, > -- > Hidetoshi > > Mohana Jeyatharan wrote: > > Hi Domagoj and All, > > > > Yes, we too support this. For hosts that want flow mobility > in PMIPv6 domain, may have to configure same address or at > least be able to accept packets that are addressed to another > interface. > > > > Moreover, this is extending PMIPv6 for such hosts and it is > not changing PMIPv6 in anyway. > > > > BR, > > Mohana > > > > -----Original Message----- > > From: netext-bounces at mail.mobileip.jp > > [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of Domagoj Premec > > Sent: Tuesday, February 17, 2009 6:45 AM > > To: 'ext MELIA TELEMACO'; 'Hidetoshi Yokota'; 'Marco Liebsch' > > Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com > > Subject: Re: [Netext] Review of the Multihoming PS I-D > > > > Hi, > > > > I share the opinion that having the same address assigned > to different > > interfaces is a viable scenario in the context of flow > mobility and I > > believe it should be included in the scope of the inter-tech work. > > > > domagoj > > > > > > > > ________________________________ > > > > From: netext-bounces at mail.mobileip.jp > > [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext > MELIA TELEMACO > > Sent: 16. veljaca 2009 14:14 > > To: Hidetoshi Yokota; Marco Liebsch > > Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com > > Subject: Re: [Netext] Review of the Multihoming PS I-D > > > > > > > > Hi Hidetoshi, > > > > I took the liberty to edit your post according (I hope) > to what Marco > > and I have been saying. Here it goes: > > > > > > Session2_CN1 > > Addr_1 Session1_CN1 > > IF#1 MAG#1 CN#1 > > Addr_2 Session1_CN2 > > > > MN-ID LMA > > > > Addr_1 > > IF#2 MAG#2 CN#2 > > Addr_2 Session2_CN2 > > > > According to the pic the MN can a) request multiple addresses > > (depending on the service he might want to get) and b) > configure the > > very same address on multiple interfaces to allow flow > mobility (e.g. > > Session2_CN1 can be moved to IF#2 Addr_1). If you do not > configure the > > same address I wonder how the LMA can route flows since the > CN1 always > > send to the same HNP (Addr_1). > > > > Marco this is your understanding as well? > > > > > > > > thanks > > > > telemaco > > > > > > > > -----Message d'origine----- > > De : Hidetoshi Yokota [mailto:yokota at kddilabs.jp] > > Envoy? : lundi 16 f?vrier 2009 13:15 > > A : Marco Liebsch > > Cc : MELIA TELEMACO; netext at mail.mobileip.jp; > > Basavaraj.Patil at nokia.com > > Objet : Re: [Netext] Review of the Multihoming PS I-D > > > > Hi Marco, Telemaco, Raj and all, > > > > This thread is interesting and important for the start. Let me > > clarify the problem that we are trying to solve. The MN has > multiple > > interfaces and multiple addresses assigned by multiple MAGs and can > > setup multiple sessions with multiple CNs (either mobile or > plain IPv6 > > hosts) simultaneously. However, the MN has only one MN-ID > and only one > > LMA (in the scople of the multihoming problem we are > discussing now). > > The addresses assigned for the MN can be bound to any > interface of the > > MN and the sessions associated with those addresses can go > through any interface of the MN. > > Also, those addresses and corresponding sessions can > migrate to other > > interfaces of the MN in the middle. The following diagram > simply shows > > this > > situation: > > > > /------- MN --------\ > > Session#1 > > Addr#1 Session#2 CN#1 > > IF#1 Addr#2 Session#3 MAG#1 CN#2 > > MN-ID IF#2 Addr#3 ... MAG#2 LMA ... > > ... ... ... ... ... > > IF#J ... ... MAG#M CN#N > > Addr#K ... > > Session#L > > > > Is this the correct view that we are discussing now? > > > > Regards, > > -- > > Hidetoshi > > > > Marco Liebsch wrote: > > > Hi, > > > > > > I agree that we should consider support of use cases > where mulitple > > > interfaces of an MN get the same HNP assiged. One > step further, the > > MN > > > must configure the same suffix to allow flow mobility > and keep flow > > > distribution etc. > > > transparent > > > to a CN. > > > > > > Regarding Raj's comments: I fully agree that we need > to specify the > > > scope of what we'll solve in NetExt and my opinion is > that the > > focus > > > should be first on the definition of a set of target > use cases, as > > too > > > many of them are treated under the umbrella of > multihoming. Then > > let's > > > analyze where RFC5213 needs some more work to support them. > > > > > > Whereas I think that most of this work will be on the > LMA to allow > > the > > > assignment of the same HNP to multiple interfaces and > to support > > > inter-working with policy based forwarding, I do > *not* think that > > > PMIPv6 signaling should be extended to support in-band > > configuration > > > of such policy routing at the LMA. Hence, we should > thoroughly > > define > > > the scope of the solution space before. > > > > > > marco > > > > > > > > > > > > MELIA TELEMACO schrieb: > > >> Hello, > > >> > > >> In principle I am fine with the 4 points Raj proposed. In > > addition, I > > >> would stress scenarios where the same HNP (and same > IP address) is > > >> configured across several interfaces. I believe > these scenarios > > are > > >> very useful for flow mobility and flow distributions. > > >> Comments? > > >> > > >> telemaco > > >> -----Message d'origine----- > > >> De : netext-bounces at mail.mobileip.jp > > >> [mailto:netext-bounces at mail.mobileip.jp] De la part de > > >> Basavaraj.Patil at nokia.com Envoye' : mercredi 4 fe'vrier 2009 > > 15:56 A` > > >> : netext at mail.mobileip.jp Cc : > Basavaraj.Patil at nokia.com Objet : > > >> [Netext] Review of the Multihoming PS I-D > > >> > > >> > > >> Hello, > > >> > > >> I have reviewed the Netext Multihoming PS I-D > > >> . Thanks > to Mohana for > > her > > >> efforts on getting this I-D ready. > > >> > > >> 1. My impression after reading the I-D is that it > misses the key > > >> problem of multihoming that we are trying to work > on. Proxy > > MIP6 as > > >> currently specified in RFC5213 has limited support for > > >> multihoming. It was decided that multihoming > should be dealt > > with > > >> separately in Netlmm during the course discussions on this > > topic in > > >> the past. While many of the issues mentioned in > the I-D are > > >> relevant I believe that Netext should be working on a more > > narrow > > >> scope to enhance PMIP6 to support a few > multihoming scenarios. > > >> > > >> 2. Sec 3 of the I-D which analyses multihoming > issues in the case > > of > > >> PMIP6/CMIP6 coexisting together is really > misplaced here. I do > > not > > >> believe we want to address this topic as part of the > > multihoming > > >> work in Netext. This is simply out of scope. > > >> > > >> 3. The I-D focuses on the problem of multiplexing > flows or having > > >> flows traverse via one interface or another or > the ability to > > move > > >> a flow from one interface to another. While these are all > > valid > > >> things to do in PMIP6, I am not convinced that these are > > >> specifically related to multihoming. > > >> > > >> Rajeev and I had a discussion on the scope of > multihoming and what > > we > > >> should really be focusing on. We came up with the following > > specific > > >> scenarios which we should address: > > >> > > >> a. The multihoming work in Netext should address the > limitations > > of > > >> RFC5213 > > >> w.r.t multihoming. The issue of having a single > BCE for an MN > > >> identified by an MN-ID and attaching via multiple > interfaces > > should > > >> be resolved. > > >> > > >> b. The scenario where an MN is connected via a MAG > to an LMA and > > the > > >> ability to establish multiple sessions via the > same MAG. This > > is > > >> the case where the MN is attached via a specific > access type > > and > > >> establishes multiple IP sessions via the MAG. > > >> > > >> c. The scenario where an MN attaches via different > interfaces > > which > > >> are of differing access technologies via MAG1 and MAG2 > > >> simultaneously. The MAG1/MAG2 entities are attached to the > > same > > >> LMA. > > >> > > >> d. A combination of the scenarios in (b) and (c), i.e having > > multiple > > >> sessions via each access type while connected > thru different > > MAGs > > >> simultaneously. > > >> > > >> Lets see if we can build some consensus around the > scope of the > > problem. > > >> > > >> -Raj > > >> > > >> _______________________________________________ > > >> 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: cjbc at it.uc3m.es (Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano) Date: Tue, 17 Feb 2009 11:18:25 +0100 Subject: [Netext] First Problem Statement about LocalizedRoutingin PMIPv6 submitted In-Reply-To: <499A87BC.4040001@nw.neclab.eu> References: <4D35478224365146822AE9E3AD4A26660690D389@exchtewks3.starentnetworks.com> <49999ADF.30509@nw.neclab.eu> <1234809135.5187.77.camel@localhost> <499A87BC.4040001@nw.neclab.eu> Message-ID: <1234865905.5187.143.camel@localhost> Hi Marco, El mar, 17-02-2009 a las 10:47 +0100, Marco Liebsch escribi?: > Hi Carlos, > > Carlos Jes?s Bernardos Cano wrote: > > Hi Marco, > > > > In my opinion, it is relevant to first identify whether basic RFC5213 > > provides a solution for the PMIPv6 MN - IPv6 CN case (when attached to > > the same MAG). If so, since that solution would be basically a framework > > (the use of the EnableMAGLocalRouting flag), it would be good for NETEXT > > to detail the solution. > I agree that we should understand what RFC5213 covers. Section 9.2 sais > "...The correspondent node can be another visiting mobile node as well, > or a local fixed node..." So, looks like a CN can be both, an IPv6 CN or a > PMIPv6 attached node. When you say NetExt should detail this solution, > then this may cover simply the description of local routing rules. I > don't expect > much text here. If you propose to detail RO setup between a PMIPv6 MN Agree this simple to define. > and an IPv6 CN > which is connected to a different MAG, that I understand from Rajeev > should be > out of scope of NetExt. Yes, that's also my understanding, though I'd prefer to consider that also within the scope of NETEXT. > > > In any case, I find useful to include the use > > case of the IPv6 CN (either attached to the same MAG than the PMIPv6 MN > > or to a different one). > Ok, maybe that needs further discussion then, whether or not we > include such use case. > > > I'm not so sure about addressing the MIPv6 CN... > > but I'm fine with including the short paragraph. > > > We do not talk about RO with a MIPv6 CN anymore, as I understood that > this is out of scope of NetExt. Perfect, I fully agree with that. > > > I'm not sure if I replied to what you were asking, BTW :-) > > > Yes, somehow you did :-) :-D Thanks, Carlos > > marco > > > Thanks, > > > > Carlos > > > > El lun, 16-02-2009 a las 17:57 +0100, Marco Liebsch escribi?: > > > >> Rajeev, Carlos, > >> > >> can we conclude from the discussion so far that > >> a.) this is a reasonable and 'in-scope' use case? > >> b.) PMIPv6 CN vs. IPv6 CN may not be transparent to a MAG and > >> the NetExt solution for PMIPv6 RO? > >> > >> If both is a 'yes', I propose to add this case to the RO PS. > >> If we don't see this as separate use case, we could also add > >> simply a short paragraph that 'this case may have issues, > >> which we must look at and take into account'. > >> > >> What do you think? > >> > >> marco > >> > >> > >> > >> Koodli, Rajeev wrote: > >> > >>> Hi, > >>> > >>> > >>> > >>>> I fully agree that the whole point of PMIP is make mobility > >>>> management transparent to the MN. However, as far as I > >>>> understand from my reading of RFC5213, a mobile node attached > >>>> to a PMIPv6 domain might not be entitled to the network-based > >>>> mobility management service, and RFC5213 (section 6.14) still > >>>> support this node to get connectivity (regular > >>>> access) from the MAG. > >>>> > >>>> > >>> I need to look into this, but I have no idea how a MAG can distinguish the two nodes.. > >>> > >>> > >>> > >>>> Related to this, it is also my interpretation of RFC5213 (section > >>>> 6.10.5) that the local routing support provided by the basic > >>>> spec (controlled with the EnableMAGLocalRouting flag) only > >>>> applies to communications between a PMIPv6 MN and a regular > >>>> IPv6 host attached to the same MAG. > >>>> > >>>> > >>> This sounds even more interesting because the "regular IPv6 host" gets better performance! > >>> So, all you have to do is to declare that you are not a PMIP6 MN to get better VoIP quality :-) > >>> > >>> Regards, > >>> > >>> -Rajeev > >>> > >>> > >>> > >>>> This is just to try to clarify what RFC5213 provides (actually, very > >>>> little) and what does not in regards to local routing > >>>> support. Do you see my point? > >>>> > >>>> Thanks! > >>>> > >>>> Carlos > >>>> > >>>> > >>>> > >>>>> > >>>>> > >>>>>> - If my previous understanding is correct, then RFC5213 > >>>>>> > >>>>>> > >>>> does not > >>>> > >>>> > >>>>>> only define any mechanism to perform local routing > >>>>>> > >>>>>> > >>>> between two MNs > >>>> > >>>> > >>>>>> connected to the same PMIPv6 domain (not even for the > >>>>>> > >>>>>> > >>>> case in which > >>>> > >>>> > >>>>>> both are attached to the same MAG). > >>>>>> Then, IMHO it would be better to change the terminology in the PS > >>>>>> and avoid using CN or coming up with different terms for > >>>>>> > >>>>>> > >>>> a CN that > >>>> > >>>> > >>>>>> is getting network-based mobility service from a CN that is not > >>>>>> (i.e. it is just a regular IPv6 node getting access from a MAG). > >>>>>> > >>>>>> > >>>>> See above. > >>>>> > >>>>> > >>>>> > >>>>>> - Currently, the PS only addresses the case of local routing > >>>>>> between two MNs connected to the same PMIPv6 domain. > >>>>>> I think the scenario of optimising traffic between an MN and a > >>>>>> regular IPv6 host that is locally connected to a MAG > >>>>>> > >>>>>> > >>>> should also be > >>>> > >>>> > >>>>>> addressed. Not sure the implications on the potential > >>>>>> > >>>>>> > >>>> solutions, but > >>>> > >>>> > >>>>>> it might have an impact on the classification scheme that > >>>>>> > >>>>>> > >>>> is used in > >>>> > >>>> > >>>>>> the PS now (A[number of MAGs][number of LMAs]). > >>>>>> > >>>>>> > >>>>>> > >>>>> Our focus should be on solving the problem for nodes > >>>>> > >>>>> > >>>> attached to a PMIP6 domain. > >>>> > >>>> > >>>>> Thanks, > >>>>> > >>>>> -Rajeev > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> Thanks, > >>>>>> > >>>>>> Carlos > >>>>>> > >>>>>> El jue, 05-02-2009 a las 15:33 +0100, Marco Liebsch escribi?: > >>>>>> > >>>>>> > >>>>>>> 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 > >>>> > >>>> > >>>>>> -0 > >>>>>> > >>>>>> > >>>>>>> 0.txt > >>>>>>> > >>>>>>> Best regards, > >>>>>>> marco > >>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> 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/ > >>>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > >>>>>> > >>>>>> > >>>>>> > >>>>> 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. > >>>> -- > >>>> 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: liebsch at nw.neclab.eu (Marco Liebsch) Date: Tue, 17 Feb 2009 10:47:40 +0100 Subject: [Netext] First Problem Statement about LocalizedRoutingin PMIPv6 submitted In-Reply-To: <1234809135.5187.77.camel@localhost> References: <4D35478224365146822AE9E3AD4A26660690D389@exchtewks3.starentnetworks.com> <49999ADF.30509@nw.neclab.eu> <1234809135.5187.77.camel@localhost> Message-ID: <499A87BC.4040001@nw.neclab.eu> Hi Carlos, Carlos Jes?s Bernardos Cano wrote: > Hi Marco, > > In my opinion, it is relevant to first identify whether basic RFC5213 > provides a solution for the PMIPv6 MN - IPv6 CN case (when attached to > the same MAG). If so, since that solution would be basically a framework > (the use of the EnableMAGLocalRouting flag), it would be good for NETEXT > to detail the solution. I agree that we should understand what RFC5213 covers. Section 9.2 sais "...The correspondent node can be another visiting mobile node as well, or a local fixed node..." So, looks like a CN can be both, an IPv6 CN or a PMIPv6 attached node. When you say NetExt should detail this solution, then this may cover simply the description of local routing rules. I don't expect much text here. If you propose to detail RO setup between a PMIPv6 MN and an IPv6 CN which is connected to a different MAG, that I understand from Rajeev should be out of scope of NetExt. > In any case, I find useful to include the use > case of the IPv6 CN (either attached to the same MAG than the PMIPv6 MN > or to a different one). Ok, maybe that needs further discussion then, whether or not we include such use case. > I'm not so sure about addressing the MIPv6 CN... > but I'm fine with including the short paragraph. > We do not talk about RO with a MIPv6 CN anymore, as I understood that this is out of scope of NetExt. > I'm not sure if I replied to what you were asking, BTW :-) > Yes, somehow you did :-) marco > Thanks, > > Carlos > > El lun, 16-02-2009 a las 17:57 +0100, Marco Liebsch escribi?: > >> Rajeev, Carlos, >> >> can we conclude from the discussion so far that >> a.) this is a reasonable and 'in-scope' use case? >> b.) PMIPv6 CN vs. IPv6 CN may not be transparent to a MAG and >> the NetExt solution for PMIPv6 RO? >> >> If both is a 'yes', I propose to add this case to the RO PS. >> If we don't see this as separate use case, we could also add >> simply a short paragraph that 'this case may have issues, >> which we must look at and take into account'. >> >> What do you think? >> >> marco >> >> >> >> Koodli, Rajeev wrote: >> >>> Hi, >>> >>> >>> >>>> I fully agree that the whole point of PMIP is make mobility >>>> management transparent to the MN. However, as far as I >>>> understand from my reading of RFC5213, a mobile node attached >>>> to a PMIPv6 domain might not be entitled to the network-based >>>> mobility management service, and RFC5213 (section 6.14) still >>>> support this node to get connectivity (regular >>>> access) from the MAG. >>>> >>>> >>> I need to look into this, but I have no idea how a MAG can distinguish the two nodes.. >>> >>> >>> >>>> Related to this, it is also my interpretation of RFC5213 (section >>>> 6.10.5) that the local routing support provided by the basic >>>> spec (controlled with the EnableMAGLocalRouting flag) only >>>> applies to communications between a PMIPv6 MN and a regular >>>> IPv6 host attached to the same MAG. >>>> >>>> >>> This sounds even more interesting because the "regular IPv6 host" gets better performance! >>> So, all you have to do is to declare that you are not a PMIP6 MN to get better VoIP quality :-) >>> >>> Regards, >>> >>> -Rajeev >>> >>> >>> >>>> This is just to try to clarify what RFC5213 provides (actually, very >>>> little) and what does not in regards to local routing >>>> support. Do you see my point? >>>> >>>> Thanks! >>>> >>>> Carlos >>>> >>>> >>>> >>>>> >>>>> >>>>>> - If my previous understanding is correct, then RFC5213 >>>>>> >>>>>> >>>> does not >>>> >>>> >>>>>> only define any mechanism to perform local routing >>>>>> >>>>>> >>>> between two MNs >>>> >>>> >>>>>> connected to the same PMIPv6 domain (not even for the >>>>>> >>>>>> >>>> case in which >>>> >>>> >>>>>> both are attached to the same MAG). >>>>>> Then, IMHO it would be better to change the terminology in the PS >>>>>> and avoid using CN or coming up with different terms for >>>>>> >>>>>> >>>> a CN that >>>> >>>> >>>>>> is getting network-based mobility service from a CN that is not >>>>>> (i.e. it is just a regular IPv6 node getting access from a MAG). >>>>>> >>>>>> >>>>> See above. >>>>> >>>>> >>>>> >>>>>> - Currently, the PS only addresses the case of local routing >>>>>> between two MNs connected to the same PMIPv6 domain. >>>>>> I think the scenario of optimising traffic between an MN and a >>>>>> regular IPv6 host that is locally connected to a MAG >>>>>> >>>>>> >>>> should also be >>>> >>>> >>>>>> addressed. Not sure the implications on the potential >>>>>> >>>>>> >>>> solutions, but >>>> >>>> >>>>>> it might have an impact on the classification scheme that >>>>>> >>>>>> >>>> is used in >>>> >>>> >>>>>> the PS now (A[number of MAGs][number of LMAs]). >>>>>> >>>>>> >>>>>> >>>>> Our focus should be on solving the problem for nodes >>>>> >>>>> >>>> attached to a PMIP6 domain. >>>> >>>> >>>>> Thanks, >>>>> >>>>> -Rajeev >>>>> >>>>> >>>>> >>>>> >>>>>> Thanks, >>>>>> >>>>>> Carlos >>>>>> >>>>>> El jue, 05-02-2009 a las 15:33 +0100, Marco Liebsch escribi?: >>>>>> >>>>>> >>>>>>> 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 >>>> >>>> >>>>>> -0 >>>>>> >>>>>> >>>>>>> 0.txt >>>>>>> >>>>>>> Best regards, >>>>>>> marco >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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/ >>>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>>>>> >>>>>> >>>>>> >>>>> 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. >>>> -- >>>> 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: liebsch at nw.neclab.eu (Marco Liebsch) Date: Tue, 17 Feb 2009 10:31:03 +0100 Subject: [Netext] First Problem Statement about LocalizedRoutingin PMIPv6 submitted In-Reply-To: <4D35478224365146822AE9E3AD4A26660690DA20@exchtewks3.starentnetworks.com> References: <4D35478224365146822AE9E3AD4A26660690DA20@exchtewks3.starentnetworks.com> Message-ID: <499A83D7.805@nw.neclab.eu> Rajeev, Koodli, Rajeev wrote: > Hi Marco, > > >> Rajeev, Carlos, >> >> can we conclude from the discussion so far that >> a.) this is a reasonable and 'in-scope' use case? >> > > What is a)? If you mean a node without PMIP6 support, I would say no. > There is no way to distinguish nodes like that way, correct, you cannot distinguish nodes, but you can distinguish how they are attached to the infrastructure. And this may have impact on RO. > and we should be focussed on solving this for PMIP6 domain IMHO. > > >> b.) PMIPv6 CN vs. IPv6 CN may not be transparent to a MAG and >> the NetExt solution for PMIPv6 RO? >> >> > > We should look at MNs which expect network-based mobility support. > Ok, thanks for your opinion. marco > Regards, > > -Rajeev > > > >> If both is a 'yes', I propose to add this case to the RO PS. >> If we don't see this as separate use case, we could also add >> simply a short paragraph that 'this case may have issues, >> which we must look at and take into account'. >> >> What do you think? >> >> marco >> >> >> >> Koodli, Rajeev wrote: >> >>> Hi, >>> >>> >>> >>>> I fully agree that the whole point of PMIP is make mobility >>>> management transparent to the MN. However, as far as I understand >>>> from my reading of RFC5213, a mobile node attached to a >>>> >> PMIPv6 domain >> >>>> might not be entitled to the network-based mobility management >>>> service, and RFC5213 (section 6.14) still support this node to get >>>> connectivity (regular >>>> access) from the MAG. >>>> >>>> >>> I need to look into this, but I have no idea how a MAG can >>> >> distinguish the two nodes.. >> >>> >>> >>>> Related to this, it is also my interpretation of RFC5213 (section >>>> 6.10.5) that the local routing support provided by the basic spec >>>> (controlled with the EnableMAGLocalRouting flag) only applies to >>>> communications between a PMIPv6 MN and a regular >>>> IPv6 host attached to the same MAG. >>>> >>>> >>> This sounds even more interesting because the "regular IPv6 >>> >> host" gets better performance! >> >>> So, all you have to do is to declare that you are not a PMIP6 MN to >>> get better VoIP quality :-) >>> >>> Regards, >>> >>> -Rajeev >>> >>> >>> >>>> This is just to try to clarify what RFC5213 provides >>>> >> (actually, very >> >>>> little) and what does not in regards to local routing >>>> >> support. Do you >> >>>> see my point? >>>> >>>> Thanks! >>>> >>>> Carlos >>>> >>>> >>>> >>>>> >>>>> >>>>>> - If my previous understanding is correct, then RFC5213 >>>>>> >>>>>> >>>> does not >>>> >>>> >>>>>> only define any mechanism to perform local routing >>>>>> >>>>>> >>>> between two MNs >>>> >>>> >>>>>> connected to the same PMIPv6 domain (not even for the >>>>>> >>>>>> >>>> case in which >>>> >>>> >>>>>> both are attached to the same MAG). >>>>>> Then, IMHO it would be better to change the terminology >>>>>> >> in the PS >> >>>>>> and avoid using CN or coming up with different terms for >>>>>> >>>>>> >>>> a CN that >>>> >>>> >>>>>> is getting network-based mobility service from a CN that is not >>>>>> (i.e. it is just a regular IPv6 node getting access from a MAG). >>>>>> >>>>>> >>>>> See above. >>>>> >>>>> >>>>> >>>>>> - Currently, the PS only addresses the case of local routing >>>>>> between two MNs connected to the same PMIPv6 domain. >>>>>> I think the scenario of optimising traffic between an MN and a >>>>>> regular IPv6 host that is locally connected to a MAG >>>>>> >>>>>> >>>> should also be >>>> >>>> >>>>>> addressed. Not sure the implications on the potential >>>>>> >>>>>> >>>> solutions, but >>>> >>>> >>>>>> it might have an impact on the classification scheme that >>>>>> >>>>>> >>>> is used in >>>> >>>> >>>>>> the PS now (A[number of MAGs][number of LMAs]). >>>>>> >>>>>> >>>>>> >>>>> Our focus should be on solving the problem for nodes >>>>> >>>>> >>>> attached to a PMIP6 domain. >>>> >>>> >>>>> Thanks, >>>>> >>>>> -Rajeev >>>>> >>>>> >>>>> >>>>> >>>>>> Thanks, >>>>>> >>>>>> Carlos >>>>>> >>>>>> El jue, 05-02-2009 a las 15:33 +0100, Marco Liebsch escribi?: >>>>>> >>>>>> >>>>>>> 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 >> >>>> >>>> >>>>>> -0 >>>>>> >>>>>> >>>>>>> 0.txt >>>>>>> >>>>>>> Best regards, >>>>>>> marco >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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/ >>>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>>>>> >>>>>> >>>>>> >>>>> 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. >>>> -- >>>> 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: Mohana.Jeyatharan at sg.panasonic.com (Mohana Jeyatharan) Date: Tue, 17 Feb 2009 15:51:22 +0800 Subject: [Netext] Review of the Multihoming PS I-D In-Reply-To: <499A4010.5050906@kddilabs.jp> Message-ID: <5F09D220B62F79418461A978CA0921BD032B4EDB@pslexc01.psl.local> Hi Hidetoshi, In Multihoming PS ID, there are some handoff optimization scenarios involved. For example optmizing the handoff of a certain interface by means of another, and achieving flow mobility via another interface during disconnection. These events are triggered due to handoff or disconnection, but the scenarios are associated with multihoming. That is being able to receive a flow that is usually destined to an interface via another "connected" interface. This is where these scenarios are different from normal handoff and more tied to multihoming. However, I agree that these are also tied with handoff and some confusion is there. Anyway, we are planning to revise the multihoming PS draft and are thinking of focusing on the disconnection scenario, handoff optimization as less focus scenarios and focus on scenarios that are cateogorized by Raj. BR, Mohana -----Original Message----- From: Hidetoshi Yokota [mailto:yokota at kddilabs.jp] Sent: Tuesday, February 17, 2009 12:42 PM To: Mohana Jeyatharan Cc: Domagoj Premec; ext MELIA TELEMACO; Marco Liebsch; netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com Subject: Re: [Netext] Review of the Multihoming PS I-D Hi Mohana and all, I think your scenario is viable, but we should probably more carefully clarify the difference between multihoming and handover. Assigning the same address to different interfaces on the MN for a sufficiently long time sounds like multihoming; however, if this situation holds only for a short period of time for MN's movement or fail over or for whatever reason, that sounds like handover. This difference would affect the behavior of the LMA and MAG(s). In Section 2 of the Multihoming PS document, Issues related to handoff performance and those related to flow mobility during sudden disconnection appear to be categorized into handover. If all agree that these issues should also be included in multihoming, that's fine. I would just like to make sure of it first of all. Regards, -- Hidetoshi Mohana Jeyatharan wrote: > Hi Domagoj and All, > > Yes, we too support this. For hosts that want flow mobility in PMIPv6 domain, may have to configure same address or at least be able to accept packets that are addressed to another interface. > > Moreover, this is extending PMIPv6 for such hosts and it is not changing PMIPv6 in anyway. > > BR, > Mohana > > -----Original Message----- > From: netext-bounces at mail.mobileip.jp [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of Domagoj Premec > Sent: Tuesday, February 17, 2009 6:45 AM > To: 'ext MELIA TELEMACO'; 'Hidetoshi Yokota'; 'Marco Liebsch' > Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com > Subject: Re: [Netext] Review of the Multihoming PS I-D > > Hi, > > I share the opinion that having the same address assigned to different > interfaces is a viable scenario in the context of flow mobility and I > believe it should be included in the scope of the inter-tech work. > > domagoj > > > > ________________________________ > > From: netext-bounces at mail.mobileip.jp > [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext MELIA TELEMACO > Sent: 16. veljaca 2009 14:14 > To: Hidetoshi Yokota; Marco Liebsch > Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com > Subject: Re: [Netext] Review of the Multihoming PS I-D > > > > Hi Hidetoshi, > > I took the liberty to edit your post according (I hope) to what > Marco and I have been saying. Here it goes: > > > Session2_CN1 > Addr_1 Session1_CN1 > IF#1 MAG#1 CN#1 > Addr_2 Session1_CN2 > > MN-ID LMA > > Addr_1 > IF#2 MAG#2 CN#2 > Addr_2 Session2_CN2 > > According to the pic the MN can a) request multiple addresses > (depending on the service he might want to get) and b) configure the very > same address on multiple interfaces to allow flow mobility (e.g. > Session2_CN1 can be moved to IF#2 Addr_1). If you do not configure the same > address I wonder how the LMA can route flows since the CN1 always send to > the same HNP (Addr_1). > > Marco this is your understanding as well? > > > > thanks > > telemaco > > > > -----Message d'origine----- > De : Hidetoshi Yokota [mailto:yokota at kddilabs.jp] > Envoy? : lundi 16 f?vrier 2009 13:15 > ? : Marco Liebsch > Cc : MELIA TELEMACO; netext at mail.mobileip.jp; > Basavaraj.Patil at nokia.com > Objet : Re: [Netext] Review of the Multihoming PS I-D > > Hi Marco, Telemaco, Raj and all, > > This thread is interesting and important for the start. Let me > clarify the problem that we are trying to solve. The MN has multiple > interfaces and multiple addresses assigned by multiple MAGs and can setup > multiple sessions with multiple CNs (either mobile or plain IPv6 hosts) > simultaneously. However, the MN has only one MN-ID and only one LMA (in the > scople of the multihoming problem we are discussing now). The addresses > assigned for the MN can be bound to any interface of the MN and the sessions > associated with those addresses can go through any interface of the MN. > Also, those addresses and corresponding sessions can migrate to other > interfaces of the MN in the middle. The following diagram simply shows this > situation: > > /------- MN --------\ > Session#1 > Addr#1 Session#2 CN#1 > IF#1 Addr#2 Session#3 MAG#1 CN#2 > MN-ID IF#2 Addr#3 ... MAG#2 LMA ... > ... ... ... ... ... > IF#J ... ... MAG#M CN#N > Addr#K ... > Session#L > > Is this the correct view that we are discussing now? > > Regards, > -- > Hidetoshi > > Marco Liebsch wrote: > > Hi, > > > > I agree that we should consider support of use cases where > mulitple > > interfaces of an MN get the same HNP assiged. One step further, > the MN > > must configure the same suffix to allow flow mobility and keep > flow > > distribution etc. > > transparent > > to a CN. > > > > Regarding Raj's comments: I fully agree that we need to specify > the > > scope of what we'll solve in NetExt and my opinion is that the > focus > > should be first on the definition of a set of target use cases, as > too > > many of them are treated under the umbrella of multihoming. Then > let's > > analyze where RFC5213 needs some more work to support them. > > > > Whereas I think that most of this work will be on the LMA to allow > the > > assignment of the same HNP to multiple interfaces and to support > > inter-working with policy based forwarding, I do *not* think that > > PMIPv6 signaling should be extended to support in-band > configuration > > of such policy routing at the LMA. Hence, we should thoroughly > define > > the scope of the solution space before. > > > > marco > > > > > > > > MELIA TELEMACO schrieb: > >> Hello, > >> > >> In principle I am fine with the 4 points Raj proposed. In > addition, I > >> would stress scenarios where the same HNP (and same IP address) > is > >> configured across several interfaces. I believe these scenarios > are > >> very useful for flow mobility and flow distributions. > >> Comments? > >> > >> telemaco > >> -----Message d'origine----- > >> De : netext-bounces at mail.mobileip.jp > >> [mailto:netext-bounces at mail.mobileip.jp] De la part de > >> Basavaraj.Patil at nokia.com Envoye' : mercredi 4 fe'vrier 2009 > 15:56 A` > >> : netext at mail.mobileip.jp Cc : Basavaraj.Patil at nokia.com Objet : > >> [Netext] Review of the Multihoming PS I-D > >> > >> > >> Hello, > >> > >> I have reviewed the Netext Multihoming PS I-D > >> . Thanks to Mohana for > her > >> efforts on getting this I-D ready. > >> > >> 1. My impression after reading the I-D is that it misses the key > >> problem of multihoming that we are trying to work on. Proxy > MIP6 as > >> currently specified in RFC5213 has limited support for > >> multihoming. It was decided that multihoming should be dealt > with > >> separately in Netlmm during the course discussions on this > topic in > >> the past. While many of the issues mentioned in the I-D are > >> relevant I believe that Netext should be working on a more > narrow > >> scope to enhance PMIP6 to support a few multihoming scenarios. > >> > >> 2. Sec 3 of the I-D which analyses multihoming issues in the case > of > >> PMIP6/CMIP6 coexisting together is really misplaced here. I do > not > >> believe we want to address this topic as part of the > multihoming > >> work in Netext. This is simply out of scope. > >> > >> 3. The I-D focuses on the problem of multiplexing flows or having > >> flows traverse via one interface or another or the ability to > move > >> a flow from one interface to another. While these are all > valid > >> things to do in PMIP6, I am not convinced that these are > >> specifically related to multihoming. > >> > >> Rajeev and I had a discussion on the scope of multihoming and > what we > >> should really be focusing on. We came up with the following > specific > >> scenarios which we should address: > >> > >> a. The multihoming work in Netext should address the limitations > of > >> RFC5213 > >> w.r.t multihoming. The issue of having a single BCE for an MN > >> identified by an MN-ID and attaching via multiple interfaces > should > >> be resolved. > >> > >> b. The scenario where an MN is connected via a MAG to an LMA and > the > >> ability to establish multiple sessions via the same MAG. This > is > >> the case where the MN is attached via a specific access type > and > >> establishes multiple IP sessions via the MAG. > >> > >> c. The scenario where an MN attaches via different interfaces > which > >> are of differing access technologies via MAG1 and MAG2 > >> simultaneously. The MAG1/MAG2 entities are attached to the > same > >> LMA. > >> > >> d. A combination of the scenarios in (b) and (c), i.e having > multiple > >> sessions via each access type while connected thru different > MAGs > >> simultaneously. > >> > >> Lets see if we can build some consensus around the scope of the > problem. > >> > >> -Raj > >> > >> _______________________________________________ > >> 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: yokota at kddilabs.jp (Hidetoshi Yokota) Date: Tue, 17 Feb 2009 13:59:07 +0900 Subject: [Netext] Review of the Multihoming PS I-D In-Reply-To: <499A2708.1040709@kddilabs.jp> References: <853DD750D9C3724FBF2DF7164FCF641C0292167E@FRVELSMBS14.ad2.ad.alcatel.com> <49994B20.7010702@nw.neclab.eu> <499958D8.50402@kddilabs.jp> <499997D1.4010503@nw.neclab.eu> <499A2708.1040709@kddilabs.jp> Message-ID: <499A441B.5080900@kddilabs.jp> Hi Marco, My answer to your last comment was a bit off the mark. Regarding the mesh-relationship between the interfaces and the assigned addresses, this could happen as an extreme case if the same address can be assigned to multiple interfaces and one interface can have multiple addresses simultaneously. If you think this is too complex and impractical, we should narrow down the scope. Do you have any condition to add to avoid the mesh-relationship? Regards, -- Hidetoshi Hidetoshi Yokota wrote: > Hi Marco, > > Marco Liebsch wrote: >> Hi Hidetoshi, >> >> please find my comments in-line. >> >> Hidetoshi Yokota wrote: >>> Hi Marco, Telemaco, Raj and all, >>> >>> This thread is interesting and important for the start. Let me clarify >>> the problem that we are trying to solve. The MN has multiple interfaces >>> and multiple addresses assigned by multiple MAGs and can setup multiple >>> sessions with multiple CNs (either mobile or plain IPv6 hosts) >>> simultaneously. However, the MN has only one MN-ID and only one LMA (in >>> the scople of the multihoming problem we are discussing now). >> So far I am ok. >>> The >>> addresses assigned for the MN can be bound to any interface of the MN >>> and the sessions associated with those addresses can go through any >>> interface of the MN. >> Well, here we should stick to the PMIP concept be clear: An MN's >> interface cannot simply use any address, but should use the HNP, >> which has been assigned to the interface during its registration. >> And this is under control of the LMA (or the AAA behind). So, in >> my opinion, an MN can use an HNP for an interface only if the >> HNP has been assigned to this interface during the registration. >> Maybe that's what you mean. > > Yes, I meant that the MN should use the HNPs under the control of the > LMA, but those HNPs, or I should say the whole addresses configured by > those HNPs are not tightly bound to the interfaces or MAGs that are used > at the initial attach. I think this is what we are talking about now. > >>> Also, those addresses and corresponding sessions >>> can migrate to other interfaces of the MN in the middle. The following >>> diagram simply shows this situation: >>> >> Maybe I read the diagram in the wrong way, but there should not be >> a 'mesh'-like relationship between all addresses (1-K) and all IFs (1-J). > > Right. I think that a session is identified by one of the MN addresses > and one of the CN addresses (more precisely, by 5-tuples, but simplified > for now), so mesh-like relationship will not happen. > > I should emphasize here that this is for the clarification of the > problem. More discussion will be needed to decide how further the scope > of the multihoming problem should cover. > > Regards, From: yokota at kddilabs.jp (Hidetoshi Yokota) Date: Tue, 17 Feb 2009 13:41:52 +0900 Subject: [Netext] Review of the Multihoming PS I-D In-Reply-To: <5F09D220B62F79418461A978CA0921BD032B4DDD@pslexc01.psl.local> References: <5F09D220B62F79418461A978CA0921BD032B4DDD@pslexc01.psl.local> Message-ID: <499A4010.5050906@kddilabs.jp> Hi Mohana and all, I think your scenario is viable, but we should probably more carefully clarify the difference between multihoming and handover. Assigning the same address to different interfaces on the MN for a sufficiently long time sounds like multihoming; however, if this situation holds only for a short period of time for MN's movement or fail over or for whatever reason, that sounds like handover. This difference would affect the behavior of the LMA and MAG(s). In Section 2 of the Multihoming PS document, Issues related to handoff performance and those related to flow mobility during sudden disconnection appear to be categorized into handover. If all agree that these issues should also be included in multihoming, that's fine. I would just like to make sure of it first of all. Regards, -- Hidetoshi Mohana Jeyatharan wrote: > Hi Domagoj and All, > > Yes, we too support this. For hosts that want flow mobility in PMIPv6 domain, may have to configure same address or at least be able to accept packets that are addressed to another interface. > > Moreover, this is extending PMIPv6 for such hosts and it is not changing PMIPv6 in anyway. > > BR, > Mohana > > -----Original Message----- > From: netext-bounces at mail.mobileip.jp [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of Domagoj Premec > Sent: Tuesday, February 17, 2009 6:45 AM > To: 'ext MELIA TELEMACO'; 'Hidetoshi Yokota'; 'Marco Liebsch' > Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com > Subject: Re: [Netext] Review of the Multihoming PS I-D > > Hi, > > I share the opinion that having the same address assigned to different > interfaces is a viable scenario in the context of flow mobility and I > believe it should be included in the scope of the inter-tech work. > > domagoj > > > > ________________________________ > > From: netext-bounces at mail.mobileip.jp > [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext MELIA TELEMACO > Sent: 16. veljaca 2009 14:14 > To: Hidetoshi Yokota; Marco Liebsch > Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com > Subject: Re: [Netext] Review of the Multihoming PS I-D > > > > Hi Hidetoshi, > > I took the liberty to edit your post according (I hope) to what > Marco and I have been saying. Here it goes: > > > Session2_CN1 > Addr_1 Session1_CN1 > IF#1 MAG#1 CN#1 > Addr_2 Session1_CN2 > > MN-ID LMA > > Addr_1 > IF#2 MAG#2 CN#2 > Addr_2 Session2_CN2 > > According to the pic the MN can a) request multiple addresses > (depending on the service he might want to get) and b) configure the very > same address on multiple interfaces to allow flow mobility (e.g. > Session2_CN1 can be moved to IF#2 Addr_1). If you do not configure the same > address I wonder how the LMA can route flows since the CN1 always send to > the same HNP (Addr_1). > > Marco this is your understanding as well? > > > > thanks > > telemaco > > > > -----Message d'origine----- > De : Hidetoshi Yokota [mailto:yokota at kddilabs.jp] > Envoy? : lundi 16 f?vrier 2009 13:15 > ? : Marco Liebsch > Cc : MELIA TELEMACO; netext at mail.mobileip.jp; > Basavaraj.Patil at nokia.com > Objet : Re: [Netext] Review of the Multihoming PS I-D > > Hi Marco, Telemaco, Raj and all, > > This thread is interesting and important for the start. Let me > clarify the problem that we are trying to solve. The MN has multiple > interfaces and multiple addresses assigned by multiple MAGs and can setup > multiple sessions with multiple CNs (either mobile or plain IPv6 hosts) > simultaneously. However, the MN has only one MN-ID and only one LMA (in the > scople of the multihoming problem we are discussing now). The addresses > assigned for the MN can be bound to any interface of the MN and the sessions > associated with those addresses can go through any interface of the MN. > Also, those addresses and corresponding sessions can migrate to other > interfaces of the MN in the middle. The following diagram simply shows this > situation: > > /------- MN --------\ > Session#1 > Addr#1 Session#2 CN#1 > IF#1 Addr#2 Session#3 MAG#1 CN#2 > MN-ID IF#2 Addr#3 ... MAG#2 LMA ... > ... ... ... ... ... > IF#J ... ... MAG#M CN#N > Addr#K ... > Session#L > > Is this the correct view that we are discussing now? > > Regards, > -- > Hidetoshi > > Marco Liebsch wrote: > > Hi, > > > > I agree that we should consider support of use cases where > mulitple > > interfaces of an MN get the same HNP assiged. One step further, > the MN > > must configure the same suffix to allow flow mobility and keep > flow > > distribution etc. > > transparent > > to a CN. > > > > Regarding Raj's comments: I fully agree that we need to specify > the > > scope of what we'll solve in NetExt and my opinion is that the > focus > > should be first on the definition of a set of target use cases, as > too > > many of them are treated under the umbrella of multihoming. Then > let's > > analyze where RFC5213 needs some more work to support them. > > > > Whereas I think that most of this work will be on the LMA to allow > the > > assignment of the same HNP to multiple interfaces and to support > > inter-working with policy based forwarding, I do *not* think that > > PMIPv6 signaling should be extended to support in-band > configuration > > of such policy routing at the LMA. Hence, we should thoroughly > define > > the scope of the solution space before. > > > > marco > > > > > > > > MELIA TELEMACO schrieb: > >> Hello, > >> > >> In principle I am fine with the 4 points Raj proposed. In > addition, I > >> would stress scenarios where the same HNP (and same IP address) > is > >> configured across several interfaces. I believe these scenarios > are > >> very useful for flow mobility and flow distributions. > >> Comments? > >> > >> telemaco > >> -----Message d'origine----- > >> De : netext-bounces at mail.mobileip.jp > >> [mailto:netext-bounces at mail.mobileip.jp] De la part de > >> Basavaraj.Patil at nokia.com Envoye' : mercredi 4 fe'vrier 2009 > 15:56 A` > >> : netext at mail.mobileip.jp Cc : Basavaraj.Patil at nokia.com Objet : > >> [Netext] Review of the Multihoming PS I-D > >> > >> > >> Hello, > >> > >> I have reviewed the Netext Multihoming PS I-D > >> . Thanks to Mohana for > her > >> efforts on getting this I-D ready. > >> > >> 1. My impression after reading the I-D is that it misses the key > >> problem of multihoming that we are trying to work on. Proxy > MIP6 as > >> currently specified in RFC5213 has limited support for > >> multihoming. It was decided that multihoming should be dealt > with > >> separately in Netlmm during the course discussions on this > topic in > >> the past. While many of the issues mentioned in the I-D are > >> relevant I believe that Netext should be working on a more > narrow > >> scope to enhance PMIP6 to support a few multihoming scenarios. > >> > >> 2. Sec 3 of the I-D which analyses multihoming issues in the case > of > >> PMIP6/CMIP6 coexisting together is really misplaced here. I do > not > >> believe we want to address this topic as part of the > multihoming > >> work in Netext. This is simply out of scope. > >> > >> 3. The I-D focuses on the problem of multiplexing flows or having > >> flows traverse via one interface or another or the ability to > move > >> a flow from one interface to another. While these are all > valid > >> things to do in PMIP6, I am not convinced that these are > >> specifically related to multihoming. > >> > >> Rajeev and I had a discussion on the scope of multihoming and > what we > >> should really be focusing on. We came up with the following > specific > >> scenarios which we should address: > >> > >> a. The multihoming work in Netext should address the limitations > of > >> RFC5213 > >> w.r.t multihoming. The issue of having a single BCE for an MN > >> identified by an MN-ID and attaching via multiple interfaces > should > >> be resolved. > >> > >> b. The scenario where an MN is connected via a MAG to an LMA and > the > >> ability to establish multiple sessions via the same MAG. This > is > >> the case where the MN is attached via a specific access type > and > >> establishes multiple IP sessions via the MAG. > >> > >> c. The scenario where an MN attaches via different interfaces > which > >> are of differing access technologies via MAG1 and MAG2 > >> simultaneously. The MAG1/MAG2 entities are attached to the > same > >> LMA. > >> > >> d. A combination of the scenarios in (b) and (c), i.e having > multiple > >> sessions via each access type while connected thru different > MAGs > >> simultaneously. > >> > >> Lets see if we can build some consensus around the scope of the > problem. > >> > >> -Raj > >> > >> _______________________________________________ > >> 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: Mohana.Jeyatharan at sg.panasonic.com (Mohana Jeyatharan) Date: Tue, 17 Feb 2009 10:59:57 +0800 Subject: [Netext] Review of the Multihoming PS I-D In-Reply-To: <9B8AFEEF81CE43818736EBC96E924411@ww300.siemens.net> Message-ID: <5F09D220B62F79418461A978CA0921BD032B4DDD@pslexc01.psl.local> Hi Domagoj and All, Yes, we too support this. For hosts that want flow mobility in PMIPv6 domain, may have to configure same address or at least be able to accept packets that are addressed to another interface. Moreover, this is extending PMIPv6 for such hosts and it is not changing PMIPv6 in anyway. BR, Mohana -----Original Message----- From: netext-bounces at mail.mobileip.jp [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of Domagoj Premec Sent: Tuesday, February 17, 2009 6:45 AM To: 'ext MELIA TELEMACO'; 'Hidetoshi Yokota'; 'Marco Liebsch' Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com Subject: Re: [Netext] Review of the Multihoming PS I-D Hi, I share the opinion that having the same address assigned to different interfaces is a viable scenario in the context of flow mobility and I believe it should be included in the scope of the inter-tech work. domagoj ________________________________ From: netext-bounces at mail.mobileip.jp [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext MELIA TELEMACO Sent: 16. veljaca 2009 14:14 To: Hidetoshi Yokota; Marco Liebsch Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com Subject: Re: [Netext] Review of the Multihoming PS I-D Hi Hidetoshi, I took the liberty to edit your post according (I hope) to what Marco and I have been saying. Here it goes: Session2_CN1 Addr_1 Session1_CN1 IF#1 MAG#1 CN#1 Addr_2 Session1_CN2 MN-ID LMA Addr_1 IF#2 MAG#2 CN#2 Addr_2 Session2_CN2 According to the pic the MN can a) request multiple addresses (depending on the service he might want to get) and b) configure the very same address on multiple interfaces to allow flow mobility (e.g. Session2_CN1 can be moved to IF#2 Addr_1). If you do not configure the same address I wonder how the LMA can route flows since the CN1 always send to the same HNP (Addr_1). Marco this is your understanding as well? thanks telemaco -----Message d'origine----- De : Hidetoshi Yokota [mailto:yokota at kddilabs.jp] Envoy? : lundi 16 f?vrier 2009 13:15 ? : Marco Liebsch Cc : MELIA TELEMACO; netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com Objet : Re: [Netext] Review of the Multihoming PS I-D Hi Marco, Telemaco, Raj and all, This thread is interesting and important for the start. Let me clarify the problem that we are trying to solve. The MN has multiple interfaces and multiple addresses assigned by multiple MAGs and can setup multiple sessions with multiple CNs (either mobile or plain IPv6 hosts) simultaneously. However, the MN has only one MN-ID and only one LMA (in the scople of the multihoming problem we are discussing now). The addresses assigned for the MN can be bound to any interface of the MN and the sessions associated with those addresses can go through any interface of the MN. Also, those addresses and corresponding sessions can migrate to other interfaces of the MN in the middle. The following diagram simply shows this situation: /------- MN --------\ Session#1 Addr#1 Session#2 CN#1 IF#1 Addr#2 Session#3 MAG#1 CN#2 MN-ID IF#2 Addr#3 ... MAG#2 LMA ... ... ... ... ... ... IF#J ... ... MAG#M CN#N Addr#K ... Session#L Is this the correct view that we are discussing now? Regards, -- Hidetoshi Marco Liebsch wrote: > Hi, > > I agree that we should consider support of use cases where mulitple > interfaces of an MN get the same HNP assiged. One step further, the MN > must configure the same suffix to allow flow mobility and keep flow > distribution etc. > transparent > to a CN. > > Regarding Raj's comments: I fully agree that we need to specify the > scope of what we'll solve in NetExt and my opinion is that the focus > should be first on the definition of a set of target use cases, as too > many of them are treated under the umbrella of multihoming. Then let's > analyze where RFC5213 needs some more work to support them. > > Whereas I think that most of this work will be on the LMA to allow the > assignment of the same HNP to multiple interfaces and to support > inter-working with policy based forwarding, I do *not* think that > PMIPv6 signaling should be extended to support in-band configuration > of such policy routing at the LMA. Hence, we should thoroughly define > the scope of the solution space before. > > marco > > > > MELIA TELEMACO schrieb: >> Hello, >> >> In principle I am fine with the 4 points Raj proposed. In addition, I >> would stress scenarios where the same HNP (and same IP address) is >> configured across several interfaces. I believe these scenarios are >> very useful for flow mobility and flow distributions. >> Comments? >> >> telemaco >> -----Message d'origine----- >> De : netext-bounces at mail.mobileip.jp >> [mailto:netext-bounces at mail.mobileip.jp] De la part de >> Basavaraj.Patil at nokia.com Envoye' : mercredi 4 fe'vrier 2009 15:56 A` >> : netext at mail.mobileip.jp Cc : Basavaraj.Patil at nokia.com Objet : >> [Netext] Review of the Multihoming PS I-D >> >> >> Hello, >> >> I have reviewed the Netext Multihoming PS I-D >> . Thanks to Mohana for her >> efforts on getting this I-D ready. >> >> 1. My impression after reading the I-D is that it misses the key >> problem of multihoming that we are trying to work on. Proxy MIP6 as >> currently specified in RFC5213 has limited support for >> multihoming. It was decided that multihoming should be dealt with >> separately in Netlmm during the course discussions on this topic in >> the past. While many of the issues mentioned in the I-D are >> relevant I believe that Netext should be working on a more narrow >> scope to enhance PMIP6 to support a few multihoming scenarios. >> >> 2. Sec 3 of the I-D which analyses multihoming issues in the case of >> PMIP6/CMIP6 coexisting together is really misplaced here. I do not >> believe we want to address this topic as part of the multihoming >> work in Netext. This is simply out of scope. >> >> 3. The I-D focuses on the problem of multiplexing flows or having >> flows traverse via one interface or another or the ability to move >> a flow from one interface to another. While these are all valid >> things to do in PMIP6, I am not convinced that these are >> specifically related to multihoming. >> >> Rajeev and I had a discussion on the scope of multihoming and what we >> should really be focusing on. We came up with the following specific >> scenarios which we should address: >> >> a. The multihoming work in Netext should address the limitations of >> RFC5213 >> w.r.t multihoming. The issue of having a single BCE for an MN >> identified by an MN-ID and attaching via multiple interfaces should >> be resolved. >> >> b. The scenario where an MN is connected via a MAG to an LMA and the >> ability to establish multiple sessions via the same MAG. This is >> the case where the MN is attached via a specific access type and >> establishes multiple IP sessions via the MAG. >> >> c. The scenario where an MN attaches via different interfaces which >> are of differing access technologies via MAG1 and MAG2 >> simultaneously. The MAG1/MAG2 entities are attached to the same >> LMA. >> >> d. A combination of the scenarios in (b) and (c), i.e having multiple >> sessions via each access type while connected thru different MAGs >> simultaneously. >> >> Lets see if we can build some consensus around the scope of the problem. >> >> -Raj >> >> _______________________________________________ >> 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: yokota at kddilabs.jp (Hidetoshi Yokota) Date: Tue, 17 Feb 2009 11:55:04 +0900 Subject: [Netext] Review of the Multihoming PS I-D In-Reply-To: <499997D1.4010503@nw.neclab.eu> References: <853DD750D9C3724FBF2DF7164FCF641C0292167E@FRVELSMBS14.ad2.ad.alcatel.com> <49994B20.7010702@nw.neclab.eu> <499958D8.50402@kddilabs.jp> <499997D1.4010503@nw.neclab.eu> Message-ID: <499A2708.1040709@kddilabs.jp> Hi Marco, Marco Liebsch wrote: > Hi Hidetoshi, > > please find my comments in-line. > > Hidetoshi Yokota wrote: >> Hi Marco, Telemaco, Raj and all, >> >> This thread is interesting and important for the start. Let me clarify >> the problem that we are trying to solve. The MN has multiple interfaces >> and multiple addresses assigned by multiple MAGs and can setup multiple >> sessions with multiple CNs (either mobile or plain IPv6 hosts) >> simultaneously. However, the MN has only one MN-ID and only one LMA (in >> the scople of the multihoming problem we are discussing now). > So far I am ok. >> The >> addresses assigned for the MN can be bound to any interface of the MN >> and the sessions associated with those addresses can go through any >> interface of the MN. > Well, here we should stick to the PMIP concept be clear: An MN's > interface cannot simply use any address, but should use the HNP, > which has been assigned to the interface during its registration. > And this is under control of the LMA (or the AAA behind). So, in > my opinion, an MN can use an HNP for an interface only if the > HNP has been assigned to this interface during the registration. > Maybe that's what you mean. Yes, I meant that the MN should use the HNPs under the control of the LMA, but those HNPs, or I should say the whole addresses configured by those HNPs are not tightly bound to the interfaces or MAGs that are used at the initial attach. I think this is what we are talking about now. >> Also, those addresses and corresponding sessions >> can migrate to other interfaces of the MN in the middle. The following >> diagram simply shows this situation: >> > Maybe I read the diagram in the wrong way, but there should not be > a 'mesh'-like relationship between all addresses (1-K) and all IFs (1-J). Right. I think that a session is identified by one of the MN addresses and one of the CN addresses (more precisely, by 5-tuples, but simplified for now), so mesh-like relationship will not happen. I should emphasize here that this is for the clarification of the problem. More discussion will be needed to decide how further the scope of the multihoming problem should cover. Regards, -- Hidetoshi > marco > >> /------- MN --------\ >> Session#1 >> Addr#1 Session#2 CN#1 >> IF#1 Addr#2 Session#3 MAG#1 CN#2 >> MN-ID IF#2 Addr#3 ... MAG#2 LMA ... >> ... ... ... ... ... >> IF#J ... ... MAG#M CN#N >> Addr#K ... >> Session#L >> >> Is this the correct view that we are discussing now? >> >> Regards, >> > > > > From: xiayangsong at huawei.com (Frank Xia) Date: Mon, 16 Feb 2009 19:54:42 -0600 Subject: [Netext] Review of the Multihoming PS I-D References: <853DD750D9C3724FBF2DF7164FCF641C0292167E@FRVELSMBS14.ad2.ad.alcatel.com> <49994B20.7010702@nw.neclab.eu> <499958D8.50402@kddilabs.jp> <853DD750D9C3724FBF2DF7164FCF641C02921A6E@FRVELSMBS14.ad2.ad.alcatel.com> <9B8AFEEF81CE43818736EBC96E924411@ww300.siemens.net> <004d01c9908b$33f09af0$420c7c0a@china.huawei.com> <275D65CAB5404A0782625DCF8081AE77@ww300.siemens.net> Message-ID: <000601c990a2$b5c9e920$0301a8c0@china.huawei.com> Hi Domagoj I am fine with the motivation of the Netext. However, I still think RFC5213 is the baseline for our work. Conceptually, it looks strange to me when a host with two different interfaces sharing one IP address. It is a challenge for an application to select a proper interface when sending a packet because IP address is not tied to one special interface. You will be appreciated if you can give me some current practices to justify your opinion, e.g RFC, OS BR Frank ----- Original Message ----- From: "Domagoj Premec" To: "'ext Frank Xia'" ; "'ext MELIA TELEMACO'" ; "'Hidetoshi Yokota'" ; "'Marco Liebsch'" Cc: ; Sent: Monday, February 16, 2009 5:18 PM Subject: RE: [Netext] Review of the Multihoming PS I-D Hi Frank, Well... the netext is about extending the baseline PMIP6 functionality and hence I don't see the RFC 5213 as a limiting factor when considering the scenarios that can be addressed in the netext. domagoj > -----Original Message----- > From: ext Frank Xia [mailto:xiayangsong at huawei.com] > Sent: 17. veljaca 2009 00:06 > To: Domagoj Premec; 'ext MELIA TELEMACO'; 'Hidetoshi Yokota'; > 'Marco Liebsch' > Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com > Subject: Re: [Netext] Review of the Multihoming PS I-D > > Hi Domagoj > > I don't think so. > > Please check RFC5213 > "If the mobile node connects to the Proxy Mobile IPv6 domain through > multiple interfaces and over multiple access networks, the network > will allocate a unique set of home network prefixes for each of the > connected interfaces" > > BR > Frank > > > ----- Original Message ----- > From: "Domagoj Premec" > To: "'ext MELIA TELEMACO'" > ; "'Hidetoshi Yokota'" > ; "'Marco Liebsch'" > > Cc: ; > Sent: Monday, February 16, 2009 4:45 PM > Subject: Re: [Netext] Review of the Multihoming PS I-D > > > Hi, > > I share the opinion that having the same address assigned to > different interfaces is a viable scenario in the context of > flow mobility and I believe it should be included in the > scope of the inter-tech work. > > domagoj > > > > ________________________________ > > From: netext-bounces at mail.mobileip.jp > [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext > MELIA TELEMACO > Sent: 16. veljaca 2009 14:14 > To: Hidetoshi Yokota; Marco Liebsch > Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com > Subject: Re: [Netext] Review of the Multihoming PS I-D > > > > Hi Hidetoshi, > > I took the liberty to edit your post according (I hope) to > what Marco and I have been saying. Here it goes: > > > Session2_CN1 > Addr_1 Session1_CN1 > IF#1 MAG#1 CN#1 > Addr_2 Session1_CN2 > > MN-ID LMA > > Addr_1 > IF#2 MAG#2 CN#2 > Addr_2 Session2_CN2 > > According to the pic the MN can a) request multiple addresses > (depending on the service he might want to get) and b) > configure the very same address on multiple interfaces to > allow flow mobility (e.g. > Session2_CN1 can be moved to IF#2 Addr_1). If you do not > configure the same address I wonder how the LMA can route > flows since the CN1 always send to the same HNP (Addr_1). > > Marco this is your understanding as well? > > > > thanks > > telemaco > > > > -----Message d'origine----- > De : Hidetoshi Yokota [mailto:yokota at kddilabs.jp] Envoy? : > lundi 16 f?vrier 2009 13:15 ? : Marco Liebsch Cc : MELIA > TELEMACO; netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com > Objet : Re: [Netext] Review of the Multihoming PS I-D > > Hi Marco, Telemaco, Raj and all, > > This thread is interesting and important for the start. Let > me clarify the problem that we are trying to solve. The MN > has multiple interfaces and multiple addresses assigned by > multiple MAGs and can setup multiple sessions with multiple > CNs (either mobile or plain IPv6 hosts) simultaneously. > However, the MN has only one MN-ID and only one LMA (in the > scople of the multihoming problem we are discussing now). The > addresses assigned for the MN can be bound to any interface > of the MN and the sessions associated with those addresses > can go through any interface of the MN. > Also, those addresses and corresponding sessions can migrate > to other interfaces of the MN in the middle. The following > diagram simply shows this > situation: > > /------- MN --------\ > Session#1 > Addr#1 Session#2 CN#1 > IF#1 Addr#2 Session#3 MAG#1 CN#2 > MN-ID IF#2 Addr#3 ... MAG#2 LMA ... > ... ... ... ... ... > IF#J ... ... MAG#M CN#N > Addr#K ... > Session#L > > Is this the correct view that we are discussing now? > > Regards, > -- > Hidetoshi > > Marco Liebsch wrote: > > Hi, > > > > I agree that we should consider support of use cases where > mulitple > > interfaces of an MN get the same HNP assiged. One step further, > the MN > > must configure the same suffix to allow flow mobility and keep > flow > > distribution etc. > > transparent > > to a CN. > > > > Regarding Raj's comments: I fully agree that we need to specify > the > > scope of what we'll solve in NetExt and my opinion is that the > focus > > should be first on the definition of a set of target use cases, as > too > > many of them are treated under the umbrella of multihoming. Then > let's > > analyze where RFC5213 needs some more work to support them. > > > > Whereas I think that most of this work will be on the LMA to allow > the > > assignment of the same HNP to multiple interfaces and to support > > inter-working with policy based forwarding, I do *not* think that > > PMIPv6 signaling should be extended to support in-band > configuration > > of such policy routing at the LMA. Hence, we should thoroughly > define > > the scope of the solution space before. > > > > marco > > > > > > > > MELIA TELEMACO schrieb: > >> Hello, > >> > >> In principle I am fine with the 4 points Raj proposed. In > addition, I > >> would stress scenarios where the same HNP (and same IP address) > is > >> configured across several interfaces. I believe these scenarios > are > >> very useful for flow mobility and flow distributions. > >> Comments? > >> > >> telemaco > >> -----Message d'origine----- > >> De : netext-bounces at mail.mobileip.jp > >> [mailto:netext-bounces at mail.mobileip.jp] De la part de > >> Basavaraj.Patil at nokia.com Envoye' : mercredi 4 fe'vrier 2009 > 15:56 A` > >> : netext at mail.mobileip.jp Cc : Basavaraj.Patil at nokia.com Objet : > >> [Netext] Review of the Multihoming PS I-D > >> > >> > >> Hello, > >> > >> I have reviewed the Netext Multihoming PS I-D > >> . Thanks to Mohana for > her > >> efforts on getting this I-D ready. > >> > >> 1. My impression after reading the I-D is that it misses the key > >> problem of multihoming that we are trying to work on. Proxy > MIP6 as > >> currently specified in RFC5213 has limited support for > >> multihoming. It was decided that multihoming should be dealt > with > >> separately in Netlmm during the course discussions on this > topic in > >> the past. While many of the issues mentioned in the I-D are > >> relevant I believe that Netext should be working on a more > narrow > >> scope to enhance PMIP6 to support a few multihoming scenarios. > >> > >> 2. Sec 3 of the I-D which analyses multihoming issues in the case > of > >> PMIP6/CMIP6 coexisting together is really misplaced here. I do > not > >> believe we want to address this topic as part of the > multihoming > >> work in Netext. This is simply out of scope. > >> > >> 3. The I-D focuses on the problem of multiplexing flows or having > >> flows traverse via one interface or another or the ability to > move > >> a flow from one interface to another. While these are all > valid > >> things to do in PMIP6, I am not convinced that these are > >> specifically related to multihoming. > >> > >> Rajeev and I had a discussion on the scope of multihoming and > what we > >> should really be focusing on. We came up with the following > specific > >> scenarios which we should address: > >> > >> a. The multihoming work in Netext should address the limitations > of > >> RFC5213 > >> w.r.t multihoming. The issue of having a single BCE for an MN > >> identified by an MN-ID and attaching via multiple interfaces > should > >> be resolved. > >> > >> b. The scenario where an MN is connected via a MAG to an LMA and > the > >> ability to establish multiple sessions via the same MAG. This > is > >> the case where the MN is attached via a specific access type > and > >> establishes multiple IP sessions via the MAG. > >> > >> c. The scenario where an MN attaches via different interfaces > which > >> are of differing access technologies via MAG1 and MAG2 > >> simultaneously. The MAG1/MAG2 entities are attached to the > same > >> LMA. > >> > >> d. A combination of the scenarios in (b) and (c), i.e having > multiple > >> sessions via each access type while connected thru different > MAGs > >> simultaneously. > >> > >> Lets see if we can build some consensus around the scope of the > problem. > >> > >> -Raj > >> > >> _______________________________________________ > >> 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: Tue, 17 Feb 2009 00:18:32 +0100 Subject: [Netext] Review of the Multihoming PS I-D In-Reply-To: <004d01c9908b$33f09af0$420c7c0a@china.huawei.com> References: <853DD750D9C3724FBF2DF7164FCF641C0292167E@FRVELSMBS14.ad2.ad.alcatel.com> <49994B20.7010702@nw.neclab.eu> <499958D8.50402@kddilabs.jp> <853DD750D9C3724FBF2DF7164FCF641C02921A6E@FRVELSMBS14.ad2.ad.alcatel.com> <9B8AFEEF81CE43818736EBC96E924411@ww300.siemens.net> <004d01c9908b$33f09af0$420c7c0a@china.huawei.com> Message-ID: <275D65CAB5404A0782625DCF8081AE77@ww300.siemens.net> Hi Frank, Well... the netext is about extending the baseline PMIP6 functionality and hence I don't see the RFC 5213 as a limiting factor when considering the scenarios that can be addressed in the netext. domagoj > -----Original Message----- > From: ext Frank Xia [mailto:xiayangsong at huawei.com] > Sent: 17. veljaca 2009 00:06 > To: Domagoj Premec; 'ext MELIA TELEMACO'; 'Hidetoshi Yokota'; > 'Marco Liebsch' > Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com > Subject: Re: [Netext] Review of the Multihoming PS I-D > > Hi Domagoj > > I don't think so. > > Please check RFC5213 > "If the mobile node connects to the Proxy Mobile IPv6 domain through > multiple interfaces and over multiple access networks, the network > will allocate a unique set of home network prefixes for each of the > connected interfaces" > > BR > Frank > > > ----- Original Message ----- > From: "Domagoj Premec" > To: "'ext MELIA TELEMACO'" > ; "'Hidetoshi Yokota'" > ; "'Marco Liebsch'" > > Cc: ; > Sent: Monday, February 16, 2009 4:45 PM > Subject: Re: [Netext] Review of the Multihoming PS I-D > > > Hi, > > I share the opinion that having the same address assigned to > different interfaces is a viable scenario in the context of > flow mobility and I believe it should be included in the > scope of the inter-tech work. > > domagoj > > > > ________________________________ > > From: netext-bounces at mail.mobileip.jp > [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext > MELIA TELEMACO > Sent: 16. veljaca 2009 14:14 > To: Hidetoshi Yokota; Marco Liebsch > Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com > Subject: Re: [Netext] Review of the Multihoming PS I-D > > > > Hi Hidetoshi, > > I took the liberty to edit your post according (I hope) to > what Marco and I have been saying. Here it goes: > > > Session2_CN1 > Addr_1 Session1_CN1 > IF#1 MAG#1 CN#1 > Addr_2 Session1_CN2 > > MN-ID LMA > > Addr_1 > IF#2 MAG#2 CN#2 > Addr_2 Session2_CN2 > > According to the pic the MN can a) request multiple addresses > (depending on the service he might want to get) and b) > configure the very same address on multiple interfaces to > allow flow mobility (e.g. > Session2_CN1 can be moved to IF#2 Addr_1). If you do not > configure the same address I wonder how the LMA can route > flows since the CN1 always send to the same HNP (Addr_1). > > Marco this is your understanding as well? > > > > thanks > > telemaco > > > > -----Message d'origine----- > De : Hidetoshi Yokota [mailto:yokota at kddilabs.jp] Envoy? : > lundi 16 f?vrier 2009 13:15 ? : Marco Liebsch Cc : MELIA > TELEMACO; netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com > Objet : Re: [Netext] Review of the Multihoming PS I-D > > Hi Marco, Telemaco, Raj and all, > > This thread is interesting and important for the start. Let > me clarify the problem that we are trying to solve. The MN > has multiple interfaces and multiple addresses assigned by > multiple MAGs and can setup multiple sessions with multiple > CNs (either mobile or plain IPv6 hosts) simultaneously. > However, the MN has only one MN-ID and only one LMA (in the > scople of the multihoming problem we are discussing now). The > addresses assigned for the MN can be bound to any interface > of the MN and the sessions associated with those addresses > can go through any interface of the MN. > Also, those addresses and corresponding sessions can migrate > to other interfaces of the MN in the middle. The following > diagram simply shows this > situation: > > /------- MN --------\ > Session#1 > Addr#1 Session#2 CN#1 > IF#1 Addr#2 Session#3 MAG#1 CN#2 > MN-ID IF#2 Addr#3 ... MAG#2 LMA ... > ... ... ... ... ... > IF#J ... ... MAG#M CN#N > Addr#K ... > Session#L > > Is this the correct view that we are discussing now? > > Regards, > -- > Hidetoshi > > Marco Liebsch wrote: > > Hi, > > > > I agree that we should consider support of use cases where > mulitple > > interfaces of an MN get the same HNP assiged. One step further, > the MN > > must configure the same suffix to allow flow mobility and keep > flow > > distribution etc. > > transparent > > to a CN. > > > > Regarding Raj's comments: I fully agree that we need to specify > the > > scope of what we'll solve in NetExt and my opinion is that the > focus > > should be first on the definition of a set of target use cases, as > too > > many of them are treated under the umbrella of multihoming. Then > let's > > analyze where RFC5213 needs some more work to support them. > > > > Whereas I think that most of this work will be on the LMA to allow > the > > assignment of the same HNP to multiple interfaces and to support > > inter-working with policy based forwarding, I do *not* think that > > PMIPv6 signaling should be extended to support in-band > configuration > > of such policy routing at the LMA. Hence, we should thoroughly > define > > the scope of the solution space before. > > > > marco > > > > > > > > MELIA TELEMACO schrieb: > >> Hello, > >> > >> In principle I am fine with the 4 points Raj proposed. In > addition, I > >> would stress scenarios where the same HNP (and same IP address) > is > >> configured across several interfaces. I believe these scenarios > are > >> very useful for flow mobility and flow distributions. > >> Comments? > >> > >> telemaco > >> -----Message d'origine----- > >> De : netext-bounces at mail.mobileip.jp > >> [mailto:netext-bounces at mail.mobileip.jp] De la part de > >> Basavaraj.Patil at nokia.com Envoye' : mercredi 4 fe'vrier 2009 > 15:56 A` > >> : netext at mail.mobileip.jp Cc : Basavaraj.Patil at nokia.com Objet : > >> [Netext] Review of the Multihoming PS I-D > >> > >> > >> Hello, > >> > >> I have reviewed the Netext Multihoming PS I-D > >> . Thanks to Mohana for > her > >> efforts on getting this I-D ready. > >> > >> 1. My impression after reading the I-D is that it misses the key > >> problem of multihoming that we are trying to work on. Proxy > MIP6 as > >> currently specified in RFC5213 has limited support for > >> multihoming. It was decided that multihoming should be dealt > with > >> separately in Netlmm during the course discussions on this > topic in > >> the past. While many of the issues mentioned in the I-D are > >> relevant I believe that Netext should be working on a more > narrow > >> scope to enhance PMIP6 to support a few multihoming scenarios. > >> > >> 2. Sec 3 of the I-D which analyses multihoming issues in the case > of > >> PMIP6/CMIP6 coexisting together is really misplaced here. I do > not > >> believe we want to address this topic as part of the > multihoming > >> work in Netext. This is simply out of scope. > >> > >> 3. The I-D focuses on the problem of multiplexing flows or having > >> flows traverse via one interface or another or the ability to > move > >> a flow from one interface to another. While these are all > valid > >> things to do in PMIP6, I am not convinced that these are > >> specifically related to multihoming. > >> > >> Rajeev and I had a discussion on the scope of multihoming and > what we > >> should really be focusing on. We came up with the following > specific > >> scenarios which we should address: > >> > >> a. The multihoming work in Netext should address the limitations > of > >> RFC5213 > >> w.r.t multihoming. The issue of having a single BCE for an MN > >> identified by an MN-ID and attaching via multiple interfaces > should > >> be resolved. > >> > >> b. The scenario where an MN is connected via a MAG to an LMA and > the > >> ability to establish multiple sessions via the same MAG. This > is > >> the case where the MN is attached via a specific access type > and > >> establishes multiple IP sessions via the MAG. > >> > >> c. The scenario where an MN attaches via different interfaces > which > >> are of differing access technologies via MAG1 and MAG2 > >> simultaneously. The MAG1/MAG2 entities are attached to the > same > >> LMA. > >> > >> d. A combination of the scenarios in (b) and (c), i.e having > multiple > >> sessions via each access type while connected thru different > MAGs > >> simultaneously. > >> > >> Lets see if we can build some consensus around the scope of the > problem. > >> > >> -Raj > >> > >> _______________________________________________ > >> 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: Mon, 16 Feb 2009 17:06:29 -0600 Subject: [Netext] Review of the Multihoming PS I-D References: <853DD750D9C3724FBF2DF7164FCF641C0292167E@FRVELSMBS14.ad2.ad.alcatel.com> <49994B20.7010702@nw.neclab.eu> <499958D8.50402@kddilabs.jp> <853DD750D9C3724FBF2DF7164FCF641C02921A6E@FRVELSMBS14.ad2.ad.alcatel.com> <9B8AFEEF81CE43818736EBC96E924411@ww300.siemens.net> Message-ID: <004d01c9908b$33f09af0$420c7c0a@china.huawei.com> Hi Domagoj I don't think so. Please check RFC5213 "If the mobile node connects to the Proxy Mobile IPv6 domain through multiple interfaces and over multiple access networks, the network will allocate a unique set of home network prefixes for each of the connected interfaces" BR Frank ----- Original Message ----- From: "Domagoj Premec" To: "'ext MELIA TELEMACO'" ; "'Hidetoshi Yokota'" ; "'Marco Liebsch'" Cc: ; Sent: Monday, February 16, 2009 4:45 PM Subject: Re: [Netext] Review of the Multihoming PS I-D Hi, I share the opinion that having the same address assigned to different interfaces is a viable scenario in the context of flow mobility and I believe it should be included in the scope of the inter-tech work. domagoj ________________________________ From: netext-bounces at mail.mobileip.jp [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext MELIA TELEMACO Sent: Monday, February 16, 2009 2:14 PM To: Hidetoshi Yokota; Marco Liebsch Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com Subject: Re: [Netext] Review of the Multihoming PS I-D Hi Hidetoshi, I took the liberty to edit your post according (I hope) to what Marco and I have been saying. Here it goes: Session2_CN1 Addr_1 Session1_CN1 IF#1 MAG#1 CN#1 Addr_2 Session1_CN2 MN-ID LMA Addr_1 IF#2 MAG#2 CN#2 Addr_2 Session2_CN2 According to the pic the MN can a) request multiple addresses (depending on the service he might want to get) and b) configure the very same address on multiple interfaces to allow flow mobility (e.g. Session2_CN1 can be moved to IF#2 Addr_1). If you do not configure the same address I wonder how the LMA can route flows since the CN1 always send to the same HNP (Addr_1). Marco this is your understanding as well? thanks telemaco -----Message d'origine----- De : Hidetoshi Yokota [mailto:yokota at kddilabs.jp] Envoy? : lundi 16 f?vrier 2009 13:15 ? : Marco Liebsch Cc : MELIA TELEMACO; netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com Objet : Re: [Netext] Review of the Multihoming PS I-D Hi Marco, Telemaco, Raj and all, This thread is interesting and important for the start. Let me clarify the problem that we are trying to solve. The MN has multiple interfaces and multiple addresses assigned by multiple MAGs and can setup multiple sessions with multiple CNs (either mobile or plain IPv6 hosts) simultaneously. However, the MN has only one MN-ID and only one LMA (in the scople of the multihoming problem we are discussing now). The addresses assigned for the MN can be bound to any interface of the MN and the sessions associated with those addresses can go through any interface of the MN. Also, those addresses and corresponding sessions can migrate to other interfaces of the MN in the middle. The following diagram simply shows this situation: /------- MN --------\ Session#1 Addr#1 Session#2 CN#1 IF#1 Addr#2 Session#3 MAG#1 CN#2 MN-ID IF#2 Addr#3 ... MAG#2 LMA ... ... ... ... ... ... IF#J ... ... MAG#M CN#N Addr#K ... Session#L Is this the correct view that we are discussing now? Regards, -- Hidetoshi Marco Liebsch wrote: > Hi, > > I agree that we should consider support of use cases where mulitple > interfaces of an MN get the same HNP assiged. One step further, the MN > must configure the same suffix to allow flow mobility and keep flow > distribution etc. > transparent > to a CN. > > Regarding Raj's comments: I fully agree that we need to specify the > scope of what we'll solve in NetExt and my opinion is that the focus > should be first on the definition of a set of target use cases, as too > many of them are treated under the umbrella of multihoming. Then let's > analyze where RFC5213 needs some more work to support them. > > Whereas I think that most of this work will be on the LMA to allow the > assignment of the same HNP to multiple interfaces and to support > inter-working with policy based forwarding, I do *not* think that > PMIPv6 signaling should be extended to support in-band configuration > of such policy routing at the LMA. Hence, we should thoroughly define > the scope of the solution space before. > > marco > > > > MELIA TELEMACO schrieb: >> Hello, >> >> In principle I am fine with the 4 points Raj proposed. In addition, I >> would stress scenarios where the same HNP (and same IP address) is >> configured across several interfaces. I believe these scenarios are >> very useful for flow mobility and flow distributions. >> Comments? >> >> telemaco >> -----Message d'origine----- >> De : netext-bounces at mail.mobileip.jp >> [mailto:netext-bounces at mail.mobileip.jp] De la part de >> Basavaraj.Patil at nokia.com Envoye' : mercredi 4 fe'vrier 2009 15:56 A` >> : netext at mail.mobileip.jp Cc : Basavaraj.Patil at nokia.com Objet : >> [Netext] Review of the Multihoming PS I-D >> >> >> Hello, >> >> I have reviewed the Netext Multihoming PS I-D >> . Thanks to Mohana for her >> efforts on getting this I-D ready. >> >> 1. My impression after reading the I-D is that it misses the key >> problem of multihoming that we are trying to work on. Proxy MIP6 as >> currently specified in RFC5213 has limited support for >> multihoming. It was decided that multihoming should be dealt with >> separately in Netlmm during the course discussions on this topic in >> the past. While many of the issues mentioned in the I-D are >> relevant I believe that Netext should be working on a more narrow >> scope to enhance PMIP6 to support a few multihoming scenarios. >> >> 2. Sec 3 of the I-D which analyses multihoming issues in the case of >> PMIP6/CMIP6 coexisting together is really misplaced here. I do not >> believe we want to address this topic as part of the multihoming >> work in Netext. This is simply out of scope. >> >> 3. The I-D focuses on the problem of multiplexing flows or having >> flows traverse via one interface or another or the ability to move >> a flow from one interface to another. While these are all valid >> things to do in PMIP6, I am not convinced that these are >> specifically related to multihoming. >> >> Rajeev and I had a discussion on the scope of multihoming and what we >> should really be focusing on. We came up with the following specific >> scenarios which we should address: >> >> a. The multihoming work in Netext should address the limitations of >> RFC5213 >> w.r.t multihoming. The issue of having a single BCE for an MN >> identified by an MN-ID and attaching via multiple interfaces should >> be resolved. >> >> b. The scenario where an MN is connected via a MAG to an LMA and the >> ability to establish multiple sessions via the same MAG. This is >> the case where the MN is attached via a specific access type and >> establishes multiple IP sessions via the MAG. >> >> c. The scenario where an MN attaches via different interfaces which >> are of differing access technologies via MAG1 and MAG2 >> simultaneously. The MAG1/MAG2 entities are attached to the same >> LMA. >> >> d. A combination of the scenarios in (b) and (c), i.e having multiple >> sessions via each access type while connected thru different MAGs >> simultaneously. >> >> Lets see if we can build some consensus around the scope of the problem. >> >> -Raj >> >> _______________________________________________ >> 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, 16 Feb 2009 23:45:02 +0100 Subject: [Netext] Review of the Multihoming PS I-D In-Reply-To: <853DD750D9C3724FBF2DF7164FCF641C02921A6E@FRVELSMBS14.ad2.ad.alcatel.com> References: <853DD750D9C3724FBF2DF7164FCF641C0292167E@FRVELSMBS14.ad2.ad.alcatel.com><49994B20.7010702@nw.neclab.eu> <499958D8.50402@kddilabs.jp> <853DD750D9C3724FBF2DF7164FCF641C02921A6E@FRVELSMBS14.ad2.ad.alcatel.com> Message-ID: <9B8AFEEF81CE43818736EBC96E924411@ww300.siemens.net> Hi, I share the opinion that having the same address assigned to different interfaces is a viable scenario in the context of flow mobility and I believe it should be included in the scope of the inter-tech work. domagoj ________________________________ From: netext-bounces at mail.mobileip.jp [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext MELIA TELEMACO Sent: 16. veljaca 2009 14:14 To: Hidetoshi Yokota; Marco Liebsch Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com Subject: Re: [Netext] Review of the Multihoming PS I-D Hi Hidetoshi, I took the liberty to edit your post according (I hope) to what Marco and I have been saying. Here it goes: Session2_CN1 Addr_1 Session1_CN1 IF#1 MAG#1 CN#1 Addr_2 Session1_CN2 MN-ID LMA Addr_1 IF#2 MAG#2 CN#2 Addr_2 Session2_CN2 According to the pic the MN can a) request multiple addresses (depending on the service he might want to get) and b) configure the very same address on multiple interfaces to allow flow mobility (e.g. Session2_CN1 can be moved to IF#2 Addr_1). If you do not configure the same address I wonder how the LMA can route flows since the CN1 always send to the same HNP (Addr_1). Marco this is your understanding as well? thanks telemaco -----Message d'origine----- De : Hidetoshi Yokota [mailto:yokota at kddilabs.jp] Envoy? : lundi 16 f?vrier 2009 13:15 ? : Marco Liebsch Cc : MELIA TELEMACO; netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com Objet : Re: [Netext] Review of the Multihoming PS I-D Hi Marco, Telemaco, Raj and all, This thread is interesting and important for the start. Let me clarify the problem that we are trying to solve. The MN has multiple interfaces and multiple addresses assigned by multiple MAGs and can setup multiple sessions with multiple CNs (either mobile or plain IPv6 hosts) simultaneously. However, the MN has only one MN-ID and only one LMA (in the scople of the multihoming problem we are discussing now). The addresses assigned for the MN can be bound to any interface of the MN and the sessions associated with those addresses can go through any interface of the MN. Also, those addresses and corresponding sessions can migrate to other interfaces of the MN in the middle. The following diagram simply shows this situation: /------- MN --------\ Session#1 Addr#1 Session#2 CN#1 IF#1 Addr#2 Session#3 MAG#1 CN#2 MN-ID IF#2 Addr#3 ... MAG#2 LMA ... ... ... ... ... ... IF#J ... ... MAG#M CN#N Addr#K ... Session#L Is this the correct view that we are discussing now? Regards, -- Hidetoshi Marco Liebsch wrote: > Hi, > > I agree that we should consider support of use cases where mulitple > interfaces of an MN get the same HNP assiged. One step further, the MN > must configure the same suffix to allow flow mobility and keep flow > distribution etc. > transparent > to a CN. > > Regarding Raj's comments: I fully agree that we need to specify the > scope of what we'll solve in NetExt and my opinion is that the focus > should be first on the definition of a set of target use cases, as too > many of them are treated under the umbrella of multihoming. Then let's > analyze where RFC5213 needs some more work to support them. > > Whereas I think that most of this work will be on the LMA to allow the > assignment of the same HNP to multiple interfaces and to support > inter-working with policy based forwarding, I do *not* think that > PMIPv6 signaling should be extended to support in-band configuration > of such policy routing at the LMA. Hence, we should thoroughly define > the scope of the solution space before. > > marco > > > > MELIA TELEMACO schrieb: >> Hello, >> >> In principle I am fine with the 4 points Raj proposed. In addition, I >> would stress scenarios where the same HNP (and same IP address) is >> configured across several interfaces. I believe these scenarios are >> very useful for flow mobility and flow distributions. >> Comments? >> >> telemaco >> -----Message d'origine----- >> De : netext-bounces at mail.mobileip.jp >> [mailto:netext-bounces at mail.mobileip.jp] De la part de >> Basavaraj.Patil at nokia.com Envoye' : mercredi 4 fe'vrier 2009 15:56 A` >> : netext at mail.mobileip.jp Cc : Basavaraj.Patil at nokia.com Objet : >> [Netext] Review of the Multihoming PS I-D >> >> >> Hello, >> >> I have reviewed the Netext Multihoming PS I-D >> . Thanks to Mohana for her >> efforts on getting this I-D ready. >> >> 1. My impression after reading the I-D is that it misses the key >> problem of multihoming that we are trying to work on. Proxy MIP6 as >> currently specified in RFC5213 has limited support for >> multihoming. It was decided that multihoming should be dealt with >> separately in Netlmm during the course discussions on this topic in >> the past. While many of the issues mentioned in the I-D are >> relevant I believe that Netext should be working on a more narrow >> scope to enhance PMIP6 to support a few multihoming scenarios. >> >> 2. Sec 3 of the I-D which analyses multihoming issues in the case of >> PMIP6/CMIP6 coexisting together is really misplaced here. I do not >> believe we want to address this topic as part of the multihoming >> work in Netext. This is simply out of scope. >> >> 3. The I-D focuses on the problem of multiplexing flows or having >> flows traverse via one interface or another or the ability to move >> a flow from one interface to another. While these are all valid >> things to do in PMIP6, I am not convinced that these are >> specifically related to multihoming. >> >> Rajeev and I had a discussion on the scope of multihoming and what we >> should really be focusing on. We came up with the following specific >> scenarios which we should address: >> >> a. The multihoming work in Netext should address the limitations of >> RFC5213 >> w.r.t multihoming. The issue of having a single BCE for an MN >> identified by an MN-ID and attaching via multiple interfaces should >> be resolved. >> >> b. The scenario where an MN is connected via a MAG to an LMA and the >> ability to establish multiple sessions via the same MAG. This is >> the case where the MN is attached via a specific access type and >> establishes multiple IP sessions via the MAG. >> >> c. The scenario where an MN attaches via different interfaces which >> are of differing access technologies via MAG1 and MAG2 >> simultaneously. The MAG1/MAG2 entities are attached to the same >> LMA. >> >> d. A combination of the scenarios in (b) and (c), i.e having multiple >> sessions via each access type while connected thru different MAGs >> simultaneously. >> >> Lets see if we can build some consensus around the scope of the problem. >> >> -Raj >> >> _______________________________________________ >> 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: Mon, 16 Feb 2009 16:01:15 -0500 Subject: [Netext] First Problem Statement about LocalizedRoutingin PMIPv6 submitted In-Reply-To: <49999ADF.30509@nw.neclab.eu> Message-ID: <4D35478224365146822AE9E3AD4A26660690DA20@exchtewks3.starentnetworks.com> Hi Marco, > Rajeev, Carlos, > > can we conclude from the discussion so far that > a.) this is a reasonable and 'in-scope' use case? What is a)? If you mean a node without PMIP6 support, I would say no. There is no way to distinguish nodes like that way, and we should be focussed on solving this for PMIP6 domain IMHO. > b.) PMIPv6 CN vs. IPv6 CN may not be transparent to a MAG and > the NetExt solution for PMIPv6 RO? > We should look at MNs which expect network-based mobility support. Regards, -Rajeev > If both is a 'yes', I propose to add this case to the RO PS. > If we don't see this as separate use case, we could also add > simply a short paragraph that 'this case may have issues, > which we must look at and take into account'. > > What do you think? > > marco > > > > Koodli, Rajeev wrote: > > Hi, > > > > > >> I fully agree that the whole point of PMIP is make mobility > >> management transparent to the MN. However, as far as I understand > >> from my reading of RFC5213, a mobile node attached to a > PMIPv6 domain > >> might not be entitled to the network-based mobility management > >> service, and RFC5213 (section 6.14) still support this node to get > >> connectivity (regular > >> access) from the MAG. > >> > > > > I need to look into this, but I have no idea how a MAG can > distinguish the two nodes.. > > > > > >> Related to this, it is also my interpretation of RFC5213 (section > >> 6.10.5) that the local routing support provided by the basic spec > >> (controlled with the EnableMAGLocalRouting flag) only applies to > >> communications between a PMIPv6 MN and a regular > >> IPv6 host attached to the same MAG. > >> > > > > This sounds even more interesting because the "regular IPv6 > host" gets better performance! > > So, all you have to do is to declare that you are not a PMIP6 MN to > > get better VoIP quality :-) > > > > Regards, > > > > -Rajeev > > > > > >> This is just to try to clarify what RFC5213 provides > (actually, very > >> little) and what does not in regards to local routing > support. Do you > >> see my point? > >> > >> Thanks! > >> > >> Carlos > >> > >> > >>> > >>>> - If my previous understanding is correct, then RFC5213 > >>>> > >> does not > >> > >>>> only define any mechanism to perform local routing > >>>> > >> between two MNs > >> > >>>> connected to the same PMIPv6 domain (not even for the > >>>> > >> case in which > >> > >>>> both are attached to the same MAG). > >>>> Then, IMHO it would be better to change the terminology > in the PS > >>>> and avoid using CN or coming up with different terms for > >>>> > >> a CN that > >> > >>>> is getting network-based mobility service from a CN that is not > >>>> (i.e. it is just a regular IPv6 node getting access from a MAG). > >>>> > >>> See above. > >>> > >>> > >>>> - Currently, the PS only addresses the case of local routing > >>>> between two MNs connected to the same PMIPv6 domain. > >>>> I think the scenario of optimising traffic between an MN and a > >>>> regular IPv6 host that is locally connected to a MAG > >>>> > >> should also be > >> > >>>> addressed. Not sure the implications on the potential > >>>> > >> solutions, but > >> > >>>> it might have an impact on the classification scheme that > >>>> > >> is used in > >> > >>>> the PS now (A[number of MAGs][number of LMAs]). > >>>> > >>>> > >>> Our focus should be on solving the problem for nodes > >>> > >> attached to a PMIP6 domain. > >> > >>> Thanks, > >>> > >>> -Rajeev > >>> > >>> > >>> > >>>> Thanks, > >>>> > >>>> Carlos > >>>> > >>>> El jue, 05-02-2009 a las 15:33 +0100, Marco Liebsch escribi?: > >>>> > >>>>> 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 > >> > >>>> -0 > >>>> > >>>>> 0.txt > >>>>> > >>>>> Best regards, > >>>>> marco > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> 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/ > >>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > >>>> > >>>> > >>> 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. > >> -- > >> 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: cjbc at it.uc3m.es (Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano) Date: Mon, 16 Feb 2009 20:01:42 +0100 Subject: [Netext] Inter-technology handover PS In-Reply-To: <4990ADEE.8060506@ericsson.com> References: <4990ADEE.8060506@ericsson.com> Message-ID: <1234810902.5187.92.camel@localhost> 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? - 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). - 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"? Thanks! Carlos El lun, 09-02-2009 a las 17:27 -0500, Suresh Krishnan escribi?: > Hi Folks, > We have submitted the initial version of the problem statement draft > describing issues with network based inter-technology handovers. Please > send us any comments or issues that you may have on the document. > > Thanks > Suresh > > -------- Original Message -------- > Subject: I-D Action:draft-krishnan-netext-intertech-ps-00.txt > Date: Mon, 9 Feb 2009 14:15:01 -0800 (PST) > From: Internet-Drafts at ietf.org > Reply-To: internet-drafts at ietf.org > To: i-d-announce at ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Issues with network based inter-technology handovers > Author(s) : S. Krishnan, et al. > Filename : draft-krishnan-netext-intertech-ps-00.txt > Pages : 9 > Date : 2009-02-09 > > Proxy Mobile IPv6 (PMIPv6) is a network based mobility management > protocol enables IP mobility for a host without requiring its > participation in any mobility-related signaling. While the PMIPv6 > protocol itself supports handover across interfaces and between > access types, there are several issues with effectively performing > inter-technology handovers with network based mobility protocols. > This document aims to enumerate some known issues with such > handovers. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-krishnan-netext-intertech-ps-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. > > _______________________________________________ > 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: cjbc at it.uc3m.es (Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano) Date: Mon, 16 Feb 2009 19:32:15 +0100 Subject: [Netext] First Problem Statement about LocalizedRoutingin PMIPv6 submitted In-Reply-To: <49999ADF.30509@nw.neclab.eu> References: <4D35478224365146822AE9E3AD4A26660690D389@exchtewks3.starentnetworks.com> <49999ADF.30509@nw.neclab.eu> Message-ID: <1234809135.5187.77.camel@localhost> Hi Marco, In my opinion, it is relevant to first identify whether basic RFC5213 provides a solution for the PMIPv6 MN - IPv6 CN case (when attached to the same MAG). If so, since that solution would be basically a framework (the use of the EnableMAGLocalRouting flag), it would be good for NETEXT to detail the solution. In any case, I find useful to include the use case of the IPv6 CN (either attached to the same MAG than the PMIPv6 MN or to a different one). I'm not so sure about addressing the MIPv6 CN... but I'm fine with including the short paragraph. I'm not sure if I replied to what you were asking, BTW :-) Thanks, Carlos El lun, 16-02-2009 a las 17:57 +0100, Marco Liebsch escribi?: > Rajeev, Carlos, > > can we conclude from the discussion so far that > a.) this is a reasonable and 'in-scope' use case? > b.) PMIPv6 CN vs. IPv6 CN may not be transparent to a MAG and > the NetExt solution for PMIPv6 RO? > > If both is a 'yes', I propose to add this case to the RO PS. > If we don't see this as separate use case, we could also add > simply a short paragraph that 'this case may have issues, > which we must look at and take into account'. > > What do you think? > > marco > > > > Koodli, Rajeev wrote: > > Hi, > > > > > >> I fully agree that the whole point of PMIP is make mobility > >> management transparent to the MN. However, as far as I > >> understand from my reading of RFC5213, a mobile node attached > >> to a PMIPv6 domain might not be entitled to the network-based > >> mobility management service, and RFC5213 (section 6.14) still > >> support this node to get connectivity (regular > >> access) from the MAG. > >> > > > > I need to look into this, but I have no idea how a MAG can distinguish the two nodes.. > > > > > >> Related to this, it is also my interpretation of RFC5213 (section > >> 6.10.5) that the local routing support provided by the basic > >> spec (controlled with the EnableMAGLocalRouting flag) only > >> applies to communications between a PMIPv6 MN and a regular > >> IPv6 host attached to the same MAG. > >> > > > > This sounds even more interesting because the "regular IPv6 host" gets better performance! > > So, all you have to do is to declare that you are not a PMIP6 MN to get better VoIP quality :-) > > > > Regards, > > > > -Rajeev > > > > > >> This is just to try to clarify what RFC5213 provides (actually, very > >> little) and what does not in regards to local routing > >> support. Do you see my point? > >> > >> Thanks! > >> > >> Carlos > >> > >> > >>> > >>>> - If my previous understanding is correct, then RFC5213 > >>>> > >> does not > >> > >>>> only define any mechanism to perform local routing > >>>> > >> between two MNs > >> > >>>> connected to the same PMIPv6 domain (not even for the > >>>> > >> case in which > >> > >>>> both are attached to the same MAG). > >>>> Then, IMHO it would be better to change the terminology in the PS > >>>> and avoid using CN or coming up with different terms for > >>>> > >> a CN that > >> > >>>> is getting network-based mobility service from a CN that is not > >>>> (i.e. it is just a regular IPv6 node getting access from a MAG). > >>>> > >>> See above. > >>> > >>> > >>>> - Currently, the PS only addresses the case of local routing > >>>> between two MNs connected to the same PMIPv6 domain. > >>>> I think the scenario of optimising traffic between an MN and a > >>>> regular IPv6 host that is locally connected to a MAG > >>>> > >> should also be > >> > >>>> addressed. Not sure the implications on the potential > >>>> > >> solutions, but > >> > >>>> it might have an impact on the classification scheme that > >>>> > >> is used in > >> > >>>> the PS now (A[number of MAGs][number of LMAs]). > >>>> > >>>> > >>> Our focus should be on solving the problem for nodes > >>> > >> attached to a PMIP6 domain. > >> > >>> Thanks, > >>> > >>> -Rajeev > >>> > >>> > >>> > >>>> Thanks, > >>>> > >>>> Carlos > >>>> > >>>> El jue, 05-02-2009 a las 15:33 +0100, Marco Liebsch escribi?: > >>>> > >>>>> 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 > >> > >>>> -0 > >>>> > >>>>> 0.txt > >>>>> > >>>>> Best regards, > >>>>> marco > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> 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/ > >>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > >>>> > >>>> > >>> 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. > >> -- > >> 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: liebsch at nw.neclab.eu (Marco Liebsch) Date: Mon, 16 Feb 2009 17:57:03 +0100 Subject: [Netext] First Problem Statement about LocalizedRoutingin PMIPv6 submitted In-Reply-To: <4D35478224365146822AE9E3AD4A26660690D389@exchtewks3.starentnetworks.com> References: <4D35478224365146822AE9E3AD4A26660690D389@exchtewks3.starentnetworks.com> Message-ID: <49999ADF.30509@nw.neclab.eu> Rajeev, Carlos, can we conclude from the discussion so far that a.) this is a reasonable and 'in-scope' use case? b.) PMIPv6 CN vs. IPv6 CN may not be transparent to a MAG and the NetExt solution for PMIPv6 RO? If both is a 'yes', I propose to add this case to the RO PS. If we don't see this as separate use case, we could also add simply a short paragraph that 'this case may have issues, which we must look at and take into account'. What do you think? marco Koodli, Rajeev wrote: > Hi, > > >> I fully agree that the whole point of PMIP is make mobility >> management transparent to the MN. However, as far as I >> understand from my reading of RFC5213, a mobile node attached >> to a PMIPv6 domain might not be entitled to the network-based >> mobility management service, and RFC5213 (section 6.14) still >> support this node to get connectivity (regular >> access) from the MAG. >> > > I need to look into this, but I have no idea how a MAG can distinguish the two nodes.. > > >> Related to this, it is also my interpretation of RFC5213 (section >> 6.10.5) that the local routing support provided by the basic >> spec (controlled with the EnableMAGLocalRouting flag) only >> applies to communications between a PMIPv6 MN and a regular >> IPv6 host attached to the same MAG. >> > > This sounds even more interesting because the "regular IPv6 host" gets better performance! > So, all you have to do is to declare that you are not a PMIP6 MN to get better VoIP quality :-) > > Regards, > > -Rajeev > > >> This is just to try to clarify what RFC5213 provides (actually, very >> little) and what does not in regards to local routing >> support. Do you see my point? >> >> Thanks! >> >> Carlos >> >> >>> >>>> - If my previous understanding is correct, then RFC5213 >>>> >> does not >> >>>> only define any mechanism to perform local routing >>>> >> between two MNs >> >>>> connected to the same PMIPv6 domain (not even for the >>>> >> case in which >> >>>> both are attached to the same MAG). >>>> Then, IMHO it would be better to change the terminology in the PS >>>> and avoid using CN or coming up with different terms for >>>> >> a CN that >> >>>> is getting network-based mobility service from a CN that is not >>>> (i.e. it is just a regular IPv6 node getting access from a MAG). >>>> >>> See above. >>> >>> >>>> - Currently, the PS only addresses the case of local routing >>>> between two MNs connected to the same PMIPv6 domain. >>>> I think the scenario of optimising traffic between an MN and a >>>> regular IPv6 host that is locally connected to a MAG >>>> >> should also be >> >>>> addressed. Not sure the implications on the potential >>>> >> solutions, but >> >>>> it might have an impact on the classification scheme that >>>> >> is used in >> >>>> the PS now (A[number of MAGs][number of LMAs]). >>>> >>>> >>> Our focus should be on solving the problem for nodes >>> >> attached to a PMIP6 domain. >> >>> Thanks, >>> >>> -Rajeev >>> >>> >>> >>>> Thanks, >>>> >>>> Carlos >>>> >>>> El jue, 05-02-2009 a las 15:33 +0100, Marco Liebsch escribi?: >>>> >>>>> 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 >> >>>> -0 >>>> >>>>> 0.txt >>>>> >>>>> Best regards, >>>>> marco >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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/ >>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>>> >>>> >>> 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. >> -- >> 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: liebsch at nw.neclab.eu (Marco Liebsch) Date: Mon, 16 Feb 2009 17:44:01 +0100 Subject: [Netext] Review of the Multihoming PS I-D In-Reply-To: <499958D8.50402@kddilabs.jp> References: <853DD750D9C3724FBF2DF7164FCF641C0292167E@FRVELSMBS14.ad2.ad.alcatel.com> <49994B20.7010702@nw.neclab.eu> <499958D8.50402@kddilabs.jp> Message-ID: <499997D1.4010503@nw.neclab.eu> Hi Hidetoshi, please find my comments in-line. Hidetoshi Yokota wrote: > Hi Marco, Telemaco, Raj and all, > > This thread is interesting and important for the start. Let me clarify > the problem that we are trying to solve. The MN has multiple interfaces > and multiple addresses assigned by multiple MAGs and can setup multiple > sessions with multiple CNs (either mobile or plain IPv6 hosts) > simultaneously. However, the MN has only one MN-ID and only one LMA (in > the scople of the multihoming problem we are discussing now). So far I am ok. > The > addresses assigned for the MN can be bound to any interface of the MN > and the sessions associated with those addresses can go through any > interface of the MN. Well, here we should stick to the PMIP concept be clear: An MN's interface cannot simply use any address, but should use the HNP, which has been assigned to the interface during its registration. And this is under control of the LMA (or the AAA behind). So, in my opinion, an MN can use an HNP for an interface only if the HNP has been assigned to this interface during the registration. Maybe that's what you mean. > Also, those addresses and corresponding sessions > can migrate to other interfaces of the MN in the middle. The following > diagram simply shows this situation: > Maybe I read the diagram in the wrong way, but there should not be a 'mesh'-like relationship between all addresses (1-K) and all IFs (1-J). marco > /------- MN --------\ > Session#1 > Addr#1 Session#2 CN#1 > IF#1 Addr#2 Session#3 MAG#1 CN#2 > MN-ID IF#2 Addr#3 ... MAG#2 LMA ... > ... ... ... ... ... > IF#J ... ... MAG#M CN#N > Addr#K ... > Session#L > > Is this the correct view that we are discussing now? > > Regards, > From: Telemaco.Melia at alcatel-lucent.com (MELIA TELEMACO) Date: Mon, 16 Feb 2009 14:14:18 +0100 Subject: [Netext] Review of the Multihoming PS I-D In-Reply-To: <499958D8.50402@kddilabs.jp> References: <853DD750D9C3724FBF2DF7164FCF641C0292167E@FRVELSMBS14.ad2.ad.alcatel.com> <49994B20.7010702@nw.neclab.eu> <499958D8.50402@kddilabs.jp> Message-ID: <853DD750D9C3724FBF2DF7164FCF641C02921A6E@FRVELSMBS14.ad2.ad.alcatel.com> Hi Hidetoshi, I took the liberty to edit your post according (I hope) to what Marco and I have been saying. Here it goes: Session2_CN1 Addr_1 Session1_CN1 IF#1 MAG#1 CN#1 Addr_2 Session1_CN2 MN-ID LMA Addr_1 IF#2 MAG#2 CN#2 Addr_2 Session2_CN2 According to the pic the MN can a) request multiple addresses (depending on the service he might want to get) and b) configure the very same address on multiple interfaces to allow flow mobility (e.g. Session2_CN1 can be moved to IF#2 Addr_1). If you do not configure the same address I wonder how the LMA can route flows since the CN1 always send to the same HNP (Addr_1). Marco this is your understanding as well? thanks telemaco -----Message d'origine----- De : Hidetoshi Yokota [mailto:yokota at kddilabs.jp] Envoy? : lundi 16 f?vrier 2009 13:15 ? : Marco Liebsch Cc : MELIA TELEMACO; netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com Objet : Re: [Netext] Review of the Multihoming PS I-D Hi Marco, Telemaco, Raj and all, This thread is interesting and important for the start. Let me clarify the problem that we are trying to solve. The MN has multiple interfaces and multiple addresses assigned by multiple MAGs and can setup multiple sessions with multiple CNs (either mobile or plain IPv6 hosts) simultaneously. However, the MN has only one MN-ID and only one LMA (in the scople of the multihoming problem we are discussing now). The addresses assigned for the MN can be bound to any interface of the MN and the sessions associated with those addresses can go through any interface of the MN. Also, those addresses and corresponding sessions can migrate to other interfaces of the MN in the middle. The following diagram simply shows this situation: /------- MN --------\ Session#1 Addr#1 Session#2 CN#1 IF#1 Addr#2 Session#3 MAG#1 CN#2 MN-ID IF#2 Addr#3 ... MAG#2 LMA ... ... ... ... ... ... IF#J ... ... MAG#M CN#N Addr#K ... Session#L Is this the correct view that we are discussing now? Regards, -- Hidetoshi Marco Liebsch wrote: > Hi, > > I agree that we should consider support of use cases where mulitple > interfaces of an MN get the same HNP assiged. One step further, the MN > must configure the same suffix to allow flow mobility and keep flow > distribution etc. > transparent > to a CN. > > Regarding Raj's comments: I fully agree that we need to specify the > scope of what we'll solve in NetExt and my opinion is that the focus > should be first on the definition of a set of target use cases, as too > many of them are treated under the umbrella of multihoming. Then let's > analyze where RFC5213 needs some more work to support them. > > Whereas I think that most of this work will be on the LMA to allow the > assignment of the same HNP to multiple interfaces and to support > inter-working with policy based forwarding, I do *not* think that > PMIPv6 signaling should be extended to support in-band configuration > of such policy routing at the LMA. Hence, we should thoroughly define > the scope of the solution space before. > > marco > > > > MELIA TELEMACO schrieb: >> Hello, >> >> In principle I am fine with the 4 points Raj proposed. In addition, I >> would stress scenarios where the same HNP (and same IP address) is >> configured across several interfaces. I believe these scenarios are >> very useful for flow mobility and flow distributions. >> Comments? >> >> telemaco >> -----Message d'origine----- >> De : netext-bounces at mail.mobileip.jp >> [mailto:netext-bounces at mail.mobileip.jp] De la part de >> Basavaraj.Patil at nokia.com Envoye' : mercredi 4 fe'vrier 2009 15:56 A` >> : netext at mail.mobileip.jp Cc : Basavaraj.Patil at nokia.com Objet : >> [Netext] Review of the Multihoming PS I-D >> >> >> Hello, >> >> I have reviewed the Netext Multihoming PS I-D >> . Thanks to Mohana for her >> efforts on getting this I-D ready. >> >> 1. My impression after reading the I-D is that it misses the key >> problem of multihoming that we are trying to work on. Proxy MIP6 as >> currently specified in RFC5213 has limited support for >> multihoming. It was decided that multihoming should be dealt with >> separately in Netlmm during the course discussions on this topic in >> the past. While many of the issues mentioned in the I-D are >> relevant I believe that Netext should be working on a more narrow >> scope to enhance PMIP6 to support a few multihoming scenarios. >> >> 2. Sec 3 of the I-D which analyses multihoming issues in the case of >> PMIP6/CMIP6 coexisting together is really misplaced here. I do not >> believe we want to address this topic as part of the multihoming >> work in Netext. This is simply out of scope. >> >> 3. The I-D focuses on the problem of multiplexing flows or having >> flows traverse via one interface or another or the ability to move >> a flow from one interface to another. While these are all valid >> things to do in PMIP6, I am not convinced that these are >> specifically related to multihoming. >> >> Rajeev and I had a discussion on the scope of multihoming and what we >> should really be focusing on. We came up with the following specific >> scenarios which we should address: >> >> a. The multihoming work in Netext should address the limitations of >> RFC5213 >> w.r.t multihoming. The issue of having a single BCE for an MN >> identified by an MN-ID and attaching via multiple interfaces should >> be resolved. >> >> b. The scenario where an MN is connected via a MAG to an LMA and the >> ability to establish multiple sessions via the same MAG. This is >> the case where the MN is attached via a specific access type and >> establishes multiple IP sessions via the MAG. >> >> c. The scenario where an MN attaches via different interfaces which >> are of differing access technologies via MAG1 and MAG2 >> simultaneously. The MAG1/MAG2 entities are attached to the same >> LMA. >> >> d. A combination of the scenarios in (b) and (c), i.e having multiple >> sessions via each access type while connected thru different MAGs >> simultaneously. >> >> Lets see if we can build some consensus around the scope of the problem. >> >> -Raj >> >> _______________________________________________ >> 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 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From: yokota at kddilabs.jp (Hidetoshi Yokota) Date: Mon, 16 Feb 2009 21:15:20 +0900 Subject: [Netext] Review of the Multihoming PS I-D In-Reply-To: <49994B20.7010702@nw.neclab.eu> References: <853DD750D9C3724FBF2DF7164FCF641C0292167E@FRVELSMBS14.ad2.ad.alcatel.com> <49994B20.7010702@nw.neclab.eu> Message-ID: <499958D8.50402@kddilabs.jp> Hi Marco, Telemaco, Raj and all, This thread is interesting and important for the start. Let me clarify the problem that we are trying to solve. The MN has multiple interfaces and multiple addresses assigned by multiple MAGs and can setup multiple sessions with multiple CNs (either mobile or plain IPv6 hosts) simultaneously. However, the MN has only one MN-ID and only one LMA (in the scople of the multihoming problem we are discussing now). The addresses assigned for the MN can be bound to any interface of the MN and the sessions associated with those addresses can go through any interface of the MN. Also, those addresses and corresponding sessions can migrate to other interfaces of the MN in the middle. The following diagram simply shows this situation: /------- MN --------\ Session#1 Addr#1 Session#2 CN#1 IF#1 Addr#2 Session#3 MAG#1 CN#2 MN-ID IF#2 Addr#3 ... MAG#2 LMA ... ... ... ... ... ... IF#J ... ... MAG#M CN#N Addr#K ... Session#L Is this the correct view that we are discussing now? Regards, -- Hidetoshi Marco Liebsch wrote: > Hi, > > I agree that we should consider support of use cases where mulitple > interfaces > of an MN get the same HNP assiged. One step further, the MN must configure > the same suffix to allow flow mobility and keep flow distribution etc. > transparent > to a CN. > > Regarding Raj's comments: I fully agree that we need to specify the > scope of what > we'll solve in NetExt and my opinion is that the focus should be first > on the definition of > a set of target use cases, as too many of them are treated under the > umbrella of > multihoming. Then let's analyze where RFC5213 needs some more work to > support them. > > Whereas I think that most of this work will be on the LMA to allow the > assignment of > the same HNP to multiple interfaces and to support inter-working with > policy based > forwarding, I do *not* think that PMIPv6 signaling should be extended to > support > in-band configuration of such policy routing at the LMA. Hence, we > should thoroughly > define the scope of the solution space before. > > marco > > > > MELIA TELEMACO schrieb: >> Hello, >> >> In principle I am fine with the 4 points Raj proposed. In addition, I >> would stress scenarios where the same HNP (and same IP address) is >> configured across several interfaces. I believe these scenarios are >> very useful for flow mobility and flow distributions. >> Comments? >> >> telemaco >> -----Message d'origine----- >> De : netext-bounces at mail.mobileip.jp >> [mailto:netext-bounces at mail.mobileip.jp] De la part de >> Basavaraj.Patil at nokia.com >> Envoye' : mercredi 4 fe'vrier 2009 15:56 >> A` : netext at mail.mobileip.jp >> Cc : Basavaraj.Patil at nokia.com >> Objet : [Netext] Review of the Multihoming PS I-D >> >> >> Hello, >> >> I have reviewed the Netext Multihoming PS I-D >> . Thanks to Mohana for her >> efforts on getting this I-D ready. >> >> 1. My impression after reading the I-D is that it misses the key >> problem of multihoming that we are trying to work on. Proxy MIP6 as >> currently specified in RFC5213 has limited support for >> multihoming. It was decided that multihoming should be dealt with >> separately in Netlmm during the course discussions on this topic in >> the past. While many of the issues mentioned in the I-D are >> relevant I believe that Netext should be working on a more narrow >> scope to enhance PMIP6 to support a few multihoming scenarios. >> >> 2. Sec 3 of the I-D which analyses multihoming issues in the case of >> PMIP6/CMIP6 coexisting together is really misplaced here. I do not >> believe we want to address this topic as part of the multihoming >> work in Netext. This is simply out of scope. >> >> 3. The I-D focuses on the problem of multiplexing flows or having >> flows traverse via one interface or another or the ability to move >> a flow from one interface to another. While these are all valid >> things to do in PMIP6, I am not convinced that these are >> specifically related to multihoming. >> >> Rajeev and I had a discussion on the scope of multihoming and what we >> should really be focusing on. We came up with the following specific >> scenarios which we should address: >> >> a. The multihoming work in Netext should address the limitations of >> RFC5213 >> w.r.t multihoming. The issue of having a single BCE for an MN >> identified by an MN-ID and attaching via multiple interfaces should >> be resolved. >> >> b. The scenario where an MN is connected via a MAG to an LMA and the >> ability to establish multiple sessions via the same MAG. This is >> the case where the MN is attached via a specific access type and >> establishes multiple IP sessions via the MAG. >> >> c. The scenario where an MN attaches via different interfaces which >> are of differing access technologies via MAG1 and MAG2 >> simultaneously. The MAG1/MAG2 entities are attached to the same >> LMA. >> >> d. A combination of the scenarios in (b) and (c), i.e having multiple >> sessions via each access type while connected thru different MAGs >> simultaneously. >> >> Lets see if we can build some consensus around the scope of the problem. >> >> -Raj >> >> _______________________________________________ >> 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: marco.liebsch at nw.neclab.eu (Marco Liebsch) Date: Mon, 16 Feb 2009 12:16:48 +0100 Subject: [Netext] Review of the Multihoming PS I-D In-Reply-To: <853DD750D9C3724FBF2DF7164FCF641C0292167E@FRVELSMBS14.ad2.ad.alcatel.com> References: <853DD750D9C3724FBF2DF7164FCF641C0292167E@FRVELSMBS14.ad2.ad.alcatel.com> Message-ID: <49994B20.7010702@nw.neclab.eu> Hi, I agree that we should consider support of use cases where mulitple interfaces of an MN get the same HNP assiged. One step further, the MN must configure the same suffix to allow flow mobility and keep flow distribution etc. transparent to a CN. Regarding Raj's comments: I fully agree that we need to specify the scope of what we'll solve in NetExt and my opinion is that the focus should be first on the definition of a set of target use cases, as too many of them are treated under the umbrella of multihoming. Then let's analyze where RFC5213 needs some more work to support them. Whereas I think that most of this work will be on the LMA to allow the assignment of the same HNP to multiple interfaces and to support inter-working with policy based forwarding, I do *not* think that PMIPv6 signaling should be extended to support in-band configuration of such policy routing at the LMA. Hence, we should thoroughly define the scope of the solution space before. marco MELIA TELEMACO schrieb: > Hello, > > In principle I am fine with the 4 points Raj proposed. In addition, I would stress scenarios where the same HNP (and same IP address) is configured across several interfaces. I believe these scenarios are very useful for flow mobility and flow distributions. > > Comments? > > telemaco > > -----Message d'origine----- > De : netext-bounces at mail.mobileip.jp [mailto:netext-bounces at mail.mobileip.jp] De la part de Basavaraj.Patil at nokia.com > Envoy? : mercredi 4 f?vrier 2009 15:56 > ? : netext at mail.mobileip.jp > Cc : Basavaraj.Patil at nokia.com > Objet : [Netext] Review of the Multihoming PS I-D > > > Hello, > > I have reviewed the Netext Multihoming PS I-D . Thanks to Mohana for her efforts on getting this I-D ready. > > 1. My impression after reading the I-D is that it misses the key > problem of multihoming that we are trying to work on. Proxy MIP6 as > currently specified in RFC5213 has limited support for > multihoming. It was decided that multihoming should be dealt with > separately in Netlmm during the course discussions on this topic in > the past. While many of the issues mentioned in the I-D are > relevant I believe that Netext should be working on a more narrow > scope to enhance PMIP6 to support a few multihoming scenarios. > > 2. Sec 3 of the I-D which analyses multihoming issues in the case of > PMIP6/CMIP6 coexisting together is really misplaced here. I do not > believe we want to address this topic as part of the multihoming > work in Netext. This is simply out of scope. > > 3. The I-D focuses on the problem of multiplexing flows or having > flows traverse via one interface or another or the ability to move > a flow from one interface to another. While these are all valid > things to do in PMIP6, I am not convinced that these are > specifically related to multihoming. > > Rajeev and I had a discussion on the scope of multihoming and what we should really be focusing on. We came up with the following specific scenarios which we should address: > > a. The multihoming work in Netext should address the limitations of RFC5213 > w.r.t multihoming. The issue of having a single BCE for an MN > identified by an MN-ID and attaching via multiple interfaces should > be resolved. > > b. The scenario where an MN is connected via a MAG to an LMA and the > ability to establish multiple sessions via the same MAG. This is > the case where the MN is attached via a specific access type and > establishes multiple IP sessions via the MAG. > > c. The scenario where an MN attaches via different interfaces which > are of differing access technologies via MAG1 and MAG2 > simultaneously. The MAG1/MAG2 entities are attached to the same > LMA. > > d. A combination of the scenarios in (b) and (c), i.e having multiple > sessions via each access type while connected thru different MAGs > simultaneously. > > Lets see if we can build some consensus around the scope of the problem. > > -Raj > > _______________________________________________ > 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: behcetsarikaya at yahoo.com (Behcet Sarikaya) Date: Sun, 15 Feb 2009 12:18:06 -0800 (PST) Subject: [Netext] Review of the Multihoming PS I-D References: <853DD750D9C3724FBF2DF7164FCF641C0292167E@FRVELSMBS14.ad2.ad.alcatel.com> Message-ID: <122302.78217.qm@web111415.mail.gq1.yahoo.com> Hi Telemaco, ________________________________ From: MELIA TELEMACO To: Basavaraj.Patil at nokia.com; netext at mail.mobileip.jp Sent: Friday, February 13, 2009 11:23:58 AM Subject: Re: [Netext] Review of the Multihoming PS I-D Hello, In principle I am fine with the 4 points Raj proposed. In addition, I would stress scenarios where the same HNP (and same IP address) is configured across several interfaces. I believe these scenarios are very useful for flow mobility and flow distributions. [behcet] Why? Do you expect prefix run-out soon? Regards, Behcet -------------- next part -------------- An HTML attachment was scrubbed... URL: From: rkoodli at starentnetworks.com (Koodli, Rajeev) Date: Fri, 13 Feb 2009 19:11:30 -0500 Subject: [Netext] First Problem Statement about LocalizedRoutingin PMIPv6 submitted In-Reply-To: <1234370715.5174.9.camel@localhost> Message-ID: <4D35478224365146822AE9E3AD4A26660690D389@exchtewks3.starentnetworks.com> Hi, > I fully agree that the whole point of PMIP is make mobility > management transparent to the MN. However, as far as I > understand from my reading of RFC5213, a mobile node attached > to a PMIPv6 domain might not be entitled to the network-based > mobility management service, and RFC5213 (section 6.14) still > support this node to get connectivity (regular > access) from the MAG. I need to look into this, but I have no idea how a MAG can distinguish the two nodes.. > > Related to this, it is also my interpretation of RFC5213 (section > 6.10.5) that the local routing support provided by the basic > spec (controlled with the EnableMAGLocalRouting flag) only > applies to communications between a PMIPv6 MN and a regular > IPv6 host attached to the same MAG. This sounds even more interesting because the "regular IPv6 host" gets better performance! So, all you have to do is to declare that you are not a PMIP6 MN to get better VoIP quality :-) Regards, -Rajeev > > This is just to try to clarify what RFC5213 provides (actually, very > little) and what does not in regards to local routing > support. Do you see my point? > > Thanks! > > Carlos > > > > > > > > > > > - If my previous understanding is correct, then RFC5213 > does not > > > only define any mechanism to perform local routing > between two MNs > > > connected to the same PMIPv6 domain (not even for the > case in which > > > both are attached to the same MAG). > > > Then, IMHO it would be better to change the terminology in the PS > > > and avoid using CN or coming up with different terms for > a CN that > > > is getting network-based mobility service from a CN that is not > > > (i.e. it is just a regular IPv6 node getting access from a MAG). > > > > See above. > > > > > > > > - Currently, the PS only addresses the case of local routing > > > between two MNs connected to the same PMIPv6 domain. > > > I think the scenario of optimising traffic between an MN and a > > > regular IPv6 host that is locally connected to a MAG > should also be > > > addressed. Not sure the implications on the potential > solutions, but > > > it might have an impact on the classification scheme that > is used in > > > the PS now (A[number of MAGs][number of LMAs]). > > > > > > > Our focus should be on solving the problem for nodes > attached to a PMIP6 domain. > > > > Thanks, > > > > -Rajeev > > > > > > > Thanks, > > > > > > Carlos > > > > > > El jue, 05-02-2009 a las 15:33 +0100, Marco Liebsch escribi?: > > > > 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 > > > -0 > > > > 0.txt > > > > > > > > Best regards, > > > > marco > > > > > > > > > > > > _______________________________________________ > > > > 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/ > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > > > > > > > > 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. > -- > 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: Telemaco.Melia at alcatel-lucent.com (MELIA TELEMACO) Date: Fri, 13 Feb 2009 18:23:58 +0100 Subject: [Netext] Review of the Multihoming PS I-D In-Reply-To: References: Message-ID: <853DD750D9C3724FBF2DF7164FCF641C0292167E@FRVELSMBS14.ad2.ad.alcatel.com> Hello, In principle I am fine with the 4 points Raj proposed. In addition, I would stress scenarios where the same HNP (and same IP address) is configured across several interfaces. I believe these scenarios are very useful for flow mobility and flow distributions. Comments? telemaco -----Message d'origine----- De : netext-bounces at mail.mobileip.jp [mailto:netext-bounces at mail.mobileip.jp] De la part de Basavaraj.Patil at nokia.com Envoy? : mercredi 4 f?vrier 2009 15:56 ? : netext at mail.mobileip.jp Cc : Basavaraj.Patil at nokia.com Objet : [Netext] Review of the Multihoming PS I-D Hello, I have reviewed the Netext Multihoming PS I-D . Thanks to Mohana for her efforts on getting this I-D ready. 1. My impression after reading the I-D is that it misses the key problem of multihoming that we are trying to work on. Proxy MIP6 as currently specified in RFC5213 has limited support for multihoming. It was decided that multihoming should be dealt with separately in Netlmm during the course discussions on this topic in the past. While many of the issues mentioned in the I-D are relevant I believe that Netext should be working on a more narrow scope to enhance PMIP6 to support a few multihoming scenarios. 2. Sec 3 of the I-D which analyses multihoming issues in the case of PMIP6/CMIP6 coexisting together is really misplaced here. I do not believe we want to address this topic as part of the multihoming work in Netext. This is simply out of scope. 3. The I-D focuses on the problem of multiplexing flows or having flows traverse via one interface or another or the ability to move a flow from one interface to another. While these are all valid things to do in PMIP6, I am not convinced that these are specifically related to multihoming. Rajeev and I had a discussion on the scope of multihoming and what we should really be focusing on. We came up with the following specific scenarios which we should address: a. The multihoming work in Netext should address the limitations of RFC5213 w.r.t multihoming. The issue of having a single BCE for an MN identified by an MN-ID and attaching via multiple interfaces should be resolved. b. The scenario where an MN is connected via a MAG to an LMA and the ability to establish multiple sessions via the same MAG. This is the case where the MN is attached via a specific access type and establishes multiple IP sessions via the MAG. c. The scenario where an MN attaches via different interfaces which are of differing access technologies via MAG1 and MAG2 simultaneously. The MAG1/MAG2 entities are attached to the same LMA. d. A combination of the scenarios in (b) and (c), i.e having multiple sessions via each access type while connected thru different MAGs simultaneously. Lets see if we can build some consensus around the scope of the problem. -Raj _______________________________________________ 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, 12 Feb 2009 09:53:18 +0100 Subject: [Netext] First Problem Statement about Localized Routing in PMIPv6 submitted In-Reply-To: <1234371603.5174.26.camel@localhost> References: <498AF8B1.1020303@nw.neclab.eu> <1234339777.21602.198.camel@localhost> <49929954.4010500@nw.neclab.eu> <1234371603.5174.26.camel@localhost> Message-ID: <4993E37E.4090407@nw.neclab.eu> Hi Carlos, Carlos Jes?s Bernardos Cano wrote: > Hi Marco, > > El mi?, 11-02-2009 a las 10:24 +0100, Marco Liebsch escribi?: > >> Hi Carlos, >> >> thanks for the feedback! >> Please find my view and answers to your comments below. >> >> Carlos Jes?s Bernardos Cano wrote: >> >>> Hi Marco, all, >>> >>> I've just read your document. Thanks for writing it! >>> >>> I have some comments/questions: >>> >>> - Regarding EnableMAGLocalRouting flag: in addition to what has been >>> already discussed in this list, I want to check whether my understanding >>> of RFC5213 is right or not. As far as I understand it, the local routing >>> mechanism that is slightly defined in PMIPv6 specs refers to the >>> optimisation of data traffic between an MN and a regular IPv6 node (a >>> node that is not getting network-based mobility service from the PMIPv6 >>> domain) that are both connected to the same MAG. This is what I >>> understand from reading sections 6.10.5 and 6.14, though IMHO this is >>> not clearly specified in RFC5213. Is this correct or am I missing >>> something? >>> >>> >> Well, I think both is intrinsically supported (maybe without >> intention), a PMIPv6-attached CN or an IPv6 CN, that uses the >> network component, which implements the MAG, as AR. In the >> first case, the MAG has a BUL entry and an associated route >> entry for the CN, in the latter case, the AR has a route >> entry for the CN. So prefix routing should work in both cases. >> The only thing you need to take care in the IPv6 case is that >> the MAG allows deviations from a default route for the MN's >> traffic, which should not go through the LMA then, but should be >> forwarded according to the local routing table. However, all these >> things are not described in RFC5213, for good reasons, as this >> was not the focus. >> > > Yes, I agree both cases are not so different, but there are still > differences. I'm not sure RFC5214 intrinsically supports both, since > there are explicit references to "IPv6..." Besides the IPv6 address of a > regular IPv6 host (IPv6 CN, as you called it) is anchored at the MAG, > while the IPv6 prefix used by a PMIPv6 MN is anchored at the LMA, so > there might be some subtle differences. > Yes, I understand the difference. > >>> - If my previous understanding is correct, then RFC5213 does not only >>> define any mechanism to perform local routing between two MNs connected >>> to the same PMIPv6 domain (not even for the case in which both are >>> attached to the same MAG). Then, IMHO it would be better to change the >>> terminology in the PS and avoid using CN or coming up with different >>> terms for a CN that is getting network-based mobility service from a CN >>> that is not (i.e. it is just a regular IPv6 node getting access from a >>> MAG). >>> >>> >> Ok, the idea was the following: MN and CN have been chosen to >> distinguish the two mobile nodes. Now, as we thought about more >> use cases before, such as for example setting up RO between a >> PMIPv6 attached MN and a MIPv6 CN, the intention was to keep >> MN and CN as terms, but to refer to a specific use case in addition. >> So, if there is a discussion about a RO 'association' between an MN >> and a CN, both are PMIPv6 attached, its for example a use case >> according to A12. RO with a MIPv6 CN should be described as B >> use cases (e.g. B12). We could introduce more uses cases to cover >> RO with an IPv6 node, such as C2. >> > > Ummm, this is getting too complex. Maybe I didn't explain well in my > previous e-mail. What I had in mind are two different scenarios: > > - PMIPv6 MNs: that is, MNs getting network-based mobility management > - Regular IPv6 hosts (we can call them IPv6 CNs): that is, nodes locally > attached to a MAG that don't benefit from a network-based mobility > management (i.e., they configure their IPv6 address from a local > "visited" prefix, not from a prefix managed by an LMA). > Yes, I agree that we may look into such use case and see if there is anything more to be done to support it. > I didn't add the third variable of MIPv6 CNs No, but I did ;-) > (i.e., nodes that support > the CN functionality of MIPv6 RO). I'll leave that case out of the PS > for the time being. > > >> Alternatively (or in addition) we could distinguish the mobile devices >> by means of extensions (CN_IP6, CN_MIP6), but this does not cover >> the use cases and all the variants of a particular use case yet. >> More in this context below. >> > > OK, I see now. One thing is the scenario based on the attachment points > of the end-points of the communication (MAGs) and the number of involved > LMAs. A different thing is the type of node a PMIPv6 MN is communicating > to (it may be a PMIPv6 MN, an IPv6 CN or a MIPv6 CN). > Yes. > >>> - Currently, the PS only addresses the case of local routing between >>> two MNs connected to the same PMIPv6 domain. I think the scenario of >>> optimising traffic between an MN and a regular IPv6 host that is locally >>> connected to a MAG should also be addressed. Not sure the implications >>> on the potential solutions, but it might have an impact on the >>> classification scheme that is used in the PS now (A[number of >>> MAGs][number of LMAs]). >>> >>> >> I don't see an issue here, as we can differentiate the mobility >> mode (if there is any) of both nodes by means of the use case >> (A,B,C,...). Since the IPv6 CN will not have a mobility anchor, >> we should indicate only the amount of involved ARs/MAGs (such as C2). >> > > I don't want to bring a new issue. I just tried to point out that it > might be good to highlight that the type of node is also important. I'm > fine with adding a new variable on the use cases to reflect that. > Yes, independent of different types of nodes and how they are attached to the network infrastructure we should agree on the scope of a future solution and either keep it as it is or add one or the other use case to the PS doc accordingly. > >> Ok, long story above. Fact is that the scope of the PS doc has been >> cut to the current NetExt charter, which focuses in particular on RO >> between two PMIPv6 attached MNs. Larger scope needs to be discussed >> and agreed on. If we need more use cases, we could describe them as >> proposed above or by other means. >> > > OK, if it is already clear and agreed that we just want to address the > problem of RO between two PMIPv6 attached MNs, then I'm fine. The only > point to clarify would be then the use of the intended use of the > EnableMAGLocalRouting flag in RFC5213... > As I said, the PS currently covers cases according to the NetExt scope. Whether or not to add one or the other use case or CN type, that's something we need to work out, so that we can update the PS doc accordingly. If we stick to support of RO between two PMIPv6 attached nodes, fine, then we probably have to go only through some editorial revision. marco > Thanks! > > Carlos > > >> marco >> >> >>> Thanks, >>> >>> Carlos >>> >>> El jue, 05-02-2009 a las 15:33 +0100, Marco Liebsch escribi?: >>> >>> >>>> 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: cjbc at it.uc3m.es (Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano) Date: Wed, 11 Feb 2009 18:00:03 +0100 Subject: [Netext] First Problem Statement about Localized Routing in PMIPv6 submitted In-Reply-To: <49929954.4010500@nw.neclab.eu> References: <498AF8B1.1020303@nw.neclab.eu> <1234339777.21602.198.camel@localhost> <49929954.4010500@nw.neclab.eu> Message-ID: <1234371603.5174.26.camel@localhost> Hi Marco, El mi?, 11-02-2009 a las 10:24 +0100, Marco Liebsch escribi?: > Hi Carlos, > > thanks for the feedback! > Please find my view and answers to your comments below. > > Carlos Jes?s Bernardos Cano wrote: > > Hi Marco, all, > > > > I've just read your document. Thanks for writing it! > > > > I have some comments/questions: > > > > - Regarding EnableMAGLocalRouting flag: in addition to what has been > > already discussed in this list, I want to check whether my understanding > > of RFC5213 is right or not. As far as I understand it, the local routing > > mechanism that is slightly defined in PMIPv6 specs refers to the > > optimisation of data traffic between an MN and a regular IPv6 node (a > > node that is not getting network-based mobility service from the PMIPv6 > > domain) that are both connected to the same MAG. This is what I > > understand from reading sections 6.10.5 and 6.14, though IMHO this is > > not clearly specified in RFC5213. Is this correct or am I missing > > something? > > > Well, I think both is intrinsically supported (maybe without > intention), a PMIPv6-attached CN or an IPv6 CN, that uses the > network component, which implements the MAG, as AR. In the > first case, the MAG has a BUL entry and an associated route > entry for the CN, in the latter case, the AR has a route > entry for the CN. So prefix routing should work in both cases. > The only thing you need to take care in the IPv6 case is that > the MAG allows deviations from a default route for the MN's > traffic, which should not go through the LMA then, but should be > forwarded according to the local routing table. However, all these > things are not described in RFC5213, for good reasons, as this > was not the focus. Yes, I agree both cases are not so different, but there are still differences. I'm not sure RFC5214 intrinsically supports both, since there are explicit references to "IPv6..." Besides the IPv6 address of a regular IPv6 host (IPv6 CN, as you called it) is anchored at the MAG, while the IPv6 prefix used by a PMIPv6 MN is anchored at the LMA, so there might be some subtle differences. > > - If my previous understanding is correct, then RFC5213 does not only > > define any mechanism to perform local routing between two MNs connected > > to the same PMIPv6 domain (not even for the case in which both are > > attached to the same MAG). Then, IMHO it would be better to change the > > terminology in the PS and avoid using CN or coming up with different > > terms for a CN that is getting network-based mobility service from a CN > > that is not (i.e. it is just a regular IPv6 node getting access from a > > MAG). > > > Ok, the idea was the following: MN and CN have been chosen to > distinguish the two mobile nodes. Now, as we thought about more > use cases before, such as for example setting up RO between a > PMIPv6 attached MN and a MIPv6 CN, the intention was to keep > MN and CN as terms, but to refer to a specific use case in addition. > So, if there is a discussion about a RO 'association' between an MN > and a CN, both are PMIPv6 attached, its for example a use case > according to A12. RO with a MIPv6 CN should be described as B > use cases (e.g. B12). We could introduce more uses cases to cover > RO with an IPv6 node, such as C2. Ummm, this is getting too complex. Maybe I didn't explain well in my previous e-mail. What I had in mind are two different scenarios: - PMIPv6 MNs: that is, MNs getting network-based mobility management - Regular IPv6 hosts (we can call them IPv6 CNs): that is, nodes locally attached to a MAG that don't benefit from a network-based mobility management (i.e., they configure their IPv6 address from a local "visited" prefix, not from a prefix managed by an LMA). I didn't add the third variable of MIPv6 CNs (i.e., nodes that support the CN functionality of MIPv6 RO). I'll leave that case out of the PS for the time being. > > Alternatively (or in addition) we could distinguish the mobile devices > by means of extensions (CN_IP6, CN_MIP6), but this does not cover > the use cases and all the variants of a particular use case yet. > More in this context below. OK, I see now. One thing is the scenario based on the attachment points of the end-points of the communication (MAGs) and the number of involved LMAs. A different thing is the type of node a PMIPv6 MN is communicating to (it may be a PMIPv6 MN, an IPv6 CN or a MIPv6 CN). > > - Currently, the PS only addresses the case of local routing between > > two MNs connected to the same PMIPv6 domain. I think the scenario of > > optimising traffic between an MN and a regular IPv6 host that is locally > > connected to a MAG should also be addressed. Not sure the implications > > on the potential solutions, but it might have an impact on the > > classification scheme that is used in the PS now (A[number of > > MAGs][number of LMAs]). > > > I don't see an issue here, as we can differentiate the mobility > mode (if there is any) of both nodes by means of the use case > (A,B,C,...). Since the IPv6 CN will not have a mobility anchor, > we should indicate only the amount of involved ARs/MAGs (such as C2). I don't want to bring a new issue. I just tried to point out that it might be good to highlight that the type of node is also important. I'm fine with adding a new variable on the use cases to reflect that. > > Ok, long story above. Fact is that the scope of the PS doc has been > cut to the current NetExt charter, which focuses in particular on RO > between two PMIPv6 attached MNs. Larger scope needs to be discussed > and agreed on. If we need more use cases, we could describe them as > proposed above or by other means. OK, if it is already clear and agreed that we just want to address the problem of RO between two PMIPv6 attached MNs, then I'm fine. The only point to clarify would be then the use of the intended use of the EnableMAGLocalRouting flag in RFC5213... Thanks! Carlos > > marco > > > Thanks, > > > > Carlos > > > > El jue, 05-02-2009 a las 15:33 +0100, Marco Liebsch escribi?: > > > >> 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 > >> > -- 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: cjbc at it.uc3m.es (Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano) Date: Wed, 11 Feb 2009 17:45:15 +0100 Subject: [Netext] First Problem Statement about Localized Routingin PMIPv6 submitted In-Reply-To: <4D35478224365146822AE9E3AD4A266606815C67@exchtewks3.starentnetworks.com> References: <4D35478224365146822AE9E3AD4A266606815C67@exchtewks3.starentnetworks.com> Message-ID: <1234370715.5174.9.camel@localhost> Hi Rajeev, El mi?, 11-02-2009 a las 09:47 -0500, Koodli, Rajeev escribi?: > Hi Carlos, > > > > - Regarding EnableMAGLocalRouting flag: in addition to > > what has been already discussed in this list, I want to check > > whether my understanding of RFC5213 is right or not. As far > > as I understand it, the local routing mechanism that is > > slightly defined in PMIPv6 specs refers to the optimisation > > of data traffic between an MN and a regular IPv6 node (a node > > that is not getting network-based mobility service from the PMIPv6 > > domain) that are both connected to the same MAG. This is what > > I understand from reading sections 6.10.5 and 6.14, though > > IMHO this is not clearly specified in RFC5213. Is this > > correct or am I missing something? > > What does it mean to say it is not getting network-based mobility support? > Isn't the whole point of PMIP to make mobility transparent to the MN? I fully agree that the whole point of PMIP is make mobility management transparent to the MN. However, as far as I understand from my reading of RFC5213, a mobile node attached to a PMIPv6 domain might not be entitled to the network-based mobility management service, and RFC5213 (section 6.14) still support this node to get connectivity (regular access) from the MAG. Related to this, it is also my interpretation of RFC5213 (section 6.10.5) that the local routing support provided by the basic spec (controlled with the EnableMAGLocalRouting flag) only applies to communications between a PMIPv6 MN and a regular IPv6 host attached to the same MAG. This is just to try to clarify what RFC5213 provides (actually, very little) and what does not in regards to local routing support. Do you see my point? Thanks! Carlos > > > > > > - If my previous understanding is correct, then RFC5213 > > does not only define any mechanism to perform local routing > > between two MNs connected to the same PMIPv6 domain (not even > > for the case in which both are attached to the same MAG). > > Then, IMHO it would be better to change the terminology in > > the PS and avoid using CN or coming up with different terms > > for a CN that is getting network-based mobility service from > > a CN that is not (i.e. it is just a regular IPv6 node getting > > access from a MAG). > > See above. > > > > > - Currently, the PS only addresses the case of local > > routing between two MNs connected to the same PMIPv6 domain. > > I think the scenario of optimising traffic between an MN and > > a regular IPv6 host that is locally connected to a MAG should > > also be addressed. Not sure the implications on the potential > > solutions, but it might have an impact on the classification > > scheme that is used in the PS now (A[number of MAGs][number of LMAs]). > > > > Our focus should be on solving the problem for nodes attached to a PMIP6 domain. > > Thanks, > > -Rajeev > > > > Thanks, > > > > Carlos > > > > El jue, 05-02-2009 a las 15:33 +0100, Marco Liebsch escribi?: > > > 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-0 > > > 0.txt > > > > > > Best regards, > > > marco > > > > > > > > > _______________________________________________ > > > 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/ > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > > > > 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. -- 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: rkoodli at starentnetworks.com (Koodli, Rajeev) Date: Wed, 11 Feb 2009 09:47:07 -0500 Subject: [Netext] First Problem Statement about Localized Routingin PMIPv6 submitted In-Reply-To: <1234339777.21602.198.camel@localhost> Message-ID: <4D35478224365146822AE9E3AD4A266606815C67@exchtewks3.starentnetworks.com> Hi Carlos, > - Regarding EnableMAGLocalRouting flag: in addition to > what has been already discussed in this list, I want to check > whether my understanding of RFC5213 is right or not. As far > as I understand it, the local routing mechanism that is > slightly defined in PMIPv6 specs refers to the optimisation > of data traffic between an MN and a regular IPv6 node (a node > that is not getting network-based mobility service from the PMIPv6 > domain) that are both connected to the same MAG. This is what > I understand from reading sections 6.10.5 and 6.14, though > IMHO this is not clearly specified in RFC5213. Is this > correct or am I missing something? What does it mean to say it is not getting network-based mobility support? Isn't the whole point of PMIP to make mobility transparent to the MN? > > - If my previous understanding is correct, then RFC5213 > does not only define any mechanism to perform local routing > between two MNs connected to the same PMIPv6 domain (not even > for the case in which both are attached to the same MAG). > Then, IMHO it would be better to change the terminology in > the PS and avoid using CN or coming up with different terms > for a CN that is getting network-based mobility service from > a CN that is not (i.e. it is just a regular IPv6 node getting > access from a MAG). See above. > > - Currently, the PS only addresses the case of local > routing between two MNs connected to the same PMIPv6 domain. > I think the scenario of optimising traffic between an MN and > a regular IPv6 host that is locally connected to a MAG should > also be addressed. Not sure the implications on the potential > solutions, but it might have an impact on the classification > scheme that is used in the PS now (A[number of MAGs][number of LMAs]). > Our focus should be on solving the problem for nodes attached to a PMIP6 domain. Thanks, -Rajeev > Thanks, > > Carlos > > El jue, 05-02-2009 a las 15:33 +0100, Marco Liebsch escribi?: > > 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-0 > > 0.txt > > > > Best regards, > > marco > > > > > > _______________________________________________ > > 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/ > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > 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. From: liebsch at nw.neclab.eu (Marco Liebsch) Date: Wed, 11 Feb 2009 15:39:29 +0100 Subject: [Netext] First Problem Statement about Localized Routing in PMIPv6 submitted In-Reply-To: <499170FC.7030101@research.telcordia.com> References: <498AF8B1.1020303@nw.neclab.eu> <498FC352.60803@research.telcordia.com> <498FF628.4080101@nw.neclab.eu> <499170FC.7030101@research.telcordia.com> Message-ID: <4992E321.7090701@nw.neclab.eu> Ashutosh Dutta wrote: > Marco, nothing much, do you think putting a word such as "However" > before the third sentence will make the abstract little bit more clear > in terms of what this document is trying to address? Well, not really. But if folks want it, I can add it. marco > > Regards > Ashutosh > > Marco Liebsch wrote: >> Hi Ashutosh, >> >> Ashutosh Dutta schrieb: >>> Marco, >>> Is it possible to make the abstract little bit clear? The >>> third sentence refers to the fact that localized routing is not >>> considered in RFC5213, right? >> Sure, it's possible. But I don't see the point point where the >> abstract is not clear. >> Do you think the abstract should say that RFC5213 considers the >> EnableMAGLocalRouting >> flag, but does not provide a full specification for localized >> routing? I prefer to keep the >> abstract concise and the message clear. Details about what is >> supported by the base PMIP >> spec, where are the limitations and where are open issues, I think >> this is something >> the document core should describe rather than the abstract. >> >> But if you have a specific proposal how to make the abstract clearer, >> just let me know. >> >> Best regards, >> marco >> >>> >>> I will look at the rest. >>> >>> Thanks >>> Ashutosh >>> >>> 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: liebsch at nw.neclab.eu (Marco Liebsch) Date: Wed, 11 Feb 2009 10:24:36 +0100 Subject: [Netext] First Problem Statement about Localized Routing in PMIPv6 submitted In-Reply-To: <1234339777.21602.198.camel@localhost> References: <498AF8B1.1020303@nw.neclab.eu> <1234339777.21602.198.camel@localhost> Message-ID: <49929954.4010500@nw.neclab.eu> Hi Carlos, thanks for the feedback! Please find my view and answers to your comments below. Carlos Jes?s Bernardos Cano wrote: > Hi Marco, all, > > I've just read your document. Thanks for writing it! > > I have some comments/questions: > > - Regarding EnableMAGLocalRouting flag: in addition to what has been > already discussed in this list, I want to check whether my understanding > of RFC5213 is right or not. As far as I understand it, the local routing > mechanism that is slightly defined in PMIPv6 specs refers to the > optimisation of data traffic between an MN and a regular IPv6 node (a > node that is not getting network-based mobility service from the PMIPv6 > domain) that are both connected to the same MAG. This is what I > understand from reading sections 6.10.5 and 6.14, though IMHO this is > not clearly specified in RFC5213. Is this correct or am I missing > something? > Well, I think both is intrinsically supported (maybe without intention), a PMIPv6-attached CN or an IPv6 CN, that uses the network component, which implements the MAG, as AR. In the first case, the MAG has a BUL entry and an associated route entry for the CN, in the latter case, the AR has a route entry for the CN. So prefix routing should work in both cases. The only thing you need to take care in the IPv6 case is that the MAG allows deviations from a default route for the MN's traffic, which should not go through the LMA then, but should be forwarded according to the local routing table. However, all these things are not described in RFC5213, for good reasons, as this was not the focus. > - If my previous understanding is correct, then RFC5213 does not only > define any mechanism to perform local routing between two MNs connected > to the same PMIPv6 domain (not even for the case in which both are > attached to the same MAG). Then, IMHO it would be better to change the > terminology in the PS and avoid using CN or coming up with different > terms for a CN that is getting network-based mobility service from a CN > that is not (i.e. it is just a regular IPv6 node getting access from a > MAG). > Ok, the idea was the following: MN and CN have been chosen to distinguish the two mobile nodes. Now, as we thought about more use cases before, such as for example setting up RO between a PMIPv6 attached MN and a MIPv6 CN, the intention was to keep MN and CN as terms, but to refer to a specific use case in addition. So, if there is a discussion about a RO 'association' between an MN and a CN, both are PMIPv6 attached, its for example a use case according to A12. RO with a MIPv6 CN should be described as B use cases (e.g. B12). We could introduce more uses cases to cover RO with an IPv6 node, such as C2. Alternatively (or in addition) we could distinguish the mobile devices by means of extensions (CN_IP6, CN_MIP6), but this does not cover the use cases and all the variants of a particular use case yet. More in this context below. > - Currently, the PS only addresses the case of local routing between > two MNs connected to the same PMIPv6 domain. I think the scenario of > optimising traffic between an MN and a regular IPv6 host that is locally > connected to a MAG should also be addressed. Not sure the implications > on the potential solutions, but it might have an impact on the > classification scheme that is used in the PS now (A[number of > MAGs][number of LMAs]). > I don't see an issue here, as we can differentiate the mobility mode (if there is any) of both nodes by means of the use case (A,B,C,...). Since the IPv6 CN will not have a mobility anchor, we should indicate only the amount of involved ARs/MAGs (such as C2). Ok, long story above. Fact is that the scope of the PS doc has been cut to the current NetExt charter, which focuses in particular on RO between two PMIPv6 attached MNs. Larger scope needs to be discussed and agreed on. If we need more use cases, we could describe them as proposed above or by other means. marco > Thanks, > > Carlos > > El jue, 05-02-2009 a las 15:33 +0100, Marco Liebsch escribi?: > >> 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: cjbc at it.uc3m.es (Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano) Date: Wed, 11 Feb 2009 09:09:37 +0100 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: <1234339777.21602.198.camel@localhost> Hi Marco, all, I've just read your document. Thanks for writing it! I have some comments/questions: - Regarding EnableMAGLocalRouting flag: in addition to what has been already discussed in this list, I want to check whether my understanding of RFC5213 is right or not. As far as I understand it, the local routing mechanism that is slightly defined in PMIPv6 specs refers to the optimisation of data traffic between an MN and a regular IPv6 node (a node that is not getting network-based mobility service from the PMIPv6 domain) that are both connected to the same MAG. This is what I understand from reading sections 6.10.5 and 6.14, though IMHO this is not clearly specified in RFC5213. Is this correct or am I missing something? - If my previous understanding is correct, then RFC5213 does not only define any mechanism to perform local routing between two MNs connected to the same PMIPv6 domain (not even for the case in which both are attached to the same MAG). Then, IMHO it would be better to change the terminology in the PS and avoid using CN or coming up with different terms for a CN that is getting network-based mobility service from a CN that is not (i.e. it is just a regular IPv6 node getting access from a MAG). - Currently, the PS only addresses the case of local routing between two MNs connected to the same PMIPv6 domain. I think the scenario of optimising traffic between an MN and a regular IPv6 host that is locally connected to a MAG should also be addressed. Not sure the implications on the potential solutions, but it might have an impact on the classification scheme that is used in the PS now (A[number of MAGs][number of LMAs]). Thanks, Carlos El jue, 05-02-2009 a las 15:33 +0100, Marco Liebsch escribi?: > 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 -- 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: jari.arkko at piuha.net (Jari Arkko) Date: Tue, 10 Feb 2009 15:05:06 +0200 Subject: [Netext] BOF situation In-Reply-To: References: Message-ID: <49917B82.7000006@piuha.net> Basavaraj, > We are trying to limit the MN involvement in any of the enhancements that > are in the scope of Netext. However we would like to at least not be bounded > by the kind of mandate that Netlmm has (i.e no changes to host). Effort > should be to develop solutions which does not require any host involvement. > However if the WG feels that there is no alternative to solving a problem or > if the preferred approach would be to involve the MN, then I do think that > Netext should have the liberty to proceed with such a design. > > But we recognize the challenges of developing any solution which involve the > host, given the installed base. And will resist the need to involve the host > if you believe this will be controversial (are you implying that this is > controversial from the point of any such approaches being no different from > host based Mobile IP? Or something else?). > My main concerns personally were (a) the effects to deploying this when host changes are needed, and (b) the argument that I foresee about proxy vs. client mobility. How about this: you figure out what exactly can and cannot be done without host changes, and then we can have a more sensible discussion? For the BOF, I would recommend trying to get at least the non-host-changing parts agreed. Jari From: adutta at research.telcordia.com (Ashutosh Dutta) Date: Tue, 10 Feb 2009 07:20:12 -0500 Subject: [Netext] First Problem Statement about Localized Routing in PMIPv6 submitted In-Reply-To: <498FF628.4080101@nw.neclab.eu> References: <498AF8B1.1020303@nw.neclab.eu> <498FC352.60803@research.telcordia.com> <498FF628.4080101@nw.neclab.eu> Message-ID: <499170FC.7030101@research.telcordia.com> Marco, nothing much, do you think putting a word such as "However" before the third sentence will make the abstract little bit more clear in terms of what this document is trying to address? Regards Ashutosh Marco Liebsch wrote: > Hi Ashutosh, > > Ashutosh Dutta schrieb: >> Marco, >> Is it possible to make the abstract little bit clear? The third >> sentence refers to the fact that localized routing is not considered >> in RFC5213, right? > Sure, it's possible. But I don't see the point point where the abstract > is not clear. > Do you think the abstract should say that RFC5213 considers the > EnableMAGLocalRouting > flag, but does not provide a full specification for localized routing? I > prefer to keep the > abstract concise and the message clear. Details about what is supported > by the base PMIP > spec, where are the limitations and where are open issues, I think this > is something > the document core should describe rather than the abstract. > > But if you have a specific proposal how to make the abstract clearer, > just let me know. > > Best regards, > marco > >> >> I will look at the rest. >> >> Thanks >> Ashutosh >> >> 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: suresh.krishnan at ericsson.com (Suresh Krishnan) Date: Mon, 09 Feb 2009 17:27:58 -0500 Subject: [Netext] Inter-technology handover PS Message-ID: <4990ADEE.8060506@ericsson.com> Hi Folks, We have submitted the initial version of the problem statement draft describing issues with network based inter-technology handovers. Please send us any comments or issues that you may have on the document. Thanks Suresh -------- Original Message -------- Subject: I-D Action:draft-krishnan-netext-intertech-ps-00.txt Date: Mon, 9 Feb 2009 14:15:01 -0800 (PST) From: Internet-Drafts at ietf.org Reply-To: internet-drafts at ietf.org To: i-d-announce at ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Issues with network based inter-technology handovers Author(s) : S. Krishnan, et al. Filename : draft-krishnan-netext-intertech-ps-00.txt Pages : 9 Date : 2009-02-09 Proxy Mobile IPv6 (PMIPv6) is a network based mobility management protocol enables IP mobility for a host without requiring its participation in any mobility-related signaling. While the PMIPv6 protocol itself supports handover across interfaces and between access types, there are several issues with effectively performing inter-technology handovers with network based mobility protocols. This document aims to enumerate some known issues with such handovers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-krishnan-netext-intertech-ps-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. From: Basavaraj.Patil at nokia.com (Basavaraj.Patil at nokia.com) Date: Mon, 9 Feb 2009 21:10:11 +0100 Subject: [Netext] BOF situation In-Reply-To: <49900D6A.4090306@piuha.net> Message-ID: Hi Jari, Thanks for approving the BoF. We are trying to limit the MN involvement in any of the enhancements that are in the scope of Netext. However we would like to at least not be bounded by the kind of mandate that Netlmm has (i.e no changes to host). Effort should be to develop solutions which does not require any host involvement. However if the WG feels that there is no alternative to solving a problem or if the preferred approach would be to involve the MN, then I do think that Netext should have the liberty to proceed with such a design. But we recognize the challenges of developing any solution which involve the host, given the installed base. And will resist the need to involve the host if you believe this will be controversial (are you implying that this is controversial from the point of any such approaches being no different from host based Mobile IP? Or something else?). -Raj On 2/9/09 5:03 AM, "ext Jari Arkko" wrote: > Hi all, > > I have approved the BOF request. > > However, one worry that has come up relates to the architectural > direction. Some of the work items relate to the involvement of the > mobile host. This is a deviation from the original concept of proxy > mobility and the current protocols -- which work or at least fail safely > even if the host is unaware that proxy mobility is happening on an > interface. The ability to work with the very slowly changing installed > base of hosts (laptops attached to a cellular modem etc) suggests that > it would be useful to employ mechanisms that have no such requirements. > Also, requiring further host involvement is likely going to be > controversial. > > Based on this, I would like the group to spend the next few weeks > talking about whether its work can be scoped down to optimizations and > enhancements that do NOT require additional host involvement. > > Jari > > _______________________________________________ > NetExt mailing list > NetExt at mail.mobileip.jp > http://www.mobileip.jp/mailman/listinfo/netext > From: jouni.nospam at gmail.com (jouni korhonen) Date: Mon, 9 Feb 2009 14:43:11 +0200 Subject: [Netext] Fwd: New Version Notification for draft-korhonen-netext-redirect-ps-00 References: <20090209123000.C36CD3A6BAF@core3.amsl.com> Message-ID: <076BDB7F-4E02-4EF5-B4EA-0EBA8E9083C9@gmail.com> Hi All, I wrote a small discussion paper on PMIPv6 redirection functionality. The aim is to come up with a good redirection support for the base protocol. Obvious use cases are load balancing, signaling reduction within a PMIPv6 Domain and eventually reduced latencies during mobility session setup. The problem area falls under the improvements and/or deployment considerations in the current proposed charter. The I-D can be found here: http://www.ietf.org/internet-drafts/draft-korhonen-netext-redirect-ps-00.txt Comments are welcome! Cheers, Jouni Begin forwarded message: > From: IETF I-D Submission Tool > Date: February 9, 2009 2:30:00 PM GMT+02:00 > To: jouni.nospam at gmail.com > Subject: New Version Notification for draft-korhonen-netext- > redirect-ps-00 > > > A new version of I-D, draft-korhonen-netext-redirect-ps-00.txt has > been successfuly submitted by Jouni Korhonen and posted to the IETF > repository. > > Filename: draft-korhonen-netext-redirect-ps > Revision: 00 > Title: Proxy Mobile IPv6 Mobility Session Redirection Problem > Statement > Creation_date: 2009-02-09 > WG ID: Independent Submission > Number_of_pages: 7 > > Abstract: > This document discusses a Proxy Mobile IPv6 mobility session > redirection functionality at the Proxy Mobile IPv6 base protocol > level. The redirection functionality would allow a Local Mobility > Anchor to redirect the Mobile Access Gateway during the Proxy Binding > Update and Acknowledgement exchange to an alternative Local Mobility > Anchor. The benefit of redirection at the protocol level is that it > removes the dependence on having such functionality provided by the > Authentication, Authorization and, Accounting elements or the Domain > Name System in a Proxy Mobile IPv6 Domain. Furthermore, doing the > redirection at the base protocol level reduces the amount of > signaling, unnecessary costly setup of mobility sessions and > unnecessary costly interactions with backend systems. > > > > The IETF Secretariat. > > From: jari.arkko at piuha.net (Jari Arkko) Date: Mon, 09 Feb 2009 13:03:06 +0200 Subject: [Netext] BOF situation Message-ID: <49900D6A.4090306@piuha.net> Hi all, I have approved the BOF request. However, one worry that has come up relates to the architectural direction. Some of the work items relate to the involvement of the mobile host. This is a deviation from the original concept of proxy mobility and the current protocols -- which work or at least fail safely even if the host is unaware that proxy mobility is happening on an interface. The ability to work with the very slowly changing installed base of hosts (laptops attached to a cellular modem etc) suggests that it would be useful to employ mechanisms that have no such requirements. Also, requiring further host involvement is likely going to be controversial. Based on this, I would like the group to spend the next few weeks talking about whether its work can be scoped down to optimizations and enhancements that do NOT require additional host involvement. Jari From: yokota at kddilabs.jp (Hidetoshi Yokota) Date: Mon, 09 Feb 2009 19:50:10 +0900 Subject: [Netext] First Problem Statement about Localized Routing in PMIPv6 submitted In-Reply-To: <4D35478224365146822AE9E3AD4A26660666D09D@exchtewks3.starentnetworks.com> References: <4D35478224365146822AE9E3AD4A26660666D09D@exchtewks3.starentnetworks.com> Message-ID: <49900A62.2090709@kddilabs.jp> Hi Marco and Rajeev, Koodli, Rajeev wrote: > Hi, > > >>> But, has there been a established way to do that already? >> If the LMA >>> enforces it, can it be done by the PBU? It seems to be in >> the opposite >>> direction. >>> >> Yes, very good point. RFC5213 sais that localized routing on >> a MAG should be based on the MAG's policy but enforced by the >> LMA. The statement about the indication in the PBU should be >> taken out from the PS, in particular since the >> EnableMAGLocalRouting flag is a configuration flag, not a >> protocol message flag. This paragraph is simply to refer to >> existing mechanisms for local routing, whereas I think the >> text in RFC5213 is more a guideline, not a protocol solution >> (of course only the text about localized routing..). >> So, regarding your question: >> No, there is no established way yet to do this. And we cannot >> assume a CN remains always attached to the same MAG as the >> MN. If it hands over to a different MAG, we need a common >> solution to handle this also in a larger scope. Hence,I am >> not sure about the role of the EnableMAGLocalRouting flag in >> the NetExt solution for localized routing. > > I would also just treat the flag as a reference to what exists today. > We need a protocol for localized routing. I agree. >>> I thinks it should also include the "termination" of the path like: >>> >>> "o Control in setting up, maintaining (e.g. during handover) and >>> termination the localized routing path." >>> >> Maybe we can go even one step further and add 'termination' >> of a localized routing path to a separate bullet, as this >> function may be performed by a different network component >> than the controlling function. What do you think? > > I think the proposal to simply add "termination" as in the above bullet > sounds good. > I don't think that we need to consider entities other than MAG and LMA > for the protocol. > It is possible that the trigger may arrive from other nodes, but those > are outside the scope of the protocol we are interested here. The reason why I pointed it out is that the clean-up of the old localized routing path does not happen automatically. It should be well defined as the protocol specification. The functional entity could reside in the MAG, LMA or both or another node. It will be ok without mentioning it in the PS. We will figure it out in the course of solution discussions (I honestly don't have a specific solution in mind). Regards, -- Hidetoshi > -Rajeev > > > >>> Other than the above, the document is very well written. >>> >> Thanks, >> marco >> >> >>> Regards, >>> >> >> _______________________________________________ >> 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 > > > From: marco.liebsch at nw.neclab.eu (Marco Liebsch) Date: Mon, 09 Feb 2009 10:23:52 +0100 Subject: [Netext] First Problem Statement about Localized Routing in PMIPv6 submitted In-Reply-To: <498FC352.60803@research.telcordia.com> References: <498AF8B1.1020303@nw.neclab.eu> <498FC352.60803@research.telcordia.com> Message-ID: <498FF628.4080101@nw.neclab.eu> Hi Ashutosh, Ashutosh Dutta schrieb: > Marco, > Is it possible to make the abstract little bit clear? The third > sentence refers to the fact that localized routing is not considered > in RFC5213, right? Sure, it's possible. But I don't see the point point where the abstract is not clear. Do you think the abstract should say that RFC5213 considers the EnableMAGLocalRouting flag, but does not provide a full specification for localized routing? I prefer to keep the abstract concise and the message clear. Details about what is supported by the base PMIP spec, where are the limitations and where are open issues, I think this is something the document core should describe rather than the abstract. But if you have a specific proposal how to make the abstract clearer, just let me know. Best regards, marco > > I will look at the rest. > > Thanks > Ashutosh > > 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: marco.liebsch at nw.neclab.eu (Marco Liebsch) Date: Mon, 09 Feb 2009 10:16:19 +0100 Subject: [Netext] First Problem Statement about Localized Routing in PMIPv6 submitted In-Reply-To: <4D35478224365146822AE9E3AD4A26660666D09D@exchtewks3.starentnetworks.com> References: <4D35478224365146822AE9E3AD4A26660666D09D@exchtewks3.starentnetworks.com> Message-ID: <498FF463.2020704@nw.neclab.eu> Hi Rajeev, please see my comments in-line. Koodli, Rajeev schrieb: > Hi, > > > >>> But, has there been a established way to do that already? >>> >> If the LMA >> >>> enforces it, can it be done by the PBU? It seems to be in >>> >> the opposite >> >>> direction. >>> >>> >> Yes, very good point. RFC5213 sais that localized routing on >> a MAG should be based on the MAG's policy but enforced by the >> LMA. The statement about the indication in the PBU should be >> taken out from the PS, in particular since the >> EnableMAGLocalRouting flag is a configuration flag, not a >> protocol message flag. This paragraph is simply to refer to >> existing mechanisms for local routing, whereas I think the >> text in RFC5213 is more a guideline, not a protocol solution >> (of course only the text about localized routing..). >> So, regarding your question: >> No, there is no established way yet to do this. And we cannot >> assume a CN remains always attached to the same MAG as the >> MN. If it hands over to a different MAG, we need a common >> solution to handle this also in a larger scope. Hence,I am >> not sure about the role of the EnableMAGLocalRouting flag in >> the NetExt solution for localized routing. >> > > I would also just treat the flag as a reference to what exists today. > We need a protocol for localized routing. > > > >>> I thinks it should also include the "termination" of the path like: >>> >>> "o Control in setting up, maintaining (e.g. during handover) and >>> termination the localized routing path." >>> >>> >> Maybe we can go even one step further and add 'termination' >> of a localized routing path to a separate bullet, as this >> function may be performed by a different network component >> than the controlling function. What do you think? >> > > I think the proposal to simply add "termination" as in the above bullet > sounds good. > I don't think that we need to consider entities other than MAG and LMA > for the protocol. > That's actually not what I meant. I still considered PMIP functional entities. In an A22 scenario, there are 4 entities involved, 2 LMAs and 2 MAGs. I simply meant that signaling for termination of RO states may be initiated by an entity, which is different from the entity that controls the setup. But I am ok with incorporating the termination aspect into the existing bullet as proposed by Hidetoshi. > It is possible that the trigger may arrive from other nodes, but those > are outside the scope of the protocol we are interested here. > Agree, that the trigger may come from non-PMIP entities. Still I think the PMIP RO protocol we'll specify needs to signal termination of RO states, even though the trigger comes from outside. Will add this to the action list and see for further comments. Thanks, marco > -Rajeev > > > > >>> Other than the above, the document is very well written. >>> >>> >> Thanks, >> marco >> >> >> >>> Regards, >>> >>> >> _______________________________________________ >> 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 > From: adutta at research.telcordia.com (Ashutosh Dutta) Date: Mon, 09 Feb 2009 00:46:58 -0500 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: <498FC352.60803@research.telcordia.com> Marco, Is it possible to make the abstract little bit clear? The third sentence refers to the fact that localized routing is not considered in RFC5213, right? I will look at the rest. Thanks Ashutosh 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: rkoodli at starentnetworks.com (Koodli, Rajeev) Date: Fri, 6 Feb 2009 14:22:44 -0500 Subject: [Netext] First Problem Statement about Localized Routing in PMIPv6 submitted In-Reply-To: <498C0399.1030903@nw.neclab.eu> Message-ID: <4D35478224365146822AE9E3AD4A26660666D09D@exchtewks3.starentnetworks.com> Hi, > > But, has there been a established way to do that already? > If the LMA > > enforces it, can it be done by the PBU? It seems to be in > the opposite > > direction. > > > Yes, very good point. RFC5213 sais that localized routing on > a MAG should be based on the MAG's policy but enforced by the > LMA. The statement about the indication in the PBU should be > taken out from the PS, in particular since the > EnableMAGLocalRouting flag is a configuration flag, not a > protocol message flag. This paragraph is simply to refer to > existing mechanisms for local routing, whereas I think the > text in RFC5213 is more a guideline, not a protocol solution > (of course only the text about localized routing..). > So, regarding your question: > No, there is no established way yet to do this. And we cannot > assume a CN remains always attached to the same MAG as the > MN. If it hands over to a different MAG, we need a common > solution to handle this also in a larger scope. Hence,I am > not sure about the role of the EnableMAGLocalRouting flag in > the NetExt solution for localized routing. I would also just treat the flag as a reference to what exists today. We need a protocol for localized routing. > > I thinks it should also include the "termination" of the path like: > > > > "o Control in setting up, maintaining (e.g. during handover) and > > termination the localized routing path." > > > Maybe we can go even one step further and add 'termination' > of a localized routing path to a separate bullet, as this > function may be performed by a different network component > than the controlling function. What do you think? I think the proposal to simply add "termination" as in the above bullet sounds good. I don't think that we need to consider entities other than MAG and LMA for the protocol. It is possible that the trigger may arrive from other nodes, but those are outside the scope of the protocol we are interested here. -Rajeev > > Other than the above, the document is very well written. > > > Thanks, > marco > > > > Regards, > > > > > _______________________________________________ > 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. From: marco.liebsch at nw.neclab.eu (Marco Liebsch) Date: Fri, 06 Feb 2009 10:32:09 +0100 Subject: [Netext] First Problem Statement about Localized Routing in PMIPv6 submitted In-Reply-To: <498BEE75.20003@kddilabs.jp> References: <498AF8B1.1020303@nw.neclab.eu> <498BEE75.20003@kddilabs.jp> Message-ID: <498C0399.1030903@nw.neclab.eu> Hi Hidetoshi, thanks for your comments. Please find my answers below. Hidetoshi Yokota schrieb: > Hi Marco, > > Thanks for creating the PS for localized routing, which I think covers > enough scenarios and problem space. I have one small question and comment: > > [Q] On p.6, The paragraph of the use case for A11 has: > > "According to [RFC5213], such operation should be enforced by the LMA > and signaled in the PBU by means of the EnableMAGLocalRouting flag." > > But, has there been a established way to do that already? If the LMA > enforces it, can it be done by the PBU? It seems to be in the opposite > direction. > Yes, very good point. RFC5213 sais that localized routing on a MAG should be based on the MAG's policy but enforced by the LMA. The statement about the indication in the PBU should be taken out from the PS, in particular since the EnableMAGLocalRouting flag is a configuration flag, not a protocol message flag. This paragraph is simply to refer to existing mechanisms for local routing, whereas I think the text in RFC5213 is more a guideline, not a protocol solution (of course only the text about localized routing..). So, regarding your question: No, there is no established way yet to do this. And we cannot assume a CN remains always attached to the same MAG as the MN. If it hands over to a different MAG, we need a common solution to handle this also in a larger scope. Hence,I am not sure about the role of the EnableMAGLocalRouting flag in the NetExt solution for localized routing. > [C] In the last bullet of the key functions on p.6: > > "o Control in setting up and maintaining (e.g. during handover) the > localized routing path." > > I thinks it should also include the "termination" of the path like: > > "o Control in setting up, maintaining (e.g. during handover) and > termination the localized routing path." > Maybe we can go even one step further and add 'termination' of a localized routing path to a separate bullet, as this function may be performed by a different network component than the controlling function. What do you think? > Other than the above, the document is very well written. > Thanks, marco > Regards, > From: yokota at kddilabs.jp (Hidetoshi Yokota) Date: Fri, 06 Feb 2009 17:01:57 +0900 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: <498BEE75.20003@kddilabs.jp> Hi Marco, Thanks for creating the PS for localized routing, which I think covers enough scenarios and problem space. I have one small question and comment: [Q] On p.6, The paragraph of the use case for A11 has: "According to [RFC5213], such operation should be enforced by the LMA and signaled in the PBU by means of the EnableMAGLocalRouting flag." But, has there been a established way to do that already? If the LMA enforces it, can it be done by the PBU? It seems to be in the opposite direction. [C] In the last bullet of the key functions on p.6: "o Control in setting up and maintaining (e.g. during handover) the localized routing path." I thinks it should also include the "termination" of the path like: "o Control in setting up, maintaining (e.g. during handover) and termination the localized routing path." Other than the above, the document is very well written. Regards, -- Hidetoshi 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: Mohana.Jeyatharan at sg.panasonic.com (Mohana Jeyatharan) Date: Fri, 6 Feb 2009 09:12:39 +0800 Subject: [Netext] Revised BoF charter In-Reply-To: Message-ID: <5F09D220B62F79418461A978CA0921BD03269F1D@pslexc01.psl.local> Hi Rajeev, Raj and All, I saw the updated charter items. Thanks so much for the updated charter goals and the reviews on the multihoming-PS-ID. When I was looking at multihoming in the revised charter I found these, and I want to be clear on this. a. improve the support for multiple IP mobility sessions via the same MAG simultaneously using a single access technology type, so that individual mobility sessions can be instantiated dynamically [Mohana] This Ok, understand one may need mobility sessions setup dynamically for multiple home network prefixes at different times. Looks very much tied to 3GPP and I agree that it is important work. b. support for selectively sharing Home Network Prefixes across access technology types so that, for instance, packet streams belonging to the same HNP could traverse different MAGs [Mohana] This is more of the multihoming (as in multihoming PS ID) such as simultaneous usage of same prefix via both interfaces. Or flows associated with a prefix to traverse via particular interface like flow based routing. c. Support for multiple IP mobility sessions for an MN attached via different interfaces (access technologies) but thru a single MAG (special case of a. and b.) [Mohana] This is a combination of a and b, but the scenario is different. [Mohana]I have just two more questions to Rajeev and Raj: Why partial handoff of prefixes from one interface to a new interface is not considered. Is it because of the narrowed scope. I think this is also an extension to the current PMIPv6 protocol. Hope you can re-consider this. It is described in P-ID. It is an important scenario, because all the flows can be transferred to a new interface by such partial handoff. [Mohana]Also, the PMIPv6 and CMIPv6 interaction case is not considered. Again is it because of CMIPv6 interaction? It has to be considered by some group. NetExt may be the ideal. {PS} I saw the local routing PS. Will look into it as well. Thanks again. BR, Mohana -----Original Message----- From: netext-bounces at mail.mobileip.jp [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of Basavaraj.Patil at nokia.com Sent: Friday, February 06, 2009 7:34 AM To: netext at mail.mobileip.jp Subject: [Netext] Revised BoF charter Hello, The updated BoF charter has been posted. Please refer to the Netext BoF in the IETF tools wiki page: http://trac.tools.ietf.org/bof/trac/wiki/WikiStart -Basavaraj _______________________________________________ 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: Fri, 6 Feb 2009 00:34:27 +0100 Subject: [Netext] Revised BoF charter Message-ID: Hello, The updated BoF charter has been posted. Please refer to the Netext BoF in the IETF tools wiki page: http://trac.tools.ietf.org/bof/trac/wiki/WikiStart -Basavaraj From: Basavaraj.Patil at nokia.com (Basavaraj.Patil at nokia.com) Date: Thu, 5 Feb 2009 23:52:54 +0100 Subject: [Netext] Review of the Multihoming PS I-D In-Reply-To: <00b701c9873c$e355fa60$150ca40a@china.huawei.com> Message-ID: Comments inline: On 2/4/09 8:53 PM, "ext Yungui Wang" wrote: > Hello Raj, > > Propose below two scenarios which have been defined in CMIPv6 > to be considered in scope of multihoming as well. > 1, Flow binding and flow mobility Why do you believe flow binding and flow mobility need to be dealt with in the context of multihoming? At least IMO the flow binding/flow mobility aspects should be dealt with as a separate topic. I view the current scope of specifying multihoming as simply the capability to establish multiple IP mobility sessions either via the same interface or via multiple interfaces to an LMA. I guess aspects of flow mobility can be considered especially if we view the ability to move an HNP from one interface to another in the case of multihoming. > 2, Issues of Supported Home Network Prefix Models > In current PMIPv6 base, it is not allowed that one HNP traverses > multiple interfaces of MN. This limitation may defense > a mobility session (or part of mobility session) moves from one > interface to another to achieve load sharing, etc. Okay. Agree about the part where an HNP may be across interfaces. We should discusss the need for this further. > More details of this scenario (/issue) were illustrated in > ref.1 [draft-jeyatharan-netext-multihoming-ps-00.txt], and > ref.2 [draft-muhanna-netlmm-multihoming-support-00.txt], etc. > > Please see more comments inline... > > B.R. > Yungui > >> >> a. The multihoming work in Netext should address the limitations of >> RFC5213 >> w.r.t multihoming. The issue of having a single BCE for an MN >> identified by an MN-ID and attaching via multiple interfaces should >> be resolved. > > [Yungui] In my understanding, this scenario (and c.) has been covered by > PMIPv6 spec, Section 5.4. > " > 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. > " The point here is that the current PMIP6 spec says " Each mobility session should be managed under a separate Binding Cache entry and with its own lifetime". Why this limitation? The same BCE associated with an MN can be used to establish multiple IP sessions. This would be the enhancement. > >> >> b. The scenario where an MN is connected via a MAG to an LMA and the >> ability to establish multiple sessions via the same MAG. This is >> the case where the MN is attached via a specific access type and >> establishes multiple IP sessions via the MAG. >> > [Yungui] What's the difference from that multiple HNP for a given > interface managed as one mobility session? > " > 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. > > " Okay. > >> c. The scenario where an MN attaches via different interfaces which >> are of differing access technologies via MAG1 and MAG2 >> simultaneously. The MAG1/MAG2 entities are attached to the same >> LMA. >> > [Yungui] Please see the same comments as (a). > Fine. But with the caveat that you have a single BCE the MN in such a scenario. Thanks for your input. -Raj >> d. A combination of the scenarios in (b) and (c), i.e having multiple >> sessions via each access type while connected thru different MAGs >> simultaneously. >> >> Lets see if we can build some consensus around the scope of the >> problem. >> >> -Raj >> >> _______________________________________________ >> 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 Feb 2009 16:27:05 -0500 Subject: [Netext] Review of the Multihoming PS I-D In-Reply-To: <00b701c9873c$e355fa60$150ca40a@china.huawei.com> Message-ID: <4D35478224365146822AE9E3AD4A26660666C8CC@exchtewks3.starentnetworks.com> Hi Yungui, Good input. Please see some replies to your comments first. > -----Original Message----- > From: netext-bounces at mail.mobileip.jp > [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of Yungui Wang > Sent: Wednesday, February 04, 2009 6:53 PM > To: Basavaraj.Patil at nokia.com; netext at mail.mobileip.jp > Cc: gongxiaoyu; Basavaraj.Patil at nokia.com > Subject: Re: [Netext] Review of the Multihoming PS I-D > > Hello Raj, > > Propose below two scenarios which have been defined in CMIPv6 > to be considered in scope of multihoming as well. > 1, Flow binding and flow mobility > 2, Issues of Supported Home Network Prefix Models In current > PMIPv6 base, it is not allowed that one HNP traverses > multiple interfaces of MN. This limitation may defense a > mobility session (or part of mobility session) moves from one > interface to another to achieve load sharing, etc. > More details of this scenario (/issue) were illustrated in > ref.1 [draft-jeyatharan-netext-multihoming-ps-00.txt], and > ref.2 [draft-muhanna-netlmm-multihoming-support-00.txt], etc. > > Please see more comments inline... > > B.R. > Yungui > > > > > a. The multihoming work in Netext should address the limitations of > > RFC5213 > > w.r.t multihoming. The issue of having a single BCE for an MN > > identified by an MN-ID and attaching via multiple > interfaces should > > be resolved. > > [Yungui] In my understanding, this scenario (and c.) has been > covered by > PMIPv6 spec, Section 5.4. > " > 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. > " Okay. > > > > > b. The scenario where an MN is connected via a MAG to an LMA and the > > ability to establish multiple sessions via the same MAG. This is > > the case where the MN is attached via a specific access type and > > establishes multiple IP sessions via the MAG. > > > [Yungui] What's the difference from that multiple HNP for a > given interface managed as one mobility session? > 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. > > " > Each mobility session may be instantiated dynamically at any time, and not necessarily as a request for multiple HNPs within a single PBU. Besides, why is there a requirement to manage multiple HNPs as part of the same mobility session? A deployment may want to treat each mobility session independently for a variety of reasons (e.g., QoS, Policy, charging etc.). > > c. The scenario where an MN attaches via different interfaces which > > are of differing access technologies via MAG1 and MAG2 > > simultaneously. The MAG1/MAG2 entities are attached to the same > > LMA. > > > [Yungui] Please see the same comments as (a). This needs to be drawn out further. Here, we should be able to support the same HNP across MAG1 and MAG2. I think this is referring to your item 2) above. What do you mean by Flow binding here? Regards, -Rajeev > > > d. A combination of the scenarios in (b) and (c), i.e > having multiple > > sessions via each access type while connected thru different MAGs > > simultaneously. > > > > Lets see if we can build some consensus around the scope of the > > problem. > > > > -Raj > > > > _______________________________________________ > > 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 > 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. From: rkoodli at starentnetworks.com (Koodli, Rajeev) Date: Thu, 5 Feb 2009 13:31:11 -0500 Subject: [Netext] charter comments In-Reply-To: <498AE21C.8070906@piuha.net> Message-ID: <4D35478224365146822AE9E3AD4A26660666C5FB@exchtewks3.starentnetworks.com> Hi Jari, Thanks for taking a look. Please see some comments below: > I am looking at > > http://www.arkko.com/ietf/ietf-74/netext/bof.txt > > is there a newer version of the charter text? Perhaps I > missed it, but this one seems include certain things also > outside the three topics that the chairs had told me they > were going to focus on (multihoming, intertechnology > handover, localized routing). Yes, the version we sent you sometime ago needs to be updated. I logged onto the WiKi few days ago, but could not update the items. Anyway, we need to update the charter. > > > Proxy MIP6, which is the IETF Network-based Mobility Protocol > > specified in RFC 5213, has been incorporated into the evolved > > architecture of Long-Term Evolution (LTE) and Wimax networks. The > > respective standards organizations are in the process of specifying > > the Proxy MIP6 protocol for their current requirements and > outlining > > the > > > > the use of the Proxy ... Okay. > > > enhancements for subsequent releases of these networks. In light of > > the above, the following observations can be made: > > > > o as the trials and deployments of 4G networks are expected to begin > > in 2009, their evolution to support features such multihoming, > > inter-access technology handovers and localized routing > > continues > > > > To be exact, the basics are being trialed and deployed > starting 2009 and then to a larger degree in 2010. The > extensions may not be on that same timeline. However, 3GPP > has a deadline December 2009 for their "Release 9" which > might include some of this functionality. Yes. Perhaps the extensions may not be rolled out in 2009, but we would like to have the protocols ready in time as the trials begin. > > > o while the base PMIPv6 protocol is completed, improvements are > > necessary in some areas, most notably multihoming and > > inter-access technology handovers > > > > o certain deployment considerations, including localized routing and > > bulk refresh of lifetime are already emerging > > > > In summary, improvements, deficiencies and deployment > considerations > > are identified to extend the network-based mobility (i.e., > PMIPv6) to > > better meet the evolution of 4G mobile networks. > > > > Yes. > > > Proposed Work: > > ------------- > > > > The proposed NetExt Working Group will focus on the > following topics > > relevant for network-based mobility: > > > > Improvements: > > > > o Multihoming: a specification including the target scenarios, > > preservation of IP sessions and load balancing (Proposed > Standard) > > > > o Inter-access Technology handovers: a specification for > IP session > > preservation when changing access technologies (PS) > > > > Both of these are very vaguely defined; hopefully there is > more detail in the documents. However, even at the BOF > proposal and charter level I would like to see this more > precisely. What type of multihoming do you intend to support? The details are expected in the PS documents. We could add little more text here, but it is not possible to go through all the details. > MN with multiple interfaces? MAG with multiple interfaces? > Also, in both cases there is some (albeit very basic) support > in RFC 5213. Please specify more of the delta you intend to > apply here. Finally, do the above require changes to mobile > nodes? I would expect that MN with multiple interfaces to use > the same IP address would require host changes. This should > be explicitly called out. (If the interfaces use different > addresses then RFC 5213 should work fine.) There is discussion going on the topic. The main scenarios are: 1. Use of multiple IP mobility sessions over a single ATT (and single MAG). 2. Use of multiple IP mobility sessions over respective ATTs (and multiple MAGs) - how to use the same HNP across different interfaces - how to use the same HNP across different interfaces at the flow granularity 3. Use of multiple IP mobility sessions over respective ATTs over a single MAG > > > Deployment Considerations: > > > > o Localized Routing: a specification for constraining routing to > > the MAG(s) without involving the LMA within a single PMIPv6 > > domain (PS) > > > > Again, there is limited functionality in RFC 5213, within a > single MAG. There is no protocol specification on how to do this. It defines a flag, which if set, can have localized routing. > > State the intended optimization model in more detail. Packets > can flow directly between the MAGs, guided by some policy > that enables this functionality on a per host/per flow basis? > In the PS document. Perhaps we will reference the PS docs against the items. > > o Bulk Refresh: specification of improving the signaling load for > > binding lifetime refresh (PS) > > > > Deficiencies: > > > > o MN involvement: documentation of scenarios where MN involvement > > may be seen as beneficial (Informational) > > > > How is this related to the other work items? We probably don't want to take this up now to focus on the other topics. > > > The BoF proposes to discuss the above items and gauge interest in > > forming a working Group. There is already work in progress > addressing > > the identified problems, which is expected to be the starting point > > for the deliverables. > > > > The proposed activity will be complementary to the existing IETF > > Working Groups, notably the NETLMM and MEXT WGs. > > > > Approximate Timeline for Deliverables: > > ------------------------------------- > > > > March 2009 WG approved by IESG > > > April by the earliest, March is over when IETF-74 is over... > > > 2Q09 Problem statements for multihoming, > localized routing > > and inter-access HO agreed upon in the WG > > 2H09 Submit Inter-access Tech Handover, Localized Routing > > and Multihoming I-Ds to IESG > > 4Q09 Submit the I-D on MN Involvement to IESG > > 1Q10 Submit Bulk Refresh I-D to IESG > > 2H10 Recharter or close WG > > > I would suggest breaking up WG document adoption and sending > to the IESG separately. Are the problem statements sent to > the IESG at all? Are the documents in the second step problem > statements or solutions? If the latter, its too aggressive schedule. Okay, we will think over the schedule again (this is from last November). Thanks, -Rajeev > > Jari > > _______________________________________________ > 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. From: liebsch at nw.neclab.eu (Marco Liebsch) Date: Thu, 05 Feb 2009 15:33:21 +0100 Subject: [Netext] First Problem Statement about Localized Routing in PMIPv6 submitted Message-ID: <498AF8B1.1020303@nw.neclab.eu> 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 From: jari.arkko at piuha.net (Jari Arkko) Date: Thu, 05 Feb 2009 14:57:00 +0200 Subject: [Netext] charter comments Message-ID: <498AE21C.8070906@piuha.net> I am looking at http://www.arkko.com/ietf/ietf-74/netext/bof.txt is there a newer version of the charter text? Perhaps I missed it, but this one seems include certain things also outside the three topics that the chairs had told me they were going to focus on (multihoming, intertechnology handover, localized routing). > Proxy MIP6, which is the IETF Network-based Mobility Protocol > specified in RFC 5213, has been incorporated into the evolved > architecture of Long-Term Evolution (LTE) and Wimax networks. The > respective standards organizations are in the process of specifying > the Proxy MIP6 protocol for their current requirements and outlining the > the use of the Proxy ... > enhancements for subsequent releases of these networks. In light of > the above, the following observations can be made: > > o as the trials and deployments of 4G networks are expected to begin > in 2009, their evolution to support features such multihoming, > inter-access technology handovers and localized routing > continues > To be exact, the basics are being trialed and deployed starting 2009 and then to a larger degree in 2010. The extensions may not be on that same timeline. However, 3GPP has a deadline December 2009 for their "Release 9" which might include some of this functionality. > o while the base PMIPv6 protocol is completed, improvements are > necessary in some areas, most notably multihoming and > inter-access technology handovers > > o certain deployment considerations, including localized routing and > bulk refresh of lifetime are already emerging > > In summary, improvements, deficiencies and deployment considerations > are identified to extend the network-based mobility (i.e., PMIPv6) to > better meet the evolution of 4G mobile networks. > Yes. > Proposed Work: > ------------- > > The proposed NetExt Working Group will focus on the following topics > relevant for network-based mobility: > > Improvements: > > o Multihoming: a specification including the target scenarios, > preservation of IP sessions and load balancing (Proposed Standard) > > o Inter-access Technology handovers: a specification for IP session > preservation when changing access technologies (PS) > Both of these are very vaguely defined; hopefully there is more detail in the documents. However, even at the BOF proposal and charter level I would like to see this more precisely. What type of multihoming do you intend to support? MN with multiple interfaces? MAG with multiple interfaces? Also, in both cases there is some (albeit very basic) support in RFC 5213. Please specify more of the delta you intend to apply here. Finally, do the above require changes to mobile nodes? I would expect that MN with multiple interfaces to use the same IP address would require host changes. This should be explicitly called out. (If the interfaces use different addresses then RFC 5213 should work fine.) > Deployment Considerations: > > o Localized Routing: a specification for constraining routing to > the MAG(s) without involving the LMA within a single PMIPv6 > domain (PS) > Again, there is limited functionality in RFC 5213, within a single MAG. State the intended optimization model in more detail. Packets can flow directly between the MAGs, guided by some policy that enables this functionality on a per host/per flow basis? > o Bulk Refresh: specification of improving the signaling load for > binding lifetime refresh (PS) > > Deficiencies: > > o MN involvement: documentation of scenarios where MN involvement > may be seen as beneficial (Informational) > How is this related to the other work items? > The BoF proposes to discuss the above items and gauge interest in > forming a working Group. There is already work in progress addressing > the identified problems, which is expected to be the starting point > for the deliverables. > > The proposed activity will be complementary to the existing IETF > Working Groups, notably the NETLMM and MEXT WGs. > > Approximate Timeline for Deliverables: > ------------------------------------- > > March 2009 WG approved by IESG > April by the earliest, March is over when IETF-74 is over... > 2Q09 Problem statements for multihoming, localized routing > and inter-access HO agreed upon in the WG > 2H09 Submit Inter-access Tech Handover, Localized Routing > and Multihoming I-Ds to IESG > 4Q09 Submit the I-D on MN Involvement to IESG > 1Q10 Submit Bulk Refresh I-D to IESG > 2H10 Recharter or close WG > I would suggest breaking up WG document adoption and sending to the IESG separately. Are the problem statements sent to the IESG at all? Are the documents in the second step problem statements or solutions? If the latter, its too aggressive schedule. Jari From: Mohana.Jeyatharan at sg.panasonic.com (Mohana Jeyatharan) Date: Thu, 5 Feb 2009 14:20:45 +0800 Subject: [Netext] FW: I-DAction:draft-jeyatharan-netext-multihoming-ps-00.txt In-Reply-To: <00b001c98672$e35a7600$150ca40a@china.huawei.com> Message-ID: <5F09D220B62F79418461A978CA0921BD03269E30@pslexc01.psl.local> Hi Yungui, Please see in-line. BR, Mohana -----Original Message----- From: Yungui Wang [mailto:w52006 at huawei.com] Sent: Wednesday, February 04, 2009 10:47 AM To: Mohana Jeyatharan Cc: netext at mail.mobileip.jp Subject: Re: [Netext] FW: I-DAction:draft-jeyatharan-netext-multihoming-ps-00.txt Hello Mohana Thanks for you clarification. Please see below comments... [Mohana] Flow based routing is not a solution and we have not described it as a solution in the PS-ID. It is just mentioned such mechanism may need to be supported by PMIPv6 extensions. The PMIPv6 protocol does not support it. At this point, I like to re emphasize what we mean by flow based routing. It is routing all P1 flows via p2 interface and all P2 flows via P1 interface. basiaclly, it is swapping of the prefixes. This flow based routing overides the normal prefix based routing of PMIPv6. That is all. Hope this helps. [Yungui] Although you don't described it as a solution, it seems you had potentially done. For example, 'basiaclly, it is swapping of the prefixes.' is your assumed solution to flow based routing. That's not an issue related to flow based routing for PMIPv6. [Mohana] Ok, what you are saying is right. Rather than setting filters for each flow, such swapping of prefixes makes a combined action. However, I just classified based on possible states and divisions of multihoming. I agree it is solution to a certain problem. But to activate this scenario (of swapping of prefixes), certain detail protocol operations have to be configured in the system. Thus it is not a full solution. Why we classified it as a scenario is because it is a state on multihoming. An MN may want This kind of deployment. Why it wants is the problem you are thinking of. I agree that 'It is routing all P1 flows via p2 interface and all P2 flows via P1 interface.' is a scenario of flow based routing, however, whose problem we had discussed is 'one prefix can't tranverse multiple interfaces'. In my mind, maybe there is a certain solution to flow based routing can make consistent with prefix based routing of PMIPv6. [Mohana] I am not sure what you mean by "flow based routing made consistent with routing based on PMIPv6". Flow based routing is just high level. The actual routing will be performed using routing based on PMIPv6 even in the case of swapping of prefixes (flow based routing that is described in the draft) [Mohana]In the sub-section there are three issues highligted. Let me highlight the principle of the issues. The first one is, flow based routing associated with certain flows associated with a prefix. If a flow does not match the filters, then the flows will be routed by using the routing rules of PMIPv6. The second and third issues are simultaneous usage for a single or multiple prefixes. The main motive for such division is that to understand the levels of multihoming that we can achieve in the base PMIPv6 protocol. What we mean by simulatneous usage for a single or multiple prefixes is mainly like a simulatneous usage of one or more. Now, what I said about prioritize the prefixes, is sometimes the network may not provide such services for all the prefixes(simulatneous usage). Then the Mn based on some decsion criteria may need to prioritze. We did not explain this in the draft. Howveer, such divisions are highlighted because there are many levels of multihoming that can be achieved. [Yungui] Sorry for I can't get your logic. If network can not provide such services for all the prefixes(simulatneous usage), why does it allocate multiple prefixes to MN? [Mohana] Yungui, this is just an example. Anyway allocating multiple prefixes to an interface and enabling routing for those multiple prefixes via all interfaces may be more core network signaling. Again if we go into this we are more or less touching on the solution space. But, We need to identify a scenario where simultaneous usage for a single or multiple prefixes. It depends on the nature of flows. For example for real-time flows one would not want such simultaneous usage. However for non-time critical flows, perhaps one would want such simultaneous usage services. On the other side, even if it is reasonable, maybe it can directly stated as an issue, e.g. prefix selection. However, proirity or MN's preference, network's policy, etc total can be considered as solution for further study. [Mohana] Yes, I was thinking more towards these lines.... In addition, the draft seems mostly being described as 'scenario - assumed solution - solution related issues (impact to PMIP6 basis)'. That means, I am not sure I have gotten the actual multihoming problems from this ps ID. [Mohana] I think we wrote the draft in such a way that multihoming scenarios are there tied to multiple prefixes model of PMIPv6 (different prefixes via its interfaces). Each of these in a very high level can be considered as a solution. But, it is more like an effect of the final solutions. Thus, whenever such high level solutions are not supported we classified it as an issue. Because as explained in the draft, there is a reason for such high level solutions to be supported. These are explained in the draft. Whenever. these high level solutions are not supported it is considered as a problem. High level solutions are not solution. Detail signaling and solution operation is needed. Thanks Yungui. B.R. Yungui ----- Original Message ----- From: "Mohana Jeyatharan" To: "Yungui Wang" Cc: Sent: Wednesday, February 04, 2009 8:47 AM Subject: RE: [Netext] FW: I-DAction:draft-jeyatharan-netext-multihoming-ps-00.txt Hi Yungui, Please see reply in-line. BR, Mohana _____ From: Yungui Wang [mailto:w52006 at huawei.com] Sent: Tuesday, February 03, 2009 11:44 AM To: Mohana Jeyatharan Cc: netext at mail.mobileip.jp Subject: Re: [Netext] FW: I-DAction:draft-jeyatharan-netext-multihoming-ps-00.txt Hello Mohana, Please see inline... B.R. Yungui ----- Original Message ----- From: Mohana Jeyatharan To: Yungui Wang Cc: netext at mail.mobileip.jp Sent: Monday, February 02, 2009 6:11 PM Subject: RE: [Netext] FW: I-DAction:draft-jeyatharan-netext-multihoming-ps-00.txt Hi Yungui, Thanks for reading. Please see reply in-line. BR, Mohana _____ From: Yungui Wang [mailto:w52006 at huawei.com] Sent: Monday, February 02, 2009 5:19 PM To: Mohana Jeyatharan Cc: netext at mail.mobileip.jp Subject: Re: [Netext] FW: I-DAction:draft-jeyatharan-netext-multihoming-ps-00.txt Hello Mohana Thanks for your hard works. There are my several comments. 1, In section 2, issue related to simultaneous usage of interfaces. Here are three sub-issues illustrated within following three scenarios respectively. Regarding of the first sub-issue, it can be educed that one IP address can't traverse multiple interfaces of MN. [Mohana] Yes, it can be considered that some IP address cannot traverse the other interface or an IP connection that can be characterised by some parameters cannot traverse another interface. The first issue is that, MN wants certain flows associated with a prefix to traverse via a certain interface. It is different from the issue, Flow based routing given in the ID. Flow based routing issue is complete swapping of prefixes, where all P1 flows sent via P2 interface and all P2 flows sent via P1 interface. [Yungui] What's you mentioned flow based routing in the PMIP6 domain? I don't see this solution until now. [Mohana] Flow based routing is not a solution and we have not described it as a solution in the PS-ID. It is just mentioned such mechanism may need to be supported by PMIPv6 extensions. The PMIPv6 protocol does not support it. At this point, I like to re emphasize what we mean by flow based routing. It is routing all P1 flows via p2 interface and all P2 flows via P1 interface. basiaclly, it is swapping of the prefixes. This flow based routing overides the normal prefix based routing of PMIPv6. That is all. Hope this helps. Regarding of the second and third sub-issue, what's their difference? In my understanding, they both seems to say the same issue that one Prefix can't traverse multiple interfaces of MN. [Mohana] I agree from operation or solution point of view one prefix or multiple prefixes the same. Whether one wants to give one prefix such simultaneous usage or multiple prefixes such simulatneous usage is the difference. Since multiple prefixes are obtained in PMIPv6 via multiple interfaces, such differences are essentail to consider. because, in some cases, the network may not support this and the Mn may need to prioritize the prefixes. [Yungui] From the third scenario described in the draft, in my understanding, load balancing feature may bring P1 flows moving from IF1 to IF2. Do you mean it is necessary to prioritize multiple prefixes (P1 and P2) via one interface (IF2) of MN? If so, I don't think this priority issue is related to multihoming/multiple-interface. However, I agree with the third scenario although it is a certain similar as the second. [Mohana]In the sub-section there are three issues highligted. Let me highlight the principle of the issues. The first one is, flow based routing associated with certain flows associated with a prefix. If a flow does not match the filters, then the flows will be routed by using the routing rules of PMIPv6. The second and third issues are simultaneous usage for a single or multiple prefixes. The main motive for such division is that to understand the levels of multihoming that we can achieve in the base PMIPv6 protocol. What we mean by simulatneous usage for a single or multiple prefixes is mainly like a simulatneous usage of one or more. Now, what I said about prioritize the prefixes, is sometimes the network may not provide such services for all the prefixes(simulatneous usage). Then the Mn based on some decsion criteria may need to prioritze. We did not explain this in the draft. Howveer, such divisions are highlighted because there are many levels of multihoming that can be achieved. 2, In section 2, issue related to Flow based Routing Maybe you are proposing flow based solution? This scenario may have been contained in the first issue and it scenarios (like the first sub-issue). [Mohana] As I explained, it is quite different. Here (flow based routing) all the flows associated with a prefix may need to be transferred via another interface. It is how you define the filters. In the first case (certain flows of a prefix sent via another interface), filters are defined for flows where as for the Flow based routing case, flows defined for prefixes. [Yungui] Please see the 1st comments. 3, In section 2, issue related to Flow Mobility during Sudden Disconnection It may be a general reliability issue associated with Multiple Interface capable node, not related to flow mobility. [Mohana]It is in a way flow mobility. If there is disconnection and if appropriate vertical handoff triggers are not sent, then flows associated with a prefix is lost. It is beneficial to get these flows via a connected interface during the diconnection period. So, it is flow mobility but happening in a disconnection scenario. [Yungui] When one link is disconnected, something over it may be is an application, a IP seesion, a flow, or nothing. I wonder if it is specially for flow mobility. Maybe this scenario can be outlined as 'Issues Related to Sudden Disconnection'. [Mohana] Ok.... Will reconsider about the wording. I understand your concern. Flow mobility is transfering of a flow .When all the flows are transferred due to disconnection, then perhaps we may need to re-consider a better term. Thanks.. 4, In section 3 Multihoming Issues in PMIPv6/CMIPv6 mixed Scenario These issues may depend on the basis issues described in PMIPv6/CMIPv6 interaction [draft-giaretta-netlmm-mip-interactions-02.txt]. I am not sure whether these issues exsit. For example, if two spearate BCEs are created with different indexes (e.g. HoA for MIP, HNP/MN-ID for PMIP, etc.) in LMA/HA for PMIPv6/CMIPv6 domain respectively, it may be not necessary to do that synchronization. [Mohana] The PMIPv6/CMIPv6 interaction draft [draft-giaretta-netlmm-mip-interactions-02.txt] was specifically designed for a single interface case. There it is considered that the MIPv6 binidng takes precedence over the PMIPv6 binding, so I am not sure why you are comparing this to PMIP/CMIP draft. Even if we follow the logic used in that draft, according to that draft only one of the bindings are valid at any point in time. Thus there is no mechanism that describes simulatneous reachability using PMIPv6 and CMIPv6 bindings. Thus we need to look at this as a special problem that is related to Multiplke Interfaces and look at how to solve the issue. [Yungui] Get it. Maybe it is necessary to be done next step. [Mohana] Ok. 5, In addition, there is a typo error in the Figure 2. In the text description, CMIP6 is used via the MN.IF1. Thus, here is AR1, not MAG1(AGW) in the Figure 2. [Mohana] well, we considered a 3GPP specific scenario. I agree in CMIPv6 case there is no MAG but it is explained in the text that a prefix for care-of address is obtained from AGW which happens to be a MAG. Anyway please highlight whether we have made a mistake here (please point to the correct text). thanks. [Yungui] Here I was just confused that the entity MAG1 located in the CMIP6 domain. Do you mean an AR (within AGW) can't allocate a prefix for configuring a CoA? [Mohana] i agree, that IF1's mobility is managed by CMIPv6. However, the architecture can support PMIPv6 as well. That is why the AGW/MAG1 term is used in figure 2. In CMIPv6 mode, The AGW does not function as a MAG to the MN. It only provides a prefix and acts as a normal AR. B.R. Yungui ----- Original Message ----- From: Mohana Jeyatharan To: netext at mail.mobileip.jp Sent: Friday, January 23, 2009 12:20 PM Subject: [Netext] FW: I-D Action:draft-jeyatharan-netext-multihoming-ps-00.txt Hello All, We have drafted the problem stated ID, which highlights multihoming related issues in PMIPv6 and the need for further work. Please have a look and we can start some discussion on scenarios and issues. Thanks. 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: Friday, January 23, 2009 12:15 PM To: i-d-announce at ietf.org Subject: I-D Action:draft-jeyatharan-netext-multihoming-ps-00.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-00.txt Pages : 12 Date : 2009-01-22 The base PMIPv6 protocol does not have adequate mechanisms to support advanced multihoming such as simultaneous usage of all interfaces of a mobile node (MN) to receive and transmit data packets associated with a given prefix allocated to MN, and allow flow based routing according to preference, rules, and policies set by the MN or network entity. This memo highlights such advanced multihoming related issues when mobility of the multiple interfaced mobile node (MuIF MN) is purely managed by PMIPv6 mechanism. It also highlights the issue of lack of simultaneous attachment support when the mobility of the MuIF MN is managed by PMIPv6 and CMIPv6 mechanisms. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-jeyatharan-netext-multihoming- ps-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. _____ _______________________________________________ NetExt mailing list NetExt at mail.mobileip.jp http://www.mobileip.jp/mailman/listinfo/netext -------------- next part -------------- An HTML attachment was scrubbed... URL: From: w52006 at huawei.com (Yungui Wang) Date: Thu, 05 Feb 2009 10:53:13 +0800 Subject: [Netext] Review of the Multihoming PS I-D References: Message-ID: <00b701c9873c$e355fa60$150ca40a@china.huawei.com> Hello Raj, Propose below two scenarios which have been defined in CMIPv6 to be considered in scope of multihoming as well. 1, Flow binding and flow mobility 2, Issues of Supported Home Network Prefix Models In current PMIPv6 base, it is not allowed that one HNP traverses multiple interfaces of MN. This limitation may defense a mobility session (or part of mobility session) moves from one interface to another to achieve load sharing, etc. More details of this scenario (/issue) were illustrated in ref.1 [draft-jeyatharan-netext-multihoming-ps-00.txt], and ref.2 [draft-muhanna-netlmm-multihoming-support-00.txt], etc. Please see more comments inline... B.R. Yungui > > a. The multihoming work in Netext should address the limitations of > RFC5213 > w.r.t multihoming. The issue of having a single BCE for an MN > identified by an MN-ID and attaching via multiple interfaces should > be resolved. [Yungui] In my understanding, this scenario (and c.) has been covered by PMIPv6 spec, Section 5.4. " 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. " > > b. The scenario where an MN is connected via a MAG to an LMA and the > ability to establish multiple sessions via the same MAG. This is > the case where the MN is attached via a specific access type and > establishes multiple IP sessions via the MAG. > [Yungui] What's the difference from that multiple HNP for a given interface managed as one mobility session? " 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. " > c. The scenario where an MN attaches via different interfaces which > are of differing access technologies via MAG1 and MAG2 > simultaneously. The MAG1/MAG2 entities are attached to the same > LMA. > [Yungui] Please see the same comments as (a). > d. A combination of the scenarios in (b) and (c), i.e having multiple > sessions via each access type while connected thru different MAGs > simultaneously. > > Lets see if we can build some consensus around the scope of the > problem. > > -Raj > > _______________________________________________ > 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: Wed, 4 Feb 2009 15:55:59 +0100 Subject: [Netext] Review of the Multihoming PS I-D Message-ID: Hello, I have reviewed the Netext Multihoming PS I-D . Thanks to Mohana for her efforts on getting this I-D ready. 1. My impression after reading the I-D is that it misses the key problem of multihoming that we are trying to work on. Proxy MIP6 as currently specified in RFC5213 has limited support for multihoming. It was decided that multihoming should be dealt with separately in Netlmm during the course discussions on this topic in the past. While many of the issues mentioned in the I-D are relevant I believe that Netext should be working on a more narrow scope to enhance PMIP6 to support a few multihoming scenarios. 2. Sec 3 of the I-D which analyses multihoming issues in the case of PMIP6/CMIP6 coexisting together is really misplaced here. I do not believe we want to address this topic as part of the multihoming work in Netext. This is simply out of scope. 3. The I-D focuses on the problem of multiplexing flows or having flows traverse via one interface or another or the ability to move a flow from one interface to another. While these are all valid things to do in PMIP6, I am not convinced that these are specifically related to multihoming. Rajeev and I had a discussion on the scope of multihoming and what we should really be focusing on. We came up with the following specific scenarios which we should address: a. The multihoming work in Netext should address the limitations of RFC5213 w.r.t multihoming. The issue of having a single BCE for an MN identified by an MN-ID and attaching via multiple interfaces should be resolved. b. The scenario where an MN is connected via a MAG to an LMA and the ability to establish multiple sessions via the same MAG. This is the case where the MN is attached via a specific access type and establishes multiple IP sessions via the MAG. c. The scenario where an MN attaches via different interfaces which are of differing access technologies via MAG1 and MAG2 simultaneously. The MAG1/MAG2 entities are attached to the same LMA. d. A combination of the scenarios in (b) and (c), i.e having multiple sessions via each access type while connected thru different MAGs simultaneously. Lets see if we can build some consensus around the scope of the problem. -Raj From: w52006 at huawei.com (Yungui Wang) Date: Wed, 04 Feb 2009 10:47:15 +0800 Subject: [Netext] FW: I-DAction:draft-jeyatharan-netext-multihoming-ps-00.txt References: <5F09D220B62F79418461A978CA0921BD0321A168@pslexc01.psl.local> <01f901c98517$39743970$150ca40a@china.huawei.com> <5F09D220B62F79418461A978CA0921BD0321A8BB@pslexc01.psl.local> <016301c985b1$b32e9590$150ca40a@china.huawei.com> <5F09D220B62F79418461A978CA0921BD03269B12@pslexc01.psl.local> Message-ID: <00b001c98672$e35a7600$150ca40a@china.huawei.com> Hello Mohana Thanks for you clarification. Please see below comments... [Mohana] Flow based routing is not a solution and we have not described it as a solution in the PS-ID. It is just mentioned such mechanism may need to be supported by PMIPv6 extensions. The PMIPv6 protocol does not support it. At this point, I like to re emphasize what we mean by flow based routing. It is routing all P1 flows via p2 interface and all P2 flows via P1 interface. basiaclly, it is swapping of the prefixes. This flow based routing overides the normal prefix based routing of PMIPv6. That is all. Hope this helps. [Yungui] Although you don't described it as a solution, it seems you had potentially done. For example, 'basiaclly, it is swapping of the prefixes.' is your assumed solution to flow based routing. That's not an issue related to flow based routing for PMIPv6. I agree that 'It is routing all P1 flows via p2 interface and all P2 flows via P1 interface.' is a scenario of flow based routing, however, whose problem we had discussed is 'one prefix can't tranverse multiple interfaces'. In my mind, maybe there is a certain solution to flow based routing can make consistent with prefix based routing of PMIPv6. [Mohana]In the sub-section there are three issues highligted. Let me highlight the principle of the issues. The first one is, flow based routing associated with certain flows associated with a prefix. If a flow does not match the filters, then the flows will be routed by using the routing rules of PMIPv6. The second and third issues are simultaneous usage for a single or multiple prefixes. The main motive for such division is that to understand the levels of multihoming that we can achieve in the base PMIPv6 protocol. What we mean by simulatneous usage for a single or multiple prefixes is mainly like a simulatneous usage of one or more. Now, what I said about prioritize the prefixes, is sometimes the network may not provide such services for all the prefixes(simulatneous usage). Then the Mn based on some decsion criteria may need to prioritze. We did not explain this in the draft. Howveer, such divisions are highlighted because there are many levels of multihoming that can be achieved. [Yungui] Sorry for I can't get your logic. If network can not provide such services for all the prefixes(simulatneous usage), why does it allocate multiple prefixes to MN? On the other side, even if it is reasonable, maybe it can directly stated as an issue, e.g. prefix selection. However, proirity or MN's preference, network's policy, etc total can be considered as solution for further study. In addition, the draft seems mostly being described as 'scenario - assumed solution - solution related issues (impact to PMIP6 basis)'. That means, I am not sure I have gotten the actual multihoming problems from this ps ID. B.R. Yungui ----- Original Message ----- From: "Mohana Jeyatharan" To: "Yungui Wang" Cc: Sent: Wednesday, February 04, 2009 8:47 AM Subject: RE: [Netext] FW: I-DAction:draft-jeyatharan-netext-multihoming-ps-00.txt Hi Yungui, Please see reply in-line. BR, Mohana _____ From: Yungui Wang [mailto:w52006 at huawei.com] Sent: Tuesday, February 03, 2009 11:44 AM To: Mohana Jeyatharan Cc: netext at mail.mobileip.jp Subject: Re: [Netext] FW: I-DAction:draft-jeyatharan-netext-multihoming-ps-00.txt Hello Mohana, Please see inline... B.R. Yungui ----- Original Message ----- From: Mohana Jeyatharan To: Yungui Wang Cc: netext at mail.mobileip.jp Sent: Monday, February 02, 2009 6:11 PM Subject: RE: [Netext] FW: I-DAction:draft-jeyatharan-netext-multihoming-ps-00.txt Hi Yungui, Thanks for reading. Please see reply in-line. BR, Mohana _____ From: Yungui Wang [mailto:w52006 at huawei.com] Sent: Monday, February 02, 2009 5:19 PM To: Mohana Jeyatharan Cc: netext at mail.mobileip.jp Subject: Re: [Netext] FW: I-DAction:draft-jeyatharan-netext-multihoming-ps-00.txt Hello Mohana Thanks for your hard works. There are my several comments. 1, In section 2, issue related to simultaneous usage of interfaces. Here are three sub-issues illustrated within following three scenarios respectively. Regarding of the first sub-issue, it can be educed that one IP address can't traverse multiple interfaces of MN. [Mohana] Yes, it can be considered that some IP address cannot traverse the other interface or an IP connection that can be characterised by some parameters cannot traverse another interface. The first issue is that, MN wants certain flows associated with a prefix to traverse via a certain interface. It is different from the issue, Flow based routing given in the ID. Flow based routing issue is complete swapping of prefixes, where all P1 flows sent via P2 interface and all P2 flows sent via P1 interface. [Yungui] What's you mentioned flow based routing in the PMIP6 domain? I don't see this solution until now. [Mohana] Flow based routing is not a solution and we have not described it as a solution in the PS-ID. It is just mentioned such mechanism may need to be supported by PMIPv6 extensions. The PMIPv6 protocol does not support it. At this point, I like to re emphasize what we mean by flow based routing. It is routing all P1 flows via p2 interface and all P2 flows via P1 interface. basiaclly, it is swapping of the prefixes. This flow based routing overides the normal prefix based routing of PMIPv6. That is all. Hope this helps. Regarding of the second and third sub-issue, what's their difference? In my understanding, they both seems to say the same issue that one Prefix can't traverse multiple interfaces of MN. [Mohana] I agree from operation or solution point of view one prefix or multiple prefixes the same. Whether one wants to give one prefix such simultaneous usage or multiple prefixes such simulatneous usage is the difference. Since multiple prefixes are obtained in PMIPv6 via multiple interfaces, such differences are essentail to consider. because, in some cases, the network may not support this and the Mn may need to prioritize the prefixes. [Yungui] From the third scenario described in the draft, in my understanding, load balancing feature may bring P1 flows moving from IF1 to IF2. Do you mean it is necessary to prioritize multiple prefixes (P1 and P2) via one interface (IF2) of MN? If so, I don't think this priority issue is related to multihoming/multiple-interface. However, I agree with the third scenario although it is a certain similar as the second. [Mohana]In the sub-section there are three issues highligted. Let me highlight the principle of the issues. The first one is, flow based routing associated with certain flows associated with a prefix. If a flow does not match the filters, then the flows will be routed by using the routing rules of PMIPv6. The second and third issues are simultaneous usage for a single or multiple prefixes. The main motive for such division is that to understand the levels of multihoming that we can achieve in the base PMIPv6 protocol. What we mean by simulatneous usage for a single or multiple prefixes is mainly like a simulatneous usage of one or more. Now, what I said about prioritize the prefixes, is sometimes the network may not provide such services for all the prefixes(simulatneous usage). Then the Mn based on some decsion criteria may need to prioritze. We did not explain this in the draft. Howveer, such divisions are highlighted because there are many levels of multihoming that can be achieved. 2, In section 2, issue related to Flow based Routing Maybe you are proposing flow based solution? This scenario may have been contained in the first issue and it scenarios (like the first sub-issue). [Mohana] As I explained, it is quite different. Here (flow based routing) all the flows associated with a prefix may need to be transferred via another interface. It is how you define the filters. In the first case (certain flows of a prefix sent via another interface), filters are defined for flows where as for the Flow based routing case, flows defined for prefixes. [Yungui] Please see the 1st comments. 3, In section 2, issue related to Flow Mobility during Sudden Disconnection It may be a general reliability issue associated with Multiple Interface capable node, not related to flow mobility. [Mohana]It is in a way flow mobility. If there is disconnection and if appropriate vertical handoff triggers are not sent, then flows associated with a prefix is lost. It is beneficial to get these flows via a connected interface during the diconnection period. So, it is flow mobility but happening in a disconnection scenario. [Yungui] When one link is disconnected, something over it may be is an application, a IP seesion, a flow, or nothing. I wonder if it is specially for flow mobility. Maybe this scenario can be outlined as 'Issues Related to Sudden Disconnection'. [Mohana] Ok.... Will reconsider about the wording. I understand your concern. Flow mobility is transfering of a flow .When all the flows are transferred due to disconnection, then perhaps we may need to re-consider a better term. Thanks.. 4, In section 3 Multihoming Issues in PMIPv6/CMIPv6 mixed Scenario These issues may depend on the basis issues described in PMIPv6/CMIPv6 interaction [draft-giaretta-netlmm-mip-interactions-02.txt]. I am not sure whether these issues exsit. For example, if two spearate BCEs are created with different indexes (e.g. HoA for MIP, HNP/MN-ID for PMIP, etc.) in LMA/HA for PMIPv6/CMIPv6 domain respectively, it may be not necessary to do that synchronization. [Mohana] The PMIPv6/CMIPv6 interaction draft [draft-giaretta-netlmm-mip-interactions-02.txt] was specifically designed for a single interface case. There it is considered that the MIPv6 binidng takes precedence over the PMIPv6 binding, so I am not sure why you are comparing this to PMIP/CMIP draft. Even if we follow the logic used in that draft, according to that draft only one of the bindings are valid at any point in time. Thus there is no mechanism that describes simulatneous reachability using PMIPv6 and CMIPv6 bindings. Thus we need to look at this as a special problem that is related to Multiplke Interfaces and look at how to solve the issue. [Yungui] Get it. Maybe it is necessary to be done next step. [Mohana] Ok. 5, In addition, there is a typo error in the Figure 2. In the text description, CMIP6 is used via the MN.IF1. Thus, here is AR1, not MAG1(AGW) in the Figure 2. [Mohana] well, we considered a 3GPP specific scenario. I agree in CMIPv6 case there is no MAG but it is explained in the text that a prefix for care-of address is obtained from AGW which happens to be a MAG. Anyway please highlight whether we have made a mistake here (please point to the correct text). thanks. [Yungui] Here I was just confused that the entity MAG1 located in the CMIP6 domain. Do you mean an AR (within AGW) can't allocate a prefix for configuring a CoA? [Mohana] i agree, that IF1's mobility is managed by CMIPv6. However, the architecture can support PMIPv6 as well. That is why the AGW/MAG1 term is used in figure 2. In CMIPv6 mode, The AGW does not function as a MAG to the MN. It only provides a prefix and acts as a normal AR. B.R. Yungui ----- Original Message ----- From: Mohana Jeyatharan To: netext at mail.mobileip.jp Sent: Friday, January 23, 2009 12:20 PM Subject: [Netext] FW: I-D Action:draft-jeyatharan-netext-multihoming-ps-00.txt Hello All, We have drafted the problem stated ID, which highlights multihoming related issues in PMIPv6 and the need for further work. Please have a look and we can start some discussion on scenarios and issues. Thanks. 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: Friday, January 23, 2009 12:15 PM To: i-d-announce at ietf.org Subject: I-D Action:draft-jeyatharan-netext-multihoming-ps-00.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-00.txt Pages : 12 Date : 2009-01-22 The base PMIPv6 protocol does not have adequate mechanisms to support advanced multihoming such as simultaneous usage of all interfaces of a mobile node (MN) to receive and transmit data packets associated with a given prefix allocated to MN, and allow flow based routing according to preference, rules, and policies set by the MN or network entity. This memo highlights such advanced multihoming related issues when mobility of the multiple interfaced mobile node (MuIF MN) is purely managed by PMIPv6 mechanism. It also highlights the issue of lack of simultaneous attachment support when the mobility of the MuIF MN is managed by PMIPv6 and CMIPv6 mechanisms. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-jeyatharan-netext-multihoming- ps-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. _____ _______________________________________________ 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: Wed, 4 Feb 2009 09:12:22 +0800 Subject: [Netext] PMIPv6 Multihoming problem statemnt draft Notification In-Reply-To: <49882BE8.306@cs.uni-goettingen.de> References: <5F09D220B62F79418461A978CA0921BD0321A30E@pslexc01.psl.local> <49882BE8.306@cs.uni-goettingen.de> Message-ID: <5F09D220B62F79418461A978CA0921BD03269B1A@pslexc01.psl.local> Hi Niklas, Thank for your comments. Please see reply in-line. BR, Mohana > -----Original Message----- > From: Niklas Neumann [mailto:niklas.neumann at cs.uni-goettingen.de] > Sent: Tuesday, February 03, 2009 7:35 PM > To: Mohana Jeyatharan > Cc: netext at mail.mobileip.jp > Subject: Re: [Netext] PMIPv6 Multihoming problem statemnt > draft Notification > > Hey Mohana, > > thank you for submitting the draft. I have a couple of questions: > > 1) Can you please help me to understand what the PMIP > relation of those issues is? To me everything you outlined in > Section 2 sounds like the general problems associated with > multi-path routing. As a matter of fact as far as I > understand, if all those problems were solved as proposed in > the draft we wouldn't need PMIP anymore because a MN would > have the means to delegate any flow to any available > interface no matter of the prefix. I am not saying all those > points in the draft are not valid issues, I just need some > help to understand the relationship to PMIP. [Mohana] First of all I was surprised to see you saying if MN can achieve multihoming with some support from network, we don't Need PMIPv6. I really don't think so. But, I agree, that some of the Multihoming scenarios and flow based routing and so on overides the PMIPv6 Base operation. However, PMIPv6 is definitely important because these Are extensions to the protocol. PMIPv6 is the base to set up the routing. All these extensions (I am talking about solution) will need to use Base PMIPv6 mechanisms. Thus, these are extensions. At this juncture I would like to quote the draft ::draft-koodli-flow-handover-00.txt. If you look at it, it can be seen that base PMIPv6 is running, but the solution is using some new Messages to achieve flow based routing. This draft matches the first issue which we have stated in our draft of achieving a flow associated with a prefix via a certain interface I can quote you an anology. MIPv6 is the base protocol and MCoA(MONAMI6) is an Extension to MIPv6 to achieve multihoming to MNs that want and can support Multihoming. When extensions are proposed, the Mn and HA needs to be chnaged. The same principle here.... Multihoming extensions are mobility protocols. > 2) Regarding Section 3, if the home domain offers two > mobility solutions (PMIP and CMIP), isn't it a deployment > error to mix the BCs of the two solutions? I am not clear how > a PMIP PBU can otherwise invalidate a CMIP BCE. [Mohana]Yes, if a home domain offers both PMIPv6 and CMIPv6 mechanisms for its interfaces, then it needs to have mechanisms to clearly Separate the caches. All we are saying is that, if the caches need to separated Proper cache separation parameters needs to be there and thus a Standardized Solution needs to be there. In the PS-ID we have touched A little bit on the solution space. If you see, some extensions Are required to achieve this cache separation. > 3) I understand that most of the issues outlined by the draft > would require active participation and determinations by the > MN. Is that correct? I don't want to anticipate any > solutions. I am just trying to understand the relation to the > network-based paradigm of PMIP and how much host-based > problems are involved here. > [Mohana] Still nothing changes as far as PMIPv6 is concerned. The mobility or the routing path for the prefix is setup using PMIPv6. We are only highlighting some involvement for MN to achieve some Better services such as multihoming in PMIPv6 domain. If the MN does not want any, fine, All these are extensions to the base PMIPv6 protocol... The core is PMIPv6 and all these are extensions. > Again, thank you for your effort, {mohana] Thanks Niklas for reading. > best regards > Niklas > > > Mohana Jeyatharan wrote: > > Hello All, > > > > We have drafted the problem stated ID, which highlights multihoming > > related issues in PMIPv6 and the need for further work. > Please have a > > look and we can start some discussion on scenarios and issues. > > This ID has been already published and it is called: > > > > draft-jeyatharan-netext-multihoming-ps-00 > > Thanks. > > > > BR, > > Mohana > > > > _______________________________________________ > > NetExt mailing list > > NetExt at mail.mobileip.jp > > http://www.mobileip.jp/mailman/listinfo/netext > > > > -- > Niklas Neumann - University of Goettingen, Institute of > Computer Science http://user.informatik.uni-goettingen.de/~nneuman1/ > Tel: +49 551 39-172053 > From: Mohana.Jeyatharan at sg.panasonic.com (Mohana Jeyatharan) Date: Wed, 4 Feb 2009 08:47:19 +0800 Subject: [Netext] FW: I-DAction:draft-jeyatharan-netext-multihoming-ps-00.txt In-Reply-To: <016301c985b1$b32e9590$150ca40a@china.huawei.com> References: <5F09D220B62F79418461A978CA0921BD0321A168@pslexc01.psl.local> <01f901c98517$39743970$150ca40a@china.huawei.com> <5F09D220B62F79418461A978CA0921BD0321A8BB@pslexc01.psl.local> <016301c985b1$b32e9590$150ca40a@china.huawei.com> Message-ID: <5F09D220B62F79418461A978CA0921BD03269B13@pslexc01.psl.local> Hi Yungui, Please see reply in-line. BR, Mohana ________________________________ From: Yungui Wang [mailto:w52006 at huawei.com] Sent: Tuesday, February 03, 2009 11:44 AM To: Mohana Jeyatharan Cc: netext at mail.mobileip.jp Subject: Re: [Netext] FW: I-DAction:draft-jeyatharan-netext-multihoming-ps-00.txt Hello Mohana, Please see inline... B.R. Yungui ----- Original Message ----- From: Mohana Jeyatharan To: Yungui Wang Cc: netext at mail.mobileip.jp Sent: Monday, February 02, 2009 6:11 PM Subject: RE: [Netext] FW: I-DAction:draft-jeyatharan-netext-multihoming-ps-00.txt Hi Yungui, Thanks for reading. Please see reply in-line. BR, Mohana ________________________________ From: Yungui Wang [mailto:w52006 at huawei.com] Sent: Monday, February 02, 2009 5:19 PM To: Mohana Jeyatharan Cc: netext at mail.mobileip.jp Subject: Re: [Netext] FW: I-DAction:draft-jeyatharan-netext-multihoming-ps-00.txt Hello Mohana Thanks for your hard works. There are my several comments. 1, In section 2, issue related to simultaneous usage of interfaces. Here are three sub-issues illustrated within following three scenarios respectively. Regarding of the first sub-issue, it can be educed that one IP address can't traverse multiple interfaces of MN. [Mohana] Yes, it can be considered that some IP address cannot traverse the other interface or an IP connection that can be characterised by some parameters cannot traverse another interface. The first issue is that, MN wants certain flows associated with a prefix to traverse via a certain interface. It is different from the issue, Flow based routing given in the ID. Flow based routing issue is complete swapping of prefixes, where all P1 flows sent via P2 interface and all P2 flows sent via P1 interface. [Yungui] What's you mentioned flow based routing in the PMIP6 domain? I don't see this solution until now. [Mohana] Flow based routing is not a solution and we have not described it as a solution in the PS-ID. It is just mentioned such mechanism may need to be supported by PMIPv6 extensions. The PMIPv6 protocol does not support it. At this point, I like to re emphasize what we mean by flow based routing. It is routing all P1 flows via p2 interface and all P2 flows via P1 interface. basiaclly, it is swapping of the prefixes. This flow based routing overides the normal prefix based routing of PMIPv6. That is all. Hope this helps. Regarding of the second and third sub-issue, what's their difference? In my understanding, they both seems to say the same issue that one Prefix can't traverse multiple interfaces of MN. [Mohana] I agree from operation or solution point of view one prefix or multiple prefixes the same. Whether one wants to give one prefix such simultaneous usage or multiple prefixes such simulatneous usage is the difference. Since multiple prefixes are obtained in PMIPv6 via multiple interfaces, such differences are essentail to consider. because, in some cases, the network may not support this and the Mn may need to prioritize the prefixes. [Yungui] From the third scenario described in the draft, in my understanding, load balancing feature may bring P1 flows moving from IF1 to IF2. Do you mean it is necessary to prioritize multiple prefixes (P1 and P2) via one interface (IF2) of MN? If so, I don't think this priority issue is related to multihoming/multiple-interface. However, I agree with the third scenario although it is a certain similar as the second. [Mohana]In the sub-section there are three issues highligted. Let me highlight the principle of the issues. The first one is, flow based routing associated with certain flows associated with a prefix. If a flow does not match the filters, then the flows will be routed by using the routing rules of PMIPv6. The second and third issues are simultaneous usage for a single or multiple prefixes. The main motive for such division is that to understand the levels of multihoming that we can achieve in the base PMIPv6 protocol. What we mean by simulatneous usage for a single or multiple prefixes is mainly like a simulatneous usage of one or more. Now, what I said about prioritize the prefixes, is sometimes the network may not provide such services for all the prefixes(simulatneous usage). Then the Mn based on some decsion criteria may need to prioritze. We did not explain this in the draft. Howveer, such divisions are highlighted because there are many levels of multihoming that can be achieved. 2, In section 2, issue related to Flow based Routing Maybe you are proposing flow based solution? This scenario may have been contained in the first issue and it scenarios (like the first sub-issue). [Mohana] As I explained, it is quite different. Here (flow based routing) all the flows associated with a prefix may need to be transferred via another interface. It is how you define the filters. In the first case (certain flows of a prefix sent via another interface), filters are defined for flows where as for the Flow based routing case, flows defined for prefixes. [Yungui] Please see the 1st comments. 3, In section 2, issue related to Flow Mobility during Sudden Disconnection It may be a general reliability issue associated with Multiple Interface capable node, not related to flow mobility. [Mohana]It is in a way flow mobility. If there is disconnection and if appropriate vertical handoff triggers are not sent, then flows associated with a prefix is lost. It is beneficial to get these flows via a connected interface during the diconnection period. So, it is flow mobility but happening in a disconnection scenario. [Yungui] When one link is disconnected, something over it may be is an application, a IP seesion, a flow, or nothing. I wonder if it is specially for flow mobility. Maybe this scenario can be outlined as 'Issues Related to Sudden Disconnection'. [Mohana] Ok.... Will reconsider about the wording. I understand your concern. Flow mobility is transfering of a flow .When all the flows are transferred due to disconnection, then perhaps we may need to re-consider a better term. Thanks.. 4, In section 3 Multihoming Issues in PMIPv6/CMIPv6 mixed Scenario These issues may depend on the basis issues described in PMIPv6/CMIPv6 interaction [draft-giaretta-netlmm-mip-interactions-02.txt]. I am not sure whether these issues exsit. For example, if two spearate BCEs are created with different indexes (e.g. HoA for MIP, HNP/MN-ID for PMIP, etc.) in LMA/HA for PMIPv6/CMIPv6 domain respectively, it may be not necessary to do that synchronization. [Mohana] The PMIPv6/CMIPv6 interaction draft [draft-giaretta-netlmm-mip-interactions-02.txt] was specifically designed for a single interface case. There it is considered that the MIPv6 binidng takes precedence over the PMIPv6 binding, so I am not sure why you are comparing this to PMIP/CMIP draft. Even if we follow the logic used in that draft, according to that draft only one of the bindings are valid at any point in time. Thus there is no mechanism that describes simulatneous reachability using PMIPv6 and CMIPv6 bindings. Thus we need to look at this as a special problem that is related to Multiplke Interfaces and look at how to solve the issue. [Yungui] Get it. Maybe it is necessary to be done next step. [Mohana] Ok. 5, In addition, there is a typo error in the Figure 2. In the text description, CMIP6 is used via the MN.IF1. Thus, here is AR1, not MAG1(AGW) in the Figure 2. [Mohana] well, we considered a 3GPP specific scenario. I agree in CMIPv6 case there is no MAG but it is explained in the text that a prefix for care-of address is obtained from AGW which happens to be a MAG. Anyway please highlight whether we have made a mistake here (please point to the correct text). thanks. [Yungui] Here I was just confused that the entity MAG1 located in the CMIP6 domain. Do you mean an AR (within AGW) can't allocate a prefix for configuring a CoA? [Mohana] i agree, that IF1's mobility is managed by CMIPv6. However, the architecture can support PMIPv6 as well. That is why the AGW/MAG1 term is used in figure 2. In CMIPv6 mode, The AGW does not function as a MAG to the MN. It only provides a prefix and acts as a normal AR. B.R. Yungui ----- Original Message ----- From: Mohana Jeyatharan To: netext at mail.mobileip.jp Sent: Friday, January 23, 2009 12:20 PM Subject: [Netext] FW: I-D Action:draft-jeyatharan-netext-multihoming-ps-00.txt Hello All, We have drafted the problem stated ID, which highlights multihoming related issues in PMIPv6 and the need for further work. Please have a look and we can start some discussion on scenarios and issues. Thanks. 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: Friday, January 23, 2009 12:15 PM To: i-d-announce at ietf.org Subject: I-D Action:draft-jeyatharan-netext-multihoming-ps-00.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-00.txt Pages : 12 Date : 2009-01-22 The base PMIPv6 protocol does not have adequate mechanisms to support advanced multihoming such as simultaneous usage of all interfaces of a mobile node (MN) to receive and transmit data packets associated with a given prefix allocated to MN, and allow flow based routing according to preference, rules, and policies set by the MN or network entity. This memo highlights such advanced multihoming related issues when mobility of the multiple interfaced mobile node (MuIF MN) is purely managed by PMIPv6 mechanism. It also highlights the issue of lack of simultaneous attachment support when the mobility of the MuIF MN is managed by PMIPv6 and CMIPv6 mechanisms. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-jeyatharan-netext-multihoming- ps-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. ________________________________ _______________________________________________ NetExt mailing list NetExt at mail.mobileip.jp http://www.mobileip.jp/mailman/listinfo/netext -------------- next part -------------- An HTML attachment was scrubbed... URL: From: niklas.neumann at cs.uni-goettingen.de (Niklas Neumann) Date: Tue, 03 Feb 2009 12:35:04 +0100 Subject: [Netext] PMIPv6 Multihoming problem statemnt draft Notification In-Reply-To: <5F09D220B62F79418461A978CA0921BD0321A30E@pslexc01.psl.local> References: <5F09D220B62F79418461A978CA0921BD0321A30E@pslexc01.psl.local> Message-ID: <49882BE8.306@cs.uni-goettingen.de> Hey Mohana, thank you for submitting the draft. I have a couple of questions: 1) Can you please help me to understand what the PMIP relation of those issues is? To me everything you outlined in Section 2 sounds like the general problems associated with multi-path routing. As a matter of fact as far as I understand, if all those problems were solved as proposed in the draft we wouldn't need PMIP anymore because a MN would have the means to delegate any flow to any available interface no matter of the prefix. I am not saying all those points in the draft are not valid issues, I just need some help to understand the relationship to PMIP. 2) Regarding Section 3, if the home domain offers two mobility solutions (PMIP and CMIP), isn't it a deployment error to mix the BCs of the two solutions? I am not clear how a PMIP PBU can otherwise invalidate a CMIP BCE. 3) I understand that most of the issues outlined by the draft would require active participation and determinations by the MN. Is that correct? I don't want to anticipate any solutions. I am just trying to understand the relation to the network-based paradigm of PMIP and how much host-based problems are involved here. Again, thank you for your effort, best regards Niklas Mohana Jeyatharan wrote: > Hello All, > > We have drafted the problem stated ID, which highlights multihoming > related issues in PMIPv6 and the need for further work. Please have a > look and we can start some discussion on scenarios and issues. > This ID has been already published and it is called: > > draft-jeyatharan-netext-multihoming-ps-00 > Thanks. > > BR, > Mohana > > _______________________________________________ > NetExt mailing list > NetExt at mail.mobileip.jp > http://www.mobileip.jp/mailman/listinfo/netext -- Niklas Neumann - University of Goettingen, Institute of Computer Science http://user.informatik.uni-goettingen.de/~nneuman1/ Tel: +49 551 39-172053 From: w52006 at huawei.com (Yungui Wang) Date: Tue, 03 Feb 2009 11:44:21 +0800 Subject: [Netext] FW: I-DAction:draft-jeyatharan-netext-multihoming-ps-00.txt References: <5F09D220B62F79418461A978CA0921BD0321A168@pslexc01.psl.local> <01f901c98517$39743970$150ca40a@china.huawei.com> <5F09D220B62F79418461A978CA0921BD0321A8BB@pslexc01.psl.local> Message-ID: <016301c985b1$b32e9590$150ca40a@china.huawei.com> Hello Mohana, Please see inline... B.R. Yungui ----- Original Message ----- From: Mohana Jeyatharan To: Yungui Wang Cc: netext at mail.mobileip.jp Sent: Monday, February 02, 2009 6:11 PM Subject: RE: [Netext] FW: I-DAction:draft-jeyatharan-netext-multihoming-ps-00.txt Hi Yungui, Thanks for reading. Please see reply in-line. BR, Mohana ---------------------------------------------------------------------------- From: Yungui Wang [mailto:w52006 at huawei.com] Sent: Monday, February 02, 2009 5:19 PM To: Mohana Jeyatharan Cc: netext at mail.mobileip.jp Subject: Re: [Netext] FW: I-DAction:draft-jeyatharan-netext-multihoming-ps-00.txt Hello Mohana Thanks for your hard works. There are my several comments. 1, In section 2, issue related to simultaneous usage of interfaces. Here are three sub-issues illustrated within following three scenarios respectively. Regarding of the first sub-issue, it can be educed that one IP address can't traverse multiple interfaces of MN. [Mohana] Yes, it can be considered that some IP address cannot traverse the other interface or an IP connection that can be characterised by some parameters cannot traverse another interface. The first issue is that, MN wants certain flows associated with a prefix to traverse via a certain interface. It is different from the issue, Flow based routing given in the ID. Flow based routing issue is complete swapping of prefixes, where all P1 flows sent via P2 interface and all P2 flows sent via P1 interface. [Yungui] What's you mentioned flow based routing in the PMIP6 domain? I don't see this solution until now. Regarding of the second and third sub-issue, what's their difference? In my understanding, they both seems to say the same issue that one Prefix can't traverse multiple interfaces of MN. [Mohana] I agree from operation or solution point of view one prefix or multiple prefixes the same. Whether one wants to give one prefix such simultaneous usage or multiple prefixes such simulatneous usage is the difference. Since multiple prefixes are obtained in PMIPv6 via multiple interfaces, such differences are essentail to consider. because, in some cases, the network may not support this and the Mn may need to prioritize the prefixes. [Yungui] From the third scenario described in the draft, in my understanding, load balancing feature may bring P1 flows moving from IF1 to IF2. Do you mean it is necessary to prioritize multiple prefixes (P1 and P2) via one interface (IF2) of MN? If so, I don't think this priority issue is related to multihoming/multiple-interface. However, I agree with the third scenario although it is a certain similar as the second. 2, In section 2, issue related to Flow based Routing Maybe you are proposing flow based solution? This scenario may have been contained in the first issue and it scenarios (like the first sub-issue). [Mohana] As I explained, it is quite different. Here (flow based routing) all the flows associated with a prefix may need to be transferred via another interface. It is how you define the filters. In the first case (certain flows of a prefix sent via another interface), filters are defined for flows where as for the Flow based routing case, flows defined for prefixes. [Yungui] Please see the 1st comments. 3, In section 2, issue related to Flow Mobility during Sudden Disconnection It may be a general reliability issue associated with Multiple Interface capable node, not related to flow mobility. [Mohana]It is in a way flow mobility. If there is disconnection and if appropriate vertical handoff triggers are not sent, then flows associated with a prefix is lost. It is beneficial to get these flows via a connected interface during the diconnection period. So, it is flow mobility but happening in a disconnection scenario. [Yungui] When one link is disconnected, something over it may be is an application, a IP seesion, a flow, or nothing. I wonder if it is specially for flow mobility. Maybe this scenario can be outlined as 'Issues Related to Sudden Disconnection'. 4, In section 3 Multihoming Issues in PMIPv6/CMIPv6 mixed Scenario These issues may depend on the basis issues described in PMIPv6/CMIPv6 interaction [draft-giaretta-netlmm-mip-interactions-02.txt]. I am not sure whether these issues exsit. For example, if two spearate BCEs are created with different indexes (e.g. HoA for MIP, HNP/MN-ID for PMIP, etc.) in LMA/HA for PMIPv6/CMIPv6 domain respectively, it may be not necessary to do that synchronization. [Mohana] The PMIPv6/CMIPv6 interaction draft [draft-giaretta-netlmm-mip-interactions-02.txt] was specifically designed for a single interface case. There it is considered that the MIPv6 binidng takes precedence over the PMIPv6 binding, so I am not sure why you are comparing this to PMIP/CMIP draft. Even if we follow the logic used in that draft, according to that draft only one of the bindings are valid at any point in time. Thus there is no mechanism that describes simulatneous reachability using PMIPv6 and CMIPv6 bindings. Thus we need to look at this as a special problem that is related to Multiplke Interfaces and look at how to solve the issue. [Yungui] Get it. Maybe it is necessary to be done next step. 5, In addition, there is a typo error in the Figure 2. In the text description, CMIP6 is used via the MN.IF1. Thus, here is AR1, not MAG1(AGW) in the Figure 2. [Mohana] well, we considered a 3GPP specific scenario. I agree in CMIPv6 case there is no MAG but it is explained in the text that a prefix for care-of address is obtained from AGW which happens to be a MAG. Anyway please highlight whether we have made a mistake here (please point to the correct text). thanks. [Yungui] Here I was just confused that the entity MAG1 located in the CMIP6 domain. Do you mean an AR (within AGW) can't allocate a prefix for configuring a CoA? B.R. Yungui ----- Original Message ----- From: Mohana Jeyatharan To: netext at mail.mobileip.jp Sent: Friday, January 23, 2009 12:20 PM Subject: [Netext] FW: I-D Action:draft-jeyatharan-netext-multihoming-ps-00.txt Hello All, We have drafted the problem stated ID, which highlights multihoming related issues in PMIPv6 and the need for further work. Please have a look and we can start some discussion on scenarios and issues. Thanks. 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: Friday, January 23, 2009 12:15 PM To: i-d-announce at ietf.org Subject: I-D Action:draft-jeyatharan-netext-multihoming-ps-00.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-00.txt Pages : 12 Date : 2009-01-22 The base PMIPv6 protocol does not have adequate mechanisms to support advanced multihoming such as simultaneous usage of all interfaces of a mobile node (MN) to receive and transmit data packets associated with a given prefix allocated to MN, and allow flow based routing according to preference, rules, and policies set by the MN or network entity. This memo highlights such advanced multihoming related issues when mobility of the multiple interfaced mobile node (MuIF MN) is purely managed by PMIPv6 mechanism. It also highlights the issue of lack of simultaneous attachment support when the mobility of the MuIF MN is managed by PMIPv6 and CMIPv6 mechanisms. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-jeyatharan-netext-multihoming- ps-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. -------------------------------------------------------------------------- _______________________________________________ NetExt mailing list NetExt at mail.mobileip.jp http://www.mobileip.jp/mailman/listinfo/netext -------------- next part -------------- An HTML attachment was scrubbed... URL: From: Mohana.Jeyatharan at sg.panasonic.com (Mohana Jeyatharan) Date: Mon, 2 Feb 2009 18:11:32 +0800 Subject: [Netext] FW: I-DAction:draft-jeyatharan-netext-multihoming-ps-00.txt In-Reply-To: <01f901c98517$39743970$150ca40a@china.huawei.com> References: <5F09D220B62F79418461A978CA0921BD0321A168@pslexc01.psl.local> <01f901c98517$39743970$150ca40a@china.huawei.com> Message-ID: <5F09D220B62F79418461A978CA0921BD0321A8BC@pslexc01.psl.local> Hi Yungui, Thanks for reading. Please see reply in-line. BR, Mohana ________________________________ From: Yungui Wang [mailto:w52006 at huawei.com] Sent: Monday, February 02, 2009 5:19 PM To: Mohana Jeyatharan Cc: netext at mail.mobileip.jp Subject: Re: [Netext] FW: I-DAction:draft-jeyatharan-netext-multihoming-ps-00.txt Hello Mohana Thanks for your hard works. There are my several comments. 1, In section 2, issue related to simultaneous usage of interfaces. Here are three sub-issues illustrated within following three scenarios respectively. Regarding of the first sub-issue, it can be educed that one IP address can't traverse multiple interfaces of MN. [Mohana] Yes, it can be considered that some IP address cannot traverse the other interface or an IP connection that can be characterised by some parameters cannot traverse another interface. The first issue is that, MN wants certain flows associated with a prefix to traverse via a certain interface. It is different from the issue, Flow based routing given in the ID. Flow based routing issue is complete swapping of prefixes, where all P1 flows sent via P2 interface and all P2 flows sent via P1 interface. Regarding of the second and third sub-issue, what's their difference? In my understanding, they both seems to say the same issue that one Prefix can't traverse multiple interfaces of MN. [Mohana] I agree from operation or solution point of view one prefix or multiple prefixes the same. Whether one wants to give one prefix such simultaneous usage or multiple prefixes such simulatneous usage is the difference. Since multiple prefixes are obtained in PMIPv6 via multiple interfaces, such differences are essentail to consider. because, in some cases, the network may not support this and the Mn may need to prioritize the prefixes. 2, In section 2, issue related to Flow based Routing Maybe you are proposing flow based solution? This scenario may have been contained in the first issue and it scenarios (like the first sub-issue). [Mohana] As I explained, it is quite different. Here (flow based routing) all the flows associated with a prefix may need to be transferred via another interface. It is how you define the filters. In the first case (certain flows of a prefix sent via another interface), filters are defined for flows where as for the Flow based routing case, flows defined for prefixes. 3, In section 2, issue related to Flow Mobility during Sudden Disconnection It may be a general reliability issue associated with Multiple Interface capable node, not related to flow mobility. [Mohana]It is in a way flow mobility. If there is disconnection and if appropriate vertical handoff triggers are not sent, then flows associated with a prefix is lost. It is beneficial to get these flows via a connected interface during the diconnection period. So, it is flow mobility but happening in a disconnection scenario. 4, In section 3 Multihoming Issues in PMIPv6/CMIPv6 mixed Scenario These issues may depend on the basis issues described in PMIPv6/CMIPv6 interaction [draft-giaretta-netlmm-mip-interactions-02.txt]. I am not sure whether these issues exsit. For example, if two spearate BCEs are created with different indexes (e.g. HoA for MIP, HNP/MN-ID for PMIP, etc.) in LMA/HA for PMIPv6/CMIPv6 domain respectively, it may be not necessary to do that synchronization. [Mohana] The PMIPv6/CMIPv6 interaction draft [draft-giaretta-netlmm-mip-interactions-02.txt] was specifically designed for a single interface case. There it is considered that the MIPv6 binidng takes precedence over the PMIPv6 binding, so I am not sure why you are comparing this to PMIP/CMIP draft. Even if we follow the logic used in that draft, according to that draft only one of the bindings are valid at any point in time. Thus there is no mechanism that describes simulatneous reachability using PMIPv6 and CMIPv6 bindings. Thus we need to look at this as a special problem that is related to Multiplke Interfaces and look at how to solve the issue. 5, In addition, there is a typo error in the Figure 2. In the text description, CMIP6 is used via the MN.IF1. Thus, here is AR1, not MAG1(AGW) in the Figure 2. [Mohana] well, we considered a 3GPP specific scenario. I agree in CMIPv6 case there is no MAG but it is explained in the text that a prefix for care-of address is obtained from AGW which happens to be a MAG. Anyway please highlight whether we have made a mistake here (please point to the correct text). thanks. B.R. Yungui ----- Original Message ----- From: Mohana Jeyatharan To: netext at mail.mobileip.jp Sent: Friday, January 23, 2009 12:20 PM Subject: [Netext] FW: I-D Action:draft-jeyatharan-netext-multihoming-ps-00.txt Hello All, We have drafted the problem stated ID, which highlights multihoming related issues in PMIPv6 and the need for further work. Please have a look and we can start some discussion on scenarios and issues. Thanks. 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: Friday, January 23, 2009 12:15 PM To: i-d-announce at ietf.org Subject: I-D Action:draft-jeyatharan-netext-multihoming-ps-00.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-00.txt Pages : 12 Date : 2009-01-22 The base PMIPv6 protocol does not have adequate mechanisms to support advanced multihoming such as simultaneous usage of all interfaces of a mobile node (MN) to receive and transmit data packets associated with a given prefix allocated to MN, and allow flow based routing according to preference, rules, and policies set by the MN or network entity. This memo highlights such advanced multihoming related issues when mobility of the multiple interfaced mobile node (MuIF MN) is purely managed by PMIPv6 mechanism. It also highlights the issue of lack of simultaneous attachment support when the mobility of the MuIF MN is managed by PMIPv6 and CMIPv6 mechanisms. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-jeyatharan-netext-multihoming- ps-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. ________________________________ _______________________________________________ NetExt mailing list NetExt at mail.mobileip.jp http://www.mobileip.jp/mailman/listinfo/netext -------------- next part -------------- An HTML attachment was scrubbed... URL: From: w52006 at huawei.com (Yungui Wang) Date: Mon, 02 Feb 2009 17:18:34 +0800 Subject: [Netext] FW: I-D Action:draft-jeyatharan-netext-multihoming-ps-00.txt References: <5F09D220B62F79418461A978CA0921BD0321A168@pslexc01.psl.local> Message-ID: <01f901c98517$39743970$150ca40a@china.huawei.com> Hello Mohana Thanks for your hard works. There are my several comments. 1, In section 2, issue related to simultaneous usage of interfaces. Here are three sub-issues illustrated within following three scenarios respectively. Regarding of the first sub-issue, it can be educed that one IP address can't traverse multiple interfaces of MN. Regarding of the second and third sub-issue, what's their difference? In my understanding, they both seems to say the same issue that one Prefix can't traverse multiple interfaces of MN. 2, In section 2, issue related to Flow based Routing Maybe you are proposing flow based solution? This scenario may have been contained in the first issue and it scenarios (like the first sub-issue). 3, In section 2, issue related to Flow Mobility during Sudden Disconnection It may be a general reliability issue associated with Multiple Interface capable node, not related to flow mobility. 4, In section 3 Multihoming Issues in PMIPv6/CMIPv6 mixed Scenario These issues may depend on the basis issues described in PMIPv6/CMIPv6 interaction [draft-giaretta-netlmm-mip-interactions-02.txt]. I am not sure whether these issues exsit. For example, if two spearate BCEs are created with different indexes (e.g. HoA for MIP, HNP/MN-ID for PMIP, etc.) in LMA/HA for PMIPv6/CMIPv6 domain respectively, it may be not necessary to do that synchronization. 5, In addition, there is a typo error in the Figure 2. In the text description, CMIP6 is used via the MN.IF1. Thus, here is AR1, not MAG1(AGW) in the Figure 2. B.R. Yungui ----- Original Message ----- From: Mohana Jeyatharan To: netext at mail.mobileip.jp Sent: Friday, January 23, 2009 12:20 PM Subject: [Netext] FW: I-D Action:draft-jeyatharan-netext-multihoming-ps-00.txt Hello All, We have drafted the problem stated ID, which highlights multihoming related issues in PMIPv6 and the need for further work. Please have a look and we can start some discussion on scenarios and issues. Thanks. 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: Friday, January 23, 2009 12:15 PM To: i-d-announce at ietf.org Subject: I-D Action:draft-jeyatharan-netext-multihoming-ps-00.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-00.txt Pages : 12 Date : 2009-01-22 The base PMIPv6 protocol does not have adequate mechanisms to support advanced multihoming such as simultaneous usage of all interfaces of a mobile node (MN) to receive and transmit data packets associated with a given prefix allocated to MN, and allow flow based routing according to preference, rules, and policies set by the MN or network entity. This memo highlights such advanced multihoming related issues when mobility of the multiple interfaced mobile node (MuIF MN) is purely managed by PMIPv6 mechanism. It also highlights the issue of lack of simultaneous attachment support when the mobility of the MuIF MN is managed by PMIPv6 and CMIPv6 mechanisms. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-jeyatharan-netext-multihoming- ps-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. ------------------------------------------------------------------------------ _______________________________________________ NetExt mailing list NetExt at mail.mobileip.jp http://www.mobileip.jp/mailman/listinfo/netext -------------- next part -------------- An HTML attachment was scrubbed... URL: