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

["Templin, Fred L" <Fred.L.Templin@boeing.com>]

I am forwarding this from the MANET list, where the topic
of encapsulation has come up for discussion. This is a
proposal for a new protocol called the :

  "Subnetwork Encapsulation and Adaptation Layer (SEAL)"

that places a 4-byte mid-layer encapsulation immediately
after the outermost IPv4 header and immediately before
the inner encapsulations, such as IPv4, IPv6, ESP/AH,
UDP/LISP, etc. The mid-layer encapsulation provides:

  - a 16 bit extension to the IPv4 ID field to create
    a 32bit ID useful for duplicate packet detection and
    association of segments of a segmented datagram
  - a segmentation and reassembly capability that avoids
    the pitfalls of IPv4 fragmentation
  - an inline path MTU probing capability that can use
    perishable probe packets and/or run piggybacked on
    ordinary data packets
  - multiprotocol support via an IPv6-like Next Header
    field

Finally, while the title includes the word: "Subnetwork",
the same concepts and constructs apply when the interdomain
routing core is treated as a giant subnetwork. Comments on
the list are welcome.

Fred
fred.l.templin@boeing.com

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


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
fred.l.templin@boeing.com
_______________________________________________
manet mailing list
manet@ietf.org
http://www.ietf.org/mailman/listinfo/manet

--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg