Network Layer¶

The transport-facing service level that identifies destinations and directs data across underlying links or subnetworks in a layered communication architecture.

Version: v1 · 2026-10-07 · History
Domain-specific #: 13959
Domain group: Applied Sciences & Engineering
Origin domain: Computer Science & Software Engineering
Subdomain: Computer Networking → Computer Science & Software Engineering

Core Idea¶

The Network Layer in the OSI Basic Reference Model is the service level between Transport and Data Link that provides data transfer between transport entities, chooses routes and relays as needed, and masks lower network differences from its users. ITU-T X.200 permits connection and connectionless modes: an IP-like connectionless datagram profile is one realization, not the definition of every network service.^[1]

The Internet architecture has a partly analogous Internet Layer. RFC 791 describes IP carrying addressed datagrams from source to destination hosts through local-network interfaces and gateways; RFC 1812 places that Internet Layer below Transport and above Link. Comparing this role with X.200 is a cross-source functional inference, not an RFC statement that the two layers are exactly equivalent. In older Internet usage, “Network Layer” could instead mean the Link Layer, a terminological near miss that RFC 1812 explicitly warns about.^[2]^[3]^[1]

Structural Signature¶

Declared layered architecture. Identify the upper transport service and lower link or subnetwork facilities. Without their service ordering, a router or address field is not itself a named layer.^[1]^[3]
Transport-facing transfer obligation. Accept data or service requests from an upper transport user and provide destination-directed delivery at the network service level. OSI states this as transfer between transport entities; IP receives data from host-to-host protocols.^[1]^[2]
Network destination identification. Use a destination address or endpoint identifier for delivery beyond an immediate link. A hierarchical address syntax is not a universal test of the layer.^[1]^[2]
Routing and relay capability. Choose or apply paths and relay through intermediate facilities when needed. A direct local path need not include an actual intermediate relay; route and relay are service functions, not proof that no other level can perform route-like decisions.^[1]^[2]
Lower-carriage dependency and abstraction. Use data-link or subnetwork facilities to carry data while presenting an upper service that need not expose every lower-path detail.^[1]^[2]

Record connection mode and quality guarantees per architecture. X.200 specifies error notification and optionally receipt confirmation; IP is specifically connectionless and does not promise end-to-end reliability or acknowledgments. Neither profile alone defines the cross-architecture role.^[1]^[2]

What It Is Not¶

A Link Layer transfers across a directly attached network interface; the mapped Network Layer/Internet Layer function addresses destination-directed delivery through a higher architectural service. RFC 1812 notes that older Internet documents sometimes called the Link Layer “Network Layer,” which is not the OSI usage.^[3] A Protocol Stack is an arrangement of several protocol levels; this entry identifies one service level. A router is an implementing device, and Routing is one function within the level, not the entire transport-facing boundary.

Packet Switching names a particular carriage or switching method, not this architectural service role. Connection-mode network service can itself use packet switching, so connection mode is not a shortcut for separating them. X.200 defines functions across underlying network and data-link facilities rather than requiring shared-link packet switching in every instance.^[1]

Scope of Application¶

The exact name and full formal service scope are supplied by OSI X.200. Its Network Layer can provide connection and connectionless transfer between transport entities, use routes and relays, map network and data-link addresses, and employ one or more subnetworks. The source is a reference model, not evidence that every described feature was deployed together.^[1]

The Internet case is the IPv4 Internet Layer described in RFC 791 and situated by RFC 1812. IP carries addressed datagrams and uses local-network protocols to reach a next gateway or destination host. Its connectionless, best-effort profile is a property of IP, not a rule imported into all Network Layers. This case is an analogue in service placement and destination/path role; it is not assigned exact OSI numbering or identical guarantees.^[2]^[3]^[1]

Clarity¶

First name the architecture, then ask five questions: who uses the service above, what destination is named, how can a path be chosen or relayed, which lower facilities carry the data, and what details are hidden at the boundary? If the answer names only an Ethernet or other directly attached link, it has not established the transport-facing network service. If it names a whole stack or one router algorithm, it has described an implementation or function rather than the layer.^[1]^[2]^[3]

State the service profile separately. X.200's connection-mode possibility makes “always connectionless” false. RFC 791's no-acknowledgment and no end-to-end reliability statements are IP-specific. A route can be direct, so “must pass through several routers” is also too strong.^[1]^[2]

Manages Complexity¶

The layer boundary lets a transport user request destination-directed transfer without spelling out every data-link segment or subnetwork. X.200 makes this hiding of lower differences part of its network-service presentation; RFC 791 exposes a corresponding division between host-to-host protocols, IP and local-network interfaces.^[1]^[2]

This simplification does not erase operational differences. The OSI model can offer different modes and quality functions, whereas IPv4 supplies its particular datagram service. Treating their common placement as exact equivalence would conceal the difference the architecture must still declare.^[1]^[2]^[3]

Abstract Reasoning¶

Consider an architecture with transport users above local link carriage. If a level accepts their data, identifies a nonlocal destination, and can select or apply a route using lower facilities, it meets the mapped network-service role. Remove the upper/lower boundary and the same destination field might remain in a packet, but it no longer constitutes a layer. Remove path/destination control and only a local link service remains.^[1]^[2]

Now vary the mode. In X.200, a connection-mode service remains within the Network Layer. In IPv4, the service is connectionless. Thus connectionlessness cannot be an all-instance identity test. Vary the path instead: an intermediate gateway may relay a datagram, while a directly attached destination can be reached without such an intermediate relay. The capability and service obligation are stable even when one route has no intermediate hop.^[1]^[2]

Knowledge Transfer¶

Transfer the service-role questions between OSI and Internet descriptions, then retain each architecture's vocabulary and guarantees. OSI's formally named Network Layer and Internet IP's Internet Layer have comparable transport-facing destination/path roles, but the comparison is our reasoned reading of X.200, RFC 791 and RFC 1812. RFC 1812 itself cautions that another use of “Network Layer” meant Link Layer.^[1]^[2]^[3]

The broader structural contribution is Layering: an upper service depends on a lower service while hiding some lower detail. The network-addressed, route-capable transport service remains a networking-specific implementation of that broad relation. Calling any tiered organization a Network Layer without the communication-service roles would be metaphor, not recognition.

Examples¶

Canonical: OSI Basic Reference Model¶

X.200 names a Network Layer between Transport and Data Link. Transport entities use a network service for transparent transfer; network entities can select routes, relay through intermediate systems and map network to data-link addresses. The standard admits both connection and connectionless modes, specifies error notification, and makes receipt confirmation optional. It describes architectural functions rather than a particular deployed packet network.^[1]

Mapped back: architecture = OSI service ordering; upper user = transport entities; destination = network-service address; path role = routing and relay when needed; lower facilities = data-link connections and subnetworks; profile = mode and quality functions declared for this model.

Applied: IPv4 Internet Layer¶

RFC 791 gives IP a source and destination address and a datagram delivery role across interconnected networks. Host-to-host protocols pass data and parameters to IP; IP uses a local-network interface to reach the next gateway or final destination. RFC 1812 locates the Internet Layer between Transport and Link. IP is connectionless and supplies no end-to-end reliability guarantee in RFC 791's profile.^[2]^[3]

Mapped back: architecture = Internet Transport/Internet/Link ordering; upper user = host-to-host protocols; destination = IP destination address; path role = path choice and gateway forwarding as needed; lower facilities = local-network interface; profile = IPv4 datagram service. The mapping is functional, not a claim of exact OSI service equivalence.

Structural Tensions¶

The cited standards do not establish one intrinsic opposed-pressure tension required by every network-service layer. Connection versus connectionless is a variant service mode, not a universal trade-off. Hiding lower-network differences while exposing service quality is a design boundary, but the cited text does not impose one fixed optimization balance across OSI and IP. The practical diagnostic is to state the actual architecture, mode and guarantee before drawing a conclusion about performance or reliability.^[1]^[2]

Structural–Framed Character¶

This entry is architecturally structural and institutionally framed. Its evaluative weight is low: throughput, reliability and ease of implementation are design outcomes, not membership criteria. Human practice and standards institutions define the service boundaries and names in OSI and Internet documentation; implementations realize the transfer functions. That institutional origin matters to the comparison, because two standards vocabularies cannot be treated as identical by a shared English label.^[1]^[3]

The language of upper/lower service dependence travels widely through the live Layering Prime. Destination addressing, routing/relay and transport/link boundaries travel only in networking settings. Recognize a case through those service roles in its own architecture before importing an OSI or Internet label. Its character: a domain-specific communication-service level with a portable layering relation and architecture-specific names, modes and guarantees.

Structural Core vs. Domain Accent¶

The actual broad Prime skeleton is Layering: ordered service levels, an upper user, a lower provider, and an abstraction boundary. The network-specific residual is a transport-facing destination/path-delivery service using link or subnetwork facilities. That residual is why the named Network Layer remains domain-specific, even though the parent layering pattern has wider reach.^[1]^[2]

The accents are OSI's formal Network Layer name and service-mode options, IPv4's datagram format and best-effort limits, and each architecture's address and interface vocabulary. Remove those and one still has a service-layer dependency; remove network destination and route capability and one no longer has this networking child. A generic “middle layer” resemblance belongs to the existing Layering Prime, not a new Prime inferred from the Network Layer name.

This entry presupposes Layering.

The sole asserted strict edge is Network Layer → Layering, typed composition/presupposes. Every admitted case needs an upper transport user and lower link/subnetwork provider arranged as services; Layering can exist without any network protocol. The edge records a necessary architectural relationship, not taxonomic identity between a communication layer and a general organizing principle.

Protocol Stack concerns an implemented ordering of several levels. Packet Switching is a carriage method and may coexist with either connection mode. Routing is a function exercised within this service role, not a parent that subsumes the whole boundary. A second direct edge based only on topical overlap is not asserted.^[1]

Relationships to Other Abstractions¶

Current abstraction Network Layer Domain-specific

Parents (1) — more general patterns this builds on

Network Layer presupposes Layering Prime

A network service layer presupposes a layered architecture with upper transport and lower link or subnetwork service boundaries.

Hierarchy path (1) — routes to 1 parentless root

Network Layer → Layering

Neighborhood in Abstraction Space¶

Network Layer sits in a sparse region of the domain-specific corpus (91^st percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.

Family — Network Architecture & Transport Protocols (25 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-10-08

Not to Be Confused With¶

The Link Layer: RFC 1812 notes an older Internet use of “Network Layer” for Link; this is a terminology difference, not the OSI service.^[3]
A router or routing algorithm: implements one path function, not the full transport-facing service level.
A protocol stack: combines several levels, whereas this entry identifies one.
Packet switching: may support a network service but is a different method/role; connection-mode service may still be packet-switched.^[1]
An always connectionless or unacknowledged service: properties of IPv4 here cannot define X.200's full Network Layer.^[1]^[2]

References¶

[1] ITU-T, Recommendation X.200, Information technology, Open Systems Interconnection, Basic Reference Model, the Basic Model, 1994, §7.5, printed pp.41–44 (official PDF pp.44–47). Full official standard inspected. The published title uses punctuation between the title components; comma transcription here keeps the complete linked title legible to the reference binder. §§7.5.2–7.5.4 define the transport-facing network service, connection and connectionless modes, routing/relay, lower-facility use, error notification and optional receipt confirmation. This is a conceptual reference model, not a deployment report. registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h ↩i ↩j ↩k ↩l ↩m ↩n ↩o ↩p ↩q ↩r ↩s ↩t ↩u ↩v ↩w ↩x ↩y

[2] Jon Postel, Internet Protocol, RFC 791 (1981), §§1.1–1.4 and §2.4, printed pp.1–3, 9. Full RFC Editor specification inspected. Defines IP datagram transfer, addresses, path/gateway roles, upper and lower interfaces, and IP-specific connectionless/no-end-to-end-reliability limits. registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h ↩i ↩j ↩k ↩l ↩m ↩n ↩o ↩p ↩q ↩r

[3] F. Baker, Requirements for IP Version 4 Routers, RFC 1812 (1995), §2.2.1, printed pp.17–18. Baker is credited as editor of this RFC. Full RFC Editor specification inspected. Places Internet Layer between Transport and Link and records the older Internet usage of “Network Layer” for Link Layer. The OSI/Internet Network role analogy in this entry is a cross-source inference, not a direct claim by this RFC. registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h ↩i ↩j