Dear authors, I read the draft "draft-seite-mext-dma-00" and have comments/questions:
1. The mobility support described in the draft seems for client mobility. In other words, it's hard to apply the suggested dynamic mobility anchoring scheme into a node dedicated for continuous services to clients.
2. In the suggested dynamic mobility anchoring scheme, data packets of a communication session established in a previous access network (MAR1) is forwarded from MAR1 to the current MAR. This data packet forwarding must be continuous as the address used in the communication session is continuously used. Note that the MN is not only the communication session initiator, but the CN could be. The data packet forwarding must impact the whole network performance as the session duration is longer, session is heavier, or mobility is higher.
3. Since the suggested dynamic mobility anchoring scheme allows the MN to send/receive data packets having different network prefix compared with that of the current access network, I'm not sure if the suggested one properly works in existing network security mechanisms. For instance, authors should address conflicts over ingress filtering mechanisms.
4. Since the suggested dynamic mobility anchoring scheme allows the MN to establish a communication session with its CN via a new address obtained in a new network. In other words, 1) the MN establishes its communication session with the CN via HoA1 at MAR1; 2) when the MN moves to MAR2, it possibly establishes a new communication session with the CN via HoA2 at MAR2 in order to avoid the overhead of data packet forwarding. This means that even if the MN wants to keep the same communication session with the CN, it must be re-establishes, i.e., making a new communication session with the CN. In addition, making the new communication session requires security operations again between the MN and CN. Authors should think the cost in handovers: continuous communication session maintaining vs. new session establishment.
5. Could you describe little bit more about the entity storing the session DB for all MNs? Hummm...we're talking about DMM, but the entity is a centralized entity in an architectural view; all MARs contacts for MN's session information.
Thanks. -- IMARA Team, INRIA, France Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random #email: jong-hyouk.lee (at) inria.fr || hurryon (at) gmail.com #webpage: http://sites.google.com/site/hurryon/ _______________________________________________ MEXT mailing list [email protected] https://www.ietf.org/mailman/listinfo/mext
