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

Some quick thoughts.

1) This is a generic problem that is not specific to mobile IP. I
think it would (generally) be a mistake to adopt approaches that
are tightly coupled to the MIP protocols.

2) The overall topic of flow balancing has been discussed extensively
over a long period of time in the transport community. It is a very
hard problem, and seemingly simple approaches tend to come with a
number of limitations/disadvantages. Please extend this call for
input/participation to the TSV community (tsvwg, perhaps?).

Thomas

McCann Peter-A001034

2007-02-14 17:16:44 UTC

I think following up with the Transport area is a good idea.
In particular, I've always thought that the monami6 work
overlaps with NSIS. Both protocols transport packet
filters that affect the processing of packets.

I have also wondered how much of monami6 could be accomplished
with the use of multiple home addresses. After all, I would
expect each interface to have its own home address and applications
would need to bind themselves to the right home address to
function properly over a given link type. In other words, it
is important to solve this problem even in the absence of
a mobility management protocol.

-Pete

Post by Thomas Narten
Some quick thoughts.
1) This is a generic problem that is not specific to mobile IP. I
think it would (generally) be a mistake to adopt approaches that
are tightly coupled to the MIP protocols.
2) The overall topic of flow balancing has been discussed extensively
over a long period of time in the transport community. It is a very
hard problem, and seemingly simple approaches tend to come with a
number of limitations/disadvantages. Please extend this call for
input/participation to the TSV community (tsvwg, perhaps?).
Thomas
_______________________________________________
Int-area mailing list
https://www1.ietf.org/mailman/listinfo/int-area

j***@nokia.com

2007-02-14 17:12:25 UTC

Jari,

At a high level, I think having a common mechanism & format for
this kind of functionality would be a really good thing. I think that
this is applicable for MIPv6, NEMO, SHIM6, HIP, MoBIKE, etc. and
defining point solutions for each protocol would be a wrong way
to go.

I think the exact transport of the mechanism and security the
mechanism may be a protocol specific issue, if they are defined
within the specific protocols - however, it might be interesting
to define a common protocol / solution, if it would meet the
requirements of Monami (for example). Has anyone done an
analysis if doing this in-band is prefered over out-of-band
(or visa-versa)?

I agree, which I think leads us to the point that the policy would
usually be more of a hint than a mandate.

However, in order for a home agent to deal with return traffic
properly, the mobile node has to tell it what policy to employ.

Agreed

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?

I tend to think that re-use is a good thing here, so if there
are no show-stoppers, I'd suggest a common solution would be
good.

Without going into too much detail about the specific
proposals it seems that there are actually a number of
- carrier protocol choice
- policy container format
- timing of the policy exchange
- securing the transfer
- etc

I think those are some of the issues that need to be seen. I'd
think that policy container format SHOULD be common across
protocols, and for the other bullets, based upon an analysis
of in-band vs. out-of-band signaling uses, the other bullets
can be sorted out. If out-of-band signaling seems like a good
way forward, then all of the bullets should be made so that they
are usable by other protocols. If we think that in-band signaling
is a requirement, then we could define the common container
format and then have protocol-specific solutions for the rest.

John

Henrik Levkowetz

2007-02-14 20:21:50 UTC

Hi John,

Post by j***@nokia.com
Jari,
At a high level, I think having a common mechanism & format for
this kind of functionality would be a really good thing. I think that
this is applicable for MIPv6, NEMO, SHIM6, HIP, MoBIKE, etc. and
defining point solutions for each protocol would be a wrong way
to go.
I think the exact transport of the mechanism and security the
mechanism may be a protocol specific issue, if they are defined
within the specific protocols - however, it might be interesting
to define a common protocol / solution, if it would meet the
requirements of Monami (for example). Has anyone done an
analysis if doing this in-band is prefered over out-of-band
(or visa-versa)?

There seems to be multiple opinions here. Some analysis has
been done, leading to one of the monami6 proposals which
suggests out-of-band communication of filter rules:
draft-larsson-monami6-filter-rules; but as mentioned there is
an alternative monami6 proposal which advocates in-band signalling,
so there isn't full consensus on this.

The main reason I see (as one of the authors of
draft-larsson-monami6-filter-rules) for doing this out-of-band
is that the timing of events which cause changes to the filter
rules seem to have little correlation with handover events in
monami6; and I would expect something similar for NEMO, SHIM6,
HIP and MOBIKE.

The actual *binding* of a particular filter rule to a particular
endpoint *will* change on handover, though; so it is important
to do the split between rule definition and endpoint binding
right to achieve proper decoupling.

<snip some good comments>

Post by j***@nokia.com

Post by Jari Arkko
Without going into too much detail about the specific
proposals it seems that there are actually a number of
- carrier protocol choice
- policy container format
- timing of the policy exchange
- securing the transfer
- etc

First a little note on terminology -- in the monami6 discussions,
we've tried to use the word 'policy' to cover a number of factors,
including user preferences, which could influence the choice (at
the MN) of paths for various traffic, while the actual rules conveyed
from MN to HA, which can be applied to the traffic flow, is referred
to as filter rules. So rather than talk about policy container
format, I'd prefer to talk about filter rule container format...

Anyway, I'm in favour of the idea of making the filter rule
container format common across protocols, and I'd suggest that
in most cases, it would be appropriate to have a common defined
carrier protocol. I'm sure we'll see cases where optimization
or other considerations will make it attractive to define in-band
filter rule transport, but if a common carrier protocol and
method for securing the transfer has already been defined, that
would hopefully be delta work, rather than complete re-invention.

Henrik

Mark Townsley

2007-02-19 23:09:19 UTC

Just to add one more WG to the list, I believe pana had this discussion
in the past as well and settled upon draft-ietf-pana-snmp, but was
unwilling to commit to this being the *only* method.

- Mark

Post by j***@nokia.com
I think the exact transport of the mechanism and security the
mechanism may be a protocol specific issue, if they are defined
within the specific protocols - however, it might be interesting
to define a common protocol / solution, if it would meet the
requirements of Monami (for example). Has anyone done an
analysis if doing this in-band is prefered over out-of-band
(or visa-versa)?

I agree, which I think leads us to the point that the policy would
usually be more of a hint than a mandate.

However, in order for a home agent to deal with return traffic
properly, the mobile node has to tell it what policy to employ.

Agreed

I tend to think that re-use is a good thing here, so if there
are no show-stoppers, I'd suggest a common solution would be
good.

Narayanan, Vidya

2007-02-14 22:20:48 UTC

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-----
Sent: Wednesday, February 14, 2007 5:00 AM
To: Internet Area
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
- carrier protocol choice
- policy container format
- timing of the policy exchange
- securing the transfer
- etc
Thoughts?
Jari
_______________________________________________
Int-area mailing list
https://www1.ietf.org/mailman/listinfo/int-area

Henrik Levkowetz

2007-02-14 23:08:56 UTC

Post by Narayanan, Vidya
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 don't know if you read my recent post, but we've analysed this and found
that there is very little correlation (basically none) between the time
when a filter rule update is needed, and the time of handover.

Post by Narayanan, Vidya
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?

First, this cannot simply be described as 'flow information', so if
that was the context of your discussion, I don't think it is quite
relevant for this discussion.

Secondly, this assumes that the filter rules would consistently be
communicated to the end host at the other end of your regular traffic,
which is an assumption that doesn't generally hold for filter rules.

Thirdly, extension headers are for optional internet-layer information
(RFC 2460), and I'm not sure this is a fair categorization of such
filter rules as we're discussing here. I don't know how much people
care about proper layering these days, though ...

Finally, although filter rules wouldn't necessarily be very large in
size, I doubt that the size constraints associated with extension
headers make it appropriate to put filter rules in an extension header.
Remember that extension headers belong to the unfragmentable part of
an IPv6 packet, so there's a variable maximum size for such a header,
(depending on the presence of other extension extension headers); it
seems as if it would create a silly size constraint for filter rules
to define their default transport to be an IPv6 extension header.

Henrik

Narayanan, Vidya

2007-02-15 03:57:54 UTC

Hi Henrik,
Sorry, due to some intermittent connectivity issues, it turned out that
even though my application had sent the email before receiving the other
responses, it was actually only sent out later.

-----Original Message-----
Sent: Wednesday, February 14, 2007 3:09 PM
To: Internet Area
Subject: Re: [Int-area] Lifting up a filter discussion from Monami6

Post by Narayanan, Vidya
I would be sympathetic to developing something generic that

works for

Post by Narayanan, Vidya
multiple protocols instead of just Mobile IP, while also keeping in
mind the issue of mobility and latency concerns associated

with that.

Post by Narayanan, Vidya
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

Post by Narayanan, Vidya
to handoffs and in the context of Mobile IP or MOBIKE-like

protocols,

Post by Narayanan, Vidya
if this means separate signaling exchanges before the flow

changes can

Post by Narayanan, Vidya
happen, it could be less than useful.

I don't know if you read my recent post, but we've analysed
this and found that there is very little correlation
(basically none) between the time when a filter rule update
is needed, and the time of handover.

I went through your other email. I see that there may be little
correlation between filter rule updates and the time of handover in one
model of doing this. In other words, I think you are referring to a
model where there a bunch of rules set up in advance, say, with an ID
that maps to each rule and upon handoffs, it is the mapping of those IDs
to interfaces or IP addresses that needs to happen and not the actual
setting up or update of the rules itself. The rules could be updated at
any time (and perhaps somewhat infrequently), while the
rule-to-interface mapping is rather dynamic. I can subscribe to that
notion, although, the question I then have is whether we need to have a
certain protocol to set up the rules and other protocols to do the
rule-to-interface mapping. Having a separate protocol that sets up the
filter rules and updates the mapping would lead to the problem of having
to run that protocol separately at the time of handoff to update the
mapping. More notes below.

Post by Narayanan, Vidya
I had briefly discussed this with Dave Thaler in San Diego

and we had

Post by Narayanan, Vidya
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

Post by Narayanan, Vidya
and latency concerns associated with it. So, from this

point of view,

Post by Narayanan, Vidya
a couple of different things would need to happen - an independent
specification needs to define such an extension header or

destination

Post by Narayanan, Vidya
option and the fields that go into it; a different

specification would

Post by Narayanan, Vidya
then describe how this is carried in a given protocol (say,

Mobile IP)

Post by Narayanan, Vidya
and how the information is secured within that context.
Thoughts on something like this?

First, this cannot simply be described as 'flow information',
so if that was the context of your discussion, I don't think
it is quite relevant for this discussion.

No, that was a terminology issue - I was still referring to filter rules
exchange as well.

Secondly, this assumes that the filter rules would
consistently be communicated to the end host at the other end
of your regular traffic, which is an assumption that doesn't
generally hold for filter rules.

We have to scope the problem here. As to what Monami6 is chartered to
solve, it is only the flow/binding policies exchange to/from the MN/MR
to the HA, very much in the context of MIP6 (and its variants) and NEMO.
Strictly from this perspective, tying this exchange to MIP6 signaling
should be acceptable. However, it seems fair to see if this can be done
a bit more generically in a way that allows this work to be useful for
something like MOBIKE, where the same kind of end hosts may be
participating in the exchange and the requirements and scope are quite
similar.

However, if this were to be extended to an any-to-any policies/rules
exchange protocol, the scope and requirements become quite different.
That seems to fall under the scope of something that NSIS might be
doing. For instance, if this exchange is between two routers, the
information involved in this exchange and the timing and binding of the
information to interfaces or addresses become very different. Handoffs
are no longer a topic for consideration, for e.g. OTOH, batching of
information/rules, granularity of that and even the security models are
quite different.

I don't think it is good to solve the router-to-router and
host-to-router/server/agent exchanges with the same approach.

Thirdly, extension headers are for optional internet-layer
information (RFC 2460), and I'm not sure this is a fair
categorization of such filter rules as we're discussing here.
I don't know how much people care about proper layering
these days, though ...

It depends on whether this is viewed as a layer violation or cross-layer
optimization :) I'm typically not a fan of layer violation. However, in
this case, I see the filter rules and policies as something that permits
QoS-aware IP routing. So, I don't particularly see a problem with this,
although I would like to hear more thoughts on this.

Finally, although filter rules wouldn't necessarily be very
large in size, I doubt that the size constraints associated
with extension headers make it appropriate to put filter
rules in an extension header.
Remember that extension headers belong to the unfragmentable
part of an IPv6 packet, so there's a variable maximum size
for such a header, (depending on the presence of other
extension extension headers); it seems as if it would create
a silly size constraint for filter rules to define their
default transport to be an IPv6 extension header.

Henrik Levkowetz

2007-02-15 07:47:26 UTC

Post by Narayanan, Vidya
Hi Henrik,
Sorry, due to some intermittent connectivity issues, it turned out that
even though my application had sent the email before receiving the other
responses, it was actually only sent out later.

-----Original Message-----
Sent: Wednesday, February 14, 2007 3:09 PM
To: Internet Area
Subject: Re: [Int-area] Lifting up a filter discussion from Monami6

Post by Narayanan, Vidya
I would be sympathetic to developing something generic that

works for

Post by Narayanan, Vidya
multiple protocols instead of just Mobile IP, while also keeping in
mind the issue of mobility and latency concerns associated

with that.

be bound

Post by Narayanan, Vidya
to handoffs and in the context of Mobile IP or MOBIKE-like

protocols,

Post by Narayanan, Vidya
if this means separate signaling exchanges before the flow

changes can

Post by Narayanan, Vidya
happen, it could be less than useful.

I don't know if you read my recent post, but we've analysed
this and found that there is very little correlation
(basically none) between the time when a filter rule update
is needed, and the time of handover.

Yes.

Post by Narayanan, Vidya
I can subscribe to that
notion, although, the question I then have is whether we need to have a
certain protocol to set up the rules and other protocols to do the
rule-to-interface mapping. Having a separate protocol that sets up the
filter rules and updates the mapping would lead to the problem of having
to run that protocol separately at the time of handoff to update the
mapping. More notes below.

This isn't a problem, it's what you want to do. You want to de-couple
these two actions in time. And that does not force you to define two
different protocols for it, although if there is some advantage to doing
so, as seems to be the case for monami6/mip6, you certainly can do so.

You probably should read the monami6 documents covering this if you're
not familiar with them, to show an example both of how and why this
could be the case.

Post by Narayanan, Vidya
I had briefly discussed this with Dave Thaler in San Diego

and we had

signaling

Post by Narayanan, Vidya
and latency concerns associated with it. So, from this

point of view,

Post by Narayanan, Vidya
a couple of different things would need to happen - an independent
specification needs to define such an extension header or

destination

Post by Narayanan, Vidya
option and the fields that go into it; a different

specification would

Post by Narayanan, Vidya
then describe how this is carried in a given protocol (say,

Mobile IP)

Post by Narayanan, Vidya
and how the information is secured within that context.
Thoughts on something like this?

First, this cannot simply be described as 'flow information',
so if that was the context of your discussion, I don't think
it is quite relevant for this discussion.

No, that was a terminology issue - I was still referring to filter rules
exchange as well.

?? I see no argument for placing this in an extension header here.

Post by Narayanan, Vidya
However, if this were to be extended to an any-to-any policies/rules
exchange protocol, the scope and requirements become quite different.
That seems to fall under the scope of something that NSIS might be
doing. For instance, if this exchange is between two routers, the
information involved in this exchange and the timing and binding of the
information to interfaces or addresses become very different. Handoffs
are no longer a topic for consideration, for e.g. OTOH, batching of
information/rules, granularity of that and even the security models are
quite different.

?? I still don't see any argument for placing this in and extension
header here.

Post by Narayanan, Vidya
I don't think it is good to solve the router-to-router and
host-to-router/server/agent exchanges with the same approach.

Oh? Not that anyone has argued that either way, but as a general statement,
that would lead you to separate IP protocols, UDP protocols, TCP, etc.,
etc., for these exchanges. I don't thing this statement is valid or
fruitful.

It depends on whether this is viewed as a layer violation or cross-layer
optimization :)

No, it doesn't.

Post by Narayanan, Vidya
I'm typically not a fan of layer violation. However, in
this case, I see the filter rules and policies as something that permits
QoS-aware IP routing. So, I don't particularly see a problem with this,
although I would like to hear more thoughts on this.

Even if there may be a relationship between filter rules and QoS, they
aren't the same thing, and mixing them together won't aid clear thinking.

Narayanan, Vidya

2007-02-16 03:44:28 UTC

Hi Henrik,
The discussion I had with Dave on this topic was something I wanted to
write to the Monami6 list about a while ago, so that the group can also
think about that. However, that somehow never happened and now that Jari
brought up this thread, I wanted to throw the idea out to see what
people think about it. I admit that I have not extensively thought about
it - so, this is not an attempt to promote any views. This is just a
discussion point. Dave mentioned it and on the surface, it seemed like
an idea worth exploring.

I understand where you stand on the topic now and I would agree with
some of it and disagree with some other parts of it. Mainly,
irrespective of whether a transport protocol or extension headers or
mobility options are used to carry this information, I do not think we
should be aiming at a single solution for host-to-router and
router-to-router exchanges of filter rules, as I do believe the
requirements and security models are quite different in the two cases.
So, I think setting the scope at this level will be useful for starters.

I hope to continue an objective technical discussion and would also like
to see if others have any thoughts on this.

Regards,
Vidya

-----Original Message-----
Sent: Wednesday, February 14, 2007 11:47 PM
To: Narayanan, Vidya
Cc: Internet Area
Subject: Re: [Int-area] Lifting up a filter discussion from Monami6

Post by Narayanan, Vidya
Hi Henrik,
Sorry, due to some intermittent connectivity issues, it turned out
that even though my application had sent the email before receiving
the other responses, it was actually only sent out later.

-----Original Message-----
Sent: Wednesday, February 14, 2007 3:09 PM
To: Internet Area
Subject: Re: [Int-area] Lifting up a filter discussion from Monami6

Post by Narayanan, Vidya
I would be sympathetic to developing something generic that

works for

Post by Narayanan, Vidya
multiple protocols instead of just Mobile IP, while also

keeping in

Post by Narayanan, Vidya
mind the issue of mobility and latency concerns associated

with that.

Post by Narayanan, Vidya
One thing to take into account is that this exchange is not
necessarily a one-time exchange and policies and filters

may change

Post by Narayanan, Vidya
over time, based on the current connection capabilities

of an end

Post by Narayanan, Vidya
host. In such cases, some of this signaling may potentially

be bound

Post by Narayanan, Vidya
to handoffs and in the context of Mobile IP or MOBIKE-like

protocols,

Post by Narayanan, Vidya
if this means separate signaling exchanges before the flow

changes can

Post by Narayanan, Vidya
happen, it could be less than useful.

I don't know if you read my recent post, but we've

analysed this and

found that there is very little correlation (basically

none) between

the time when a filter rule update is needed, and the time of
handover.

I went through your other email. I see that there may be little
correlation between filter rule updates and the time of handover in
one model of doing this. In other words, I think you are

referring to

Post by Narayanan, Vidya
a model where there a bunch of rules set up in advance,

say, with an

Post by Narayanan, Vidya
ID that maps to each rule and upon handoffs, it is the mapping of
those IDs to interfaces or IP addresses that needs to

happen and not

Post by Narayanan, Vidya
the actual setting up or update of the rules itself. The

rules could

Post by Narayanan, Vidya
be updated at any time (and perhaps somewhat infrequently),

while the

Post by Narayanan, Vidya
rule-to-interface mapping is rather dynamic.

Yes.

Post by Narayanan, Vidya
I can subscribe to that
notion, although, the question I then have is whether we

need to have

Post by Narayanan, Vidya
a certain protocol to set up the rules and other protocols

to do the

Post by Narayanan, Vidya
rule-to-interface mapping. Having a separate protocol that

sets up the

Post by Narayanan, Vidya
filter rules and updates the mapping would lead to the problem of
having to run that protocol separately at the time of handoff to
update the mapping. More notes below.

This isn't a problem, it's what you want to do. You want to
de-couple these two actions in time. And that does not force
you to define two different protocols for it, although if
there is some advantage to doing so, as seems to be the case
for monami6/mip6, you certainly can do so.
You probably should read the monami6 documents covering this
if you're not familiar with them, to show an example both of
how and why this could be the case.

Post by Narayanan, Vidya
I had briefly discussed this with Dave Thaler in San Diego

and we had

Post by Narayanan, Vidya
talked about defining the flow information in a generic format,
perhaps as an IPv6 extension header or as a Destination

Option. If

Post by Narayanan, Vidya
such an approach were to be taken, this information

could then be

Post by Narayanan, Vidya
carried in any protocol, which would get rid of additional

signaling

Post by Narayanan, Vidya
and latency concerns associated with it. So, from this

point of view,

Post by Narayanan, Vidya
a couple of different things would need to happen - an

independent

Post by Narayanan, Vidya
specification needs to define such an extension header or

destination

Post by Narayanan, Vidya
option and the fields that go into it; a different

specification would

Post by Narayanan, Vidya
then describe how this is carried in a given protocol (say,

Mobile IP)

Post by Narayanan, Vidya
and how the information is secured within that context.
Thoughts on something like this?

First, this cannot simply be described as 'flow

information', so if

that was the context of your discussion, I don't think it is quite
relevant for this discussion.

No, that was a terminology issue - I was still referring to filter
rules exchange as well.

Secondly, this assumes that the filter rules would consistently be
communicated to the end host at the other end of your regular
traffic, which is an assumption that doesn't generally hold for
filter rules.

We have to scope the problem here. As to what Monami6 is

chartered to

Post by Narayanan, Vidya
solve, it is only the flow/binding policies exchange

to/from the MN/MR

Post by Narayanan, Vidya
to the HA, very much in the context of MIP6 (and its

variants) and NEMO.

Post by Narayanan, Vidya
Strictly from this perspective, tying this exchange to MIP6

signaling

Post by Narayanan, Vidya
should be acceptable. However, it seems fair to see if this can be
done a bit more generically in a way that allows this work to be
useful for something like MOBIKE, where the same kind of

end hosts may

Post by Narayanan, Vidya
be participating in the exchange and the requirements and scope are
quite similar.

?? I see no argument for placing this in an extension header here.

Post by Narayanan, Vidya
However, if this were to be extended to an any-to-any

policies/rules

Post by Narayanan, Vidya
exchange protocol, the scope and requirements become quite

different.

Post by Narayanan, Vidya
That seems to fall under the scope of something that NSIS might be
doing. For instance, if this exchange is between two routers, the
information involved in this exchange and the timing and binding of
the information to interfaces or addresses become very different.
Handoffs are no longer a topic for consideration, for e.g. OTOH,
batching of information/rules, granularity of that and even the
security models are quite different.

?? I still don't see any argument for placing this in and
extension header here.

Post by Narayanan, Vidya
I don't think it is good to solve the router-to-router and
host-to-router/server/agent exchanges with the same approach.

Oh? Not that anyone has argued that either way, but as a
general statement, that would lead you to separate IP
protocols, UDP protocols, TCP, etc., etc., for these
exchanges. I don't thing this statement is valid or fruitful.

these days,

though ...

It depends on whether this is viewed as a layer violation or
cross-layer optimization :)

No, it doesn't.

Post by Narayanan, Vidya
I'm typically not a fan of layer violation. However, in

this case, I

Post by Narayanan, Vidya
see the filter rules and policies as something that permits

QoS-aware

Post by Narayanan, Vidya
IP routing. So, I don't particularly see a problem with

this, although

Post by Narayanan, Vidya
I would like to hear more thoughts on this.

Even if there may be a relationship between filter rules and
QoS, they aren't the same thing, and mixing them together
won't aid clear thinking.

Finally, although filter rules wouldn't necessarily be

very large in

size, I doubt that the size constraints associated with extension
headers make it appropriate to put filter rules in an extension header.
Remember that extension headers belong to the

unfragmentable part of

an IPv6 packet, so there's a variable maximum size for

such a header,

(depending on the presence of other extension extension

headers); it

seems as if it would create a silly size constraint for

filter rules

to define their default transport to be an IPv6 extension header.

Henrik Levkowetz

2007-02-16 04:50:26 UTC

Post by Narayanan, Vidya
I understand where you stand on the topic now and I would agree with
some of it and disagree with some other parts of it. Mainly,
irrespective of whether a transport protocol or extension headers or
mobility options are used to carry this information, I do not think we
should be aiming at a single solution for host-to-router and
router-to-router exchanges of filter rules, as I do believe the
requirements and security models are quite different in the two cases.
So, I think setting the scope at this level will be useful for starters.

I don't see any reason why there has to be different solutions for
host-to-router and router-to-router, but I also think that it's premature
to have a strong view on this until we've agreed both that the work is
worth doing in general and collected the requirements.

My primary interest right now is to see if it makes sense to work on a
common solution, or whether we should go back and complete the monami6
work for the needs expressed in the monami6 charter and base documents
only.

I think there is enough commonality with the needs of the protocols
mentioned earlier (HIP/Shim6/Mobike) that a common solution could be
considered for these.

Henrik

Mark Townsley

2007-02-19 23:07:15 UTC

Post by Narayanan, Vidya
Hi Henrik,
The discussion I had with Dave on this topic was something I wanted to
write to the Monami6 list about a while ago, so that the group can also
think about that. However, that somehow never happened and now that Jari
brought up this thread, I wanted to throw the idea out to see what
people think about it. I admit that I have not extensively thought about
it - so, this is not an attempt to promote any views. This is just a
discussion point. Dave mentioned it and on the surface, it seemed like
an idea worth exploring.
I understand where you stand on the topic now and I would agree with
some of it and disagree with some other parts of it. Mainly,
irrespective of whether a transport protocol or extension headers or
mobility options are used to carry this information, I do not think we
should be aiming at a single solution for host-to-router and
router-to-router exchanges of filter rules, as I do believe the

And router to host? I'm afraid that it is fairly common for IPsec VPN
clients to have filtering policy thrust upon them from the tunnel
concentrator (e.g., whether split tunneling and such is permitted or not).

- Mark

Post by Narayanan, Vidya
requirements and security models are quite different in the two cases.
So, I think setting the scope at this level will be useful for starters.
I hope to continue an objective technical discussion and would also like
to see if others have any thoughts on this.
Regards,
Vidya

-----Original Message-----
Sent: Wednesday, February 14, 2007 11:47 PM
To: Narayanan, Vidya
Cc: Internet Area
Subject: Re: [Int-area] Lifting up a filter discussion from Monami6

Post by Narayanan, Vidya
Hi Henrik,
Sorry, due to some intermittent connectivity issues, it turned out
that even though my application had sent the email before receiving
the other responses, it was actually only sent out later.

-----Original Message-----
Sent: Wednesday, February 14, 2007 3:09 PM
To: Internet Area
Subject: Re: [Int-area] Lifting up a filter discussion from Monami6

Post by Narayanan, Vidya
I would be sympathetic to developing something generic that

works for

Post by Narayanan, Vidya
multiple protocols instead of just Mobile IP, while also

keeping in

Post by Narayanan, Vidya
mind the issue of mobility and latency concerns associated

with that.

Post by Narayanan, Vidya
One thing to take into account is that this exchange is not
necessarily a one-time exchange and policies and filters

may change

Post by Narayanan, Vidya
over time, based on the current connection capabilities

of an end

Post by Narayanan, Vidya
host. In such cases, some of this signaling may potentially

be bound

Post by Narayanan, Vidya
to handoffs and in the context of Mobile IP or MOBIKE-like

protocols,

Post by Narayanan, Vidya
if this means separate signaling exchanges before the flow

changes can

Post by Narayanan, Vidya
happen, it could be less than useful.

I don't know if you read my recent post, but we've

analysed this and

found that there is very little correlation (basically

none) between

the time when a filter rule update is needed, and the time of
handover.

I went through your other email. I see that there may be little
correlation between filter rule updates and the time of handover in
one model of doing this. In other words, I think you are

referring to

Post by Narayanan, Vidya
a model where there a bunch of rules set up in advance,

say, with an

Post by Narayanan, Vidya
ID that maps to each rule and upon handoffs, it is the mapping of
those IDs to interfaces or IP addresses that needs to

happen and not

Post by Narayanan, Vidya
the actual setting up or update of the rules itself. The

rules could

Post by Narayanan, Vidya
be updated at any time (and perhaps somewhat infrequently),

while the

Post by Narayanan, Vidya
rule-to-interface mapping is rather dynamic.

Yes.

Post by Narayanan, Vidya
I can subscribe to that
notion, although, the question I then have is whether we

need to have

Post by Narayanan, Vidya
a certain protocol to set up the rules and other protocols

to do the

Post by Narayanan, Vidya
rule-to-interface mapping. Having a separate protocol that

sets up the

Post by Narayanan, Vidya
filter rules and updates the mapping would lead to the problem of
having to run that protocol separately at the time of handoff to
update the mapping. More notes below.

This isn't a problem, it's what you want to do. You want to
de-couple these two actions in time. And that does not force
you to define two different protocols for it, although if
there is some advantage to doing so, as seems to be the case
for monami6/mip6, you certainly can do so.
You probably should read the monami6 documents covering this
if you're not familiar with them, to show an example both of
how and why this could be the case.

Post by Narayanan, Vidya
I had briefly discussed this with Dave Thaler in San Diego

and we had

Post by Narayanan, Vidya
talked about defining the flow information in a generic format,
perhaps as an IPv6 extension header or as a Destination

Option. If

Post by Narayanan, Vidya
such an approach were to be taken, this information

could then be

Post by Narayanan, Vidya
carried in any protocol, which would get rid of additional

signaling

Post by Narayanan, Vidya
and latency concerns associated with it. So, from this

point of view,

Post by Narayanan, Vidya
a couple of different things would need to happen - an

independent

Post by Narayanan, Vidya
specification needs to define such an extension header or

destination

Post by Narayanan, Vidya
option and the fields that go into it; a different

specification would

Post by Narayanan, Vidya
then describe how this is carried in a given protocol (say,

Mobile IP)

Post by Narayanan, Vidya
and how the information is secured within that context.
Thoughts on something like this?

First, this cannot simply be described as 'flow

information', so if

that was the context of your discussion, I don't think it is quite
relevant for this discussion.

No, that was a terminology issue - I was still referring to filter
rules exchange as well.

Secondly, this assumes that the filter rules would consistently be
communicated to the end host at the other end of your regular
traffic, which is an assumption that doesn't generally hold for
filter rules.

We have to scope the problem here. As to what Monami6 is

chartered to

Post by Narayanan, Vidya
solve, it is only the flow/binding policies exchange

to/from the MN/MR

Post by Narayanan, Vidya
to the HA, very much in the context of MIP6 (and its

variants) and NEMO.

Post by Narayanan, Vidya
Strictly from this perspective, tying this exchange to MIP6

signaling

end hosts may

Post by Narayanan, Vidya
be participating in the exchange and the requirements and scope are
quite similar.

?? I see no argument for placing this in an extension header here.

Post by Narayanan, Vidya
However, if this were to be extended to an any-to-any

policies/rules

Post by Narayanan, Vidya
exchange protocol, the scope and requirements become quite

different.

?? I still don't see any argument for placing this in and
extension header here.

Post by Narayanan, Vidya
I don't think it is good to solve the router-to-router and
host-to-router/server/agent exchanges with the same approach.

Oh? Not that anyone has argued that either way, but as a
general statement, that would lead you to separate IP
protocols, UDP protocols, TCP, etc., etc., for these
exchanges. I don't thing this statement is valid or fruitful.

these days,

though ...

It depends on whether this is viewed as a layer violation or
cross-layer optimization :)

No, it doesn't.

Post by Narayanan, Vidya
I'm typically not a fan of layer violation. However, in

this case, I

Post by Narayanan, Vidya
see the filter rules and policies as something that permits

QoS-aware

Post by Narayanan, Vidya
IP routing. So, I don't particularly see a problem with

this, although

Post by Narayanan, Vidya
I would like to hear more thoughts on this.

Even if there may be a relationship between filter rules and
QoS, they aren't the same thing, and mixing them together
won't aid clear thinking.

Finally, although filter rules wouldn't necessarily be

very large in

size, I doubt that the size constraints associated with extension
headers make it appropriate to put filter rules in an extension header.
Remember that extension headers belong to the

unfragmentable part of

an IPv6 packet, so there's a variable maximum size for

such a header,

(depending on the presence of other extension extension

headers); it

seems as if it would create a silly size constraint for

filter rules

to define their default transport to be an IPv6 extension header.

Henrik Levkowetz

2007-02-19 23:48:23 UTC

Hi Mark,
...

Post by Mark Townsley

Ah! That's one possible application of this I hadn't thought of, but
once mentioned it's (to me, at least!) a very interesting example of
how a standard filter description language could be useful.

Henrik

Narayanan, Vidya

2007-02-20 05:19:26 UTC

-----Original Message-----
Sent: Monday, February 19, 2007 3:07 PM
To: Narayanan, Vidya
Cc: Henrik Levkowetz; Internet Area
Subject: Re: [Int-area] Lifting up a filter discussion from Monami6

Post by Narayanan, Vidya
Hi Henrik,
The discussion I had with Dave on this topic was something

I wanted to

Post by Narayanan, Vidya
write to the Monami6 list about a while ago, so that the group can
also think about that. However, that somehow never happened and now
that Jari brought up this thread, I wanted to throw the idea out to
see what people think about it. I admit that I have not extensively
thought about it - so, this is not an attempt to promote any views.
This is just a discussion point. Dave mentioned it and on

the surface,

Post by Narayanan, Vidya
it seemed like an idea worth exploring.
I understand where you stand on the topic now and I would

agree with

Post by Narayanan, Vidya
some of it and disagree with some other parts of it. Mainly,
irrespective of whether a transport protocol or extension

headers or

Post by Narayanan, Vidya
mobility options are used to carry this information, I do

not think we

Post by Narayanan, Vidya
should be aiming at a single solution for host-to-router and
router-to-router exchanges of filter rules, as I do believe the

And router to host? I'm afraid that it is fairly common for
IPsec VPN clients to have filtering policy thrust upon them
from the tunnel concentrator (e.g., whether split tunneling
and such is permitted or not).

True. When I mentioned host-to-router, I had implicitly included the
other direction as well. I would imagine the filter specifications for
MOBIKE to fall under that category. I do think that the approaches for
MIP6, MOBIKE and perhaps SHIM6 (I'm less sure of this) share similar
requirements and having one solution may make sense. Would this cover
the VPN scenario that you have mentioned above?

Vidya

- Mark

Post by Narayanan, Vidya
requirements and security models are quite different in the

two cases.

Post by Narayanan, Vidya
So, I think setting the scope at this level will be useful

for starters.

Post by Narayanan, Vidya
I hope to continue an objective technical discussion and would also
like to see if others have any thoughts on this.
Regards,
Vidya

-----Original Message-----
Sent: Wednesday, February 14, 2007 11:47 PM
To: Narayanan, Vidya
Cc: Internet Area
Subject: Re: [Int-area] Lifting up a filter discussion from Monami6

Post by Narayanan, Vidya
Hi Henrik,
Sorry, due to some intermittent connectivity issues, it

turned out

Post by Narayanan, Vidya
that even though my application had sent the email before

receiving

Post by Narayanan, Vidya
the other responses, it was actually only sent out later.

-----Original Message-----
Sent: Wednesday, February 14, 2007 3:09 PM
To: Internet Area
Subject: Re: [Int-area] Lifting up a filter discussion

from Monami6

Post by Narayanan, Vidya
I would be sympathetic to developing something generic that

works for

Post by Narayanan, Vidya
multiple protocols instead of just Mobile IP, while also

keeping in

Post by Narayanan, Vidya
mind the issue of mobility and latency concerns associated

with that.

Post by Narayanan, Vidya
One thing to take into account is that this exchange is not
necessarily a one-time exchange and policies and filters

may change

Post by Narayanan, Vidya
over time, based on the current connection capabilities

of an end

Post by Narayanan, Vidya
host. In such cases, some of this signaling may potentially

be bound

Post by Narayanan, Vidya
to handoffs and in the context of Mobile IP or MOBIKE-like

protocols,

Post by Narayanan, Vidya
if this means separate signaling exchanges before the flow

changes can

Post by Narayanan, Vidya
happen, it could be less than useful.

I don't know if you read my recent post, but we've

analysed this and

found that there is very little correlation (basically

none) between

the time when a filter rule update is needed, and the time of
handover.

I went through your other email. I see that there may be little
correlation between filter rule updates and the time of

handover in

Post by Narayanan, Vidya
one model of doing this. In other words, I think you are

referring to

Post by Narayanan, Vidya
a model where there a bunch of rules set up in advance,

say, with an

Post by Narayanan, Vidya
ID that maps to each rule and upon handoffs, it is the mapping of
those IDs to interfaces or IP addresses that needs to

happen and not

Post by Narayanan, Vidya
the actual setting up or update of the rules itself. The

rules could

Post by Narayanan, Vidya
be updated at any time (and perhaps somewhat infrequently),

while the

Post by Narayanan, Vidya
rule-to-interface mapping is rather dynamic.

Yes.

Post by Narayanan, Vidya
I can subscribe to that
notion, although, the question I then have is whether we

need to have

Post by Narayanan, Vidya
a certain protocol to set up the rules and other protocols

to do the

Post by Narayanan, Vidya
rule-to-interface mapping. Having a separate protocol that

sets up the

Post by Narayanan, Vidya
filter rules and updates the mapping would lead to the problem of
having to run that protocol separately at the time of handoff to
update the mapping. More notes below.

This isn't a problem, it's what you want to do. You want to
de-couple these two actions in time. And that does not

force you to

define two different protocols for it, although if there is some
advantage to doing so, as seems to be the case for

monami6/mip6, you

certainly can do so.
You probably should read the monami6 documents covering this if
you're not familiar with them, to show an example both of

how and why

this could be the case.

Post by Narayanan, Vidya
I had briefly discussed this with Dave Thaler in San Diego

and we had

Post by Narayanan, Vidya
talked about defining the flow information in a generic format,
perhaps as an IPv6 extension header or as a Destination

Option. If

Post by Narayanan, Vidya
such an approach were to be taken, this information

could then be

Post by Narayanan, Vidya
carried in any protocol, which would get rid of additional

signaling

Post by Narayanan, Vidya
and latency concerns associated with it. So, from this

point of view,

Post by Narayanan, Vidya
a couple of different things would need to happen - an

independent

Post by Narayanan, Vidya
specification needs to define such an extension header or

destination

Post by Narayanan, Vidya
option and the fields that go into it; a different

specification would

Post by Narayanan, Vidya
then describe how this is carried in a given protocol (say,

Mobile IP)

Post by Narayanan, Vidya
and how the information is secured within that context.
Thoughts on something like this?

First, this cannot simply be described as 'flow

information', so if

that was the context of your discussion, I don't think

it is quite

relevant for this discussion.

No, that was a terminology issue - I was still referring

to filter

Post by Narayanan, Vidya
rules exchange as well.

Secondly, this assumes that the filter rules would

consistently be

communicated to the end host at the other end of your regular
traffic, which is an assumption that doesn't generally hold for
filter rules.

We have to scope the problem here. As to what Monami6 is

chartered to

Post by Narayanan, Vidya
solve, it is only the flow/binding policies exchange

to/from the MN/MR

Post by Narayanan, Vidya
to the HA, very much in the context of MIP6 (and its

variants) and NEMO.

Post by Narayanan, Vidya
Strictly from this perspective, tying this exchange to MIP6

signaling

Post by Narayanan, Vidya
should be acceptable. However, it seems fair to see if

this can be

Post by Narayanan, Vidya
done a bit more generically in a way that allows this work to be
useful for something like MOBIKE, where the same kind of

end hosts may

Post by Narayanan, Vidya
be participating in the exchange and the requirements and

scope are

Post by Narayanan, Vidya
quite similar.

?? I see no argument for placing this in an extension header here.

Post by Narayanan, Vidya
However, if this were to be extended to an any-to-any

policies/rules

Post by Narayanan, Vidya
exchange protocol, the scope and requirements become quite

different.

Post by Narayanan, Vidya
That seems to fall under the scope of something that NSIS

might be

Post by Narayanan, Vidya
doing. For instance, if this exchange is between two routers, the
information involved in this exchange and the timing and

binding of

Post by Narayanan, Vidya
the information to interfaces or addresses become very different.
Handoffs are no longer a topic for consideration, for e.g. OTOH,
batching of information/rules, granularity of that and even the
security models are quite different.

?? I still don't see any argument for placing this in and

extension

header here.

Post by Narayanan, Vidya
I don't think it is good to solve the router-to-router and
host-to-router/server/agent exchanges with the same approach.

Oh? Not that anyone has argued that either way, but as a general
statement, that would lead you to separate IP protocols, UDP
protocols, TCP, etc., etc., for these exchanges. I don't

thing this

statement is valid or fruitful.

these days,

though ...

It depends on whether this is viewed as a layer violation or
cross-layer optimization :)

No, it doesn't.

Post by Narayanan, Vidya
I'm typically not a fan of layer violation. However, in

this case, I

Post by Narayanan, Vidya
see the filter rules and policies as something that permits

QoS-aware

Post by Narayanan, Vidya
IP routing. So, I don't particularly see a problem with

this, although

Post by Narayanan, Vidya
I would like to hear more thoughts on this.

Even if there may be a relationship between filter rules and QoS,
they aren't the same thing, and mixing them together won't

aid clear

thinking.

Finally, although filter rules wouldn't necessarily be

very large in

size, I doubt that the size constraints associated with

extension

headers make it appropriate to put filter rules in an extension header.
Remember that extension headers belong to the

unfragmentable part of

an IPv6 packet, so there's a variable maximum size for

such a header,

(depending on the presence of other extension extension

headers); it

seems as if it would create a silly size constraint for

filter rules

to define their default transport to be an IPv6 extension header.

Magnus Westerlund

2007-02-20 10:41:05 UTC

Narayanan, Vidya skrev:

Narayanan, Vidya

2007-02-20 18:15:34 UTC

Hi Magnus,

-----Original Message-----
Sent: Tuesday, February 20, 2007 2:41 AM
To: Narayanan, Vidya
Cc: Henrik Levkowetz; Internet Area
Subject: Re: [Int-area] Lifting up a filter discussion from Monami6

Pekka Savola

2007-02-20 18:54:42 UTC

The real problem here seems to be that MIP6 (and associated protocols
such as NEMO), for good or bad, has chosen the path of being part of the
IP layer rather than running at the transport layer. Since the mapping
of filter rules to addresses (not defining or exchanging the rules
itself, but, the mapping) is very much part of a handoff problem, it
needs to be integrated with the protocol for optimal operation during
handoffs. One option on the table is the use of mobility options (which
is an option to the Mobility Header, which is also an IPv6 extension
header) - that would make this applicable only to the MIP6 class of
protocols. If we want MOBIKE or Shim6 to be able to use it, I was
suggesting looking into defining its own IPv6 extension header, since
that can be carried in any of these protocols (except MOBIKE over IPv4).

If I recall correctly, the issue of piggybacking arbitrary data on
signalling messages was deferred from MIPv6 specifications, and hasn't
been solved in later extensions or other protocols either. This is
likely to bring up issues with different application PDU sizes, PMTUD,
etc.

Maybe filter signalling is sufficiently more restricted case of
piggybacking arbitrary data that devising framing, PMTUD, etc. for it
is simpler. I might agree with that if the filters were restricted to
be (say) less than 500 bytes so that no fragmentation was never
needed.

While solving the more general problem might be useful, it's not clear
to me yet whether the requirements in this mobility space are strong
enough to preclude using a more generic transport protocol.

--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

Narayanan, Vidya

2007-02-20 22:56:48 UTC

-----Original Message-----
Sent: Tuesday, February 20, 2007 10:55 AM
To: Narayanan, Vidya
Cc: Magnus Westerlund; Internet Area
Subject: RE: [Int-area] Lifting up a filter discussion from Monami6

The real problem here seems to be that MIP6 (and associated

protocols

such as NEMO), for good or bad, has chosen the path of

being part of

the IP layer rather than running at the transport layer. Since the
mapping of filter rules to addresses (not defining or

exchanging the

rules itself, but, the mapping) is very much part of a handoff
problem, it needs to be integrated with the protocol for optimal
operation during handoffs. One option on the table is the use of
mobility options (which is an option to the Mobility

Header, which is

also an IPv6 extension
header) - that would make this applicable only to the MIP6 class of
protocols. If we want MOBIKE or Shim6 to be able to use it, I was
suggesting looking into defining its own IPv6 extension

header, since

that can be carried in any of these protocols (except

MOBIKE over IPv4).
If I recall correctly, the issue of piggybacking arbitrary
data on signalling messages was deferred from MIPv6
specifications, and hasn't been solved in later extensions or
other protocols either. This is likely to bring up issues
with different application PDU sizes, PMTUD, etc.
Maybe filter signalling is sufficiently more restricted case
of piggybacking arbitrary data that devising framing, PMTUD,
etc. for it is simpler. I might agree with that if the
filters were restricted to be (say) less than 500 bytes so
that no fragmentation was never needed.

Maybe I am missing something here, but, how does UDP help with
fragmentation? The alternative proposed at the transport layer seems to
be UDP-based.

While solving the more general problem might be useful, it's
not clear to me yet whether the requirements in this mobility
space are strong enough to preclude using a more generic
transport protocol.

In a mobile environment, the mobile node is in the best position to
determine the mapping of filter rules to addresses based on currently
available interfaces and connection conditions. This could be fairly
dynamic and I can see a need to exchange this upon handoff to
communicating devices (such as the HA or VPN GW or even a CN).

Vidya

--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

Henrik Levkowetz

2007-02-20 23:57:14 UTC

on 2007-02-20 23:56 Narayanan, Vidya said the following:
...

Post by Pekka Savola
If I recall correctly, the issue of piggybacking arbitrary
data on signalling messages was deferred from MIPv6
specifications, and hasn't been solved in later extensions or
other protocols either. This is likely to bring up issues
with different application PDU sizes, PMTUD, etc.
Maybe filter signalling is sufficiently more restricted case
of piggybacking arbitrary data that devising framing, PMTUD,
etc. for it is simpler. I might agree with that if the
filters were restricted to be (say) less than 500 bytes so
that no fragmentation was never needed.

Maybe I am missing something here, but, how does UDP help with
fragmentation? The alternative proposed at the transport layer seems to
be UDP-based.

No. Jari raised the question of whether a more general filter
definition language would be a good idea (my paraphrasing), and
you proposed that IPv6 extension headers should be used as
transport for it. Nobody else has proposed a specific transport
yet in this discussion.

Personally I'd support something which uses an existing generic
transport protocol, such as UDP or SCTP; with DTLS security for
instance; but I'm not too concerned with the exact pick of such
a protocol. What I'm very concerned about is the idea of moving
something which can both easily and reasonably be carried by an
existing generic transport protocol down into IPv6 extension
headers, when there's no evidence or arguments that doing so would
be particularly sensible or beneficial.

(Now, if somebody here had indeed proposed UDP as transport in
this discussion, I'd like to repeat something which Magnus
already hinted at, which is that it's still quite a difference
between what you can fit into a UDP package, and what you can add
in an IP header to a package which already carries a payload,
before fragmentation of that package occurs.)

Post by Pekka Savola
While solving the more general problem might be useful, it's
not clear to me yet whether the requirements in this mobility
space are strong enough to preclude using a more generic
transport protocol.

You keep ignoring the information that an analysis of the origins
of filter rule changes show them to be uncorrelated with handover
events.

Henrik

Narayanan, Vidya

2007-02-21 00:14:12 UTC

-----Original Message-----
Sent: Tuesday, February 20, 2007 3:57 PM
To: Narayanan, Vidya
Cc: Pekka Savola; Internet Area
Subject: Re: [Int-area] Lifting up a filter discussion from Monami6
...

Post by Pekka Savola
If I recall correctly, the issue of piggybacking arbitrary data on
signalling messages was deferred from MIPv6 specifications, and
hasn't been solved in later extensions or other protocols either.
This is likely to bring up issues with different application PDU
sizes, PMTUD, etc.
Maybe filter signalling is sufficiently more restricted case of
piggybacking arbitrary data that devising framing, PMTUD,

etc. for it

Post by Pekka Savola
is simpler. I might agree with that if the filters were

restricted

Post by Pekka Savola
to be (say) less than 500 bytes so that no fragmentation was never
needed.

Maybe I am missing something here, but, how does UDP help with
fragmentation? The alternative proposed at the transport

layer seems

Post by Narayanan, Vidya
to be UDP-based.

Okay. I was going with Jari's original email on this thread, in which he
talked about one existing proposal of doing this over UDP.

Personally I'd support something which uses an existing
generic transport protocol, such as UDP or SCTP; with DTLS
security for instance; but I'm not too concerned with the
exact pick of such a protocol. What I'm very concerned about
is the idea of moving something which can both easily and
reasonably be carried by an existing generic transport
protocol down into IPv6 extension headers, when there's no
evidence or arguments that doing so would be particularly
sensible or beneficial.
(Now, if somebody here had indeed proposed UDP as transport
in this discussion, I'd like to repeat something which Magnus
already hinted at, which is that it's still quite a
difference between what you can fit into a UDP package, and
what you can add in an IP header to a package which already
carries a payload, before fragmentation of that package occurs.)

Post by Pekka Savola
While solving the more general problem might be useful, it's not
clear to me yet whether the requirements in this mobility

space are

Post by Pekka Savola
strong enough to preclude using a more generic transport protocol.

In a mobile environment, the mobile node is in the best position to
determine the mapping of filter rules to addresses based on

currently

Post by Narayanan, Vidya
available interfaces and connection conditions. This could

be fairly

Post by Narayanan, Vidya
dynamic and I can see a need to exchange this upon handoff to
communicating devices (such as the HA or VPN GW or even a CN).

You keep ignoring the information that an analysis of the
origins of filter rule changes show them to be uncorrelated
with handover events.

I was only referring to the mapping of filter rules to addresses here,
not the exchange of filter rules themselves.

Vidya

Henrik

Pekka Savola

2007-02-21 10:15:56 UTC

Post by Pekka Savola
Maybe filter signalling is sufficiently more restricted case
of piggybacking arbitrary data that devising framing, PMTUD,
etc. for it is simpler. I might agree with that if the
filters were restricted to be (say) less than 500 bytes so
that no fragmentation was never needed.

Maybe I am missing something here, but, how does UDP help with
fragmentation? The alternative proposed at the transport layer seems to
be UDP-based.

If a packet carries data or signalling from a single application only,
handling correct packetization of data that application may wish to
send is rather straightforward because just one application needs to
be concerned.

If a packet may carry data from multiple sources (e.g., MIPv6,
filters, even arbitrary applications) every one of these will need to
be involved and interact in the packetization process.

However, the second case gets simpler if you'd use MTU=1280, disable
PMTUD, and fragment every packet that exceeds the MTU without trying
to optimize the payloads such that no fragmentation was necessary.

Maybe this was the model you were suggesting and a reason for the
disconnect.

--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

Narayanan, Vidya

2007-02-22 06:08:05 UTC

-----Original Message-----
Sent: Wednesday, February 21, 2007 2:16 AM
To: Narayanan, Vidya
Cc: Magnus Westerlund; Internet Area
Subject: RE: [Int-area] Lifting up a filter discussion from Monami6

Post by Pekka Savola
Maybe filter signalling is sufficiently more restricted case of
piggybacking arbitrary data that devising framing, PMTUD,

etc. for it

Post by Pekka Savola
is simpler. I might agree with that if the filters were

restricted

Post by Pekka Savola
to be (say) less than 500 bytes so that no fragmentation was never
needed.

Maybe I am missing something here, but, how does UDP help with
fragmentation? The alternative proposed at the transport

layer seems

Post by Narayanan, Vidya
to be UDP-based.

If a packet carries data or signalling from a single
application only, handling correct packetization of data that
application may wish to send is rather straightforward
because just one application needs to be concerned.
If a packet may carry data from multiple sources (e.g.,
MIPv6, filters, even arbitrary applications) every one of
these will need to be involved and interact in the
packetization process.
However, the second case gets simpler if you'd use MTU=1280,
disable PMTUD, and fragment every packet that exceeds the MTU
without trying to optimize the payloads such that no
fragmentation was necessary.
Maybe this was the model you were suggesting and a reason for
the disconnect.

Ah! Yes, I didn't think the payloads will be optimized to avoid
fragmentation. Also, I'm not sure if the filter rules in this case would
be handled as a separate application. Perhaps each application (MIP6 or
MOBIKE or SHIM6) that would carry the filter rules would have to handle
processing of the same? Ultimately, the filter rules are meant to be
used by one of these applications anyway.

Vidya

--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

Narayanan, Vidya

2007-02-16 03:46:24 UTC

Hi Thierry,
As I've just written in my email to Henrik, this was a discussion point
I was providing to discuss the feasibility of it. But, if it is
something people feel is viable, it will be a slightly different
approach from any of the proposed approaches thus far, yes.

Vidya

-----Original Message-----
Sent: Thursday, February 15, 2007 4:20 AM
To: Narayanan, Vidya
Subject: Re: [Int-area] Lifting up a filter discussion from Monami6
So, you are proposing a 4th solution if I got you right ?
Thierry.
On Wed, 14 Feb 2007 14:20:48 -0800

Post by Narayanan, Vidya
I would be sympathetic to developing something generic that

works for

Post by Narayanan, Vidya
multiple protocols instead of just Mobile IP, while also keeping in
mind the issue of mobility and latency concerns associated

with that.

Post by Narayanan, Vidya
One thing to take into account is that this exchange is not

necessarily

Post by Narayanan, Vidya
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

Post by Narayanan, Vidya
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

Post by Narayanan, Vidya
talked about defining the flow information in a generic

format, perhaps

Post by Narayanan, Vidya
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

Post by Narayanan, Vidya
concerns associated with it. So, from this point of view, a

couple of

Post by Narayanan, Vidya
different things would need to happen - an independent specification
needs to define such an extension header or destination

option and the

Post by Narayanan, Vidya
fields that go into it; a different specification would then

describe

Post by Narayanan, Vidya
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

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
- carrier protocol choice
- policy container format
- timing of the policy exchange
- securing the transfer
- etc
Thoughts?
Jari
_______________________________________________
Int-area mailing list
https://www1.ietf.org/mailman/listinfo/int-area

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

Benjamin Lim

2007-02-16 03:05:33 UTC

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-----
Sent: Wednesday, February 14, 2007 9:00 PM
To: Internet Area
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
- carrier protocol choice
- policy container format
- timing of the policy exchange
- securing the transfer
- etc
Thoughts?
Jari
_______________________________________________
Int-area mailing list
https://www1.ietf.org/mailman/listinfo/int-area

Henrik Levkowetz

2007-02-16 05:10:39 UTC

Hi Benjamin,

Post by Benjamin Lim
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?

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

Thierry Ernst

2007-02-16 14:27:51 UTC

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

Post by Henrik Levkowetz
Hi Benjamin,

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
_______________________________________________
Monami6 mailing list
https://www1.ietf.org/mailman/listinfo/monami6

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

Henrik Levkowetz

2007-02-16 15:16:48 UTC

Hi Thierry,

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

Post by Thierry Ernst
Hi,
Do we need to keep ccing int-area (at the same time of Monami6) ?

Depends on how general the issue is, I guess.

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

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

Post by Thierry Ernst
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.

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.

Post by Thierry Ernst
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).

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

Henrik

Post by Thierry Ernst
Thierry.
On Fri, 16 Feb 2007 06:10:39 +0100

Post by Henrik Levkowetz
Hi Benjamin,

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
_______________________________________________
Monami6 mailing list
https://www1.ietf.org/mailman/listinfo/monami6

Thierry Ernst

2007-02-16 16:30:25 UTC

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

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

Post by Thierry Ernst
Hi,
Do we need to keep ccing int-area (at the same time of Monami6) ?

Depends on how general the issue is, I guess.

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

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

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.

Post by Henrik Levkowetz
Hi Benjamin,

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
_______________________________________________
Monami6 mailing list
https://www1.ietf.org/mailman/listinfo/monami6

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

Henrik Levkowetz

2007-02-16 19:13:42 UTC

Hi Thierry,

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

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

Ah. Ok.

...

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

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

http://www.calm.hu/

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

Thierry Ernst

2007-02-19 11:50:43 UTC

Hi Henrik,

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

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

http://www.calm.hu/

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.

Hesham Soliman

2007-02-19 17:43:36 UTC

Hi Jari, all,

After reading this email and reading all the responses I think a few
comments are in order.
Generally speaking, I would think that when given a choice between a "one
size fits all" solution versus one solution per protocol, most people would
choose the former. However, I don't think the choice is so simple as some of
the responses seemed to imply.

I think it is ill-advised to take a decision on this without understanding
the scenarios, and the resulting requirements from those scenarios.
Additionally, we need to consider how each of the protocols using the
solution actually work. I'll list the scenarios we (authors of one of the
solutions) had in mind and let others comment or add their own scenarios.

Regardless of the approach, the solution we had in mind would transfer flow
descriptions and binding information between the flow in question and one or
more of the mobile node's addresses. The sender of this information is the
mobile node. The receiver is either a correspondent node or another
intermediate node. If we use the terms HA/MAP then we're implying the use of
MIPv6. So I'll stick to generic language.

Now, each of the protocols you mention below (HIP, Mobike, SHIM6 ...etc)
have their own way of identifying the sending node to the receiver of the
signalling. This identity is obviously essential for securing the
signalling. Furthermore, they're all different in this regard. So I don't
think having one solution that fits all is a simple task. Even within one
protocol, the security requirements are different depending on the node
receiving the signalling. MIPv6 is the perfect example for this case. Can we
just assume that IPsec or AAA will work with a CN? I don't see how. Also,
some entities don't exist in all protocols, e.g. the HA/MAP.

So even if we go with "one solution" it would have to incorporate several
modes of operation (at least from the security perspective) to work for all
the different protocols.

Another question to ask here is what is the real benefit of having one
solution? I'm not talking about saving documents, I mean a real benefit to
an implementer. If the flow descriptors need to have the same format then
that's easily done and reusable for implementers. But that doesn't require
one transport protocol.

On the other hand, there are examples of protocols that incorporated the
same function without having to coordinate one protocol across the board. A
recent example is the use of IPv4 and IPv6 addresses in mobility protocols,
which was done in MIPv6, MIPv4 and I think shim6 without having to come up
with a single solution.

Regardless of the outcome of this discussion, I hope we can get specific
with the comments that highlight the benefits of having one Vs several
solutions. I urge people to look at the bullets at the end of Jari's
original email and consider them when they make up their mind for one
approach Vs another.

Hesham

Post by Jari Arkko
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
- carrier protocol choice
- policy container format
- timing of the policy exchange
- securing the transfer
- etc
Thoughts?
Jari
_______________________________________________
Int-area mailing list
https://www1.ietf.org/mailman/listinfo/int-area

Heikki Mahkonen

2007-02-20 07:41:06 UTC

Hi Hesham,

Post by Hesham Soliman
Regardless of the approach, the solution we had in mind would transfer flow
descriptions and binding information between the flow in question and one or
more of the mobile node's addresses. The sender of this information is the
mobile node. The receiver is either a correspondent node or another
intermediate node. If we use the terms HA/MAP then we're implying the use of
MIPv6. So I'll stick to generic language.

==> I think that the solution you describe in your draft for flow
bindings might be enough for MIPv6 but it is not sufficient for instance
in NEMO case (or other non MIPv6 intermediate node case). In the flow
binding draft it is mandatory for the intermediate node to be able to
receive a BU message, right?

In NEMO the MNN cannot send a BU message to the MR so the MNN. Because
of this you would need to write another draft (which would resemble I
think the one or both of the alternative solutions). Or change the NEMO
so the MNN can send BU to the MR?

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.

Best regards,

Heikki Mahkonen

Tero Kauppinen (JO/LMF)

2007-02-20 09:29:44 UTC

-----Original Message-----
Sent: 19. helmikuuta 2007 19:44
To: 'Jari Arkko'; 'Internet Area'
Subject: RE: [Int-area] Lifting up a filter discussion from Monami6
Hi Jari, all,
After reading this email and reading all the responses I
think a few comments are in order.
Generally speaking, I would think that when given a choice
between a "one size fits all" solution versus one solution
per protocol, most people would choose the former. However, I
don't think the choice is so simple as some of the responses
seemed to imply.
I think it is ill-advised to take a decision on this without
understanding the scenarios, and the resulting requirements
from those scenarios.
Additionally, we need to consider how each of the protocols
using the solution actually work. I'll list the scenarios we
(authors of one of the
solutions) had in mind and let others comment or add their
own scenarios.
Regardless of the approach, the solution we had in mind would
transfer flow descriptions and binding information between
the flow in question and one or more of the mobile node's
addresses. The sender of this information is the mobile node.
The receiver is either a correspondent node or another
intermediate node. If we use the terms HA/MAP then we're
implying the use of MIPv6. So I'll stick to generic language.
Now, each of the protocols you mention below (HIP, Mobike,
SHIM6 ...etc) have their own way of identifying the sending
node to the receiver of the signalling. This identity is
obviously essential for securing the signalling. Furthermore,
they're all different in this regard. So I don't think having
one solution that fits all is a simple task. Even within one
protocol, the security requirements are different depending
on the node receiving the signalling. MIPv6 is the perfect
example for this case. Can we just assume that IPsec or AAA
will work with a CN? I don't see how. Also, some entities
don't exist in all protocols, e.g. the HA/MAP.
So even if we go with "one solution" it would have to
incorporate several modes of operation (at least from the
security perspective) to work for all the different protocols.
Another question to ask here is what is the real benefit of
having one solution? I'm not talking about saving documents,
I mean a real benefit to an implementer. If the flow
descriptors need to have the same format then that's easily
done and reusable for implementers. But that doesn't require
one transport protocol.

What makes you think that it is only about the same format? If mobility
management protocols are able to stick to jobs that really belong to
mobility management protocols in contrast to extending them with the
management of filtering rules, I would say that it's more than just
about using the same format. If I, as an implementer of a mobility
protocol, don't have to consider the details of managing filter rules,
it has a visible impact on the implementation. If I, on the other hand,
would need to integrate my mobility protocol implementation into a
system where another mobility protocol is also doing filter rule
management of its own, I would say that my job is to a greater extend
more demanding. Eventually the system will start to evolve in such a way
that the filter rule management is pulled out to a common module in
which case I start thinking why would the mobility management protocol
be even bothered with the details of transferring filter rules. In my
scale saving a few bits/bytes weights considerably less than a better
overall design, i.e. stuffing everything into mobility signaling vs.
having one protocol more, but, on the other hand, that it just my scale.

Tero

On the other hand, there are examples of protocols that
incorporated the same function without having to coordinate
one protocol across the board. A recent example is the use of
IPv4 and IPv6 addresses in mobility protocols, which was done
in MIPv6, MIPv4 and I think shim6 without having to come up
with a single solution.
Regardless of the outcome of this discussion, I hope we can
get specific with the comments that highlight the benefits of
having one Vs several solutions. I urge people to look at the
bullets at the end of Jari's original email and consider them
when they make up their mind for one approach Vs another.
Hesham

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

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

- carrier protocol choice
- policy container format
- timing of the policy exchange
- securing the transfer
- etc
Thoughts?
Jari
_______________________________________________
Int-area mailing list
https://www1.ietf.org/mailman/listinfo/int-area

_______________________________________________
Int-area mailing list
https://www1.ietf.org/mailman/listinfo/int-area

Heikki Mahkonen

2007-02-20 11:04:14 UTC

Fwd..

-------- Original Message --------
To: Monami6 WG <***@ietf.org>, int-***@ietf.org
Subject: Re: [Monami6] FW: [Int-area] Lifting up a filter discussion

Hi Hesham,

Hesham Soliman

2007-02-20 11:29:25 UTC

Hi Heikki,

I don't think we need to discuss this on the INT area mailing list so I'll
respond to you on the monami list. I think your analysis is off target but
I'll explain it on monami.

Hesham

-----Original Message-----
Sent: Tuesday, February 20, 2007 6:41 PM
Subject: Re: [Monami6] FW: [Int-area] Lifting up a filter
discussion fromMonami6
Hi Hesham,

Post by Hesham Soliman
Regardless of the approach, the solution we had in mind

would transfer flow

Post by Hesham Soliman
descriptions and binding information between the flow in

question and one or

Post by Hesham Soliman
more of the mobile node's addresses. The sender of this

information is the

Post by Hesham Soliman
mobile node. The receiver is either a correspondent node or another
intermediate node. If we use the terms HA/MAP then we're

implying the use of

Post by Hesham Soliman
MIPv6. So I'll stick to generic language.

==> I think that the solution you describe in your draft for flow
bindings might be enough for MIPv6 but it is not sufficient
for instance
in NEMO case (or other non MIPv6 intermediate node case). In
the flow
binding draft it is mandatory for the intermediate node to
be able to
receive a BU message, right?
In NEMO the MNN cannot send a BU message to the MR so the
MNN. Because
of this you would need to write another draft (which would
resemble I
think the one or both of the alternative solutions). Or
change the NEMO
so the MNN can send BU to the MR?
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.
Best regards,
Heikki Mahkonen
_______________________________________________
Monami6 mailing list
https://www1.ietf.org/mailman/listinfo/monami6

Jari Arkko

2007-02-20 20:49:55 UTC

There were a couple of questions about what list to
use for this discussion -- Lets keep the general
discussion on the int-area list. I thought the topic
deserved a wider audience, and that's still the case.
But if there was some detail about current proposals,
monami6 list works for that better. The question
of what nodes to involve, including hosts under an
MR, did seem important though in terms of thinking
what architecture works for this function.

Jari

Hesham Soliman

2007-02-20 11:46:26 UTC

Post by Tero Kauppinen (JO/LMF)

Post by Hesham Soliman
So even if we go with "one solution" it would have to
incorporate several modes of operation (at least from the
security perspective) to work for all the different protocols.
Another question to ask here is what is the real benefit of
having one solution? I'm not talking about saving documents,
I mean a real benefit to an implementer. If the flow
descriptors need to have the same format then that's easily
done and reusable for implementers. But that doesn't require
one transport protocol.

What makes you think that it is only about the same format?

=> I look forward to more reasons.

Post by Tero Kauppinen (JO/LMF)
If mobility
management protocols are able to stick to jobs that really belong to
mobility management protocols in contrast to extending them with the
management of filtering rules, I would say that it's more than just
about using the same format. If I, as an implementer of a mobility
protocol, don't have to consider the details of managing
filter rules,
it has a visible impact on the implementation.

=> First of all, what are those mobility management jobs and why is this
aspect not relevant to those jobs? Second, you *do* need to worry about flow
bindings regardless of the solution because even in the approach you
advocate only the transport protocol for the filters is independent, no? The
signalling for the flow binding is still included in the BU, at least in
MIPv6, or are you suggesting that you don't carry anything related to flows
in the BU, this includes mapping between flow id's and CoAs?

If I, on the

Post by Tero Kauppinen (JO/LMF)
other hand,
would need to integrate my mobility protocol implementation into a
system where another mobility protocol is also doing filter rule
management of its own, I would say that my job is to a greater extend
more demanding. Eventually the system will start to evolve
in such a way
that the filter rule management is pulled out to a common module in
which case I start thinking why would the mobility
management protocol

=> I don't know which system you refer to above, but I think it's well
understood among people working in this area that there is a common module
handling flow descriptions and the policies associated between a flow and an
interface/CoA. This module can be indenpendent of the mobility protocol;
what we're discussing here is how to send this information to some other
node.

Hesham

Tero Kauppinen (JO/LMF)

2007-02-20 12:10:50 UTC

Post by Tero Kauppinen (JO/LMF)
What makes you think that it is only about the same format?

=> I look forward to more reasons.

Me too.

Post by Tero Kauppinen (JO/LMF)
If mobility
management protocols are able to stick to jobs that really

belong to > mobility management protocols in contrast to
extending them with the > management of filtering rules, I
would say that it's more than just > about using the same
format. If I, as an implementer of a mobility > protocol,
don't have to consider the details of managing > filter
rules, > it has a visible impact on the implementation.
=> First of all, what are those mobility management jobs and
why is this aspect not relevant to those jobs?

Filter rules need not to be mobility management dependent.

Post by Hesham Soliman
Second, you
*do* need to worry about flow bindings regardless of the
solution because even in the approach you advocate only the
transport protocol for the filters is independent, no?

Not to the same extend.

The

Post by Hesham Soliman
signalling for the flow binding is still included in the BU,
at least in MIPv6, or are you suggesting that you don't carry
anything related to flows in the BU, this includes mapping
between flow id's and CoAs?

No, I'm not suggesting that. Naturally there needs be to some sort of a
link, but I'm just questioning the approach that it should be both the
mapping and the rule in which case changes to rules would always result
in mobility management signaling.

/Tero

Hesham Soliman

2007-02-20 12:34:12 UTC

Post by Tero Kauppinen (JO/LMF)
The

No, I'm not suggesting that. Naturally there needs be to
some sort of a
link, but I'm just questioning the approach that it should
be both the
mapping and the rule in which case changes to rules would
always result
in mobility management signaling.

=> That's fine, so please question the approach. It's best to have clear
questions/doubts to progress the discussion. Or feel free to respond to my
earlier comments. But it's hard to respond to statements like "A is better
than B" without an associated explanation.

Hesham

Post by Tero Kauppinen (JO/LMF)
/Tero

Tero Kauppinen (JO/LMF)

2007-02-20 12:55:17 UTC

-----Original Message-----
Sent: 20. helmikuuta 2007 14:34
To: Tero Kauppinen (JO/LMF); 'Jari Arkko'; 'Internet Area'
Subject: RE: [Int-area] Lifting up a filter discussion from Monami6

Post by Tero Kauppinen (JO/LMF)
The

Post by Hesham Soliman
signalling for the flow binding is still included in the

BU, > > at least in MIPv6, or are you suggesting that you
don't carry > > anything related to flows in the BU, this
includes mapping > > between flow id's and CoAs?

Post by Tero Kauppinen (JO/LMF)
No, I'm not suggesting that. Naturally there needs be to
some sort of a > link, but I'm just questioning the

approach that it should > be both the > mapping and the
rule in which case changes to rules would > always result >
in mobility management signaling.
=> That's fine, so please question the approach. It's best to
have clear questions/doubts to progress the discussion. Or
feel free to respond to my earlier comments. But it's hard to
respond to statements like "A is better than B" without an
associated explanation.

I think that separating filter rules as much as possible from mobility
management protocols (mmp) is good because:

* integrating a new mmp to the framework is easier because the impact on
the mmp is kept minimal
* changes in filter rules do not always necessitate additional mmp
signaling, signaling of course but not mmp signaling
* filter rules can be distributed to nodes (or received from nodes) that
would not normally receive mmp signals from the terminal (or would not
send mmp signals to the terminal)

I fully acknowledge that these present just my personal opinions because
one of the tricky aspects in this whole vs. discussion is that I think
it is possible get both approaches to work.

/Tero

Hesham Soliman

2007-02-20 21:40:14 UTC

The real problem here seems to be that MIP6 (and

associated protocols

such as NEMO), for good or bad, has chosen the path of

being part of the

IP layer rather than running at the transport layer. Since

the mapping

of filter rules to addresses (not defining or exchanging the rules
itself, but, the mapping) is very much part of a handoff

problem, it

needs to be integrated with the protocol for optimal

operation during

handoffs. One option on the table is the use of mobility

options (which

is an option to the Mobility Header, which is also an IPv6

extension

header) - that would make this applicable only to the MIP6 class of
protocols. If we want MOBIKE or Shim6 to be able to use it, I was
suggesting looking into defining its own IPv6 extension

header, since

that can be carried in any of these protocols (except

=> Correct, it was actually deliberately removed from the spec for good
reasons IMO.

This is

likely to bring up issues with different application PDU
sizes, PMTUD,
etc.
Maybe filter signalling is sufficiently more restricted case of
piggybacking arbitrary data that devising framing, PMTUD,

=> It's not actually piggybacking in the case of MIPv6, it's part of the
mobility header itself.

Hesham

etc. for it
is simpler. I might agree with that if the filters were
restricted to
be (say) less than 500 bytes so that no fragmentation was never
needed.
While solving the more general problem might be useful, it's
not clear
to me yet whether the requirements in this mobility space are strong
enough to preclude using a more generic transport protocol.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________
Int-area mailing list
https://www1.ietf.org/mailman/listinfo/int-area

Hesham Soliman

2007-02-20 22:21:42 UTC

Post by Tero Kauppinen (JO/LMF)

Post by Hesham Soliman
=> That's fine, so please question the approach. It's best to
have clear questions/doubts to progress the discussion. Or
feel free to respond to my earlier comments. But it's hard to
respond to statements like "A is better than B" without an
associated explanation.

I think that separating filter rules as much as possible
from mobility

=> I think the keyword above is "as much as possible". Because as you know,
in the "one solution" approach, you *do* add extensions to the mmp. More
below.

Post by Tero Kauppinen (JO/LMF)
* integrating a new mmp to the framework is easier because
the impact on
the mmp is kept minimal

=> This becomes an implementation issue. The "minimal" impacts you refer to
are based on the assumption that the flow descriptors are defined in your
mobility module. This need not be the case as I mentioned earlier. The
mobility protocol can simply be a carrier for this information. So one could
have a generic module with a generic API to any mobility protocol. The
format of the option can also be the same if needed.

Post by Tero Kauppinen (JO/LMF)
* changes in filter rules do not always necessitate additional mmp
signaling, signaling of course but not mmp signaling

=> Changes in filters will necessitate signalling. what difference does it
make whether this signalling is done in mmp or not?

Post by Tero Kauppinen (JO/LMF)
* filter rules can be distributed to nodes (or received from
nodes) that
would not normally receive mmp signals from the terminal (or
would not
send mmp signals to the terminal)

=> That's false. What's the point of sending filter rules that describe a
flow without binding that flow to an address?? If you're binding that flow
to an address in your generic signalling then you've invented a new mobility
protocol that runs on top of whatever you already have.

Post by Tero Kauppinen (JO/LMF)
I fully acknowledge that these present just my personal
opinions because
one of the tricky aspects in this whole vs. discussion is
that I think
it is possible get both approaches to work.

=> I'm glad you listed those points. It's clear to me that more detail is
needed in this discussion to clarify the issues to others on the list.

Hesham

Post by Tero Kauppinen (JO/LMF)
/Tero

RYUJI WAKIKAWA

2007-02-21 05:57:12 UTC

Hi Jari,

Thanks for starting this discussion.

Unless the sender and receiver agree to use one transport protocol,
it can be any protocol.
Operators can pick one of existing secure transport protocol.
I don't have strong motivation to pick one transport protocol.
This decision depends on how system or application treat the timing
of the exchange, too.

Post by Jari Arkko
- policy container format

Regardless of transport protocol, filter and policy should be ideally
described in a common format.

If we assume running HIP/SHIM/MIP with policy at the same node,
we should consider the policy and filter "race" among those three
protocols.
How we can convert policies derived from different protocols to a
filter set is big problem here.
At least, a common way to "describe" filter and policy is useful to
coordinate the filter set.

If MIP-filter scheme has the field-A for the policy description, but
other-filter schemes don't have field-A, or
if one has the field-X with meaning-X, but others have the same field
with different meaning,
these are the worst case.

Post by Jari Arkko
- timing of the policy exchange

This depends on application.
One application needs to send policy from operators (i.e. HA in
MIP6), but some other want to set policy from clients (MN/MR).

In addition, some application doesn't support dynamic policy exchange.
Some sets of policy are statically configured on MN and HA, and is
dynamically switched according to the path availability.

Trigger of filter change must be promptly operated like the same
timing of BU/BA in MIP6,
but trigger of policy exchange is not necessary operated at the same
time.

Post by Jari Arkko
- securing the transfer
- etc

I actually want to see more comments from SHIM6, HIP, Mobike.
regards,
ryuji

Post by Jari Arkko
Thoughts?
Jari
_______________________________________________
Int-area mailing list
https://www1.ietf.org/mailman/listinfo/int-area

Hesham Soliman

2007-02-21 08:35:29 UTC

Hi Heikki,

I guess Jari wants us to continue this point on the int-area list so I'll
respond to both.
See below.

Post by Hesham Soliman
Regardless of the approach, the solution we had in mind

would transfer flow

Post by Hesham Soliman
descriptions and binding information between the flow in

question and one or

Post by Hesham Soliman
more of the mobile node's addresses. The sender of this

information is the

Post by Hesham Soliman
mobile node. The receiver is either a correspondent node or another
intermediate node. If we use the terms HA/MAP then we're

implying the use of

Post by Hesham Soliman
MIPv6. So I'll stick to generic language.

=> No no no :). You've skipped a lot of steps here. First of all, the
current solution does support nemo because the signalling can be sent from
the MR to the HA/MAP. As you probably know nemo does not allow the MR to
send BUs to a CN, so this fully supports nemo. Now, your second point is
about an MNN sending a BU. First, lets be clear that the MNN does not send
BUs to the MR in any spec defined today, so the BU would have to be sent
from the MNN to a CN/HA/MAP. I don't see why this can't be done in
draft-soliman. If you mean that the MNN (more likely a VMN) needs to know
what properties correspond to which prefix advertised by the MR then this
goes back to a separate issue of how the MR informs MNNs of the properties
associated with advertised prefixes. This issue was raised many years ago
(when nemo was a bof) and was recently referred to by Thierry in his
response to a query about this point. Thierry's response was on this thread
so feel free to take a look.

So the bottom line is the MIPv6 solution does support this case.

Post by Hesham Soliman
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.

Hesham

Alexandru Petrescu

2007-02-21 11:14:09 UTC

Post by Hesham Soliman
Hi Heikki,
I guess Jari wants us to continue this point on the int-area list so
I'll respond to both. See below.

Post by Hesham Soliman
Regardless of the approach, the solution we had in mind

would transfer flow

Post by Hesham Soliman
descriptions and binding information between the flow in

question and one or

Post by Hesham Soliman
more of the mobile node's addresses. The sender of this

information is the

Post by Hesham Soliman
mobile node. The receiver is either a correspondent node or
another intermediate node. If we use the terms HA/MAP then we're

implying the use of

Post by Hesham Soliman
MIPv6. So I'll stick to generic language.

Yes both Hesham and Heikki: MNN doesn't send NEMO BU and MR doesn't send
BU toCN.

(terminology: MNN as defined by terminology documents is a Mobile
Network Node, thus a Mobile Node, which can be a Mobile Router; but I
assume the intent was to say a MH (not a MR) that is connected to a
moving network doesn't send BU to MR - I agree with this).

Post by Hesham Soliman
Now, your second point is about an MNN sending a BU. First, lets be
clear that the MNN does not send BUs to the MR in any spec defined
today, so the BU would have to be sent from the MNN to a CN/HA/MAP. I
don't see why this can't be done in draft-soliman. If you mean that
the MNN (more likely a VMN) needs to know what properties correspond
to which prefix advertised by the MR then this goes back to a
separate issue of how the MR informs MNNs of the properties
associated with advertised prefixes. This issue was raised many years
ago (when nemo was a bof) and was recently referred to by Thierry in
his response to a query about this point. Thierry's response was on
this thread so feel free to take a look.

Regardlessof Thierry mentioning it, it's still unsolved.

It's still true that an LFN/MH has certain preferences for application,
preferences that aren't currently communicated to MR. So when MR makes
monami decisions on which interface to use it's monami-relevant only for
that MR, not for LFN.

In this sense, monami filters at MR are irrelevant to LFN. In which
case one can easily say that monami filters are only for MR. Which is
easy to say that is relevant only for the MH part of that MR.

My reasoning is. But let me turn it into a question:

What's the effect of MR monami filters on the LFN application?

Post by Hesham Soliman
So the bottom line is the MIPv6 solution does support this case.

Post by Hesham Soliman
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.

I agree with you with the first part. But I see a strong relationship
of MR making monami decisions and its effects on LFN. If this
relationship is not defined then one simply can't say Monami is for
NEMO. End-to-end arguments can be made about this.

I also think a clear distinction should be made here, that I wanted to
say since long but things were too hectic at that time.

When monami6 was formed there network mobility was an important topic
discussed in many places. Monami6 has a goal to work in the NEMO
context, so it helped building it up. This can be understood in two ways:

-simplest: NEMO is an extension to MIP, so a HA doing NEMO can be
extended to do monami (mcoa) and it will continue to do NEMO no
problem. But that doesn't mean NEMO protocol was extended. It more
means that that HA will continue to use UDP as before, or HTTP or NEMO.
-more complex: have monami flow bindings to have a meaning _through_ the
MR, to LFN and have a NEMO sense. That is a more relevant means to say
that the MONAMI6 WG does NEMO. OTherwise monami6 does NEMO as much as
it does UDP.

Alex

Hesham Soliman

2007-02-21 17:37:20 UTC

Alex,

Post by Alexandru Petrescu
In this sense, monami filters at MR are irrelevant to LFN. In which
case one can easily say that monami filters are only for MR.
Which is
easy to say that is relevant only for the MH part of that MR.
What's the effect of MR monami filters on the LFN application?

=> See below.

Post by Heikki Mahkonen
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

Post by Heikki Mahkonen
from the laptop trough the phone.

=> Of course, so if it gets the prefixes from the MR and

associated

Post by Hesham Soliman
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.

=> This is not different from a router in the fixed network that
load-balances traffic without informing end hosts. This happens all the time
today and no one is making e2e arguments about that. Routers are given the
authority to route traffic in the most optimum manner, as they see it.

Hesham

Alexandru Petrescu

2007-02-21 18:10:36 UTC

[lifting up monmami6 WG from CC]

Post by Heikki Mahkonen

Post by Heikki Mahkonen
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

Post by Heikki Mahkonen
from the laptop trough the phone.

=> Of course, so if it gets the prefixes from the MR and

associated

Post by Hesham Soliman
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.

=> This is not different from a router in the fixed network that
load-balances traffic without informing end hosts. This happens all
the time today and no one is making e2e arguments about that.

Hi HEsham, I'm not sure how it's thought routers in the fixed network
load-balance traffic without informing end-hosts. IETF has some nice
qos reservation mechanisms that are triggered by end-node after which
routers in the middle look at packet markings and load-balance
accordingly. COPS, RSVP, Traffic Class, Diffserv are keywords for
search. It's the end-node who tags the packets anyways.

It's even true for a MIP6 HA: HA copies the traffic class from inner to
outer header, so what's decided by MN is respected by HA. (there's an
option with pre-configured Traffic Class at HA , but optional that is).

So I think flow bindings for NEMO _would_ be different than
COPS/RSVP/Traffic Class, because MR would make decisions irrespective of
the LFN will, what do you think?

Alex

Hesham Soliman

2007-02-21 18:20:42 UTC

Post by Alexandru Petrescu
Hi HEsham, I'm not sure how it's thought routers in the fixed network
load-balance traffic without informing end-hosts. IETF has some nice
qos reservation mechanisms that are triggered by end-node after which
routers in the middle look at packet markings and load-balance
accordingly. COPS, RSVP, Traffic Class, Diffserv are keywords for
search. It's the end-node who tags the packets anyways.

=> This is not related to reality in deployed networks. End hosts don't use
RSVP and hosts hardly ever mark TOS fields. Anyway, your response is not
related to what I said earlier, routers do split flows to different links
all the time (of course one flow is expected to take the same path in the
network under normal circumstances). This is a fact and I don't see why an
end host has to know which specific links its traffic goes through on every
hop. That makes no sense.

Post by Alexandru Petrescu
It's even true for a MIP6 HA: HA copies the traffic class
from inner to
outer header, so what's decided by MN is respected by HA.
(there's an
option with pre-configured Traffic Class at HA , but
optional that is).

=> Again, this is not related to my comment or this thread in general.

Hesham

Alexandru Petrescu

2007-02-21 18:42:35 UTC

[really lifting it from CC this time]

Post by Alexandru Petrescu
Hi HEsham, I'm not sure how it's thought routers in the fixed
network load-balance traffic without informing end-hosts. IETF has
some nice qos reservation mechanisms that are triggered by
end-node after which routers in the middle look at packet markings
and load-balance accordingly. COPS, RSVP, Traffic Class, Diffserv
are keywords for search. It's the end-node who tags the packets
anyways.

=> This is not related to reality in deployed networks. End hosts
don't use RSVP and hosts hardly ever mark TOS fields.

Huh? RSVP-related RFCs date of last year, recent routers include COPS,
and end hosts routinely mark Traffic Class. What do you mean hosts
hardly ever mark ToS fields? You mean IPv4? I meant IPv6. Modern
wireless access networks have QoS features too.

Post by Hesham Soliman
Anyway, your response is not related to what I said earlier, routers
do split flows to different links all the time (of course one flow is
expected to take the same path in the network under normal
circumstances).

Routers split flows based on what specs? I think you agree we can't say
that because some non-specified flow splitting happens then we need to
specify a similar thing. It means actually we don't want to specify a
similar thing.

Post by Hesham Soliman
This is a fact

What RFC number?

Post by Hesham Soliman
and I don't see why an end host has to know which specific links its
traffic goes through on every hop. That makes no sense.

It depends. _If_ the MR decision to choose a different interface is
based on another interface link-down event then it's normal, it's about
keeping connectivity up for the LFN and the LFN can only be happy about
it. Core routers do the same when selecting paths.

If on the other hand, the decision to choose a different interface is
based on application needs, and MR may _think_ the LFN's application
prefers a certain interface - then it's totally different thing. And I
believe flow bindings fall into this category, because it has filters on
all possible fields in an application payload.

Have I got this right?

Alex

Hesham Soliman

2007-02-21 19:09:45 UTC

This is really getting away from the relevant monami issues but I'll give
you my last 2 cents.

Post by Hesham Soliman
=> This is not related to reality in deployed networks. End hosts
don't use RSVP and hosts hardly ever mark TOS fields.

Huh? RSVP-related RFCs date of last year,

=> And that means they're used?

recent routers

Post by Alexandru Petrescu
include COPS,
and end hosts routinely mark Traffic Class.

=> I didn't say COPS is not used. I'd love to know about the deployment that
you're referring to (where hosts are setting the TC routinely)...

Post by Hesham Soliman
Anyway, your response is not related to what I said

earlier, routers

Post by Hesham Soliman
do split flows to different links all the time (of course

one flow is

Post by Hesham Soliman
expected to take the same path in the network under normal
circumstances).

Routers split flows based on what specs? I think you agree
we can't say
that because some non-specified flow splitting happens then
we need to
specify a similar thing. It means actually we don't want to
specify a
similar thing.

=> You seem to think that a product can't implement an algorithm unless it's
specified in an RFC. This is obviously wrong. Anyone can do whatever they
want, hopefully, provided that they don't break existing specs. And that's
the case here.

Post by Hesham Soliman
This is a fact

What RFC number?

=> Fact != RFC....

Post by Hesham Soliman
and I don't see why an end host has to know which specific

links its

Post by Hesham Soliman
traffic goes through on every hop. That makes no sense.

It depends. _If_ the MR decision to choose a different interface is
based on another interface link-down event then it's normal,
it's about
keeping connectivity up for the LFN and the LFN can only be
happy about
it. Core routers do the same when selecting paths.
If on the other hand, the decision to choose a different interface is
based on application needs, and MR may _think_ the LFN's application
prefers a certain interface - then it's totally different
thing. And I
believe flow bindings fall into this category, because it
has filters on
all possible fields in an application payload.
Have I got this right?

=> No. I don't think you understand that routers can select any next hop
they think is appropriate. Link down/up events are only one factor in this
selection. This is a perfectly acceptable behaviour.

Hesham

Post by Alexandru Petrescu
Alex

Alexandru Petrescu

2007-02-21 19:36:50 UTC

Post by Hesham Soliman
This is really getting away from the relevant monami issues but I'll
give you my last 2 cents.

Post by Hesham Soliman
=> This is not related to reality in deployed networks. End hosts
don't use RSVP and hosts hardly ever mark TOS fields.

Huh? RSVP-related RFCs date of last year,

=> And that means they're used?

Would you like _your_ flow bindings document to become an RFC and one
year later people say it doesn't mean it's used just because it has an
RFC number on it.

Post by Alexandru Petrescu
include COPS, and end hosts routinely mark Traffic Class.

=> I didn't say COPS is not used. I'd love to know about the
deployment that you're referring to (where hosts are setting the TC
routinely)...

Well TC marking is used in my lab, works according to specs.

All MIPv6 implementations supposedly use it too, because the MIP6 spec
says so.

Post by Hesham Soliman
Anyway, your response is not related to what I said

earlier, routers

Post by Hesham Soliman
do split flows to different links all the time (of course

one flow is

Post by Hesham Soliman
expected to take the same path in the network under normal
circumstances).

Routers split flows based on what specs? I think you agree we
can't say that because some non-specified flow splitting happens
then we need to specify a similar thing. It means actually we
don't want to specify a similar thing.

=> You seem to think that a product can't implement an algorithm
unless it's specified in an RFC. This is obviously wrong.

I agree with you if I implied so. But no, far from me that idea. I
think it is a very good idea in some contexts to do just that, specify
locally (non-IETF) a protocol, implement test debug and benefit from the
feature (sell other things in the mean time). Google features (earth,
sitemaps, and more) are just that, widely used, and so on.

Remark in the case of Google, although the methods are not standardized,
they're publicly documented, so we can talk about sitemaps.

Post by Hesham Soliman
Anyone can do whatever they want, hopefully, provided that they don't
break existing specs.

I agree.

Post by Hesham Soliman
And that's the case here.

No no, it's different. An assumption is made on the behaviour of the
network and no proof is given. I'm not even mentioned a protocol name
that is not IETF and that does that flow splitting for an uncoscious
endnode. Doesn't mean I don't believe it exists - it may very well.

But flow splitting can happen in so many different ways that some of
them may be in support of your proposal of MR doing flow bindings on
behalf of LFN, others against.

Being silent about what you mean (what non-IETF flow splitting is widely
used?) means that I can't understand you.

What if for example the flow splitting you mean happens in a network
where only two types of applications are possible, with the
distinguisher being WAP or TCP/IP. The network indeed splits the flows
and gives more ressources to WAP and less to TCP/IP. But it is still
the endnode to decide to use either WAP or TCP/IP.

With flow bindings draft we can't say we choose WAP vs TCP/IP, it's just
TCP/IP. The flow bindings draft qualifies only on TCP/IP parameters.

Post by Hesham Soliman
This is a fact

What RFC number?

=> Fact != RFC....

This is very disappointing. Because it means _your_ draft could become
an RFC and thus a non-fact.

Post by Alexandru Petrescu
If on the other hand, the decision to choose a different interface
is based on application needs, and MR may _think_ the LFN's
application prefers a certain interface - then it's totally
different thing. And I believe flow bindings fall into this
category, because it has filters on all possible fields in an
application payload.
Have I got this right?

=> No. I don't think you understand that routers can select any next
hop they think is appropriate. Link down/up events are only one
factor in this selection. This is a perfectly acceptable behaviour.

Ok, let me try cool down. I agree routers select a next hop they think
appropriate w/o endnode involvement. That selection happens based on
the src and dst address and the traffic class, all being set by the endnode.

You seem to say other routers do it differently, not looking at any
field, or changing some of the fields. You don't say what exactly
method is used. But you say that because other fixed routers don't care
of LFN then MR could either.

I think that is not enough of support for flow bindings monami6.

I also think that the flow binding monami6 methods could make a lot
sense _if_ the MR were informed by the LFN of LFN's preferences. This
is the crux of our argument and we differ - you say flow bindings
monami6 don't need that LFN preferences. And knowing that in NEMO WG
they look _probably_ at exactly MR communicating with LFN for parameter
exchange for RO then I think they should be done in tandem. Ie flow
bindings in monami6 aren't possible w/o RO in NEMO.

Alex

Hesham Soliman

2007-02-21 20:08:16 UTC

Post by Hesham Soliman
=> I didn't say COPS is not used. I'd love to know about the
deployment that you're referring to (where hosts are

setting the TC

Post by Hesham Soliman
routinely)...

Well TC marking is used in my lab, works according to specs.
All MIPv6 implementations supposedly use it too, because the
MIP6 spec
says so.

=> What are you talking about? RFC 3775 doesn't say a host should set the TC
field.

<snip>

Post by Hesham Soliman
=> No. I don't think you understand that routers can

select any next

Post by Hesham Soliman
hop they think is appropriate. Link down/up events are only one
factor in this selection. This is a perfectly acceptable behaviour.

=> I never said that. That would be nonesense.

You don't say what exactly

Post by Hesham Soliman
method is used.

=> I said they do it on a per-flow basis, meaning a flow is expected to take
the same path in the network. But two different flows can take different
paths.

Post by Hesham Soliman
I also think that the flow binding monami6 methods could make a lot
sense _if_ the MR were informed by the LFN of LFN's
preferences.

=> That's fine, but as I mentioned earlier (and so did Thierry) this is a
separate point and can augment any proposal.

This

Post by Hesham Soliman
is the crux of our argument and we differ - you say flow bindings
monami6 don't need that LFN preferences.

=> You must be reading different text from what I wrote, I never said that.
I said it's a separate issue and I hope it gets solved. It's orthogonal to
the choice of protocol, which is what Jari's thread was about.

And knowing that in NEMO WG

Post by Hesham Soliman
they look _probably_ at exactly MR communicating with LFN
for parameter
exchange for RO then I think they should be done in tandem. Ie flow
bindings in monami6 aren't possible w/o RO in NEMO.

=> Sorry, I don't know what you're talking about.

Hesham

Post by Hesham Soliman
Alex

Alexandru Petrescu

2007-02-21 20:58:04 UTC

Post by Hesham Soliman
=> I didn't say COPS is not used. I'd love to know about the
deployment that you're referring to (where hosts are setting the
TC routinely)...

Well TC marking is used in my lab, works according to specs.
All MIPv6 implementations supposedly use it too, because the MIP6
spec says so.

=> What are you talking about? RFC 3775 doesn't say a host should set
the TC field.

Ok, rfc3775 requires both the MN and the HA to use generic encapsulation
with a written reference to another RFC that says when encapsulating
copy the traffic-class field (optionally pre-configure it). Which means
that if MN decides to use a certain class then the intermediary router
HA respects its decision. Right?

So is Traffic Class actually used? I'd say yes, by and large.

Post by Hesham Soliman
=> No. I don't think you understand that routers can select any
next hop they think is appropriate. Link down/up events are only
one factor in this selection. This is a perfectly acceptable
behaviour.

=> I never said that. That would be nonesense.

So you didn't say core routers don't look at any fields, didn't say core
routers dont change some fields (in order to achieve their flow
splitting). Since this is undocumented in an RFC, the only thing I
could is to ask you how do you think the core routers do this flow
splitting?

Post by Alexandru Petrescu
You don't say what exactly method is used.

=> I said they do it on a per-flow basis, meaning a flow is expected
to take the same path in the network. But two different flows can
take different paths.

Is a 'flow' an application-level flow, like srcport-dstport go this path
and other pair other path? Or is it a dstaddress-based 'flow'? Or is
it a src-dst flow? Are there other distinctors than address and port?

Does the endnode learn at any time what paths and path selection are
used by the core routers (signalling from router to endnode)?

If I understand these, then I can say whether that particular deployment
is in support of flow bindings monami6 w/o LFN involvement make sense or
not.

I'm very surprised when it's said that Traffic Class isn't used and
other method is in wide use (flow splitting) but can't characterize it
more than just flows taking different paths.

Post by Alexandru Petrescu
I also think that the flow binding monami6 methods could make a lot
sense _if_ the MR were informed by the LFN of LFN's preferences.

=> That's fine, but as I mentioned earlier (and so did Thierry) this
is a separate point and can augment any proposal.

In a sense yes, I agree it's separated issue, like one can HTTP between
two endnodes and then UDP between one of these nodes and a third.

But remark HTTP and UDP have IP in common, use IP header fields in the
same way. With flowbindings context if one wants to use RSVP on LFN and
flow balancing according to the Traffic Class in the MR (all specified
currently) then this will not work, because you suggest that MR uses the
Flow Identification Option for this classification, or the MR uses the
Traffic Class.

So at this point Traffic Class fields and Flow Identification Options
are competitors. It's not like HTTP and UDP both use IP in the same
way, now you have Flow Identification Options and Traffic Class trying
to do same thing.

Post by Alexandru Petrescu
This is the crux of our argument and we differ - you say flow
bindings monami6 don't need that LFN preferences.

=> You must be reading different text from what I wrote, I never said
that. I said it's a separate issue and I hope it gets solved.

What if solving that issue means actually using Traffic Class? Doesn't
it mean that solving that issue means Flow Identification Option isn't
used? Which of the two RFCs will be used? Which will be a fact?

Post by Hesham Soliman
It's orthogonal to the choice of protocol, which is what Jari's
thread was about.

I think choosing a flow bindings protocol (among three) drafts is
indeed a separate issue. I think then that this issue of competition
between Traffic Class and Flow Identification Option (or Filter Rules in
draft-larsson-monami6-filter-rules-01.txt or Policy Data Set in
draft-mitsuya-monami6-flow-distribution-policy-02.txt) is a second issue.

For example, if there's a means that any of these three drafts rules
makes use of the Traffic Class pre-defined in an RFC (assured
forwarding, etc) then I think I'm basically fine.

I'm also very fine if there's a means for LFN to tell MR via this
Traffic Class field what class it prefers, and fine if MR copies the
Traffic Class field.

Post by Alexandru Petrescu
And knowing that in NEMO WG they look _probably_ at exactly MR
communicating with LFN for parameter exchange for RO then I think
they should be done in tandem. Ie flow bindings in monami6 aren't
possible w/o RO in NEMO.

=> Sorry, I don't know what you're talking about.

Well, as you know in the NEMO WG there's been rechartering to identify
requirements for Route Optimization. While gathering these
requirements, it may be found out that LFN wants to send the BU to HA
(instead of MR sending BU for its prefix). For LFN to do that, it may
be that MR sends to LFN what are the subnets to which it connects. At
that point the flow bindings should be established by LFN somehow.

Or, this may be a solution to the problem we discussed, that LFN knows
nothing about MR decisions and that is bad. That's why I'm saying NEMO
RO and flow bindings for NEMO are tightly related.

There may be additional issues directly related: one would want to make
sure that when NEMO RO is used and LFN sends a BU, it's the Flow
Bindings specified by that BU that prevail, and not the Flow Bindings in
the BU MR would send.

Now more clear?

Alex

Thierry Ernst

2007-03-17 21:51:10 UTC