Hi Pierrick, Thanks for your interest and the questions. As you pointed out correctly the n-MAG shall not rely on the mobility unaware MN to get knowledge of the p-MAG thus we assume that this is shared by the LMA in PBU/PBA as described in ch. 3.2. We also had in mind future DMM applicability since we were faced with questioning of direct n-MAG - p-MAG relationship ... Which is less a problem in DMM where we assumed MAG=LMA. We therefore issued the (still active!) draft http://tools.ietf.org/id/draft-vonhugo-multimob-dmm-context-00.txt considering this.
And right, the flags should enhance the efficient resource usage - so B initiates Buffering of received multicast traffic at p-MAG (not to get lost in nowhere), F is to start Forwarding of stored and currently received data to n-MAG since connection to MN is established, and L to Leave the group and stop receive multicast data (of course only in case no other subscribing MN is attached to p-MAG). The usefulness however also depends on the real-time character of application and/or whether the application itself uses buffering in the terminal. I think compared to other HO enhancement drafts in Multimob we tried to rely as little as possible on FPMIP and FMIP, but adapt CXTP to mobile multicast situation specifically. Which way is the more pragmatic one may be discussed ... If you have any improvement suggestions please feel free to share with us so we might consider them in updating the draft (I just detected the outdated state ...). Thanks again and Best regards Dirk -----Ursprüngliche Nachricht----- Von: [email protected] [mailto:[email protected]] Im Auftrag von [email protected] Gesendet: Montag, 6. August 2012 15:59 An: [email protected] Betreff: [multimob] questions on multimob cxtp-extensions Hi Dirk, Hidetoshi, I've read http://tools.ietf.org/html/draft-vonhugo-multimob-cxtp-extension-01 and I think it is pragmatic way to support Handover in a PMIP based architecture. Actually, relying on a control plane between access routers is definitely in the scope of current network evolution, i.e. distributed mobile architecture. In your solution, the n-MAG is expected to request context transfer from the n-MAG. But, if the MN cannot come into play, how the n-MAG knows the p-MAG? I'm asking because I think we have similar question in DMM (Distributed Mobility Management) where the n-MAG is supposed to contact the p-MAG acting as LMA... but that's another story, I just want to stress the consistency between your approach and current DMM considerations. If I understood correctly, you are suggesting a temporally transfer of multicast data between access routers. This forwarding state is controlled by the n-MAG via new flags in CXTP. IMU, we need flags to start and stop forwarding. L flag allows to stop forwarding, right? but difference between B and F flags, is not clear to me. Can you explain? Thanks. BR, Pierrick _________________________________________________________________________________________________________________________ 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. _______________________________________________ multimob mailing list [email protected] https://www.ietf.org/mailman/listinfo/multimob _______________________________________________ multimob mailing list [email protected] https://www.ietf.org/mailman/listinfo/multimob
