Subject: [manet] SMF-06 comments

From: "Joe Macker" <[email-masked]>
Date: Fri, 4 Jan 2008 13:14:53 -0500

List:

I received some good feedback on draft-ietf-manet-smf-06.txt.

We will likely edit another revision over the next 2-3 weeks and would like to get any additional feedback from list members.  The
target would be to quickly provide a version 7 (minor changes) and then consider WGLC.

The target remains EXPERIMENTAL submission track.

-joe

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

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 9 Jan 2008 10:23:53 -0800

Joe,

We were going to talk about an encapsulation proposal
for duplicate detection in IPv4 MANETs, so I'd like to
take the opportunity to outline my thoughts now.

The proposal I have in mind might be classified as
a "bump-in-the-interface" approach in which the
encapsulation/decapsulation occurs within the MANET
interface itself and does not occur within a separate
tunnel interface. This can be done in (at least) two
different ways:

  1) Have the MANET interface check for a special IPv4
     destination address in ip-protocol-4 packets, e.g.,
     an all-manet-routers site-scoped multicast address.

  2) Define a new IP protocol type (call it something like
     "manet-encaps") and have the MANET interface intercept
     all packets of the manet-encaps protocol type.

The MANET interface would present a single MTU to the
IPv4 layer, e.g., 1500 bytes. For unicast and link-scoped
multicast, the MANET interface would send packets w/o
encapsulation as-normal since (to my understanding) these
are not currently considered as SMF candidates. For
site- or greater-scoped multicast, the MANET interface
would encapsulate packets using a simple IPv4-in-IPv4
encapsulation. As above, this might use ip-protocol-4
or a new IP protocol number for manet-encaps, but the
encapsulation would be done within the MANET interface
and not in a seperate tunnel interface.

Since the encapsulation adds an extra 20 bytes, the
available MTU will be 20 bytes less than the MANET
interface's advertised MTU. So, if the encapsulation
makes the packet too large, the MANET interface will:

  1) If DF=1 in the IPv4 header of the original multicast
     packet, the MANET interface drops the packet and
     sends an internally-generated IPv4 "fragmentation
     needed" message to the original source. (The
     original source may be a node in a network outside
     the MANET or may be the local MANET router itself.)
     But see also (*) below..

  2) If DF=0 in the IPv4 header of the original multicast
     packet, the MANET interface performs IPv4 fragmentation
     on the original packet before encapsulation, and then
     encapsulates each fragment. As an example, the
     fragmentation can be accommodated by having the MANET
     interface kick the packet back up to the MANET router's
     IPv4 layer, which will fragment the packet and present
     each fragment back to the MANET interface again (but
     this is just one implementation alternative and not
     the only one).

In both cases, the MANET interface sets DF=1 in the outer
IPv4 header added by the encapsulation. This means that
there will be no further fragmentation permitted in the
network as the encapsulated packet is flooded throughout
the MANET by SMF.

As to the reason for doing this, the encapsulation
adds a 16-bit ip_id (the "outer_id") that can be used
along with the ip_id information in the inner IPv4 header
(the "inner_id") to aid in duplicate packet detection.
The MANET interface should not simply write a
monotonically-increasing value in the outer_id however,
since that value would track with the value set in the
inner_id and not provide an effective augmentation to
duplicate detection.

Instead, the MANET interface should increment the value
in the outer_id by 1 for every N inner packets it forwards
from the original source. The simplifying assumption that
the original source is setting monotonically-increasing
values in the inner_id of successive packets would seem
to suggest 65535 as a reasonable value for N due to the
16-bit length of inner_id. However, there is no guarantee
that the original source is using monotonically-increasing
as its method for setting inner_id.

It seems reasonable to assume that, if the original source
is not setting inner_id as monotonically-increasing, then
at worst it is setting inner_id randomly. This is in fact
a configuration alternative for at least one major OS I
am aware of. Based on birthday paradox calculations, a value
for N of ~200 would still provide a reasonable probability
that few non-duplicate packets would include an identical
value in both the inner_id and outer_id. So, we can pick a
number of ~256 or smaller and still have an effective
differentiation for non-duplicate packets assuming that SMF
consults both the inner_id and outer_id. (And, any loss due
to false positives would be the fault of the original source
and not the SMF MANET router.)

Using the manet-encaps described above, SMF MANET routers
could consult the tuple:

  (outer_id, inner_id, inner_src, inner_dst, inner_frag_info)

(and could optionally include "outer_src") when comparing
an incoming packet with the its cache of packets received
earlier. With N=256, this would allow for up to 16 million
packets from the original (inner_src, inner_dst) flow before
appreciable duplication would occur. This seems like plenty
in relation to how many packet cache entries an SMF router
will be able to retain for each flow. N could be tuned to a
lower value also to allow for an even lower incidence of
loss due to false duplicate detection and/or to match with
the actual duplicate cache sizes configured by the SMF
routers in the MANET.

In terms of decapsulation, upon receipt of a manet-encaps
packet the SMF router's MANET interface would consult the
inner_dst to see if it is an IPv4 multicast group that
has been joined on the MANET interface. If not, the SMF
router simply forwards the packet without decapsulating
it (if it is configured to do so). Otherwise, the SMF
also delivers a decapsulated copy of the packet to the
IPv4 layer.

Comments?

Fred
[email-masked]

(*) As food for additional thought, the encapsulation
within the MANET interface might make the packet larger
than the MANET interface's advertised MTU, but still
produce an encapsulated packet that is no larger than the
underlying media's physical MTU. For example, I believe
that IEEE 802.11 supports the physical transmission of
packets of ~2KB or larger (have to check for the exact
value) while most OS's I am aware of only configure an
MTU of 1500 on the IEEE 802.11 interface seen by the IPv4
layer. In such cases, it might be possible to send an
encapsulated packet of 1520 bytes over the physical media
without having to drop the packet and return an IPv4
fragmentation needed message even though the IPv4 interface
advertised an MTU of only 1500.      

> -----Original Message-----
> From: Joe Macker [mailto:[email-masked]] 
> Sent: Friday, January 04, 2008 10:15 AM
> To: [email-masked]
> Subject: [manet] SMF-06 comments
> 
> List:
> 
> We will likely edit another revision over the next 2-3 weeks 
> and would like to get any additional feedback from list members.  The

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 15 Jan 2008 08:33:04 -0800

Joe,

I would like to revisit our previous discussion and
propose  that the encapsulation method for DPD in IPv4
MANETs (described below) be added to the SMF draft before
publication as an experimental RFC. The specification is
straightforward and can be taken directly from this text.
The implementation is also straightforward and can be
added to your testbed with a modest effort (I could help
with this). There is also much to be learned from
experimentation, so going as part of an experimental
now would be better than deferring the experiment to
a (much?) later time. Please advise.

Fred

> From: Templin, Fred L 
> Sent: Wednesday, January 09, 2008 10:24 AM
> To: Joe Macker; [email-masked]
> Subject: RE: [manet] SMF-06 comments
> 
> Joe,
>

---

From: "Ian Chakeres" <[email-masked]>
Date: Wed, 16 Jan 2008 17:17:52 +0530

I tend to feel that using encapsulation is slightly challenging, and
that we shouldn't try to add it to the current SMF document.

Encapsulation bring in extra modification and configuration on both
ends of the tunnel, not to mention MTU issues. In the past, I
experimented with multicast encapsulation. FYI: I did not find good
(straightforward) support for multicast in multicast on Linux or
FreeBSD.

My 2 cents,
Ian

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 16 Jan 2008 14:35:10 +0100

I remember Joe mentioned he prefers keeping SMF as a "native multicast
forwarding mechanism. And I remember he prefers other mechanisms to be
described in other documents. 
I incline to agree with Joe.

There is existing code for encapsulated multicast forwarding (Basic
Multicast Forwarding: BMF) as plugin for olsr.org olsrd daemon. It is not
described in an IETF document. Maybe someone is willing to volunteer. I
discussed this with Erik Tromp and Thales representatives before, they are
not against.
The main reason for BMF to encapsulate is having the address of the router
that forwarded the multicast packet, required if S-MPR-forwarding is used.
Note that SMF using S-MPR-forwarding needs previous hop also. SMF acts on
Layer-2, BMF on layer-3.
BMF encapsulation provides a TLV with a hash fingerprint, currently 32 bits.
We could discuss using a TLV similar to what is defined for SMF-IPv6.

I agree with Ian that encapsulation is slightly challenging. But we could
work on solving the issues. We have already made large progress on SMF and
fragmentation.

Teco.

> -----Oorspronkelijk bericht-----
> Van: Ian Chakeres [mailto:[email-masked]]
> Verzonden: woensdag 16 januari 2008 12:48
> Aan: [email-masked]
> Onderwerp: Re: [manet] SMF-06 comments
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 16 Jan 2008 07:43:21 -0800

Ian, 

> From: Ian Chakeres [mailto:[email-masked]] 
> Sent: Wednesday, January 16, 2008 3:48 AM
> To: [email-masked]
> Cc: Joe Macker; Templin, Fred L
> Subject: Re: [manet] SMF-06 comments
> 

The encapsulation is analyzed in my posting; which part
do you find "challenging"? Plus, the text of what would
go into the SMF document is largely written based on what
is in the poast. Also, as I said I am willing to help with
the code; the effort IMHO is on the order of 2 weeks or less. 
 
> ends of the tunnel, not to mention MTU issues.

There are already changes needed on MANET nodes that
participate in SMF; the encapsulation is a rather small
addition to what is needed already. In terms of MTU, I
have been studying the tunnel MTU issue for ~5 years,
and I believe my analysis to be complete. Please comment
on my proposal if you feel there are any uncertainties.

> In the past, I

Please reread my proposal and comment there. The proposal
is for a "bump-in-the-interface" multicast-in-multicast
encaps, and I am leaning toward a new IP protocol type
rather than overload ip-proto-4. This can go as part of
the changes already needed to support SMF.

> Ian

Please comment on my proposal.

Fred

---

From: "Joe Macker" <[email-masked]>
Date: Wed, 16 Jan 2008 11:05:45 -0500

I agree with Ian.

As I have said I am ok with working on an encapsulation version in a separate ID.

-Joe

> Sent: Wednesday, January 16, 2008 6:48 AM
> To: [email-masked]

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 16 Jan 2008 08:15:48 -0800

Joe,

The analysis for the encapsulation is here on the list
now, along with the time estimate for code integration.
In my experience, the effort is not large and does not
add an onerous burden to the changes already needed for
SMF.

AFAICT, there is one opportunity for getting SMF changes
into MANET nodes - that opportunity being now. A second-
pass document would be stuck with the unsolvable problem
of how to be sure that all nodes on the MANET implement
the new feature, since interoperability with legacy SMF
nodes would be broken. 

Thanks - Fred

> Sent: Wednesday, January 16, 2008 8:06 AM
> To: 'Ian Chakeres'; [email-masked]
> Cc: Templin, Fred L

---

From: "Joe Macker" <[email-masked]>
Date: Wed, 16 Jan 2008 11:30:33 -0500

Ok, I hear what you saying but I disagree with integrating it into SMF EXP.

My older post suggested an approach are we moving away from that.

-Joe
> From: Templin, Fred L [mailto:[email-masked]]
> Sent: Wednesday, January 16, 2008 11:16 AM
> To: Joe Macker; Ian Chakeres; [email-masked]

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 16 Jan 2008 10:29:08 -0800

Joe, 

> Sent: Wednesday, January 16, 2008 8:31 AM
> To: Templin, Fred L; 'Ian Chakeres'; [email-masked]

If the post you are referring to is the same one I am
thinking (I think so) then the difference is that I had
not really sat down and thought about the details of
what an encapsulation solution would look like as of that
time. Now that I have had a chance to think about it, I
believe that the solution is really not all that
challenging.

The first key aspect of the proposal is the
"bump-in-the-interface" approach as opposed to the
normal two-interface approach that has the encapsulation
and MANET interfaces as separate interfaces. This is
important, because applications need to be able to join
multicast groups on a unified, single interface that
represents the node's attachment to the MANET.

The second aspect (the one over which there has been some
uncertainty expressed) is the encapsulation MTU. This is
clearly addressed in the proposal in a way that honors
path MTU discovery and avoids in-the-network fragmentation.

The proposal also discusses the benefit of encapsulation
in the first place, but could probably also emphasize more
clearly the benefit for having the ip source address of
the ingress MANET router as a "tagger-id" (i.e., to
differentiate from other ingress MANET routers).

Adding to the technical considerations, there is the
backward compatibility issue to consider as I think
you have acknowledged. So yes, I think we should take
another look.

Thanks - Fred

---

From: Philippe Jacquet <[email-masked]>
Date: Thu, 17 Jan 2008 21:58:20 +0100

Hi, all,

Another example of encapsulation based protocol: some times ago, we 
wrote the specifications of a simplified multicast protocol based on 
OLSR (SMOLSR) with encapsulation.

Anis Laouiti has implemented it on http://hipercom.inria.fr/SMOLSR-MOLSR/

Best regards,
Philippe

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 17 Jan 2008 15:17:18 -0800

Teco,

I took a look at this BMF, and the idea of adding a 32 bit
fingerprint (or, ID) could easily apply also with my proposal
for a new IP protocol type for encapsulation from within the
MANET interface. This would eliminate the need for playing
tricks with the 16bit ip_id in the outer IP header.

As described in my proposal, this would be a sub-IP layer
approach (unlike the BMF layer 3 approach) and hence
compatible with SMF. The encapsulation would be:

                     +-------------+
                     |Outer IP Hdr |
                     | (ipproto=Y) |
                     +-------------+
                     |  32-bit ID  |
+-------------+      +-------------+
|Inner IP Hdr |      |Inner IP Hdr |
| (ipproto=X) |      | (ipproto=X) |
+-------------+ ==>  +-------------+
|             |      |             |
~   Payload   ~      ~   Payload   ~
|             |      |             |
+-------------+      +-------------+

The inner IP header would have an IP source address of the
original source and IP destination address of the multicast
group, with ipproto=X (for X = UDP, TCP, etc.) The outer IP
header would have an IP source address of the ingress MANET
router that first forwarded the multicast packet into the
MANET, an IP destination address of a site-scoped IPv4
multicast group, and ipproto=Y where "Y" is the new IP
protocol type. The 32-bit ID field would have a value set
by the ingress MANET router - most likely monotonically-
increasing w/o regards to the original source, i.e., no
need for ingress MANET routers to keep a cache of source
addresses.

Again, the proposal is for a single, unified MANET interface
as-seen from the IP layer of the MANET router, with the ip
protocol Y encapsulation/decapsulation occuring from within
the interface. This alows the MANET router to join/leave
multicast groups and send/receive plain IP packets on the
interface as-normal even though the encapsulation is
occurring beneath. The MTU question is resolved, as
explained in my original message.

Thanks for pointing out the BMF, and please send any
comments.

Fred

> From: Teco Boot [mailto:[email-masked]] 
> Sent: Wednesday, January 16, 2008 5:35 AM
> To: [email-masked]
> > On Jan 15, 2008 10:03 PM, Templin, Fred L 
> <[email-masked]>
> > wrote:
> > > Joe,
> > >

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 17 Jan 2008 15:33:33 -0800

> explained in my original message.

Well, with the new 32-bit ID we can perhaps do a bit
better than I described in the previous message. The
MANET interface would have an MTU of (X) while the
encapsulated multicast packets would see an MTU of
only (X-ENCAPS). So, we could have the MANET interface
split packets that are (X-ENCAPS) < size <= (X) into
two smaller-sized packets (perhaps of size (X)/2 each)
and let MANET routers that join the multicast groups
reassemble. This would be different from IPv4 reassembly,
and would amount to a 2-fragment-only splitting and
concatenation operation.

Using this approach, there would never be a case of
having to generate an internally-generated ICMP Packet
Too Big message from within the MANET interface. The
only drawback is that MANET routers that join multicast
groups need to allocate some storage to reassembly; but,
the reassembly itself is trivial.

Most of this is spelled out here now on the list;
next steps?

Fred

---

From: "Teco Boot" <[email-masked]>
Date: Fri, 18 Jan 2008 09:24:37 +0100

Hi Fred,

Details for encapsulation, the TLV approach provides options for future
expansions. 
Of cause the MTU / fragmentation problem is increased, certainly with
variable overhead.

I do not have strong opinions on the fragmentation problem, as the best
practice is to circumvent fragmentation my sending packets far smaller than
MTU. But I think fragmentation should be supported, also for supporting
heterogeneous media.
A fragmentation BCP is cutting a packet in half instead of sending a large
MTU-sized packet and a small second one. The large packet is candidate for
another fragmentation (tunnel in IPsec in MANET-encap, heterogeneous media
etc).

The large difference between BMF and your proposal is the source address
used. It is the tagger or the previous hop. Is there a paper on what is the
best solution? Why not using both, putting tagger or prev_hop address in the
TLV?

Cross-posting on MANET_ID:
There is the compatibility issue. Assume we are all at IETF, and I use my
experimental implementation and Fred and Joe do the same, I do not want be
influenced and disrupted by the others. MANET_ID with a large identifier
(e.g. randomly generated) helps to keep experimental protocols private.

Regards, Teco

> Van: Templin, Fred L [mailto:[email-masked]]
> Verzonden: vrijdag 18 januari 2008 0:17
> Aan: Teco Boot; [email-masked]
> Onderwerp: RE: [manet] SMF-06 comments
> 
> Teco,
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 18 Jan 2008 09:35:39 -0800

Hi Teco, 

> Sent: Friday, January 18, 2008 12:25 AM
> To: Templin, Fred L; [email-masked]

I tend to think the SMF multicast mid-layer encapsulation
should be kept as simple and lightweight as possible. I
don't know why a TLV would be required for any future use. 
 
> MTU.

This is agreed the best practice for end systems when
sending multicast; sending only smallish packets (well
under 1500 bytes) ensures that they reach as many
destinations as possible. Also, when using IPv4 the
sender should set DF=1 to avoid polluting or damaging
the reassembly caches of many receivers. But, the
network cannot enforce any behavior on the end systems,
and should make best effort based on the size of the
packets it can forward and the setting of the DF bit.

It is well known that in-the-network IPv4 fragmentation
is harmful for unicast, but pathalogical for multicast.
That is why I am specifically *not* advocating IPv4
fragmentation, but rather a limited mid-layer segmentation
capability that is distinct from IPv4 fragmentation and
does not incur the problems. Going back to my proposal
and revising slightly, the encapsulation is:

                     +-------------+
                     |Outer IP Hdr |
                     | (ipproto=Y) |
                     +-------------+
                     | 32-bit shim |

where the 32-bit shim has the following format:

0                              1 1                             3
0                              5 6                             1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   ID Extension (14 bits)  |F|S|           Checksum            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The "ID extension" is a 14bit extension of the 16bit ip_id
in the outer IPv4 header, making for a 30bit extended ip_id.
The "F" bit is 0 if this datagram is unfragmented and 1 if
it is part of a (mid-layer) segmented datagram. The "S"
bit is 0 if this is the "A" segment and 1 if this is the
"B" segment (we will support at most 2-segment segmentation).
The checksum is simply the 1's complement of bits 0 thru
15 and used as an integrity check in case any of those bits
were damaged in transmission.

> But I think fragmentation should be supported, also for supporting
> heterogeneous media.

If the original source sets DF=0 in the inner packet, then
the network has no choice but to assume that the source is
acting responsibly and uses IPv4 fragmentation as specified
in RFC 791. If the original source sets DF=1 and the packet
is too big, then the network can either drop the packet and
send back an ICMP PTB or perform the limited mid-layer
segmentation from within the injecting MANET router's MANET
interface as specified here. Note that the limited mid-layer
segmentation does not have to honor the inner DF bit as long
as it puts the segmented original packet back together before
forwarding it outside of the MANET.
 
> another fragmentation (tunnel in IPsec in MANET-encap, heterogeneous
media

This has been talked about extensively on the RRG list,
but the use case there is slightly different from the
MANET flooding use case we are talking about here. If
you are talking about IPv4 fragmentation for a packet
which, before encapsulation, has DF=0 then I agree
with splitting into roughly equal-sized fragments and
that is in fact part of the proposal. But, if you are
talking about fragmentation either after or during
encapsulation then the situation is somewhat different
since the goal is simply to mitigate the addition of
the encapsulating header for multicasts only.

Let's say the ingress MANET router's MANET interface
has an MTU of 1500 bytes, and a 1477 byte multicast
packet is presented to the interface by the IP layer.
IP expects the packet will be transmitted, but the
sub-IP layer encapsulation described above adds a
24-byte encapsulating header, which makes the packet to
be 1501 bytes which is too large for transmission on the
underlying media. The MANET interface could drop the
packet and return an ICMP packet too big with MTU=1476,
but that might result in a reduced packet delivery ratio
when a simple and limited mid-layer segmentation and
reassembly could accommodate the packet.

Note that particularly for the multicast case, the 1477
byte packet should not receive better treatment than a
1476 byte one. So, the segmentation should send a 1476+24
packet plus a 1+24 packet rather than sending a 739+24
plus a 738+24. (NB: DF=1 in the outer IPv4 header *always*.)
If the 1476+24 (=1500) is too big for some router in the
MANET to forward, it will return an ICMP PTB with MTU=X
to the injecting MANET router, which will translate the
PTB into a PTB with MTU=MIN(1476,X) to send back to the
original source.

Again, note that the goal for the mid-layer segmentation
is only to accommodate packets that are no larger than
the MANET interface MTU but larger than the MANET
interface MTU minus 24 bytes. A case could be made that
all efforts should be made to accommodate all multicasts,
in which case there might be reason to do the 50/50
fragmentation you are describing for all packets between
MTU/2 - MTU. But, I tend to think this to be a poor practice
when we are talking about multicasts that will be flooded
everywhere since the segmentation would become commonplace.
In other words, for multicast the segmentation should only
be exercised in the extreme case that the packet is close
to the size of the actual underlying physical media, which
original sources that honor the BCPs should not be doing in
the first place.
 
> used. It is the tagger or the previous hop.

IMHO, the larger differences are the encapsulation, the
layering approach and the MTU handling.

> Is there a paper on what is the
> best solution?

Of course not; I'm just making this up as I go along.
Isn't that the way you did it for the IPv6 case? But
IMHO, the proposal I am posting here on the list now
speaks for itself. Please continue to comment.

> Why not using both, putting tagger or prev_hop address in the
> TLV?

With a sub-IP layer approach, the receiving MANET
interface already knows the previous hop address
because it can tell by looking at the L2 source
address which is the address of the previous hop.
So, there is no need to convey the previous hop
id within the encapsulation.

Fred

> > > forwarding mechanism. And I remember he prefers other 
> mechanisms to
> > be

---

From: Philippe Jacquet <[email-masked]>
Date: Sat, 19 Jan 2008 11:47:07 +0100

Following our SMOLSR experiments we found useful to use last hop 
encapsulation and sequence number in order to detect in real time link 
failure. This could be useful in the SMF scenarii where MANET traffics 
are all restricted to multicast and flow much faster than hellos.

It should be noted that link failure notification in multicast would go 
much simpler than with unicast where the connection with low layer 
failure notification lead to nightmarish implementations. Here 
everything would be in layer 3.

Philippe

---

From: Philippe Jacquet <[email-masked]>
Date: Sat, 19 Jan 2008 11:52:29 +0100

I forgot to include MOLSR old spec we wrote 4 years ago. This was all 
inspired from old RFC 3626. Not updated since...

> everything would be in layer 3.

   Simple Multicast based on Optimized Link State Routing Protocol (SMOLSR)

                       Specification of the protocol

Abstract

This document describes the simple multicast based on OLSR protocol. The 
protocol is a forwarding protocol that enables the point to multipoint 
or multipoint to multipoint data transfer in a mobile ad hoc network. It 
is based on the MPR flooding of the OLSR protocol which provide very 
efficient flooding in terms of limited number of retransmissions. The 
principle is the following: multicast packets are captured in the output 
IP stack and encapsulated within DATA_BROADCAST_MESSAGE packet type. 
These packets are flooded in the entire network via the MPRs. Further to 
retransmission procedure, at each host, received  DATA_BROADCAST_MESSAGE 
messages which are not duplicated are also de-capsulated and forwarded 
in the input IP-stack to be delivered to the host upper layer. It is 
assumed that the upper layer of the host contains a filter interface 
that accepts or rejects multicast packets according to the host 
membership to multicast group. Briefly the SMOLSR is an external 
protocol to OLSR. The only information needed from SMOLSR on OLSR is (i) 
the list of the interfaces of the symmetric neighbors of the host and 
(ii) the list of the interfaces of the host MPR selectors.

1. Introduction    1
1.1. SMOLSR Terminology    2
1.2. Applicability Section    3
1.3. Protocol Overview    4
2. Protocol Functioning    4
2.1. Packet Format and Forwarding    4
2.1.1. Protocol and Port Number    5
2.1.2. Multiple Interfaces and Main Address    5
2.1.3. SMOLSR Packet Format    5
2.1.4. Packet Processing and DATA_BROADCAST_MESSAGE Message Flooding    7
2.2. Packet generation    8
2.2.1. SMOLSR packet generation and transmission    8
2.2.2. DATA_BROADCAST_MESSAGE message generation    8
3. Node Configuration    9
3.1. Address Assignment    9
3.2. Routing Configuration    9
3.3. Data Packet Forwarding    10
4. Proposed Values for the Constants    10
5. Sequence Numbers    10

Introduction

The Optimized Link State Routing Protocol (OLSR) is developed for mobile 
ad hoc networks. It operates as a table driven, proactive protocol. 
I.e., exchanges topology information with other nodes of the network 
regularly. Each node selects a set of its neighbor nodes as "multipoint 
relays" (MPR). In OLSR, only nodes, selected as such MPRs, are 
responsible for forwarding control traffic, intended for diffusion into 
the entire network. I.e. MPRs provide an efficient mechanism for 
flooding control traffic by reducing the number of transmissions required.

Nodes, selected as MPRs, also have a special responsibility when 
declaring link state information in the network. Indeed, the only 
requirement for OLSR to provide routes to all destinations is that MPR 
nodes declare link-state information for links between them self and 
their MPR selectors. Additional available link-state information may be 
utilized e.g. for redundancy.

These nodes which have been selected as a multipoint relay by some 
neighbor nodes announce this information periodically in their control 
messages. Thereby, a node announces to the network, that it has 
reachability to the nodes which have selected it as MPR. In route 
calculation, the MPRs are used to form the route from a given node to 
any destination in the network. Furthermore, the protocol uses the MPRs 
to facilitate efficient flooding of control messages in the network.

A node selects MPRs from among its one hop neighbors with "symmetrical", 
i.e. bi-directional, linkages. Therefore, selecting the route through 
MPRs automatically avoids the problems associated with data packet 
transfer over uni-directional links (such as the problem of not getting 
link-layer acknowledgments for data packets at each hop)

OLSR is developed to work independently from other protocols. Likewise, 
OLSR makes no assumptions about the underlying link-layer.

The simple Multicast protocol based on OLSR (SMOLSR) is supposed to work 
on all version of OLSR, provided it can access to host symmetric 
neighborhood and host MPR selector list. It takes advantage of the 
flooding mechanism designed for OLSR via its MPR. It use the following 
input information from OLSR: (i) the list of neighbor interfaces which 
belong to symmetric neighbors of the host, (ii) the list of interfaces 
which belong to host MPR selectors, (iii) the main address of the host, 
and (iv) the interface list of the host.

SMOLSR Terminology

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [5].  The SMOLSR
protocol uses the following terminology:

   multipoint relay selector (MPR selector, MS)

  A node which has selected its one-hop neighbor, node X, as its
  multipoint relay, will be called a multipoint relay selector
  of node X. MPR selection is performed within OLSR protocol.

   node

  A MANET router which implements the Optimized Link State
  Routing protocol and this SMOLSR protocol.

   interface

  A network device participating in the MANET (usually a wire-
  less device). A node may have several interfaces, each inter-
  face assigned an unique IP address.

   neighbor interface

  An interface I is a neighbor interface of an interface J if J
  can hear I (i.e. it is possible to send traffic from I to J).

   sender interface

  The sender interface of a control message is the neighbor
  interface over which the message has been transmitted.

   receiver interface

  The receiver interface of a control message is the (local)
  interface, over which a control message has been received.

   neighbor node

  A node X is a neighbor node of node Y if node Y can hear node
  X (i.e. one of X interfaces is a neighbor interface of some
  interface of Y).

     symmetric link

  A bi-directional link between two interfaces, i.e. interface I
  and interface J where both can hear each other.

   symmetric neighborhood

  The symmetric neighborhood of any node X is the set of nodes
  which have at least one symmetric link to X.

   main address

  The main address of a node, which will be used in OLSR control
  traffic as the "originator address" of all messages emitted by
  this node. It is the address of one of its interfaces.

Multicast packet

A packet generated by application level attended to a multicast group 
and that will be forwarded by the SMOLSR protocol via encapsulation and 
MPRs.

Applicability Section

SMOLSR is a transport protocol for multicast communication in mobile 
ad-hoc networks (MANETs). It is well suited to large and dense mobile 
networks, as the optimization achieved using the MPRs works well in this 
context and where multicast groups are not specifically localized. The 
larger and more dense a network, the more optimization can be achieved 
as compared to the classic link state algorithm. SMOLSR uses hop-by-hop 
routing, i.e. each node uses its local information to route packets.

SMOLSR is well suited for networks, where the traffic is random and 
sporadic between "several" nodes rather than being almost exclusively 
between a small specific set of nodes.

Protocol Overview

SMOLSR is a forwarding protocol for mobile ad hoc networks. The protocol 
inherits the stability of the OLSR protocol.

SMOLSR minimizes the overhead from flooding of broadcast data traffic by 
using only selected nodes, called MPRs, to retransmit those datas. This 
technique significantly reduces the number of retransmissions required 
to flood a message to all nodes in the network.

SMOLSR is designed to work in a completely distributed manner and does 
thus not depend on any central entity. The protocol does NOT PROVIDE 
reliable transmission of data packets as long as wireless link layer 
broadcast packet transmissions are prone to collisions or loss due to 
mobility and are not acknowledged. Reliable multicast transmission must 
be performed at higher level, for example relies on acknowledgement 
aggregation on packet sequencing.

Also, in this current version SMOLSR does not provide sequenced delivery 
of messages, and packet re-sequencing must be performed at higher level. 
However message sequence numbers could be used for this purpose.

Furthermore, OLSR provides support for protocol extensions such as sleep 
mode operation, multicast-routing etc. Such extensions may be introduced 
as additions to the protocol without breaking backwards compatibility 
with earlier versions.

Protocol Functioning

This section describes the details of the protocol functioning. This 
includes descriptions of the format and contents of the packets being 
exchanged by routers and the algorithms (e.g. for packet handling and 
routing table calculation). The key notion for these mechanisms is the 
MPR relationship.

Packet Format and Forwarding

SMOLSR communicates using a packet format for multicast data inherited 
from the unified OLSR packet format. It introduces the SMOLSR multicast 
packet format and the DATA_BROADCAST_MESSAGE message type that 
encapsulates multicast data packet. The SMOLSR packet carries the 
DATA_BROADCAST_MESSAGE messages. These packets are embedded in UDP 
datagrams for transmission over the network. The present draft is 
presented with IPv4 addresses.

Each SMOLSR packet may encapsulate one or more DATA_BROADCAST_MESSAGE 
messages. The messages share a common header format, which enables nodes 
to correctly accept and (if applicable) retransmit messages.

Messages can be flooded onto the entire network, or flooding can be 
limited to nodes within a diameter (in terms of number of hops) from the 
originator of the message. Thus transmitting a message to the 
neighborhood of a node is just a special case of flooding. When flooding 
DATA_BROADCAST_MESSAGE message, duplicate retransmissions will be 
eliminated locally (i.e. each node maintains a duplicate table to 
prevent transmitting the same message twice) and minimized in the entire 
network through the usage of MPRs as described in later sections.

Protocol and Port Number

Packets in SMOLSR are communicated using UDP. It uses port 1698. Port 
698 has been assigned by IANA for exclusive usage by the OLSR protocol.

Multiple Interfaces and Main Address

A node may have several wireless interfaces, each of them having a 
distinct IP address. OLSR supports such nodes with multiple interfaces. 
For this reason, each node SHOULD choose one of its interface addresses 
as its "main address". It is of no importance which address is chosen, 
however a node SHOULD always use the same address as its main address. 
For example, the smallest interface address may be chosen as the main 
interface. The main address MUST be used in OLSR control traffic as the 
"originator address" of all messages emitted by a node.

A node must transmit and retransmit all control messages on all 
interfaces.  The source address in the IP header must contain the 
IP-address of the interface where the message is transmitted. This 
address will be denoted the "sender interface address".

SMOLSR Packet Format

The IP destination field in the SMOLSR multicast packet is the broadcast 
address of the interface which transmits the packet. The basic layout of 
a packet in SMOLSR is as follows(omitting the IP and UDP headers):

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Packet Length         |    Packet Sequence Number     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Message Type |    Reserved   |         Message Size          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Originator Address                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Time To Live |   Hop Count   |    Message Sequence Number    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       :                            MESSAGE                            :
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Message Type |    Reserved   |         Message Size          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Originator Address                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Time To Live |   Hop Count   |    Message Sequence Number    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       :                            MESSAGE                            :
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       :                                                               :
                (etc)

Packet Header

      Packet Length

           The length (in bytes) of the packet

      Packet Sequence Number

The Packet Sequence Number (PSN) MUST be incremented at each any new 
SMOLSR multicast packet transmitted on a given interface. The packet 
sequence numbers are managed on a per interface basis.

    The sender information for a packet is obtainable from the IP header.

Message Header

      Message Type

This field indicates which type of message is to be found in the 
"MESSAGE" partition. There is only one message type in this draft called 
DATA_BROADCAST_MESSAGE type are reserved for messages in this draft and 
in extension drafts.

      Reserved

MUST be set to "00000000" to be in compliance with this version of the 
draft.

      Message Size

           This field gives the size of this message, counted in bytes
           and measured from the beginning of the "Message Type" field
           and until the beginning of the next "Message Type" field (or -
           if there are no following messages - until the end of the
           packet).

      Originator Address

           This field contains the main address of the node, which has
           originally generated this message. This field SHOULD NOT be
           confused with the source address from the IP header, which is
           changed each time to the address of the intermediate interface
           which is re-transmitting this message. The Originator Address
           field MUST *NEVER* be changed in retransmissions.

      Time To Live

           This field contains the maximum number of hops a message will
           be transmitted. Before a message is retransmitted, the Time To
           Live MUST be decremented by 1. When a node receives a message
           with a Time To Live equal to 0 or 1, the message MUST NOT be
           retransmitted under any circumstances. Normally, a node would
           not receive a message with a TTL of zero.

           Thus, by setting this field, the originator of a message can
           limit the flooding radius.

      Hop Count

           This field contains the number of hops a message has attained.
           Before a message is retransmitted, the Hop Count MUST be
           incremented by 1.

           Initially, this is set to '0' by the originator of the message.

      Message Sequence Number

           While generating a message, the "originator" node will assign 
a unique
           identification number to each message. This number is
           inserted into the Sequence Number field of the message. The
           sequence number is increased by 1 (one) for each message orig-
           inating from the node - "wrap-arounds" are handled as
           described in a later section. Message sequence numbers are
           used to ensure that a given message is not retransmitted more
           than once by any node.

Packet Processing and DATA_BROADCAST_MESSAGE Message Flooding

Upon receiving a SMOLRS packet, that contains one or several 
DATA_BROADCAST_MESSAGE messages types. A node may receive the same 
message several times. Thus, to avoid re-processing of some messages 
which were already received and processed, each node maintains a a 
DATA_BROADCAST_MESSAGE Duplicate table. In this table, the node records 
information about the most recently received messages where duplicate 
processing of a message is to be avoided. For such a message, a node 
records a "Duplicate Tuple" (DB_addr, DB_seq_num, DB_time), where 
DB_addr is the originator address of the message, DB_seq_num is the 
message sequence number of the message and DB_time specifies the time at 
which a tuple expires and *MUST* be removed.

In a node, the set of DATA_BROADCAST_MESSAGE Duplicate Tuples are 
denoted the "DB-Duplicate set".

In this section, the term "Originator Address" will be used for the main 
address of the node which sent the message. The term "Sender Interface 
Address" will be used for the sender address (given in the IP header of 
the packet containing the message) of the interface which sent the message.

Thus, upon receiving a basic packet that contains DATA_BROADCAST_MESSAGE 
messages, a node performs the following tasks for each encapsulated message:

1If the time to live of the message is less than or equal to '0' (zero), 
the message MUST silently be dropped.

2If there exists a tuple in the DB-duplicate set, where:

                         DB_addr == Originator Address, AND

                         DB_seq_num == Message Sequence Number

then the message has already been completely processed and MUST silently 
be ignored.

3The message SHOULD be processed according to the
           following algorithm:

3.1If the sender interface address of the message is not detected to be 
in the symmetric neighborhood interface list of the node, the message 
MUST be hereafter silently be dropped.
3.2If the sender interface address of the message is detected to be in 
the symmetric neighborhood interface of the node, an entry in the 
duplicate set is recorded with:

                     DB_addr = originator address

                     DB_seq_num = Message Sequence Number

                     DB_time = current time + DB_HOLD_TIME.
And a de-capsulated copy of the message is forwarded to the higher level 
host multicast membership filter.
3.3If the sender interface address is an interface address of a MPR 
selector of this node and if the time to live of the message is greater 
than '1', the message MUST be forwarded according to the following:

3.3.1The TTL of the message is reduced by one.
3.3.2The hop-count of the message is increased by one.
3.3.3The message is included in as many SMOLSR packets as the host has 
interface managed by OLSR and are transmitted on those 
interfaces.(Notice: The remaining fields of the message header SHOULD be 
left unmodified.)

Packet generation

SMOLSR packet generation and transmission

An SMOLSR packet contains one or several DATA_BROADCAST_MESSAGE messages 
that need to be transmitted or retransmitted. The DATA_BROADCAST_MESSAGE 
messages in a same SMOLSR packet don’t need to be of same originator. 
The packet sequence number of the SMOLSR multicast packet depends on the 
transmitting interface and is equal to the value incremented by one of 
the previous SMOLSR packet transmitted by this interface. In this 
present draft the SMOLSR packet sequence number is not used, but it is a 
provision for QoS management of link regarding multicast operations. If 
SMOLSR packet are more frequent than basic OLSR control packet, then the 
packet sequence number can be used in order to detect link failure or 
link emergence faster than OLSR hello packet and used as link quality 
feedback to OLSR.

DATA_BROADCAST_MESSAGE message generation

Each node should monitor the multicast packet transmission activities of 
the host, for example by checking the output IP stack. When a multicast 
packet is detected to be transmitted to the interfaces managed by OLSR, 
it is intercepted and then encapsulated in a DATA_BROADCAST_MESSAGE 
message as follows:

      Message Body

           This field is a copy of the intercepted multicast packet

      Message Type

This field is set to DATA_BROADCAST_MESSAGE type.

      Originator Address

           This field contains the main address of the host.

      Time To Live

This field is identical to the time to live field of the encapsulated 
multicast message.

      Hop Count

           Set to zero.

      Message Sequence Number

The value incremented by one of the previous DATA_BROADCAST_MESSAGE 
message -"wraparounds" are handled as described in a later section.

Each new DATA_BROADCAST_MESSAGE messages is included in as many SMOLSR 
packets as the host has OLSR interface and following the SMOLSR packet 
generation and transmission rules. New DATA_BROADCAST_MESSAGE messages 
can coexists with older DATA_BROADCAST_MESSAGE messages of different 
originator in a same SMOLSR packet, provided they are intended to the 
same multicast group.

In this present draft there is no fragmentation protocol attached to 
DATA_BROADCAST_MESSAGE message. This implies that multicast packet 
generated by host upper layer SHOULD fit the maximum allowed packet size 
including the additional overhead created by DATA_BROADCAST_MESSAGE and 
SMOLSR multicast packet headers. Packet that cannot fit the packet 
limitation SHOULD silently discarded.

Node Configuration

Address Assignment

The nodes in the MANET network SHOULD be assigned addresses within a 
defined address sequence. I.e., the nodes in the MANET SHOULD be 
addressable through a network address and a netmask.

Likewise, the nodes in each associated network SHOULD be assigned 
addresses from a defined address sequence, distinct from that being used 
in the MANET.

Routing Configuration

Any MANET node with associated networks or hosts SHOULD be configured 
such that it has routes set up to the interfaces with associated hosts 
or network.

Data Packet Forwarding

SMOLSR perform multicast packet forwarding. It is designed to work in 
full compatibility with the OLSR protocol and with the forwarding 
function as specified in IETF RFC1812.

Proposed Values for the Constants

This section list the values for the constants used in the description 
of the protocol.

           DB_HOLD_TIME                         = TBD

           DATA_BROADCAST_MESSAGE         = TBD

Sequence Numbers

Sequence numbers are used in OLSR with the purpose of discarding "old" 
information, i.e. messages received out of order. However with a limited 
number of bits for representing sequence numbers, wraparounds (that the 
sequence number is incremented from the maximum possible value to zero) 
will occur. To prevent this from interfering with the operation of the 
protocol, the following MUST be observed.

The term MAXVALUE designates in the following the largest possible value 
for a sequence number.

The sequence number S1 is said to be "greater than" the sequence number 
S2 iff:

           S1 > S2 AND S1 - S2 <= MAXVALUE/2 OR

           S2 > S1 AND S2 - S1 > MAXVALUE/2

Thus when comparing two messages, it is possible - even in the presence 
of wraparound - to determine which message contains the most recent 
information.

---

From: Brian Adamson <[email-masked]>
Date: Sat, 19 Jan 2008 11:35:43 -0500

I think these sorts of ideas which I think have merit including what 
Teco suggested as maybe basing the encapsulation upon packet-bb point 
towards perhaps specifying this as a separate document from the basic 
SMF specification?  I think some other possibilities might arise with 
an encapsulation scheme along the lines of the BMF scheme.  Some 
added capabilities might be supported such a intermediate system 
merging or filtering of some messages, etc to support potential 
autoconf or other protocols.  I think a single encapsulation scheme, 
perhaps packet-bb based good achieve both Fred's goals and potentialy 
other objectives that lie in fuzzy divide of control plane and data 
plane.

I haven't complete digested all of Fred's ideas for IP encapsulation, 
but it seems that the existing SMF spec would handle IP in IP 
encapsulated packets.

Brian

At 11:47 AM +0100 1/19/08, Philippe Jacquet wrote:
>encapsulation and sequence number in order to detect in real time 
>link failure. This could be useful in the SMF scenarii where MANET 
>traffics are all restricted to multicast and flow much faster than 
>hellos.
>
>It should be noted that link failure notification in multicast would 
>go much simpler than with unicast where the connection with low 
>layer failure notification lead to nightmarish implementations. Here 

-- 
Brian
__________________________________
Brian Adamson
<http://cs.itd.nrl.navy.mil/5522>
<mailto:[email-masked]>

---

From: "Joseph Kopena" <[email-masked]>
Date: Tue, 22 Jan 2008 01:26:30 -0500

> take the opportunity to outline my thoughts now.

Hi all,

Apologies for joining the conversation late.  I haven't fully
processed all of Fred, Teco, and Philippe's comments, but they sound
interesting.  However, I encourage the group to consider holding those
features for a second multicast ID, or an ID extending SMF.  SMF works
nicely as a simple, basic building block on which to construct more
sophisticated systems.  Having written SMF in simulation & working on
more robust "live" versions based on packetbb & nhdp, these
encapsulation features would definitely take implementation into
another level of coding complexity.  As it stands, it's a nice,
straightforward spec that happens to be highly useful, at least for
the variety of projects in which it has been used in my lab, and seems
to be converging on a solid finished draft.

Fred also mentioned concern about trying to ensure the encapsulation
functionality is in there before SMF has widespread deployment.
However, it's worth keeping in mind that SMF is still experimental
track.  I think that would be a larger concern if SMF was not still in
the phase, as I see it, of being fleshed out and determining exactly
what features, such as encapsulation, are important to users.

Thx

-- 
- joe kopena
  http://gicl.cs.drexel.edu/people/tjkopena/

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 22 Jan 2008 08:28:35 -0800

Joseph,

I respect your opinion, but I do not agree with the
characterization of complexity - the encapsulation I
am proposing is simple and correct for the intended
purpose. I encourage you to take a look at the proposal
and comment.

Also, as I said, not having the encapsulation go in
the base draft could make it undeployable at a later
date; I am aware of at least one experimental RFC that
is now shipping in wide-scale deployment in multiple
commercial implementations. Finally, it is not clear
to me that this group would endorse a good-faith effort
to produce a companion draft as a wg task. Clarity on
these latter two points would be welcome.

Fred

> From: Joseph Kopena [mailto:[email-masked]] 
> Sent: Monday, January 21, 2008 10:27 PM
> To: manet

---

From: "Joe Macker" <[email-masked]>
Date: Fri, 25 Jan 2008 15:35:18 -0500

As a chair I would like to reach an interim milestone first and begin the experimental period including more focused work on related
IDs. 

I don't have a problem with working on extensions. I am suggesting it.

What does the WG say re the question of further work here?
>From what I heard most people seem ok with that.

I  also appreciate Joe Kopena's feedback as an implementor/experienced user. Thanks.

---- side comment on deployment paranoia -----
Despite the realities of corruption, I do not want to corrupt the EXPERIMENTAL RFC purpose/process.
I had agreement with the previous AD (vetted by the WG) that we would work this to EXP as a basic native forwarding mechanism.

I know of widescale commercial deployment at the ID stage also.

Then based upon experience consider STD TRACK revision. Design changes would be expected.

There is more to learn on CDSes, filtering, border operation,etc.  
Writing IDs that extend or enhance SMF is encouraged and expected.

-Joe
> Sent: Tuesday, January 22, 2008 11:29 AM
> To: Joseph Kopena; manet

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 28 Jan 2008 10:37:27 -0800

Joe,

Speaking only in terms of the technical, the situation
is actually much simpler than what was written in my
previous messages and entails:

  - no mid-layer integrity checks (i.e., the same as
    for IPv6 extension headers)
  - no mid-layer segmentation/reassembly
  - the ability to encapsulate an original IP multicast
    packet of either IP version (plus a previous-hop IP
    address if desired) in an outer IPv4 header

The solution defines a new IP protocol type "Y" and a new
encapsulation format ("manet-encaps") for encapsulating
original IP multicast packets with IPv4 as the outer
encapsulation as follows:

                     +---------------------+
                     |    Outer IPv4 Hdr   |
                     |     (ipproto=Y)     |
                     +------+----+---------+
                     |ID Ext|Type|   ...   |
+-------------+      +------+----+--       |
|             |      |                     |
|  Original   |      |                     |
|     IP      | ==>  |        Data         |
~  Multicast  ~      ~                     ~
|   Packet    |      |                     |
|             |      |                     |
+-------------+      +---------------------+

where "ID Ext" is a 16-bit extension of the outer
IPv4 ID field, "Type" is a 4-bit version number, and
"Data" encapsulates any additional mid-layer header
info plus the original IP multicast packet as follows:

 Type       Data
 ****       ****
   0        a 12-bit reserved field, followed by an IPv4
            address, followed by the original IPv4 packet
   1        a 12-bit reserved field, followed by an IPv4
            address, followed by the original IPv6 packet
   2        a 12-bit reserved field, followed by an IPv6
            address, followed by the original IPv4 packet
   3        a 12-bit reserved field, followed by an IPv6
            address, followed by the original IPv6 packet
   4        the original IPv4 packet (Type is actually the
            first 4 bits of the IPv4 packet)
   6        the original IPv6 packet (Type is actually the
            first 4 bits of the IPv6 packet)
   8        heh!
   5, 7-15  reserved for future use

When an SMF node injects a multicast packet into a MANET
over SMF-enabled interfaces, it first calculates the size
of the desired encapsulation ("ENCAPS") based on Type as
follows:

 Type       ENCAPS
 ****       ******
   0          28
   1          28
   2          40
   3          40
   4          22
   6          22
   5, 7-15    Reserved for future use

Next, if the original packet is an IPv4 packet with DF=0
the SMF node fragments the packet using IPv4 fragmentation
if necessary such that the size of each fragment plus ENCAPS
is smaller than the known or assumed MTU of the link with
the smallest MTU in the MANET (e.g., 1500 bytes for 802.11).
AFTER IPv4 packet fragmentation per the above, the SMF node
forwards the packet into SMF interfaces as follows:

1) if the packet/fragment is too large for any underlying
   SMF interfaces, the SMF node does not forward it into those
   interface but forwards it into any remaining interfaces as
   specified in steps 2)and 3). (If the original packet was
   IPv6, the SMF node also sends a suitable ICMPv6 Packet
   Too Big message to the original source).
2) if the packet/fragment size plus ENCAPS is too large for
   any remaining underlying SMF interface, the SMF node
   forwards it into those interface(s) *without* first
   performing ipproto "Y" encapsulation
3) otherswise, i.e., if the packet/fragment size plus ENCAPS
   is no larger than any remaining underlying SMF interfaces,
   the SMF node encapsulates it with the desired ipproto "Y"
   encapsulation and forwards the encapsulated packet/fragment
   into those interfaces

When forwarding the packet with ipproto "Y" encapsulation,
if the original IP packet was IPv6 or IPv4 with DF=1, the
SMF node sets DF=1 in the outer IPv4 header. If the original
packet was IPv4 with DF=0, the SMF node sets DF=1 if the size
of the smallest linkMTU in the MANET is either known or can be
guessed, and sets DF=0 otherwise. In this latter case, (i.e.,
when the size of the smallest linkMTU in the MANET is unknown)
the SMF node institutes pacing such that a window of no more
than 64K packets will be forwarded into the MANET based on
outstanding packet lifetimes and regardless of whether DF=0/1. 

During encapsulation, the SMF node sets the extended IPv4 ID
to a monotonically-increasing 32-bit value, i.e., the ID field
in the outer IPv4 header is assigned the low-order 16 bits and
the ID Extension field immediately following the outer IPv4
header is assigned the high-order 16 bits.

This encapsulation allows SMF nodes to perform simplified DPD
checks on each outer packet-to-be-forwarded as follows (*):

+----+----+----------+----------+-----------------------------------+
| df | mf | fragment | ipproto  | IPv4 DPD Action                   |
|    |    | offset   |          |                                   |
+----+----+----------+----------+-----------------------------------+
| 1  | 1  | *        | *        | Invalid, Do not Forward           |
|    |    |          |          |                                   |
| 1  | 0  | nonzero  | *        | Invalid, Do not Forward           |
|    |    |          |          |                                   |

| 1  | 0  | 0        | Y        | Tuple I-DPD-32 Check and Process  |
|    |    |          |          | for Forwarding                    |
|    |    |          |          |                                   |
| 0  | *  | *        | Y        | Tuple I-DPD-16 Check and Process  |
|    |    |          |          | for Forwarding                    |
|    |    |          |          |                                   |
| *  | *  | *        | non-Y    | H-DPD Check and Process           |
|    |    |          |          | for Forwarding                    |
+----+----+----------+----------+-----------------------------------+

(*) Note that, while the outer IPv4 header cannot have DF=1
with MF=1 or offset = zero, it is not an error for the inner
IP packet to be part of a fragmented IPv4 datagram on which
fragmentation was performed before encapsulation.

The tuple for I-DPD-* checking includes only the IPv4 source
address and ID in the outer header. When I-DPD-32 is used,
the ID is calculated as the concatenation of the ID field in
the outer IPv4 header as the low-order 16 bits and the ID
Extension field as the high--order 16 bits. When I-DPD-16 is
used, only the 16-bit ID field in the outer IPv4 header is
used. When the ipproto in the outer IPv4 header is not "Y",
H-DPD is performed using a suitable hash/checksum across
the length of the packet.

This checking eliminates any duplication that would occur
*within* the MANET. If the encapsulated packet/fragment
also includes an IPSec header, then an extended check that
includes the ID in the IPSec header could also eliminate
any duplication that occurred *outside* of the MANET.  

Lastly, the ability to encapsulate either IP protocol
version plus previous hop IP information (when desired)
makes for a more versatile situation than for native
IPv6 MANETs. The I-DPD checks are also simpler and more
efficient in most situations, and H-DPD only occurs in
a worst-case situation that can easily be mitigated by
asking sources to be slightly more conservative in the
size of packets they send.

SMF draft/extension? WG item? Build-and-test? Other?
(All options are pretty straightforward...)

Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 31 Jan 2008 09:42:41 -0800

Attached is a linux kernel implementation of the
encapsulation method for SMF IPv4 DPD specified in this
message thread. The implementation is based on the latest
net-2.6 netdev development tree, and is installed using
the patch utility. It has been tested between two nodes
running the modified kernel attached to the same LAN
segment and is ready for experimentation in more
advanced scenarios.

The implementation inserts an outer IP header after
fragmentation of the inner IP packet and just prior to
submission to L2, i.e. it is a sub-IP layer encapsulation
and as such does not introduce a new tunnel interface. The
outer IP header sets a protocol value that is TBD for SMF
encapsulation, and a destination address that is TBD for
a site-scoped all-manet-routers IPv4 multicast address.
When there is not enough available MTU, the encapsulation
is conceptually compressed to 0 bytes, and SMF uses H-DPD
instead of I-DPD.

As long as the user-level SMF code can recognize the 
encapsulation header, there is opportunity for simplified
and robust I-DPD checking for IPv4 using only the outer
source address and 32-bit ID assigned by the ingress SMF
node. There is also opportunity for incremental deployment
in a mixed environment of SMF nodes that do and do not
insert the encapsulation at the kernel level.

Comments welcome,

Fred

> Sent: Monday, January 28, 2008 10:37 AM
> To: Joe Macker; Joseph Kopena; manet
> Subject: DPD for IPv4 MANETs (was: RE: [manet] SMF-06 comments)
> 
> Joe,
> 
--- net-2.6/include/linux/if.h.orig	2008-01-31 08:32:06.000000000 -0800
+++ net-2.6/include/linux/if.h	2008-01-31 08:33:32.000000000 -0800
@@ -51,6 +51,7 @@
 #define IFF_DORMANT	0x20000		/* driver signals dormant	*/
 
 #define IFF_ECHO	0x40000		/* echo sent packets		*/
+#define	IFF_SMF		0x80000		/* SMF multicast encaps		*/
 
 #define IFF_VOLATILE	(IFF_LOOPBACK|IFF_POINTOPOINT|IFF_BROADCAST|IFF_ECHO|\
 		IFF_MASTER|IFF_SLAVE|IFF_RUNNING|IFF_LOWER_UP|IFF_DORMANT)
--- net-2.6/include/linux/in.h.orig	2008-01-31 08:31:27.000000000 -0800
+++ net-2.6/include/linux/in.h	2008-01-31 08:45:22.000000000 -0800
@@ -46,6 +46,7 @@ enum {
   IPPROTO_COMP   = 108,                /* Compression Header protocol */
   IPPROTO_SCTP   = 132,		/* Stream Control Transport Protocol	*/
   IPPROTO_UDPLITE = 136,	/* UDP-Lite (RFC 3828)			*/
+  IPPROTO_SMF = 140,		/* Simplified Multicast Forwarding	*/
 
   IPPROTO_RAW	 = 255,		/* Raw IP packets			*/
   IPPROTO_MAX
@@ -240,6 +241,7 @@ struct sockaddr_in {
 #define INADDR_ALLHOSTS_GROUP 	0xe0000001U	/* 224.0.0.1   */
 #define INADDR_ALLRTRS_GROUP    0xe0000002U	/* 224.0.0.2 */
 #define INADDR_MAX_LOCAL_GROUP  0xe00000ffU	/* 224.0.0.255 */
+#define	INADDR_MANET_GROUP	0xefff0001U	/* 239.255.0.1 */

 /* <asm/byteorder.h> contains the htonl type stuff.. */
--- net-2.6/include/linux/ip.h.orig	2008-01-31 08:32:16.000000000 -0800
+++ net-2.6/include/linux/ip.h	2008-01-31 08:47:35.000000000 -0800
@@ -112,6 +112,11 @@ static inline struct iphdr *ip_hdr(const
 	return (struct iphdr *)skb_network_header(skb);
 }
 
+static inline struct ip_smf_hdr *ip_smf_hdr(const struct sk_buff *skb)
+{
+	return (struct ip_smf_hdr *)skb_network_header(skb);
+}
+
 static inline struct iphdr *ipip_hdr(const struct sk_buff *skb)
 {
 	return (struct iphdr *)skb_transport_header(skb);
@@ -146,4 +151,11 @@ struct ip_beet_phdr {
 	__u8 reserved;
 };
 
+struct ip_smf_hdr {
+	struct iphdr iph;
+	__be16 idext;
+	__u8 type;
+	__u8 flags;
+};
+
 #endif	/* _LINUX_IP_H */
--- net-2.6/include/net/ip.h.orig	2008-01-31 08:31:27.000000000 -0800
+++ net-2.6/include/net/ip.h	2008-01-31 08:50:03.000000000 -0800
@@ -76,6 +76,20 @@ extern rwlock_t ip_ra_lock;
 
 #define IP_FRAG_TIME	(30 * HZ)		/* fragment lifetime	*/
 
+#define	CONFIG_SMF
+#if defined(CONFIG_SMF)
+/* SMF flags. */
+#define	IP_SMF_FRAG	0x80		/* Segmented SMF pkt */
+#define	IP_SMF_SEG	0x40		/* A/B segment */
+#define IP_SMF_RSVD	0x3F		/* Reserved bits */
+
+/* SMF encapsulation types. */
+#define IP_SMF_PKT	0x00		/* SMF hdr -> IP pkt */
+#define IP_SMF_V4ADDR	0x01		/* SMF hdr -> IPv4 addr -> IP pkt */
+#define IP_SMF_V6ADDR	0x02		/* SMF hdr -> IPv6 addr -> IP pkt */
+#define IP_SMF_COMP	0xff		/* Compressed SMF header -> IP pkt */
+#endif /* defined(CONFIG_SMF) */
+
 struct msghdr;
 struct net_device;
 struct packet_type;
@@ -241,6 +255,22 @@ static inline void ip_select_ident_more(
 		__ip_select_ident(iph, dst, more);
 }
 
+#if defined(CONFIG_SMF)
+static inline void ip_select_ident_smf(struct ip_smf_hdr *smf)
+{
+	static u32 ip_smf_id = 1;
+	static DEFINE_SPINLOCK(ip_smf_id_lock);
+
+	spin_lock_bh(&ip_smf_id_lock);
+	smf->iph.id = htons(ip_smf_id & 0xffff);
+	smf->idext  = htons((ip_smf_id>>16) & 0xffff);
+	if (++ip_smf_id == 0)
+		ip_smf_id = 1;
+	spin_unlock_bh(&ip_smf_id_lock);
+}
+#endif /* defined(CONFIG_SMF) */
+#undef	CONFIG_SMF
+
 /*
  *	Map a multicast IP onto multicast MAC for type ethernet.
  */
--- net-2.6/net/ipv4/ip_input.c.orig	2008-01-31 08:32:37.000000000 -0800
+++ net-2.6/net/ipv4/ip_input.c	2008-01-31 08:33:32.000000000 -0800
@@ -139,6 +139,7 @@
 #include <net/sock.h>
 #include <net/arp.h>
 #include <net/icmp.h>
+#include <net/inet_ecn.h>
 #include <net/raw.h>
 #include <net/checksum.h>
 #include <linux/netfilter_ipv4.h>
@@ -431,6 +432,61 @@ int ip_rcv(struct sk_buff *skb, struct n
 		goto drop;
 	}
 
+#define	CONFIG_SMF
+#if defined(CONFIG_SMF)
+	if (iph->protocol == IPPROTO_SMF) {
+		struct ip_smf_hdr *smf = (struct ip_smf_hdr *)iph;
+		struct iphdr *inner, *outer = iph;
+		int len2;
+
+		if (!pskb_may_pull(skb, sizeof(*smf) + sizeof (struct iphdr)))
+			goto inhdr_error;
+
+		if ((outer->ihl != 5) || outer->frag_off != htons(IP_DF) ||
+		    smf->type != IP_SMF_PKT) 
+			goto inhdr_error;
+
+		inner = (struct iphdr *)(smf + 1);
+
+		if (inner->version != 4)
+			goto process;	/* kick to tunnel driver(s) */
+
+		skb->mac_header = skb->network_header;
+		__skb_pull(skb, sizeof(*smf));
+		skb_reset_network_header(skb);
+
+		if (inner->ihl < 5)
+			goto inhdr_error;
+
+		if (!pskb_may_pull(skb, inner->ihl*4))
+			goto inhdr_error;
+
+		inner = ip_hdr(skb);
+
+		if (unlikely(ip_fast_csum((u8 *)inner, iph->ihl)))
+			goto inhdr_error;
+
+		len2 = ntohs(inner->tot_len);
+		if ((skb->len < len2) || len2 != (len - sizeof(*smf))) {
+			IP_INC_STATS_BH(IPSTATS_MIB_INTRUNCATEDPKTS);
+			goto drop;
+		} else if (len2 < (inner->ihl*4))
+			goto inhdr_error;
+
+		/* inner TTL experiences outer hops */
+		inner->ttl = outer->ttl;
+
+		/* inner ECN experiences outer congestion */
+		if (INET_ECN_is_ce(outer->tos))
+			IP_ECN_set_ce(inner);
+
+		nf_reset(skb);
+	}
+
+process:
+#endif /* defined(CONFIG_SMF) */
+#undef CONFIG_SMF
+
 	/* Remove any debris in the socket control block */
 	memset(IPCB(skb), 0, sizeof(struct inet_skb_parm));
 
--- net-2.6/net/ipv4/ip_output.c.orig	2008-01-31 08:31:28.000000000 -0800
+++ net-2.6/net/ipv4/ip_output.c	2008-01-31 08:42:51.000000000 -0800
@@ -188,6 +188,60 @@ static inline int ip_finish_output2(stru
 	else if (rt->rt_type == RTN_BROADCAST)
 		IP_INC_STATS(IPSTATS_MIB_OUTBCASTPKTS);
 
+#define	CONFIG_SMF
+#if defined(CONFIG_SMF)
+	if (rt->rt_type == RTN_MULTICAST && dev->header_ops &&
+#ifdef notyet
+	    (dev->flags & (IFF_MULTICAST|IFF_SMF)) &&
+#endif
+	    (skb->len + sizeof(struct ip_smf_hdr) <= dev->mtu)) {
+		int max_headroom = (hh_len + sizeof(struct ip_smf_hdr));
+		struct iphdr *inner, *outer;
+		struct ip_smf_hdr *smf;
+
+		inner = ip_hdr(skb);
+
+		if (skb_headroom(skb) < max_headroom) {
+			struct sk_buff *skb2;
+
+			skb2 = skb_realloc_headroom(skb, max_headroom);
+			if (skb2 == NULL) {
+				kfree_skb(skb);
+				return -ENOMEM;
+			}
+			if (skb->sk)
+				skb_set_owner_w(skb2, skb->sk);
+			kfree_skb(skb);
+			skb = skb2;
+		}
+			
+		skb->transport_header = skb->network_header;
+		skb_push(skb, sizeof(*smf));
+		skb_reset_network_header(skb);
+
+		/* install the SMF header */
+		smf		=	ip_smf_hdr(skb);
+		smf->type	= 	IP_SMF_PKT;
+		smf->flags	= 	0;
+		outer 		=	&(smf->iph);
+		outer->version	=	4;
+		outer->tos	=	inner->tos;
+		outer->ttl	=	inner->ttl;
+		outer->frag_off =	htons(IP_DF);
+		outer->daddr	=	htonl(INADDR_MANET_GROUP);
+		outer->saddr	=	rt->rt_src;
+		outer->protocol	=	IPPROTO_SMF;
+		outer->ihl	=	5;
+		outer->tot_len	=	htons(skb->len);
+		ip_select_ident_smf(smf);
+		ip_send_check(outer);
+		memset(&(IPCB(skb)->opt), 0, sizeof(IPCB(skb)->opt));
+		nf_reset(skb);
+		goto process;
+	}
+#endif /* defined(CONFIG_SMF) */
+#undef	CONFIG_SMF
+
 	/* Be paranoid, rather than too clever. */
 	if (unlikely(skb_headroom(skb) < hh_len && dev->header_ops)) {
 		struct sk_buff *skb2;
@@ -203,6 +257,7 @@ static inline int ip_finish_output2(stru
 		skb = skb2;
 	}
 
+process:
 	if (dst->hh)
 		return neigh_hh_output(dst->hh, skb);
 	else if (dst->neighbour)
_______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 31 Jan 2008 11:12:04 -0800

Next step for the specification and implementation is to
investigate support IPv6 multicast over IPv4 MANETs that
use SMF. This is somewhat different than the IPv4-in-IPv4
case, since the encapsulation is cross-stack as opposed
to intra-stack. That means that there will need to be an
IPv6 tunnel virtual interface that overlays the IPv4 MANET
interfaces the same as for ISATAP interfaces. (It would
essentially add an IPv6 multicast capability to ISATAP.)

In this arrangement, the IPv6 multicasts will always have
an IPv4 SMF encapsulation header which means that they will
require a mid-layer segmentation/reassembly when the size
of the IPv6 multicast packet is no larger than the available
MTU but the size added by the encapsulating header makes the
packet too large for the available MTU. This mid-layer
segmentation should only be necessary for MANETs that
include links with unusually small MTUs - in which case
the IPv6 encapsulation over IPv4 MANET approach would
support the minimum IPv6 MTU of 1280 bytes whereas a
native IPv6 MANET approach would not.

This brings up the question as to how would links with
unusually small MTUs due to bandwidth/delay constraints
support the minimum IPv6 MTU of 1280 bytes? Native link-
layer adaptation at L2 is possible (e.g., the same as
for 802.11) but the IP layer would still experience
the same human-perceptible delay issues as for a large
single L2 transmission. This is not a problem when
IPv4 is used as the L2 for IPv6.

Comments?

Fred

> Sent: Thursday, January 31, 2008 9:43 AM
> To: manet
> Cc: 'Joe Macker'; 'Joseph Kopena'; 'Ian Chakeres'; Templin, Fred L
> Subject: RE: DPD for IPv4 MANETs (was: RE: [manet] SMF-06 comments)
> 
> > |    |    | offset   |          |                           
>         |
> > |    |    |          |          |                           
>         |
> > |    |    |          |          |                           
>         |
> > |    |    |          |          |                           
>         |
> > |    |    |          |          |                           
>         |