Re: [DMM] Comments on DMM Gap Analysis.

[<[e-mail]>]

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