Re: [DMM] Comments on DMM Gap Analysis.

[Peter McCann <[e-mail]>]

Maybe the document should be entitled "Existing IP Mobility Practices
and DMM Gap Analysis."  I am not sure there are any "DMM Practices"
currently.

-Pete

Zuniga, Juan Carlos wrote:
> Hi Pierrick, all,
> 
> The document title is "DMM Practices and Gap Analysis", and the
> intention is to address both. When we presented at the meeting it I
> made it clear that we wanted to show our approach to the problem,
> which was first to agree on what are the "current practices" that we
> want to consider, and then provide a "gap analysis" wrt the DMM
> requirements document.
> 
> We are currently working on a new version of the document taking into
> account the feedback we got at the meeting and on the ML. We will
> provide more details about the current practices and will take a stab
> at the gap analysis for discussion.
> 
> Cheers,
> 
> Juan Carlos
> 
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]]
>> Sent: Wednesday, September 19, 2012 9:03 AM
>> To: '[e-mail]'; [e-mail]; [e-mail];
>> [e-mail]; Zuniga, Juan Carlos
>> Cc: [e-mail]
>> Subject: RE: [DMM] Comments on DMM Gap Analysis.
>> 
>> 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 : [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