I support the extension to MN Id type. I talked to few people (Yokota-san, Jouni ..) on this in the past and below is the explanation. Currently, the NAI that is carried in the PBU does not distinguish a IMSI based NAI, generic-NAI and a MAc-based NAI. Email below.
Regarding supporting GTP-U as a tunnel type, I'm not to keen on that. If the tunnel type is GTP-U, there is no reason for the SDO to use a different signaling protocol, it can be GTP-C. That battle is over, I'd rather focus on pushing SDN approaches than trying to supporting GTP-U types in IETF mobility protocols. But, if some one wants to do this, I'll not argue against this. Sri From: Sri Gundavelli <[email protected]<mailto:[email protected]>> Date: Thursday, February 28, 2013 11:57 AM To: Hidetoshi Yokota <[email protected]<mailto:[email protected]>> Subject: NAI Support over Gx Hi Yokota-san: We need a new sub-type to differentiate between NAI (user@realm) vs., IMSI-NAI. Can we define new sub-types to Mobile Node Identifier option ? Value [http://www.iana.org/assignments/_support/sort_none.gif] Description [http://www.iana.org/assignments/_support/sort_none.gif] Reference [http://www.iana.org/assignments/_support/sort_none.gif] 1 NAI [RFC4283<http://www.iana.org/go/rfc4283>] 2 USER-NAI (user@realm, should not be used for IMSI-NAI) 3 MAC-48 Goal is to address the issue below. Any comments ? --- 1. If MAG sends a PBU which includes IMSI: MN NAI Mobility Option Follows: Type: 0x08 Length: 0x36 Sub Type: 0x01 NAI: [email protected]<mailto:[email protected]> The LMA will trigger the PCRF using the following AVP in the Gx CCR-I: [M] Subscription-Id: [M] Subscription-Id-Type: END_USER_IMSI (1) [M] Subscription-Id-Data: 724052800014033 2. If MAG sends a PBU which includes MSISDN: Vendor Specific Mobility Option Follows: Type: 0x13 Length: 0x0C Vendor ID: 0x000028AF Sub Type: 0x0C (MSISDN) Fragment (M) Flag: 0x00 MSISDN: <552176297602> Then, the LMA will trigger the PCRF using the following AVP in the Gx CCR-I: [M] Subscription-Id: [M] Subscription-Id-Type: END_USER_E164 (0) [M] Subscription-Id-Data: 552176297602 3. If the MAG sends a PBU with Username: MN NAI Mobility Option Follows: Type: 0x08 Length: 0x2C Sub Type: 0x01 NAI: [email protected]<mailto:[email protected]> Then, How can LMA trigger the PCRF with this following AVP ?: [M] Subscription-Id: [M] Subscription-Id-Type: END_USER_NAI (3) [M] Subscription-Id-Data: [email protected]<mailto:[email protected]> On 9/9/14 2:04 AM, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> wrote: Hi, I second Charlie on this proposal, especially on the need for additional MNID and tunnel types. Another example for the latter is: using GRE with MIP/NEMO. BR, Pierrick -----Message d'origine----- De : dmm [mailto:[email protected]] De la part de Charlie Perkins Envoyé : lundi 8 septembre 2014 19:50 À : MONGAZON-CAZAVET, BRUNO (BRUNO); [email protected]<mailto:[email protected]> Objet : Re: [DMM] regarding the re-chartering.. Hello folks, I'll go look for the link(s). But in the meantime, as part of the ongoing maintenance work, I'd be happy to see the following: - Additional tunnel types (including GTP) - Additional mobile node identifier types (including IMSI, MAC, ...) - Additional security mechanisms If there is a sliver of a chance that we could go down any one or more of these paths, I will resurrect the old Internet drafts as well. If people are interested, I will re-submit them for the November meeting. There are two or three other things that Mobile IP needs also, that take more words to express, but not necessarily directly related to distributed mobility management. Much of my development had to do with trying to provide an easier / incremental path for the deployment of Mobile IP by SDO partners in 3GPP, which would necessitate inclusion in their standards, which (for instance) seems to necessitate GTP as a tunneling protocol, etc. Regards, Charlie P. On 9/7/2014 11:57 PM, MONGAZON-CAZAVET, BRUNO (BRUNO) wrote: On 05/09/2014 19:10, Charlie Perkins wrote: Hello folks, I have made various presentations at IETF, some from many years ago, proposing that Mobile IP enable use of GTP as a tunneling option. I still think that would be a good idea. Should I re-re-revive a draft stating this in more detail? I would be interested to look at this draft. Thanks. Bruno Regards, Charlie P. On 9/5/2014 1:48 AM, Alper Yegin wrote: Alex, DMM is not meant to be only about a bunch of MIP-based solutions. There are various components in DMM solution space that'd also work with GTP-based architectures. For example, identifying the mobility needs of flows. Or, conveying the mobility characteristic of a prefix to the UE. Alper On Sep 4, 2014, at 1:14 PM, Alexandru Petrescu wrote: Le 03/09/2014 20:53, Brian Haberman a écrit : Behcet, On 9/3/14 2:33 PM, Behcet Sarikaya wrote: You don't seem to understand my points. That is quite possible. Your comment on the list was "I am against any deployment work before we decide on a solution..." I read that as an objection to having the deployment models work item on the agenda. Please do tell me what I am missing. Regards, Brian Hi, I am following the discussion and me too I do not quite understand what is the complain. I am happy to learn that a if a WG is to be formed then it would be around a solution rather than just requirements or architecture. That said, I would like to express a worry along similar lines. In DMM, precedents and the keen NETEXT, there seems to be a hard-rooted disconnect between the product developped - (P)Mobile IP - and the deployments. We know for a fact that 3GPP deployments (2G/3G/4G) do not use (P)Mobile IP. We also know that 3GPP specs do mention Mobile IP. To such a point that I wonder whether 3GPP has not the same disconnect as here. On another hand, we do have indications of where (P)Mobile IP is used - the trials, the projects, the kernel code, and not least the slideware attracting real customers. The worry: develop DMM protocol while continuing the disconnect. Alex _______________________________________________ dmm mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/dmm _______________________________________________ dmm mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/dmm _______________________________________________ dmm mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/dmm _______________________________________________ dmm mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/dmm _______________________________________________ dmm mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/dmm _______________________________________________ dmm mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/dmm _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ dmm mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/dmm
_______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
