Re: [DMM] Comments on DMM Gap Analysis.

[Marco Liebsch <[e-mail]>]

Hi,

of course the gap analysis can be limited to a study and assessment of solely available
IP mobility protocols. The question is against which template these gaps are assessed.
To tackle and address the complete space of DMM problems (and some of them are
very specific to DMM) I doubt that relying only on mobility extensions is sufficient.
Simply because the nature of DMM moves some problems out of the IP mobility
space. Squeezing them to fit into a mobility problem and solving them by mobility extension
may work functionally, but..

In the past, backend protocols played always role in solving the complete problem.
IMHO, some non-mobility protocols should be included in the analysis and the
solution space. If the WG wants to start with analyzing solely mobility protocols first
and extend the scope in a next step, fine. But I just worry that the limited gap analysis
will be taken as base to solve DMM completely as mobility protocol extension. That'll
help only to be fast, nothing else.

marco


>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On Behalf Of
>liu dapeng
>Sent: Donnerstag, 20. September 2012 05:47
>To: [e-mail]; jouni.nospam; Julien Laganier
>Cc: [e-mail]; [e-mail]
>Subject: Re: [DMM] Comments on DMM Gap Analysis.
>
>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, [e-mail] <[e-mail]>:
>> 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
>>
>
>
>--
>
>------
>Best Regards,
>Dapeng Liu
>_______________________________________________
>dmm mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/dmm