Subject: [Monami6] RE: [Int-area] Lifting up a filter discussion from Monami6

From: "Benjamin Lim" <[email-masked]>
Date: Fri, 16 Feb 2007 11:05:33 +0800

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-masked]]
> Sent: Wednesday, February 14, 2007 9:00 PM
> To: Internet Area
> Cc: [email-masked]
> 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-masked]
> https://www1.ietf.org/mailman/listinfo/int-area

_______________________________________________
Monami6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/monami6

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 16 Feb 2007 06:10:39 +0100

Hi Benjamin,

> Any thoughts on how such issue can be solved?

While the proposals discussed in monami6 so far has been geared to transfer
of filter rules, this seems to call for transfer not of filter rules, but
of a subset of policy declarations (some sort of preferences for quality
and cost of service) between the Mobile Router and the Node attaching to the
Mobile Network (the MNN).

I think that as a general problem, this may be less well understood, and
possibly more complex, than expressing filter rules.  The filter rules I
see needed by for instance monami6 appear to be a subset of filter rules
that can be expressed for firewalls today, using well-defined languages; but
I'm not aware of mature languages for expressing cost/latency/bandwidth/
/reliability/security/etc. preferences, and how to weigh them against each
other.

I know that some work has been done in SHIM6 on expressing and communicating
policy, but don't know that work well enough to know whether it would be
applicable to this case.

	Henrik

---

From: Thierry Ernst <[email-masked]>
Date: Fri, 16 Feb 2007 15:27:51 +0100

Hi,

Do we need to keep ccing int-area (at the same time of Monami6) ?

The term "Mobile Node" is missleading. What Benjamin is talking about
is a Mobile Network Node (MNN).

So, the issue raised by Benjamin is known for a long time, even before
the set up of Monami6. The issue is discussed in
http://www.ietf.org/internet-drafts/draft-ietf-nemo-multihoming-issues-07.txt
section 4.10, and the conclusion (section 5 same draft) is that the
issue is not specific to mobility at all (but is more important to be
solved in mobility scenarios). This is why it is not brought up to the attention of the Monami6 working group. 

However, since it is more important to be solved for Monami6 use case,
we could contemplate to solve it within Monami6, if interest arises. Of
course, the solution should not be specific to mobility since the
mobility protocol doesn't intervene between MR and MNN.

This issue is also worked out by the automotive industry, within ISO
TC204 WG16 (they have their own solution using SNMPv3).

Thierry.

On Fri, 16 Feb 2007 06:10:39 +0100

-- 
Thierry ERNST, PhD 
INRIA Rocquencourt France Project-Team IMARA / JRU LARA
http://www.lara.prd.fr +33 1 39 63 59 30 (office)

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 16 Feb 2007 16:16:48 +0100

Hi Thierry,

Since you're top posting, I'm not sure if you're responding to
Benjamin or me.

> Do we need to keep ccing int-area (at the same time of Monami6) ?

Depends on how general the issue is, I guess.

> is a Mobile Network Node (MNN).

Yes, and so am I, using that exact term, if you look again at my response
to Benjamin.

> attention of the Monami6 working group. 

Yes, it's covered in 4.10 of this document, to about the same level of
details as done in this thread so far.  However, the distinction between
filter rules and policies/preferences, which I believe is important in
this context, isn't covered there.

> TC204 WG16 (they have their own solution using SNMPv3).

Do you have more details about this, maybe a pointer to available documents?

	Henrik

---

From: Thierry Ernst <[email-masked]>
Date: Fri, 16 Feb 2007 17:30:25 +0100

>Since you're top posting, I'm not sure if you're responding to

Actually, I was replying to Benjamin, but replying back using the last
mail on the thread ;-)

>this context, isn't covered there.

I don't know how important the distinction is, and so far I've only
heard and dealt with policies and preferences. They could be probably
be specified in whatever language (including proprietary) as long as
there is a transport to convey them between the two nodes. How this is
used at the MR is all internal and is not of interest from an IETF
standardization point of view. 

>Do you have more details about this, maybe a pointer to available documents?

Nop, the documents are not public. But here is their public website:
http://www.calm.hu/

Thierry.

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 16 Feb 2007 20:13:42 +0100

Hi Thierry,

> Actually, I was replying to Benjamin, but replying back using the last

Ah. Ok.

...
> Nop, the documents are not public. But here is their public website:

Ok, thanks!  It does indeed look as if they are considering distribution
of preference policies within the system, but it doesn't look as if the
architecture requires a standardized protocol for transfer of preferences.
Hard to tell for certain, though, based on the information available on
the website.

	Henrik

---

From: Thierry Ernst <[email-masked]>
Date: Mon, 19 Feb 2007 12:50:43 +0100

Hi Henrik,

>Hard to tell for certain, though, based on the information available on

What I can tell you is that they have their own solution, and this
solution is part of the CALM standard which is supposed to be deployed
in vehicles. So, this would be the standard solution within the vehicles
for ITS applications. They dot not necessarily need an IETF standard,
and don't even try, though they do reuse some of the existing standards
like NEMO Basic Support, etc. 

Thierry.

---

From: "Benjamin Lim" <[email-masked]>
Date: Thu, 22 Feb 2007 13:54:27 +0800

Hi,

Sorry for the late response. I have no access to my mail client for the past
few days. 
Response inline from snip parts of various mails.

>From Thierry;
[snip]
> mobility protocol doesn't intervene between MR and MNN.
[/snip]

[Ben] Exactly what I feel. Based on the mails I have read on this
discussion, I feel that monami6 draft(s) on flow bindings should consider
such use case of preference settings of MNN being attached to a MR. This is
inline with monami6 being supportive of NEMO.

>From Hesham;
[snip]
>>Just as an example. In NEMO the MNN might have a need to set the preferred

>>routes for it's traffic into the MR. For instance, think of a case where
the MNN is a 
>>laptop and the user uses a cellular phone with multiple interfaces as a
MR. In this 
>>scenario the user most certainly would expect some control over the
application 
>>flows from the laptop trough the phone.
>
> => Of course, so if it gets the prefixes from the MR and associated 
> properties with each one it can make that choice. I don't see the 
> relationship between this issue and the current discussion on this 
> thread.
[/snip]

[Ben] From what Hesham mentioned on prefix and associated properties, this
could be a possible solution to the problem in which the MNN in NEMO has no
way of knowing the existence of multiple paths (and their network
characteristics). Since there is mention on applicability on flow bindings
to HMIPv6, why not mention applicability for MNN in NEMO in the draft and
include this point? This is just my suggestion.

Regards,
Benjamin Lim