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

From: "Hesham Soliman" <[email-masked]>
Date: Tue, 20 Feb 2007 04:49:44 +1100

FYI 

-----Original Message-----
From: Hesham Soliman [mailto:[email-masked]] 
Sent: Tuesday, February 20, 2007 4:44 AM
To: 'Jari Arkko'; 'Internet Area'
Cc: [email-masked]
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. 

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
 > register its presence in multiple locations simultaneously.
 > One of things that they expect to be able to do is to control
 > what traffic goes to what care-of address; this flow to this
 > address, and the other flow to that other address. Mobile nodes
 > can obviously decide by themselves what outgoing interface to use.
 > However, in order for a home agent to deal with return traffic
 > properly, the mobile node has to tell it what policy to
 > employ.
 > 
 > The working group has debated between a number of different
 > approaches for doing this. In one approach, draft-soliman-
 > monami6-flow-binding the mobile node adds a filter to a Mobile
 > IPv6 Binding Update to tell what traffic should use this binding.
 > Another approach, draft-larsson-monami6-filter-rules, decouples
 > the policy exchange from the mobility protocol. The policies are
 > exchanged at a different time (typically earlier) and carried by a
 > different protocol (in this case over UDP). Yet another draft,
 > draft-mitsuya-monami6-flow-distribution-policy also separates
 > the mobility protocol and policy transfer, and carries
 > the policies in HTTP.
 > 
 > Monami6 should of course decide how they want to design this.
 > But this may be an interesting debate from a more generic point
 > of view. Do we have input for them? For instance, are there needs
 > in HIP/Shim6/Mobike space for similar functionality? Should the
 > designs be tailored for each of these situations? Is there some
 > advantage or disadvantage in looking at a generic solution?
 > Would a generic solution be doable?
 > 
 > Without going into too much detail about the specific proposals
 > it seems that there are actually a number of different topics here:
 > - carrier protocol choice
 > - policy container format
 > - timing of the policy exchange
 > - securing the transfer
 > - etc
 > 
 > Thoughts?
 > 
 > Jari
 > 
 > _______________________________________________
 > Int-area mailing list
 > [email-masked]
 > https://www1.ietf.org/mailman/listinfo/int-area
 > 

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

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

---

From: Heikki Mahkonen <[email-masked]>
Date: Tue, 20 Feb 2007 09:41:06 +0200

Hi Hesham,

> 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

---

From: "Hesham Soliman" <[email-masked]>
Date: Tue, 20 Feb 2007 22:29:25 +1100

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 

 > From: Heikki Mahkonen [mailto:[email-masked]] 
 > Sent: Tuesday, February 20, 2007 6:41 PM
 > To: Monami6 WG; [email-masked]
 > Subject: Re: [Monami6] FW: [Int-area] Lifting up a filter 
 > discussion fromMonami6
 > 
 > Hi Hesham,
 > 
 > Hesham Soliman wrote:

---

From: Jari Arkko <[email-masked]>
Date: Tue, 20 Feb 2007 22:49:55 +0200

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

---

From: "Hesham Soliman" <[email-masked]>
Date: Wed, 21 Feb 2007 19:35:29 +1100

Hi Heikki, 

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

 > so the MNN can send BU to the MR?

=> 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. 

 > would expect some control over the application flows from the laptop 

=> 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

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 21 Feb 2007 12:14:09 +0100

Hesham Soliman wrote:
> Hi Heikki,
> 
> I guess Jari wants us to continue this point on the int-area list so
>  I'll respond to both. See below.
> 
>> Hesham Soliman wrote:
>>> 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
>> 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?
> 
>  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.

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).

> 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?

>> 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

---

From: "Hesham Soliman" <[email-masked]>
Date: Thu, 22 Feb 2007 04:37:20 +1100

Alex,  

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

=> See below.

 > NEMO.  End-to-end arguments can be made about this.

=> 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

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 21 Feb 2007 19:10:36 +0100

[lifting up monmami6 WG from CC]

Hesham Soliman wrote:
>>>> 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
>> 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.
> 
> 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

---

From: "Hesham Soliman" <[email-masked]>
Date: Thu, 22 Feb 2007 05:20:42 +1100

> 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. 

 > option with pre-configured Traffic Class at HA , but 

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

Hesham