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 [email protected] https://www.ietf.org/mailman/listinfo/dmm
