Re: [DMM] Comments on DMM Gap Analysis.

[liu dapeng <[e-mail]>]

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