Subject: [Monami6] Packet format: draft-soliman-monami6-flow-binding-00.txt

From: "Tero Kauppinen (JO/LMF)" <[email-masked]>
Date: Wed, 12 Apr 2006 13:40:47 +0300

I started reading the draft and got all the way to page 6. :)

I agree that it is important to save bytes, but IMO not at the cost of 
making the format non-extendable.

At minimum the described format should follow the alignment rules which 
is not true here. If all fields are present, there are more than one 
alignment errors: Flow Label, the SPI field, and the C.S. field which 
doesn't even fall into natural 32-bit word boundaries. I realize that 
one or more fields can be missing in which case the layout is different, 
but still alignment rules should be obeyed in all cases.

-- 
Tero Kauppinen                                 Tel: +358 9 299 3057
Research Scientist, NomadicLab, IP Networks,   Fax: +358 9 299 5055
Ericsson Research, Corporate Unit.             Mobile: +358 40 590 7560
Oy L M Ericsson Ab
mailto:[email-masked]

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

---

From: Heikki Mahkonen <[email-masked]>
Date: Wed, 12 Apr 2006 14:03:23 +0300

Hi Hesham,

I have also read this draft and I think that the Binding Update List 
(BUL) and Binding Cache (BC) are not the right place to hold the 
policy/flow binding information. If you use these data structures for 
this information and the MN returns home you loose all the policies as 
the  entries in BUL and BC are removed. Or if it is decided that these 
data structures are best place to hold this information, shouldn't there 
be some way to keep the "policy"/"flow binding" entries there while the 
MN is at home?

In addition there should be machanism to use multiple 
addresses/interfaces for one flow. I think the packet format as it is 
right now does not offer a way to extend support for using multiple 
addresses per flow, right?

Best regards,

Heikki Mahkonen

---

From: "Tero Kauppinen (JO/LMF)" <[email-masked]>
Date: Wed, 12 Apr 2006 14:23:30 +0300

> be some way to keep the "policy"/"flow binding" entries there while the 

I don't also think that flow bindings should be kept in BC (and BUL), 
because this would lead to the situation that BC contains entries that 
are not actually BC entries but flow binding entries, i.e. when 
processing entries in BC it would be required to differentiate between 
two types of entires as well as perform different actions basing on the 
type. What I'm aim at, IMO it is not wise to put all information to just 
one database because they happen to share something in common (the 
care-of address) but they still on the functional level are used to 
different purposes.

---

From: Nicolas Montavont <[email-masked]>
Date: Wed, 12 Apr 2006 13:58:59 +0200

Tero,

You are right, and we failed (up to now) to find out a format that 
respect the alignment. We are working on that...

Nicolas

Tero Kauppinen (JO/LMF) wrote:

> At minimum the described format should follow the alignment rules 
> which is not true here. If all fields are present, there are more than 
> one alignment errors: Flow Label, the SPI field, and the C.S. field 
> which doesn't even fall into natural 32-bit word boundaries. I realize 
> that one or more fields can be missing in which case the layout is 
> different, but still alignment rules should be obeyed in all cases.
>

---

From: Nicolas Montavont <[email-masked]>
Date: Wed, 12 Apr 2006 13:58:00 +0200

Hi,

First of all, thank you for reading the draft.

The BC and BUL are not the place where policies are stored. These 
structures are used to store current bindings between HoA, flows and CoAs.
General policies (that indicate which flow should be mapped to which 
CoA) is out of scope of the draft, and the storage of these policies is 
not defined (up to the implementors).

Nicolas

Tero Kauppinen (JO/LMF) wrote:

>> this information and the MN returns home you loose all the policies 
>> as the  entries in BUL and BC are removed. Or if it is decided that 
>> these data structures are best place to hold this information, 
>> shouldn't there be some way to keep the "policy"/"flow binding" 
>> entries there while the MN is at home?
>
>
> two types of entires as well as perform different actions basing on 
> the type. What I'm aim at, IMO it is not wise to put all information 
> to just one database because they happen to share something in common 
> (the care-of address) but they still on the functional level are used 
> to different purposes.
>

---

From: Heikki Mahkonen <[email-masked]>
Date: Wed, 12 Apr 2006 15:44:34 +0300

Hi Nicolas,

Couple of questions.

Does the FID in this draft mean the same thing as BID in the MCoA draft? 
What is the correlation between these two identifiers? Is this an 
optional solution also for the MCoA draft?

Why should the BC and BUL include more information than just the FID 
(sec: 5.2 & 6.1)?

What is the difference in result between action "discard" (2) and 
"remove" (255)?

By the way in the draft the FID field is drawn as a 8 bit field and it 
is said to be 16 bit unsigned field. I quess its just a typo?

BR,

Heikki Mahkonen

---

From: Nicolas Montavont <[email-masked]>
Date: Wed, 12 Apr 2006 14:57:47 +0200

Hi Heikki,

Heikki Mahkonen wrote:

> Hi Nicolas,
>
> Couple of questions.
>
> Does the FID in this draft mean the same thing as BID in the MCoA 
> draft? What is the correlation between these two identifiers? Is this 
> an optional solution also for the MCoA draft?

The FID is mandatory in our draft.
The FID uniquely identifies a flow binding, and really helps when you 
want to cancel an existing flow binding.

We couldn't use the BID, because one BID is linked to one CoA, while in 
our case, we may need several identifiers for a single CoA. Therefore, 
an identifier must be linked to a flow binding, not only to a CoA.

> Why should the BC and BUL include more information than just the FID 

Because when a node has to forward a packet (CN or HA) to the MN, it 
should be able to check if the flow maps an existing binding. For 
example, assume a MN that has registered CoA1 for destination port 1000. 
When the CN has to send a packet of this flow (port number = 1000), it 
needs to look into its BC to select the appropriate CoA.

Does it make sense to you?

> What is the difference in result between action "discard" (2) and 

This is not very well explained yet in the document, I agree with you :(
Let start with the easiest: "remove" means that the MN requests the node 
to delete an existing flow binding.

The idea of the "discard" action was to allow a MN to request its HA not 
to forward a specific flow. Assume a MN that goes from 802.11 to a GPRS 
connection. The MN may request its HA to stop forwarding video packets 
while it uses the GPRS interface.

> is said to be 16 bit unsigned field. I quess its just a typo?

Yes it is, thanks.

Nicolas

---

From: "Soliman, Hesham" <[email-masked]>
Date: Wed, 12 Apr 2006 08:07:15 -0700

=> Good start :)

=> I'm not sure about that. The format can be extensible in several
ways: 
  - We can define sub-options
  - We can add a version field that allows for new versions of the 
    same option. 
Can you elaborate on how you would like it to be extensible and how the 
current format stops you from doing that?

  At minimum the described format should follow the alignment rules which 
  is not true here. If all fields are present, there are more than one 
  alignment errors: Flow Label, the SPI field, and the C.S. field which 
  doesn't even fall into natural 32-bit word boundaries. 

=> What is the alignment rule? :) This option is defined so that it does 
*not* have static alignment. I know this is different from the way we define
options in IPv6, but I'd like to hear why this is really bad and whether 
having a fixed option is a lot better given the huge waste we will have
(more than 100% overhead in many cases).

Hesham

I realize that

---

From: "Soliman, Hesham" <[email-masked]>
Date: Wed, 12 Apr 2006 08:18:06 -0700

the  entries in BUL and BC are removed.

=> This draft describes flow binding for the cases where the mobile node
has either: 
  1. more than one CoA
  2. a HoA and a CoA (i.e. the MN is at home and a foreign network at the same
     time). 
If the MN is only at home then of course the BC entries are removed and the use
of MIP is not appropriate to split flows. I don't understand your concern here
about deleting policies. If you want to route flows differently while you're 
at home (i.e. between 2 different HoAs) then MIP is not a good tool for doing that.
But I don't see much benefit in that scenario. 

  Or if it is decided that these 
  data structures are best place to hold this information, shouldn't there 
  be some way to keep the "policy"/"flow binding" entries there while the 
  MN is at home?

=> What for? Could please show a scenario?

=> That's right. Splitting the same flow to two different interfaces 
is not a good thing to do because:
  - It can cause packets to arrive out of order
  - It can break security if the packets are protected. 
So I don't think this is something we want to do. 

Hesham

Best regards,

Heikki Mahkonen

---

From: "Tero Kauppinen (JO/LMF)" <[email-masked]>
Date: Thu, 13 Apr 2006 09:11:55 +0300

> current format stops you from doing that?

Okay, I should have said 'hard to extent'. Sure there are a couple of 
bits left and room for 255 bytes altogether, but let's imagine that we 
end up with the proposed kind of format and then later on when people 
start extending the format. It will be difficult to add new fields, 
because there is no clean way to recognize (and skip) fields. Let's say 
that I write an extension called X, and someone then writes an extension 
called Y. Because I have already added a new field, the author of the 
extension Y has to also take this into account; the Y field could be 
after the X field. I just feel that creating such a chain of dependency 
is not necessarily a good characteristic of a protocol.

> => What is the alignment rule? :) 

I was not referring to the alignment rule in this particular case, 
because there in none as you pointed out but to a general rule of 
aligning IPv6 options.

This option is defined so that it does
> having a fixed option is a lot better given the huge waste we will have

I don't know about being really bad, but I'm sure that some experts can 
write a novel about why alignment is generally a good thing. Anyway, 
proper alignment increases the processing speed (important for servers 
like the HA) and it eases the implementation task (less bugz)

Let's consider, for example, the C.S. field when all fields are present. 
Currently the host has to extract the information with something like:

cs = ((((char *) p->data[cs_offset])   & 0x0f) << 4) |
      ((((char *) p->date[cs_offset+1]) & 0xf0) >> 4);

instead of:

cs = p->data[cs_offset];

In addition, some architectures can't handle integers that don't start 
from their natural word boundaries, i.e.

flow_label = *((u16_t *) p->data[fl_offset]);

would crash the system.

The situation could be improved at least to some extend with the 
following re-arrangement of the fields:

       |                                                               |
       +                                                               +
       |                                                               |
       +                       Source Address                          +
       |                                                               |
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                                                               |
       +                    Destination Address                        +
       |                                                               |
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                            SPI                                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Source port               |    Destination port           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Flow Label             |   Protocol    |     C. S.     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

How does that sound?

Regz,
Tero

---

From: "Tero Kauppinen (JO/LMF)" <[email-masked]>
Date: Thu, 13 Apr 2006 11:28:47 +0300

We realize that some changes to the BC and the BUL are required, but do 
not think that flow matching rules should be part of the databases. 
Hence, we feel that the database structure should be something like:

    +---------+
    | Policy  | * Policies with flow matching rules.
    | DB      |   Queries results in a BID list, e.g.
    +---------+   if src_port=6666 && dst_port=80 -> BID=77,...

    +--------+
    |BU /BUL | * The standard binding list completed with the BID field.
    +--------+

Entries in the databases would be something like:

  Policy/Flow DB                            BC/BUL
  +---------------------+-------+..+---+   +---------------+-------+
  | Flow matching Rules | BID X |  | Z |   | RFC3775 stuff | BID X |
  +---------------------+-------+..+---+   +---------------+-------+
  | Flow matching Rules | BID Y |  | Z |   | RFC3775 stuff | BID Y |
  +---------------------+-------+..+---+   +---------------+-------+
  .                             .  .   .   | RFC3775 stuff | BID Z |
  +---------------------+-------+..        +---------------+-------+
  | Flow matching Rules | BID X |
  +---------------------+-------+.. . .

Note that one entry in the policy/flow DB can contain more than one BID.
-- 
Tero

---

From: Heikki Mahkonen <[email-masked]>
Date: Thu, 13 Apr 2006 14:32:45 +0300

Hi Hesham,

> But I don't see much benefit in that scenario.
==> As Tero showed/told in his mail we think that the multihoming should 
be regarded as a general technical issue and the MIPv6 is needed to 
enable the practical use of multihoming. I mean MIPv6 is needed so the 
MN can use its identifier (HoA) for traffic flows instead of the 
locators (CoAs). This way if one flow moves between CoAs (possibly 
interfaces) the traffic flow does not stop. If the monami6 charter says 
that the multihoming should be regarded as something which can only be 
achieved if you use MIPv6 and in the way the monami6 describes (only in 
foreign link), it is IMO wrong. This said, my reasoning is that MNs have 
a need to bind flows to interfaces or different HoAs even if they are 
attached to home network. When the MN moves away from the home network 
these flows must also be mapped to CoAs (BIDs) and when it returns again 
they are mapped to interfaces or HoAs again.

I don't know if this is something that should be standardized or should 
it be left to implementors. I do however think that if you already have 
a need for some general policy data structure in multihomed node you 
should not make a specification which says that you need this 
information also to be copied into MIPv6 data structures if there is no 
reason for having it there. I mean it is enough to map a policy to 
interface(s), HoA(s) or CoA(s) with BID(s) which is specified in the 
MCoA draft.

> => What for? Could please show a scenario?
==> As I mentioned above I think that the MNs have a need for the 
multihoming mechanism even if they are located at home network. One 
situation could be that the MN has two interfaces which are both 
attached to their home links. In this case some policies are needed to 
map flows between the interfaces and HoAs and if one or both interfaces 
make a handover then these flows need to be mapped to BIDs. I don't know 
if this is reasonable scenario? At least its possible but might be 
unlikely. Hey, at least I tried. =)

> So I don't think this is something we want to do.
==> The drafts ( "Motivations and Scenarios for Using Multiple 
Interfaces and Global Addresses" and "Analysis of Multihoming in Mobile 
IPv6" ) in the monami6 WG say that this could be used in some scenarios. 
Anyway, I would not be too concern how the packets would arrive (TCP) or 
how the security is handled in this situation. I think this is a whole 
new technical discussion which is not part of the monami6 charter. I 
think that in this WG it should be researched if this is possible or 
not, technically I mean. The use cases for it could come up later in 
some other WG. However, the other draft (above) already specifies at 
least some use cases...

Finally, I'm not saying that the flow binding draft is completely 
useless. I think that in some cases the BU would be good place to 
distribute policies. One good issue is that the MIPv6 security 
mechanisms can be used to secure also the policies. However, I think 
that these policies should be kept in the general policy data structure 
and they should be mapped to CoAs with BIDs not FIDs. Bad thing is that 
if you want to enable multihoming for MNs in home link the BU cannot be 
used to distribute the policies.

-Heikki

> ------------------------------------------------------------------------
>

---

From: Heikki Mahkonen <[email-masked]>
Date: Thu, 13 Apr 2006 15:17:19 +0300

Hi Nicolas,

> want to cancel an existing flow binding.
==> OK! Thank you for clarifying this. As I said I was thinking more in 
lines that the FID = BID to map the flow binding to a BID and that is 
why I said that it is not possible to map it to several BIDs with the 
current packet structure...

> an identifier must be linked to a flow binding, not only to a CoA.
==> I think it is possible to link one flow to several BIDs or several 
flows to one BID in the general policy data structure.

> Does it make sense to you?
==> I don't know does it make sense. As said in the earlier mails I 
think that policies should anyway be kept in this general policy data 
scturcture and they should be mapped to CoA with some means. Now, what I 
mean with policy is the same data that your draft actually specifies for 
flow binding. I don't think that this data is needed in two places 
(general policy data structure and BUL/BC), do you? I have been thinking 
that for the mapping between general policy data structure entries and 
BUL/BC entries are made with the BIDs.

I quess you must have differnet opinion?

> while it uses the GPRS interface.
==> OK! This sounds good. I didn't get this from the draft. Thank you!

-Heikki

---

From: Gábor Fekete <[email-masked]>
Date: Thu, 13 Apr 2006 15:48:44 +0300

> they are mapped to interfaces or HoAs again.
The first thing that cought my attention when started with monami6 is
that it says "Mobile Nodes and Multiple Interfaces in IPv6" but then it
deals only with MIP and NEMO. So, IMHO, the title is a bit misleading.

> interface(s), HoA(s) or CoA(s) with BID(s) which is specified in the 

I agree. But, again, monami6 seems to be MIPv6 (and NEMO) specific.
Or isn't it the case? Now I am confused!

> ...
If a multi-interfaced MN is at home, you may still use BUs to distribute
policies to CNs.

Just as a side note, neither MIP nor NEMO was designed for multihoming
(or flow-separation), so they have to be "hacked". Monami6 is trying to
"hack" them. In my opinion the biggest ugliness is caused by the fact
that HoA is not only an ID but a locator at the _same_time_.
For flow-separation (different ifaces for different flows) you have to
have a node that does this separation (for inbound traffic for the MN).
For MIPv6, If all the CNs support MIP6 then you are good, but if not
then you have to rely on the HA. But the HA is not there for you all the
time, i.e., if it stops proxying for the HoA then you are left with no
"flow-separator" node (for incoming flows).

Gabor