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: dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] On Behalf Of > jouni korhonen > Sent: woensdag 19 september 2012 9:58 > To: dmm@ietf.org; h chan; Juan Carlos Zuniga > Cc: dmm-cha...@tools.ietf.org > 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 > > dmm@ietf.org > > https://www.ietf.org/mailman/listinfo/dmm > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
