Internet-Draft Recursive Peer Model August 2026
Li Expires 11 February 2027 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-li-recursive-peer-model-00
Published:
Intended Status:
Informational
Expires:
Author:
S. Li
Independent

A Recursive Peer Model for Network Protocols

Abstract

The seven-layer OSI model has served as a foundational framework for network protocol design and education for four decades. However, modern networking practices—including VPNs, NAT, tunneling protocols, and overlay networks—have revealed structural flaws in the OSI model that require ad hoc exceptions to explain.

This document presents a Recursive Peer Model (RPM) as an alternative architectural framework. The model is based on a single observation: every intermediate protocol layer contains its own four-layer structure—Bearer Layer, Data Link Layer, Network Layer, and Transport Layer—and this structure recurs at every layer of the protocol stack. The Data Layer and Medium Layer serve as the two recursive boundaries, terminating at "pure data" and "physical medium" respectively.

The Recursive Peer Model eliminates the need for "exception" clauses (such as the "tunnel exception" for VPNs), provides coherent explanations for protocols that OSI cannot categorize cleanly (such as ARP and ICMP), and offers a unified framework for describing both existing and future protocols.

About This Document

This note is to be removed before publishing as an RFC.

Status information for this document may be found at https://datatracker.ietf.org/doc/draft-li-recursive-peer-model/.

Discussion of this document takes place on the lishi.china Group mailing list (mailto:lishi.china@qq.com).

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 11 February 2027.

▲

Table of Contents

1. Introduction

Since the introduction of the OSI seven-layer model in 1984 [ISO_IEC.7498-1.1994], network protocol design and education have been dominated by its "rigid layering" philosophy. However, four decades of networking practice have shown that real-world protocol stacks are far more flexible and complex than the OSI model's linear stack structure.

The IP-in-IP encapsulation used in VPNs has no legitimate position within the OSI framework and is relegated to a "tunnel exception." The ARP protocol is assigned to either the Data Link Layer or the Network Layer by different textbooks, with no consensus. ICMP is defined as a "Network Layer protocol" yet is encapsulated within IP payloads, creating a logical circularity. These phenomena suggest that the OSI model may have fundamental structural deficiencies.

This document proposes a new protocol description framework—the Recursive Peer Model (RPM). The core idea is that every intermediate protocol layer itself contains a complete four-layer structure, rather than "belonging to" one of the OSI's seven layers. These four layers are, from bottom to top:

The Data Layer at the top and the Medium Layer at the bottom serve as the two recursive boundaries, terminating at "pure data" and "physical medium" respectively.

Unlike the OSI model's "fixed layer number" classification, the Recursive Peer Model starts from "what functions does this protocol itself contain," allowing each protocol to find a coherent position within the model. This shift provides clear and coherent explanations for protocols that are difficult to categorize within the OSI framework.

2. Terminology and Definitions

2.1. Recursive Peer Model (RPM)

A protocol architecture description framework based on the core axiom: every intermediate protocol layer itself contains a four-layer structure—Bearer Layer, Data Link Layer, Network Layer, and Transport Layer. This four-layer structure applies recursively across all intermediate protocol layers. The Data Layer at the top and the Medium Layer at the bottom serve as the two recursive boundaries, terminating at "pure data" and "physical medium" respectively.

2.2. Bearer Layer

When a protocol looks downward, it treats its immediate lower-layer protocol (regardless of its internal complexity) as a point-to-point bearer link. The protocol does not concern itself with the internal mechanisms of the bearer layer; it only uses the transport service provided by it.

2.4. Network Layer

Whether a protocol itself provides cross-node forwarding service. If the protocol forwards data between nodes that are not directly adjacent, it possesses a Network Layer; if it does not forward, its Network Layer is null.

2.5. Transport Layer

When a protocol looks upward, it treats its immediate upper-layer protocol as pure data payload to be transported. The protocol does not concern itself with the content of the transport layer; it only transports it from one end to the other.

2.6. Data Layer

The upward boundary of the recursive model. The Data Layer (such as JSON, HTML, image binaries, audio streams, etc.) is the final form of user data, above which no further protocol layers are carried. The Data Layer itself does not possess a Data Link Layer or Network Layer—it neither encapsulates data nor forwards data. It is the natural termination point of the recursive model.

Application layer protocols (such as HTTP [RFC9110]) treat the Data Layer as their "Transport Layer" (pure data payload) and define how to format and transmit that data.

2.7. Medium Layer

The downward boundary of the recursive model. The Medium Layer (such as optical fiber, copper cable, radio waves) is the ultimate carrier of physical signals, below which no further protocol layers exist. Therefore, the "Bearer Layer" of the Medium Layer is null.

However, the Medium Layer still possesses a complete Data Link Layer and Network Layer:

  • Data Link Layer: the physical medium itself (copper cable, optical fiber, coaxial cable, etc.)—the substance that carries signals;

  • Network Layer: optical fiber splicing, mechanical splicing, optical distribution frame management—activities that complete signal continuation between non-directly-connected physical medium segments, consistent with the definition of Network Layer.

The Medium Layer treats the Coding/Modulation Layer as its "Transport Layer" (carrying modulated signals), while itself providing Data Link Layer (the medium itself) and Network Layer (medium continuation) functions. Its Bearer Layer is null because there is no protocol layer below the Medium Layer.

3. The Recursive Peer Model

3.1. Core Proposition

Every intermediate protocol layer itself contains a four-layer structure, from bottom to top:

  • Bearer Layer: the point-to-point link provided by the lower layer;

  • Data Link Layer: the protocol's own encapsulation, multiplexing, error correction, encryption/decryption;

  • Network Layer: the protocol's own cross-node forwarding (may be null);

  • Transport Layer: the upper-layer protocol as pure data payload.

This four-layer structure exists recursively in every intermediate protocol. Whether one examines TCP [RFC9293], IP [RFC791], or Ethernet [IEEE802.3], the same four-layer structure is found.

3.2. Recursive Boundary Conditions

The recursive nesting of the Recursive Peer Model has two natural boundaries:

Upward Boundary (Topmost Layer): Data Layer.

The Data Layer is the final form of user data, above which no further protocol layers are carried. The Data Layer itself does not possess a Data Link Layer or Network Layer—it neither encapsulates nor forwards data. It is the natural termination point of the recursive model.

Application layer protocols (such as HTTP) treat the Data Layer as their "Transport Layer" (pure data payload). The Data Layer itself does not participate in the recursive nesting of protocol layers.

Downward Boundary (Bottommost Layer): Medium Layer.

The Medium Layer is the ultimate carrier of physical signals, below which no further protocol layers exist. Therefore, the "Bearer Layer" of the Medium Layer is null.

However, the Medium Layer still possesses a complete Data Link Layer and Network Layer:

  • Data Link Layer: the physical medium itself (copper cable, optical fiber, coaxial cable, etc.)—the substance that carries signals;

  • Network Layer: optical fiber splicing, mechanical splicing, optical distribution frame management—activities that complete signal continuation between non-directly-connected physical medium segments.

The Medium Layer treats the Coding/Modulation Layer as its "Transport Layer" (carrying modulated signals), while itself providing Data Link Layer (the medium itself) and Network Layer (medium continuation) functions. Its Bearer Layer is null because there is no protocol layer below the Medium Layer.

These two boundary conditions together define the scope of the recursive model:

  • Upward termination at "pure data" (no further encapsulation);

  • Downward termination at "physical medium" (no further carrier, though the Medium Layer itself may still possess Data Link Layer and Network Layer functions).

3.3. Four-Layer Structure Decomposition

Using the standard TCP/IP protocol stack [RFC1122] as an example, the four-layer structure of each protocol itself can be observed as follows:

Table 1: Four-Layer Structure Decomposition
Protocol Layer Bearer Layer (Lower) Data Link Layer (Self) Network Layer (Self) Transport Layer (Upper)
HTTP TCP Header format, methods, status codes null Data Layer
TCP IP Checksum, retransmission, flow control, port multiplexing null HTTP
IP Ethernet Fragmentation/reassembly, protocol number multiplexing, header checksum Router forwarding TCP segments, UDP datagrams, ICMP messages
Ethernet/MAC Coding/Modulation Layer CRC checksum, collision detection/avoidance, MAC addressing Bridge flooding forwarding (simple network layer) IP packets, ARP frames
Coding/Modulation Layer Medium Layer Digital ↔ physical signal mapping (NRZ/PAM4/QAM) Signal shaping, amplification, regeneration, retransmission (repeaters/optical amplifiers) Ethernet frames
Medium Layer null (recursive termination) Copper cable, optical fiber, coaxial cable (signal-carrying substance) Fiber splicing, mechanical splicing, ODF management Coding/Modulation Layer

Key insight: every row has the exact same four-column structure. TCP does not "belong to" the Transport Layer—TCP itself has a Transport Layer (HTTP). IP does not "belong to" the Network Layer—IP itself has a Network Layer (router forwarding) and also a Transport Layer (carrying TCP). Each protocol is a "complete micro-protocol-stack."

3.4. Distinction Between Medium Layer and Coding/Modulation Layer

In the Recursive Peer Model, the traditional OSI "Physical Layer" is further distinguished into two separate layers:

  • Coding/Modulation Layer: defines the mapping between digital signals and physical signals (such as PAM4 encoding, NRZ encoding, QAM modulation). This is the "protocol" that specifies how to convert digital bits into signals transmittable over physical media.

  • Medium Layer: the physical substance that carries the physical signals (such as optical fiber, copper cable, radio waves). This is the "physical foundation"—the ultimate carrier of signal transmission.

The relationship between the two is: the Coding/Modulation Layer treats the Medium Layer as its Bearer Layer. The Coding/Modulation Layer does not concern itself with how optical signals propagate through fiber or how electrical signals attenuate through copper—it only defines "how to map," and "how to carry" is answered by the Medium Layer.

This distinction maintains the "protocol versus carrier separation" principle of the model at the lowest layer, consistent with the relationships between other layers in the model.

3.5. Recursive Relationships

The four-layer structure nests recursively across different protocol layers. This recursion is bidirectional:

  • Downward recursion (Bearer Chain): each layer's Bearer Layer points to its immediate lower layer;

  • Upward recursion (Transport Chain): each layer's Transport Layer points to its immediate upper layer.

Every node on both chains is a "complete four-layer structure."

The following diagram illustrates this recursive nesting:

       ┌─────────────────────────────────────────────────┐
       │  Data Layer (recursive termination)             │
       │  Pure Data (JSON/HTML/images, etc.)             │
       │  (no Link Layer or Network Layer)               │
       └─────────────────────┬───────────────────────────┘
                             │ HTTP's Transport Layer
                             │ points to Data Layer
                             ↓
       ┌─────────────────────────────────────────────────┐
       │  HTTP Application Layer                         │
       │  ┌─────────────────────────────────────────┐    │
       │  │ Transport Layer: Data Layer             │    │
       │  ├─────────────────────────────────────────┤    │
       │  │ Network Layer: null                     │    │
       │  ├─────────────────────────────────────────┤    │
       │  │ Data Link Layer: header formats,        │    │
       │  ├─────────────────────────────────────────┤    │
       │  │ methods, status codes                   │    │
       │  ├─────────────────────────────────────────┤    │
       │  │ Bearer Layer: TCP (as 1-hop link)       │    │
       │  └─────────────────────────────────────────┘    │
       └─────────────────────┬───────────────────────────┘
                             │ HTTP's Bearer Layer
                             │ points to TCP
                             ↓
       ┌─────────────────────────────────────────────────┐
       │  TCP Protocol Layer                             │
       │  ┌─────────────────────────────────────────┐    │
       │  │ Transport Layer: HTTP                   │    │
       │  ├─────────────────────────────────────────┤    │
       │  │ Network Layer: null                     │    │
       │  ├─────────────────────────────────────────┤    │
       │  │ Data Link Layer: checksum,              │    │
       │  ├─────────────────────────────────────────┤    │
       │  │ retransmission, flow control, ports     │    │
       │  ├─────────────────────────────────────────┤    │
       │  │ Bearer Layer: IP (as 1-hop link)        │    │
       │  └─────────────────────────────────────────┘    │
       └─────────────────────┬───────────────────────────┘
                             │ TCP's Bearer Layer
                             │ points to IP
                             ↓
       ┌─────────────────────────────────────────────────┐
       │  IP Protocol Layer                              │
       │  ┌─────────────────────────────────────────┐    │
       │  │ Transport Layer: TCP/UDP/ICMP           │    │
       │  ├─────────────────────────────────────────┤    │
       │  │ Network Layer: router forwarding        │    │
       │  ├─────────────────────────────────────────┤    │
       │  │ Data Link Layer: fragmentation/         │    │
       │  ├─────────────────────────────────────────┤    │
       │  │ reassembly, protocol multiplexing       │    │
       │  ├─────────────────────────────────────────┤    │
       │  │ Bearer Layer: Ethernet (as 1-hop link)  │    │
       │  └─────────────────────────────────────────┘    │
       └─────────────────────┬───────────────────────────┘
                             │ IP's Bearer Layer
                             │ points to Ethernet
                             ↓
       ┌─────────────────────────────────────────────────┐
       │  Ethernet/MAC Protocol Layer                    │
       │  ┌─────────────────────────────────────────┐    │
       │  │ Transport Layer: IP/ARP                 │    │
       │  ├─────────────────────────────────────────┤    │
       │  │ Network Layer: bridge flooding          │    │
       │  ├─────────────────────────────────────────┤    │
       │  │ Data Link Layer: CRC, collision         │    │
       │  ├─────────────────────────────────────────┤    │
       │  │ detection/avoidance, MAC addressing     │    │
       │  ├─────────────────────────────────────────┤    │
       │  │ Bearer Layer: Coding/Modulation         │    │
       │  ├─────────────────────────────────────────┤    │
       │  │ Layer (as 1-hop link)                   │    │
       │  └─────────────────────────────────────────┘    │
       └─────────────────────┬───────────────────────────┘
                             │ Ethernet's Bearer Layer
                             │ points to Coding/Modulation
                             ↓
       ┌─────────────────────────────────────────────────┐
       │  Coding/Modulation Layer                        │
       │  ┌─────────────────────────────────────────┐    │
       │  │ Transport Layer: Ethernet frames        │    │
       │  ├─────────────────────────────────────────┤    │
       │  │ Network Layer: signal shaping,          │    │
       │  ├─────────────────────────────────────────┤    │
       │  │ amplification, regeneration,            │    │
       │  ├─────────────────────────────────────────┤    │
       │  │ retransmission (repeaters/optical       │    │
       │  ├─────────────────────────────────────────┤    │
       │  │ amplifiers, unidirectional forwarding)  │    │
       │  ├─────────────────────────────────────────┤    │
       │  │ Data Link Layer: digital ↔ physical     │    │
       │  ├─────────────────────────────────────────┤    │
       │  │ signal mapping (NRZ/PAM4/QAM/           │    │
       │  ├─────────────────────────────────────────┤    │
       │  │ Manchester encoding)                    │    │
       │  ├─────────────────────────────────────────┤    │
       │  │ Bearer Layer: Medium Layer              │    │
       │  ├─────────────────────────────────────────┤    │
       │  │ (as 1-hop link)                         │    │
       │  └─────────────────────────────────────────┘    │
       └─────────────────────┬───────────────────────────┘
                             │ Coding/Modulation's
                             │ Bearer Layer points
                             │ to Medium Layer
                             ↓
       ┌─────────────────────────────────────────────────┐
       │  Medium Layer (recursive termination)           │
       │  Physical Medium (fiber, copper, radio waves)   │
       │  (Bearer Layer is null, but Data Link Layer     │
       │   and Network Layer exist)                      │
       │  Data Link Layer: the medium itself             │
       │  Network Layer: fiber splicing, mechanical      │
       │  splicing, ODF management                       │
       └─────────────────────────────────────────────────┘
Figure 1: Recursive Nesting of Four-Layer Structures

Every layer does the same thing: it nests its own four-layer structure above its Bearer Layer, while simultaneously providing Bearer Layer service to its upper layer. This is what "recursive peer" means—every protocol is a complete four-layer system, and they are peers to each other, differing only in their nesting depth.

The only differences are at the two boundaries:

  • Data Layer (topmost): no Transport Layer, no further expansion;

  • Medium Layer (bottommost): no Bearer Layer, but still has Data Link Layer and Network Layer.

3.6. Two Key Distinctions from OSI

Distinction 1: Unlike OSI's "absolute numbering"

In OSI, the "Transport Layer" is Layer 4 and the "Data Link Layer" is Layer 2—fixed numbers.

In the Recursive Peer Model, "Transport Layer" and "Data Link Layer" are relative functions carried by each protocol itself:

  • Ethernet's Transport Layer is IP/ARP;

  • IP's Transport Layer is TCP [RFC9293]/UDP [RFC768];

  • TCP's Transport Layer is HTTP;

  • HTTP's Transport Layer is the Data Layer.

"Transport Layer" is not a fixed layer number, but rather the perspective of each protocol looking upward.

Distinction 2: Every protocol has its own Network Layer (may be null)

In OSI, only Layer 3 (IP) is called the Network Layer.

In the Recursive Peer Model, every protocol can have a Network Layer:

  • Ethernet's Network Layer: bridge flooding forwarding;

  • IP's Network Layer: router forwarding;

  • Coding/Modulation Layer's Network Layer: signal shaping, amplification, regeneration, retransmission;

  • Medium Layer's Network Layer: fiber splicing, mechanical splicing, ODF management;

  • TCP's Network Layer: null (does not forward).

"Network Layer" is not a fixed layer number, but rather a functional label indicating whether the protocol itself provides cross-node forwarding.

4. Re-examining Classic Protocols with the Recursive Peer Model

4.1. VPN (IP-in-IP): Recursive Nesting of Two IP Layers

VPN is classified as a "tunnel exception" within the OSI framework and has no legitimate layer number.

In the Recursive Peer Model, VPN is structured as the recursive nesting of two IP [RFC791] protocol four-layer structures:

  • Outer IP: its Bearer Layer is the physical network, Data Link Layer is standard IP processing, Network Layer is public network routing, Transport Layer is the inner IP packet (as pure data).

  • Inner IP: its Bearer Layer is the outer IP (treated as a 1-hop link), Data Link Layer is standard IP processing, Network Layer is private network routing, Transport Layer is the upper-layer application data.

The two IP layers each perform their own functions, nesting perfectly within the same four-layer framework. No "exception" clause is required.

4.4. Ethernet: Possessing a Simple Network Layer

In OSI, Ethernet [IEEE802.3] is fixed at the Data Link Layer (Layer 2). However, in the Recursive Peer Model, the Ethernet/MAC protocol itself has a complete four-layer structure:

  • Bearer Layer: Coding/Modulation Layer;

  • Data Link Layer: CRC checksum, collision detection/avoidance, MAC addressing;

  • Network Layer: bridge flooding forwarding (though simple, it is indeed forwarding across collision domains);

  • Transport Layer: IP packets, ARP frames, etc.

This observation reveals a fundamental problem with the OSI model: the assertion that "Ethernet has only a Data Link Layer" is incorrect. Ethernet has its own Network Layer (bridges), only its forwarding algorithm is simpler than IP routing.

4.5. Coding/Modulation Layer: A Minimal Network Layer

In the Recursive Peer Model, the Coding/Modulation Layer also has a complete four-layer structure:

  • Bearer Layer: Medium Layer;

  • Data Link Layer: digital-to-physical signal mapping (PAM4/NRZ/QAM, etc.);

  • Network Layer: signal shaping, amplification, regeneration, retransmission (repeaters, optical amplifiers);

  • Transport Layer: Ethernet frames.

The Coding/Modulation Layer's Network Layer is extremely simple—signal forwarding between physical medium segments is unidirectional and semi-permanent, driven by hardware (repeaters, optical amplifiers) rather than routing protocols. However, it is still "forwarding data between non-directly-connected nodes," and thus satisfies the definition of a Network Layer.

4.6. Medium Layer: Medium Continuation as Network Layer

The Medium Layer has no independent position in the traditional OSI model. However, in the Recursive Peer Model, the Medium Layer also has a four-layer structure:

  • Bearer Layer: null (recursive termination);

  • Data Link Layer: the physical medium itself (copper cable, optical fiber, radio waves);

  • Network Layer: fiber splicing, mechanical splicing, optical distribution frame management—the continuation and interconnection of signals between physical medium segments;

  • Transport Layer: the Coding/Modulation Layer (carrying modulated signals).

The Medium Layer's Network Layer is equally simple, working in coordination with the Coding/Modulation Layer's Network Layer: the Coding/Modulation Layer handles signal shaping, amplification, and regeneration, while the Medium Layer handles splicing and continuation between medium segments. Together they complete the end-to-end transmission of physical signals.

5. Comparison with the OSI Seven-Layer Model

This section compares the Recursive Peer Model with the OSI seven-layer reference model [ISO_IEC.7498-1.1994].

5.1. Core Differences

Table 2
Dimension OSI Seven-Layer Model Recursive Peer Model
Structure Fixed 7-layer linear stack Each intermediate layer has its own 4 layers, recursively nested; Data/Medium Layers as boundaries
Definition of "Transport Layer" Fixed name of Layer 4 Each protocol's upper layer is its Transport Layer
Definition of "Data Link Layer" Fixed name of Layer 2 Each protocol's lower layer is its Bearer Layer; the protocol's own encapsulation/multiplexing/error correction is its Data Link Layer
Definition of "Network Layer" Fixed name of Layer 3 Whether the protocol itself provides cross-node forwarding (may be null)
Protocol Classification Each protocol belongs to a fixed layer Each protocol itself contains four layers
Positioning of VPN "Tunnel exception" (outside the model) Recursive nesting of two IP layers (inside the model)
Positioning of ARP Inconsistent (L2 or L3) Mapping function between IP Data Link Layer and Bearer Layer
Positioning of Ethernet Layer 2 Protocol with complete four-layer structure (Bearer=Coding/Modulation, Network=bridge)
Positioning of Physical Layer Layer 1 (single layer) Split into Coding/Modulation Layer and Medium Layer, each with complete four-layer structure
Positioning of Medium Layer None Recursive termination (Bearer Layer null, but Data Link Layer and Network Layer exist)

5.2. Structural Deficiencies of the OSI Model

The Recursive Peer Model reveals three fundamental structural deficiencies of the OSI seven-layer model:

Deficiency 1: Binding layer numbers to functions. OSI prescribes a fixed number of layers, forcing every protocol to be assigned a fixed layer number. VPNs, which exist in practice, cannot be assigned a legitimate layer number.

Deficiency 2: Absolute treatment of "Transport Layer," "Network Layer," and "Data Link Layer." In OSI, these are three different layer numbers. But in real protocol stacks, every protocol simultaneously has all three perspectives. These three names should not be layer numbers, but rather functional labels carried by each protocol itself.

Deficiency 3: Ignoring the complete four-layer structure of each protocol. OSI simplifies TCP to a "Transport Layer protocol," forgetting that TCP itself has a Transport Layer (carrying application data) and a Bearer Layer (depending on IP). Ethernet is simplified to a "Data Link Layer protocol," forgetting that Ethernet itself has a Network Layer (bridge forwarding).

5.3. Advantages of the Recursive Peer Model

  1. Generality: Does not prescribe a fixed number of layers; can describe any existing or future communication protocol through recursive nesting.

  2. Self-consistency: Requires no "exception" clauses; VPNs, IP-in-IP, and other modern networking technologies naturally fall within the framework.

  3. Completeness: The four-layer structure of each protocol is fully described, rather than simplified to "belongs to layer X."

  4. Recursiveness: The same four-layer structure applies uniformly across all protocol layers, eliminating the need to learn multiple classification logics.

  5. Extensibility: New protocols can be precisely positioned in the model simply by describing their own four-layer structure (who is the Bearer Layer, what the Data Link Layer does, whether the Network Layer forwards, who is the Transport Layer).

6. Implications for Network Education

Learning computer networking is much the same. The OSI seven-layer model uses the metaphor of a "seven-story building" to make it easy for beginners to understand. But the cost is that this building is rigid, exceptional, and requires constant patching. Beginners find "seven layers" intuitive at first, but when they encounter VPNs, NAT, and tunneling technologies, they discover that this building is full of "unplanned extensions" that require numerous "exception clauses" to explain.

The Recursive Peer Model takes the opposite pedagogical approach:

One model, one set of rules, describes all protocols. That is the power of recursion.

Based on this understanding, the Recursive Peer Model suggests that network education should:

  1. Teach the four-layer structure of each protocol first, then inter-protocol dependencies: help students understand that each protocol is a complete four-layer system, rather than "this protocol belongs to layer X."

  2. Use "recursion" instead of "stacking": teach students the recursive perspective that "every protocol has a Bearer Layer, Data Link Layer, Network Layer, and Transport Layer," rather than viewing the protocol stack as a seven-story building.

  3. Introduce the "Network Layer can be null" concept: help students understand that TCP and UDP have null Network Layers, thus naturally understanding why they do not forward data.

  4. Each protocol is complete: help students understand that "TCP has its own Transport Layer (carrying applications) and its own Bearer Layer (depending on IP)"—a protocol's functionality is far richer than the label "belongs to Layer 4."

7. Security Considerations

This document discusses a descriptive model of network protocol architecture and does not directly involve any new security protocols or security mechanisms. However, the model itself may have implications for network security analysis:

8. Acknowledgments

The author thanks the many peers who provided discussion and feedback during the conception of the recursive model. Special thanks to all network engineers and researchers who resonate with the observation that "the OSI model can no longer fully describe modern networks."

9. References

9.1. Normative References

[ISO_IEC.7498-1.1994]
ISO/IEC, "Information technology — Open Systems Interconnection — Basic Reference Model: The Basic Model", ISO/IEC 7498-1:1994, .
[RFC1122]
Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, , <https://www.rfc-editor.org/rfc/rfc1122>.

9.2. Informative References

[IEEE802.3]
IEEE, "IEEE Standard for Ethernet", IEEE 802.3-2022, , <https://standards.ieee.org/ieee/802.3/10422/>.
[RFC768]
Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC768, , <https://www.rfc-editor.org/rfc/rfc768>.
[RFC791]
Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC791, , <https://www.rfc-editor.org/rfc/rfc791>.
[RFC792]
Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC792, , <https://www.rfc-editor.org/rfc/rfc792>.
[RFC826]
Plummer, D., "An Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", STD 37, RFC 826, DOI 10.17487/RFC826, , <https://www.rfc-editor.org/rfc/rfc826>.
[RFC9110]
Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, , <https://www.rfc-editor.org/rfc/rfc9110>.
[RFC9293]
Eddy, W., Ed., "Transmission Control Protocol (TCP)", STD 7, RFC 9293, DOI 10.17487/RFC9293, , <https://www.rfc-editor.org/rfc/rfc9293>.

Author's Address

Shi Li
Independent