Subject: [manet] SEAL (was: DPD for IPv4 MANETs)

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 1 Feb 2008 13:04:24 -0800

I would like to have just one more word on this subject
for now. I would like to propose a new IP encapsulation
protocol called the:

  "Subnetwork Encapsulation and Adaptation Layer (SEAL)" 

protocol which would be used by routers for encapsulating
the packets they send across a subnetwork within a MANET.
The solution defines a new IP protocol type for SEAL and
a new encapsulation format for encapsulating both unicast
and multicast IP packets with an IPv4 header and a 4-byte
"SEAL header" as the outer encapsulation as follows:

                     +---------------------+
                     |    Outer IPv4 Hdr   |
                     ~      (20 bytes)     ~
                     |    (ipproto=SEAL)   |
                     +---------------------+
                     |  SEAL Hdr (4 bytes) |
+-------------+      +---------------------+ 
|             |      |                     |
|  Original   | ==>  |      Original       |
~     IP      ~      ~         IP          ~
|   Packet    |      |       Packet        |
|             |      |                     |
+-------------+      +---------------------+

where the SEAL header has the following format:

 0                             1 1             2 2             3
 0                             5 6             3 4             1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     ID Extension (16 bits)    |  Next Header  |P|R|S|  Seg #  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

and the fields are defined as follows:

 ID Extension - a 16-bit extension of the ID field in the outer
                IPv4 header; contains the upper 16 bits of a 32
                bit id when combined with the outer ID.

 Next Header  - an 8-bit next header value that is used exactly
                as for the IPv6 Next Header and IPv4 Protocol.

 P            - a 1-bit flag. If P=1, this is a probe packet for
                which the decapsulator sends a probe-reply.

 R            - a 1-bit flag. If R=1, this is a reply to a probe.

 S            - a 1-bit flag. If S=1, this is part of a segmented
                packet using SEAL segmentation

 Segment #    - a 5-bit segment number. Encodes the segment number
                (from 0 - 31) of a segmented SEAL packet.

The 16-bit ID in the outer IPv4 header contains the low-order
16 bits, and the 16-bit ID extension in the SEAL header 
contains the high-order 16 bits of a 32-bit identification
included by the encapsulator. The value should be set as
monotonically-increasing, i.e., the same as for the IPv6
fragment ID. The combined 32-bit value can be used for
simplified I-DPD checks for duplicate detection.

The SEAL segmentation and reassembly procedure is used
only when necessary and entails a simple cutting-and-pasting
of the original IP packet when the original IP packet is too
large for the subnetwork. The SEAL encapsulator splits a
too-large original IP packet into smaller segments for which
each segment except the final one is of equal-length. Each
segment is encapsulated in an outer IPv4/SEAL header with
the S flag set to 1 and and with a Segment number set to 0
for the first segment, 1 for the second segment, etc. (there
are at most 32 segments in a segmented SEAL packet). The SEAL
decapsulator splices a segmented SEAL packet back together
simply by splicing segments 0 thru last together in
increasing segment number.

The 'P' and 'R' flags are used to probe the path MTU on the
path to the SEAL decapsulator and are to be used for unicast
only (not multicast). The 'P' flag can be set on either
actual data packets or on specialized probe packets that 
are discarded by the decapsulator. The 'R' flag is set on
specialized reply packets that include identifying information
that identifies the probe packet that triggered the reply.

Finally, the "Next Header" allows multi-protocol operation
over SEAL encapsulation. The inner packet could be an IPv4
packet, an IPv6 packet, a UDP encapsulation (such as proposed
for the LISP protocol) etc.

Comments are welcome,

Fred
[email-masked]
_______________________________________________
manet mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/manet

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 28 Feb 2008 08:36:39 -0800

The SEAL proposal is now specified in an I-D:

  http://www.ietf.org/internet-drafts/draft-templin-seal-03.txt

SEAL provides an extended 32bit ID that supports simplified
DPD for both multicast and unicast. SEAL also accommodates
MANETs that contain heterogeneous links with diverse MTUs.
(It is a shame the list was down for so long that an earlier
attempt to post this failed.)

Fred

>-----Original Message-----
>From: Templin, Fred L 
>Sent: Friday, February 01, 2008 1:04 PM
>To: manet; Joe Macker; Ian Chakeres; Joseph Kopena
>Subject: [manet] SEAL (was: DPD for IPv4 MANETs)
>
>
_______________________________________________
manet mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/manet