Hi, Since Jari brought up this discussion, I would like to put forth an issue about interworking Monami6 with NEMO. In Monami6, a mobile node knows the traffic condition over its multiple links. Thus, the mobile node is able to inform its home agent how to route the flow to the mobile node (through the various filter rules setting methods proposed in the WG).
The mobile node now associates with a mobile router with multiple egress paths (roaming into NEMO). However, the mobile node has no way of knowing the existence of multiple paths (and their network characteristics) to continue on with flow filtering. On the other hand, the mobile router cannot perform efficient flow filtering since the mobile router has no way to know the traffic requirements of the mobile node's flow. The fact is that the tunnel ends at the mobile router whereas the traffic ends at mobile node cause such a problem with flow filtering. Any thoughts on how such issue can be solved? Regards, Benjamin Lim > -----Original Message----- > From: Jari Arkko [mailto:[EMAIL PROTECTED] > Sent: Wednesday, February 14, 2007 9:00 PM > To: Internet Area > Cc: [EMAIL PROTECTED] > Subject: [Int-area] Lifting up a filter discussion from Monami6 > > > I would like to lift up one issue from the Monami6 WG > to a more general discussion. Monami6 is developing an > extension to Mobile IPv6 / Nemo so that a mobile node could > register its presence in multiple locations simultaneously. > One of things that they expect to be able to do is to control > what traffic goes to what care-of address; this flow to this > address, and the other flow to that other address. Mobile nodes > can obviously decide by themselves what outgoing interface to use. > However, in order for a home agent to deal with return traffic > properly, the mobile node has to tell it what policy to > employ. > > The working group has debated between a number of different > approaches for doing this. In one approach, draft-soliman- > monami6-flow-binding the mobile node adds a filter to a Mobile > IPv6 Binding Update to tell what traffic should use this binding. > Another approach, draft-larsson-monami6-filter-rules, decouples > the policy exchange from the mobility protocol. The policies are > exchanged at a different time (typically earlier) and carried by a > different protocol (in this case over UDP). Yet another draft, > draft-mitsuya-monami6-flow-distribution-policy also separates > the mobility protocol and policy transfer, and carries > the policies in HTTP. > > Monami6 should of course decide how they want to design this. > But this may be an interesting debate from a more generic point > of view. Do we have input for them? For instance, are there needs > in HIP/Shim6/Mobike space for similar functionality? Should the > designs be tailored for each of these situations? Is there some > advantage or disadvantage in looking at a generic solution? > Would a generic solution be doable? > > Without going into too much detail about the specific proposals > it seems that there are actually a number of different topics here: > - carrier protocol choice > - policy container format > - timing of the policy exchange > - securing the transfer > - etc > > Thoughts? > > Jari > > _______________________________________________ > Int-area mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/int-area _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
