Fuzzy layering is not a new philosophy of protocol design.
In IP hourglass model the IP layer lies between the upper transport layer and
the lower physical network layer, hides the details of various access methods
of the physical media and/or the different physical media themselves.
There is an observation that the IP layer, the transport layer protocol TCP/UDP
and the de facto API suite, which we may call application adaptation layer, BSD
Socket are actually not strictly layered but instead interleaved to a certain
extent.
Meanwhile, the application layer is strictly non-interleaved with the physical
network layer.
We can call this phenomenon ‘fuzzy-layering’. Layering to some extent do help,
yet interleaving among layers, limited to a certain extent, is beneficial, even
inevitable. Meanwhile, no layering at all is thoroughly unimaginable. The
extent is, IMHO, three clear layers, each layer with some interleaved
sub-layers. The three layers are the application layer, the grand transport
layer, and the physical network layer. The grand transport layer consists of
three sub-layer: network (sub-)layer (IPv4/IPv6), transmission (sub-)layer
(UDP/TCP/SCTP), some shim (sub-)layers (TLS, RTP etc.) and the application
adaptation (sub-)layer (BSD Socket, OpenSSL, etc.).
Fuzzy-layering tells us that transport layer protocol and network layer
protocol may share some bit field in the network layer protocol header.
--- TCP with ECN extension
has already been a practice of fuzzy-layering.
TCP in the end system and IP in the intermediate systems share the two ECN bits
in the IP header.
--- Traffic classifier
Let a bit in the Traffic Class octet of the IPv6 header be 'Milk Type
Indicator' (MTI, but not' moving target indicator'), which means to request
timely delivery of a packet.
The transport layer of the sender may set the bit, which tells the intermediate
network layer devices to queue the packet 'first in first drop'. That is, the
router should queue a packet with MTI bit set in a short, fast queue. When the
queue overflows, the router drops the oldest packet at first.
The receiving side of the transport layer may deliver to the upper layer
application the packets with MTI bit set in the preserved send order, while
discard those packets delayed longer than some negotiated constraint.
In fact the MTI bit is a 'two-class', one class is 'wine type', the other is
'milk type', QoS classifier. It is a class of classifier different from
priority.
--- IPv6 flow label assignment
Transport layer may set a 'control' bit in the IPv6 Traffic Class octet of the
initiating packet during the setup phase of a connection.
The edge router inspects the control bit. If it is set, the edge router can
further inspect the packet, and reserve resource as required by the piggybacked
resource reservation header in the transport layer packet, allocate and/or
assign a flow label to the expected connection, put the flow label in the flow
label field of the initiating acknowledgement packet.
When the transport layer try to tear down a connection gracefully it should set
the same control bit in the Traffic Class octet as well. The edge router should
release the flow label and corresponding reserved resource. Of course a
time-out mechanism should also be applied to recycle flow labels.
If a site has multiple edge routers, the routers can be configured as a
functional cluster that shares the same flow label space.
--- Mobility, the split of the interface ID of the IPv6 header
We can split the 64-bit interface ID into two 32-bit parts. The higher 32-bit
could be called ‘host aggregation ID’, the lower 32-bit could be called ‘upper
layer thread ID’.
When an endpoint is roaming, the 96-bit prefix of its IPv6 address may vary at
different access points, but the upper layer thread ID should be kept. The
endpoint should notify its peer when its IPv6 address is changed. The peer
should send packet to the endpoint in the new address. In the context of the
endpoint the upper layer thread ID must be unique and thus the connection is
kept across varying IP address. Of course, message authentication code should
be applied to support the identification of the connected peers, and optionally
to protect the integrity of the message.