Hi, >> >> 2/ When you describe the establishment of bidirectional tunnels >> >> between MAGs you refer RFC5213 for further detail, but RFC5213 does >> >> not include tunnel establishment between MAGs. This is not covered >> >> by standard PMIP (it implies an extension). >> > You are right that RFC5213 does not include tunnel establishment > between >> > MAGs.we will correct the description in the next version. >> > we can refer to section6.2 of draft-ietf-netext-pmip-lr for tunneling >> > between the MAGs. >> >> See M-tunnel configuration described in section 4 of above draft. > There can be vavious tunnel negotiation mechanisms between MAG,better > based on existing mechanism.
Does your draft assume MAG acts as MLD proxy for remote subscription and also acts as PIM router for local routing? >> >> 4/ Through the PBU-Q/PBA-Q sequence of messages you are able to >> >> obtain the CoA for the MN source. However, how do you know in >> >> advance that the MN source is attached to the domain? There is no >> >> way of knowing it in advance, and because the MN HoA is not an >> >> address of the PMIPv6 domain, how do you deduce that it is a MN >> >> source? Do you send the PBU-Q for all kind of SSM subscriptions? >> >> Additionally, what happens (what is the message) in case the source >> >> is effectively not attached to the PMIPv6 domain >> > Yes,we can not know in advance that the MN source is attached to the same >> > domain.So if the MAG in the listener side figures(through the PBU-Q/PBA-Q >> > messages) that the MN source is not attached to a MAG in the domain, it >> > will process the multicast message as normal. >> > We send the PBU-Q every time when the MAG in the listener side first joins >> > the (S,G) channel. >> > We don't solve the case when the source is not attached to the PMIPv6 >> > domain, the draft assumes that the MN source and MN listener are both >> > mobile nodes attached to their own MAG. >> >> I don't understand why other query message (except IGMP/MLD query) is >> needed. > The query message in our solution is used to locate the MN source in the > PMIPv6 domain. Then I may ask the same question Luis did. Does this extension properly work with moving source? Regards, -- Hitoshi Asaeda _______________________________________________ multimob mailing list [email protected] https://www.ietf.org/mailman/listinfo/multimob
