Hello All, I also have the similar thinking that we should first document and agree on the "practices for the deployment of existing mobility protocols in a distributed mobility management environment". After that, if we find that there indeed some "gap" existing, we can then move to "gap analysis".
Best Regards, Dapeng 2012/9/19, [email protected] <[email protected]>: > Hi Jouni and Julien, > > > Sorry for jumping into the discussion but I'm a little bit confused with > recent discussions in DMM. So, let me ask for clarifications about the scope > of the gap analysis... > > The WG is now tackling with the work item 'Practices and Gap Analysis' and, > in my understanding, we are expected to provide a gap analysis regarding the > use of mobility protocols in a distributed mobility management environment. > However, it seems that the scope of discussions on gap analysis is > different.... and I'm confused :-) > > Actually, in the charter, we agreed to firstly "document practices for the > deployment of existing mobility protocols in a distributed mobility > management environment" and, then, to make the gap analysis. However, > considering current discussions on "gap analysis": the document on practices > has been omitted and discussions are about vanilla mobility protocols and > architectures with respect to DMM requirements. So, maybe, such > considerations are interesting in the scope of the problem statement, but it > seems to me that it is not the goal of the gap analysis, as initially > intended in the charter. Am I missing something? > > If I refer to previous DMM charter (because current DMM charter is empty... > BTW, is there a reason for an empty charter?), one Work item was: "Document > practices for the deployment of existing mobility protocols in a distributed > mobility management environment". Is this document still in DMM stuff? If > yes, shouldn't we document practices before going into the gap analysis? > > BR, > Pierrick > >> -----Message d'origine----- >> De : [email protected] [mailto:[email protected]] De la part de >> [email protected] >> Envoyé : mercredi 19 septembre 2012 13:11 >> À : [email protected]; [email protected]; [email protected]; >> [email protected] >> Cc : [email protected] >> Objet : Re: [DMM] Comments on DMM Gap Analysis. >> >> Hi Jouni, Hi all, >> >> After discussing this issue with Carlos Jesús Bernardos and Juan Carlos >> Zuniga, we concluded that the following set of possible technologies >> could be included in the Gap analysis draft: >> >> => Shim6: Level 3 Multihoming Shim Protocol for IPv6 http://www.rfc- >> editor.org/rfc/rfc5533.txt >> >> >> => LISP Mobile Node >> http://www.ietf.org/id/draft-meyer-lisp-mn-07.txt >> Locator/ID Separation Protocol (LISP) >> http://www.ietf.org/id/draft-ietf-lisp-23.txt >> >> => Mobile IPv6 Fast Handovers >> http://tools.ietf.org/id/draft-ietf-mipshop-rfc5268bis-01.txt >> This is the draft that became then RFC5568, so no need to mention it. >> http://www.rfc-editor.org/rfc/rfc5568.txt >> >> >> => Fast Handovers for Proxy Mobile IPv6 >> http://www.rfc-editor.org/rfc/rfc5949.txt >> >> => Host Identity Protocol >> http://www.rfc-editor.org/rfc/rfc4423.txt >> http://www.rfc-editor.org/rfc/rfc5201.txt >> http://www.rfc-editor.org/rfc/rfc6253.txt >> http://www.rfc-editor.org/rfc/rfc5206.txt >> >> >> >> => IKEv2 Mobility and Multihoming Protocol (MOBIKE) >> http://www.rfc-editor.org/rfc/rfc4555.txt >> >> >> => GTPv2-C: 3rd Generation Partnership Project; Technical Specification >> Group Core Network and Terminals; 3GPP Evolved Packet System (EPS); >> Evolved General Packet Radio Service (GPRS) Tunnelling Protocol for >> Control plane (GTPv2-C); Stage 3 (Release 11) >> http://www.3gpp.org/ftp/Specs/archive/29_series/29.274/29274-b30.zip >> >> Please inform us if this list makes sense to you? >> >> Best regards, >> Georgios >> >> >> > -----Original Message----- >> > From: [email protected] [mailto:[email protected]] On Behalf Of >> > jouni korhonen >> > Sent: woensdag 19 september 2012 9:58 >> > To: [email protected]; h chan; Juan Carlos Zuniga >> > Cc: [email protected] >> > Subject: Re: [DMM] Comments on DMM Gap Analysis. >> > >> > >> > Folks, >> > >> > It has been rather silent on the list recently. Regarding the >> "explosion" of >> > possible technologies in the GAP analysis, we discussed (chairs) that >> it is >> > better to scope the area "a bit". The charter today has the >> assumption that >> > we build on top of existing _IP_ _Mobility_ protocols (and bunch of >> IETF >> > defined examples follow). So, to tighten the scope, the Gap Analysis >> should >> > leave all routing, session (SIP, ..), transport (MPTCP, SCTP, DCCP, >> ..), >> > locator/identifier split (HIP, Lisp, ..), naming (DNS tricks, ..) etc >> based >> > solutions out. Coarse but should help us to make progress. We could >> discuss >> > whether transport layer solution like SCTP fit in but I do not see >> them as end- >> > 2-end solutions being deployable in Internet at the moment. >> > >> > Let us stick with technologies out there that have/had a place in >> sun: few >> > MIP variants, MOBIKE, stuff in 3GPP(2) (oops.. but I think this >> deserves to be >> > evaluated since they are somewhat popular), and what applications do >> > (reconnecting..). This analysis should be down to earth practical and >> realistic >> > on what is already out there to play with. >> > >> > - Jouni & Julien >> > >> > >> > >> > On Jul 27, 2012, at 3:53 PM, Jong-Hyouk Lee wrote: >> > >> > > Dear Anthony and Juan. >> > > >> > > I enjoyed the both gap analysis documents (draft-chan-dmm- >> framework- >> > gap-analysis-02 and draft-zuniga-dmm-gap-analysis-01). Here I give >> some >> > comments that should be used directly in the gap analysis documents >> if you >> > guys like. >> > > >> > > Kindly consider the followings during the gap analysis discussion >> (since I will >> > not be attending the IETF meeting this time). >> > > >> > > 1. Comment on address (resource) management in a DMM environment. >> > > 2. Comment on a deployment of a client-based mobility solution >> (i.e., >> > MIPv6) in a DMM environment. >> > > 3. Commnet on neighbor mobility anchors' information in a DMM >> > environment. >> > > 4. Commnet on an establishment of security associations in a DMM >> > environment. >> > > >> > > === 1. Comment on address (resource) management in a DMM >> > environment. >> > > === When existing IP mobility support protocols (e.g., MIPv6 and >> PMIPv6) >> > are considered to be deployed in a DMM environment, a mobile node >> (MN) >> > is allowed to configure a new address while keeping its previous >> address(es). >> > It introduces the following differences with the address (resource) >> > management of the existing ones: >> > > >> > > MN's address configured at the interface with a DMM environment: n >> = >> > > (IP address at the current access network + previously configured >> IP >> > > address(es) with ongoing sessions) MN's address configured at the >> > > interface without a DMM environment: 1 = (care-of address in MIPv6 >> or >> > > MN's home address in PMIPv6) >> > > >> > > This leads a couple of considerations we didn't have with the >> existing >> > > IP mobility support protocols. For instance, >> > > >> > > 1) MN's address management: use of a newly configured address at >> the >> > current access network for new communication sessions while a proper >> > address selection for previously established ongoing communication >> > sessions. >> > > >> > > 2) Additional treatment for ingress filtering: Ingress filtering is >> widely used >> > against source address spoofing. The source addresses (especially, >> the >> > network prefix part) of incoming packets are strictly checked to make >> sure >> > that those packets are actually from the network that they claim to >> be from. >> > As the MN are allowed to send data packets with the previously >> configured >> > address(es) at the new access network, those data packets would be >> filtered >> > at the ingress filtering place because the source address of those >> data >> > packets is not belonging to the new access network. Accordingly, an >> > additional treatment for ingress filtering is required. >> > > >> > > 3) MN's address increase at the MN's interface: Recall the number >> of MN's >> > address configured at an interface is n. Then, n is increased, as the >> MN >> > changes its point of attachment while keeping its ongoing >> communication >> > sessions. It brings the question: "How many addresses are currently >> possible >> > to be configured at an interface?" >> > > >> > > 4) Routing entry increase at the serving mobility anchor: Let the >> serving >> > mobility anchor is the mobility anchor serves the MN. Traffic >> associated to >> > the MN travels via the serving mobility anchor. The increase of the >> addresses >> > associated to the MN, n, is not only concerning to the MN, but also >> > concerning the serving mobility anchor as it contributes the increase >> of >> > routing entries for the MN. >> > > >> > > === 2. Comment on a deployment of a client-based mobility solution >> > > (i.e., MIPv6) in a DMM environment. === When a client-based >> mobility >> > solution (i.e., MIPv6) is consiered to be deployed in a DMM >> environment, an >> > MN is involved in mobility signaling such as Binding Update and >> > Acknowledgement messages. This is the big difference with the >> network- >> > based mobility solution (i.e., PMIPv6). As the MN send signaling to >> inform its >> > movement to its mobility anchor, the client-based mobility solution >> allows >> > the MN to supply client-centric decision for mobility management. >> > > >> > > Suppose that the origin mobility anchor is the mobility anchor >> where the >> > MN has configured its IP address and established ongoing >> communication >> > sessions with the IP address. The number of origin mobility anchors >> are n - 1. >> > Recall that the serving mobility anchor is the mobility anchor where >> the MN is >> > being served by. Then, the MN's involvement in mobility signaling >> brings us >> > the questions: "Should we let the MN send mobilty signaling to its >> all mobility >> > anchors?" or "Would it make sense that the MN only sends mobility >> signaling >> > to its serving mobility anchor?" Depending on the choice, we will >> have >> > different results: >> > > >> > > 1) "MN sends mobility signaling to its all mobility anchors" >> causes: >> > > 1.1 increased mobility signaling load, e.g., signaling * (n - 1). >> > > 1.2 bidirectional tunnels are established between the MN and its >> mobility >> > anchors. >> > > 1.3 tunneling overhead over the air is present. >> > > 1.4 but the tunnels are terminated at the MN so that the MN has >> control >> > over the tunnels. >> > > >> > > 2) "MN sends mobility signaling only to its serving mobility >> anchor" causes: >> > > 2.1 reduced mobility signaling load, e.g., signaling * 1. >> > > 2.2 bidirectional tunnels are established between the serving >> mobility >> > anchors and origin mobility anchors. >> > > 2.3 tunneling overhead over the air can be avoided. >> > > 2.4 but the MN does not have control over the tunnels so it might >> affect to >> > NEtwork MObility (NEMO) as the MN (i.e., MR in NEMO) loses the >> tunneling >> > control. >> > > >> > > === 3. Neighbor mobility anchors' information in a DMM environment. >> > > === In the client-based mobility solution such as MIPv6, the >> network >> > topology information does not required to be known to the mobility >> anchor, >> > i.e., home agent (HA), since the HA is informed the current location >> of the >> > MN. As the HA knows the current location of the MN, it is able to >> tunnel >> > packets associated to the MN. In the network-based mobility solution >> such >> > as PMIPv6, the similar things happen, i.e., the tunnel between the >> local >> > mobility anchor (LMA) and the mobile access gateway (MAG) is >> established >> > for a given MN. >> > > >> > > However, as mobility anchors are distributed and bidirectional >> tunnels (for >> > a given MN) between the distributed mobility anchors are required, >> the >> > neighbor mobility anchors' information should be provided to the MN >> or the >> > mobility anchor for the establishment of the directional tunnels or >> the >> > update of the MN's current location. >> > > >> > > Decoupling the data plane and control plane while keeping a >> centralized >> > node maintaining the mobility context including neighbor mobility >> anchors' >> > information (e.g., identification, IP address, etc) in a DMM >> environment is >> > one of possible solutions. >> > > >> > > === 4. Comment on an establishment of security associations in a >> DMM >> > > environment. === For each IP mobility support protocol, different >> security >> > associations (SAs) are required for providing secure mobility >> services to MNs >> > as follows: >> > > >> > > 1) MIPv6 >> > > 1.1 SA between MN and HA. >> > > 1.2 SA between MN and serving access router (AR) providing wireless >> link >> > to the MN. >> > > >> > > 2) Fast Handover MIPv6 (FMIPv6) >> > > 2.1 SA between MN and HA. >> > > 2.2 SA between MN and serving AR. >> > > 2.3 SA between previous and new ARs. >> > > >> > > 3) PMIPv6 >> > > 3.1 SA between MN and serving MAG. >> > > 3.2 SA between serving MAG and LMA. >> > > >> > > 4) Fast Handover PMIPv6 (FPMIPv6) >> > > 4.1 SA between MN and serving MAG. >> > > 4.2 SA between serving MAG and LMA. >> > > 4.3 SA between previous and new MAGs. >> > > >> > > Note that the above ones do not consider the cases of SA with a >> security- >> > backend server (e.g., AAA server) and with a correspondent node (CN). >> > > >> > > However, depending on DMM solutions, SAs are configured that are >> > > different from those of the existing IP mobility support protocols. >> > > For instance, >> > > >> > > 1) the case of "MN sends mobility signaling to its all mobility >> > > anchors" (client-based mobility solution) >> > > 1.1 SA between MN and serving mobility anchor providing wireless >> link to >> > the MN. >> > > 1.2 SA between MN and origin mobility anchors, i.e., (n - 1) SAs >> required >> > with MN and origin mobility anchors. >> > > >> > > 2) the case of "MN sends mobility signaling only to its serving >> > > mobility anchor" (client-based mobility solution) >> > > 2.1 SA between MN and serving mobility anchor. >> > > 2.2 SA between serving mobility anchor and origin mobility anchors, >> i.e., (n >> > - 1) SAs required with serving mobility anchor and origin mobility >> anchors. >> > > >> > > 3) the case of "serving mobility anchor sends signaling on behalf >> of >> > > the MN to origin mobility anchors" (network-based mobility >> solution) >> > > 3.1 SA between MN and serving mobility anchor. >> > > 3.2 SA between serving mobility anchor and origin mobility anchors, >> i.e., (n >> > - 1) SAs required with serving mobility anchor and origin mobility >> anchors. >> > > >> > > Note that as like before SAs with a security-backend server (e.g., >> AAA >> > server) and with a CN are not presented. >> > > >> > > As shown above, DMM solutions (that relies on bidirectional >> tunnelings for >> > packet forwarding between MN and mobility anchors or between just >> > mobility anchors) might bring the key management issues to establish >> such >> > SAs. >> > > >> > > Since it's a holiday season, I cannot fully address all of them in >> my mind, but >> > kindly consider these ones. >> > > >> > > Cheers. >> > > >> > > -- >> > > RSM Department, TELECOM Bretagne, France Jong-Hyouk Lee, living >> > > somewhere between /dev/null and /dev/random >> > > >> > > #email: jonghyouk (at) gmail (dot) com >> > > #webpage: http://sites.google.com/site/hurryon/ >> > > >> > > _______________________________________________ >> > > dmm mailing list >> > > [email protected] >> > > https://www.ietf.org/mailman/listinfo/dmm >> > >> > _______________________________________________ >> > dmm mailing list >> > [email protected] >> > https://www.ietf.org/mailman/listinfo/dmm >> _______________________________________________ >> dmm mailing list >> [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, > France Telecom - 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, France Telecom - Orange is not liable for messages > that have been modified, changed or falsified. > Thank you. > > _______________________________________________ > dmm mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmm > -- ------ Best Regards, Dapeng Liu _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
