Re: [DMM] Comments on DMM Gap Analysis.

[Behcet Sarikaya <[e-mail]>]

Hi Jouni,

Isn't the gap obvious? Has this not yet been discussed already? The
gap is the use of a central anchor. Yes there is possibility of LMA/HA
selection but it is not dynamic.

Why can't we document this in a document quickly and move on?

What we need to do is to document the implications of moving away from
this single anchoring towards dynamic anchoring or DMM. As I
mentioned, what is the impact of cloud networks in DMM?

As you mentioned, we should also consider 3GPP case, i.e. GTP which
brings control plane/data plane separation. What are the impact of DMM
in control/data plane separation?

I think to write a document on these is the real challenge.

Regards,

Behcet

On Thu, Sep 20, 2012 at 3:34 AM, Jouni Korhonen <[e-mail]> wrote:
> Pierrick,
>
> On 9/19/12 4:03 PM, "ext [e-mail]"
> <[e-mail]> wrote:
>
>> 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 :-)
>
> The "distributed" environment would be what we have now.. Like if you
> operate a network that has more than one anchor node, you can consider that
> as a system which could enable distribution. And if e.g. anchor distribution
> is possible/done today that would be documented (example: LMA selection
> during the attach time based on geographical location).
>
>     o Practices: Document practices for the deployment of existing
>        mobility protocols in a distributed mobility management
>        environment.
>
> Gap analysis is then based on that.. and
>
>> Actually, in the charter, we agreed to firstly "document practices for the
>> deployment of existing mobility protocols in a distributed mobility management
>
> ..during the meeting I asked the question whether we deal current practices
> and gap analysis in the same document, since there are conflicting
> milestones. There was no clear answer from the room as far as I remember
> (and minutes indicate).
>
> I am (still) on the opinion that these two can and probably should be the
> one same document. There are not too many current practices given the rather
> low number of _really_deployed_ IP mobility technologies that we can write
> meaningful current practices about. Then you would do the gap analysis
> against those.
>
>> 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?
>
> I should have been clearer that I would like to see these two combined.
> o Submit I-D 'Practices and Gap Analysis' as a working group document.
>
> That also kind of forces strict scoping of mobility technologies I mentioned
> about in my earlier mail.
>
> I don't want to see a current practices or gap analysis of solutions that
> has no relation to an existing and rather short term planned deployment
> reality..
>
>> 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
>
> There are issues between datatracker and tools coordination or something.
> Tools guys are on this. You can find older(?) version of the charter on the
> tools page and yesterday the charter re-appeared again to datatracker.
>
>> 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?
>
> Mmm yes. But if you combine both you should be fine too. If folks think and
> insist that there shall be a current practices as a separate document, so be
> it.
>
> - Jouni
>
>
>
>>
>> BR,
>> Pierrick
>>
>>> -----Message d'origine-----
>>> De : [e-mail] [mailto:[e-mail]] De la part de
>>> [e-mail]
>>> Envoyé : mercredi 19 septembre 2012 13:11
>>> À : [e-mail]; [e-mail]; [e-mail];
>>> [e-mail]
>>> Cc : [e-mail]
>>> 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: [e-mail] [mailto:[e-mail]] On Behalf Of
>>>> jouni korhonen
>>>> Sent: woensdag 19 september 2012 9:58
>>>> To: [e-mail]; h chan; Juan Carlos Zuniga
>>>> Cc: [e-mail]
>>>> 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
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/dmm
>>>>
>>>> _______________________________________________
>>>> dmm mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/dmm
>>> _______________________________________________
>>> dmm mailing list
>>> [e-mail]
>>> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmm