I would be sympathetic to developing something generic that works for multiple protocols instead of just Mobile IP, while also keeping in mind the issue of mobility and latency concerns associated with that. One thing to take into account is that this exchange is not necessarily a one-time exchange and policies and filters may change over time, based on the current connection capabilities of an end host. In such cases, some of this signaling may potentially be bound to handoffs and in the context of Mobile IP or MOBIKE-like protocols, if this means separate signaling exchanges before the flow changes can happen, it could be less than useful.
I had briefly discussed this with Dave Thaler in San Diego and we had talked about defining the flow information in a generic format, perhaps as an IPv6 extension header or as a Destination Option. If such an approach were to be taken, this information could then be carried in any protocol, which would get rid of additional signaling and latency concerns associated with it. So, from this point of view, a couple of different things would need to happen - an independent specification needs to define such an extension header or destination option and the fields that go into it; a different specification would then describe how this is carried in a given protocol (say, Mobile IP) and how the information is secured within that context. Thoughts on something like this? Vidya > -----Original Message----- > From: Jari Arkko [mailto:[EMAIL PROTECTED] > Sent: Wednesday, February 14, 2007 5:00 AM > 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
