Fuzzy-layering and its suggestion

["Jason Gao" <[e-mail]>]

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.