A DecNet a Digital (Digital Equipment Corporation) jól átgondolt fejlesztése, melynek elsô verziója 1975-ben látott napvilágot és két PDP-11 miniszámítógépet kapcsolt össze. Bár a Digital számos erôfeszítést tett, hogy nyílt szabványokat integráljon bele és így mások is alkalmazzák, mind a mai napig az ô nevéhez fûzôdik. Jelenlegi, ötödik verziója, a Phase V vagy DecNet/OSI, ahogy a Digital irodalmában hívják, magában foglalja az összes idevágó OSI protokollt és a korábbi DecNet protokollokat: kompatibilis a DecNet Phase IV-gyel. A DecNet címzési rendszere két részbôl áll. Egy 6 bites területbôl és egy 10 bites állomásszámból. Így 64 terület mindegyikén 1023 állomás lehetséges, a két részt decimális alakban, ponttal elválasztva szokták feltüntetni (például 10.200). A DecNet az OSI IS-IS routing protokollját használja az OSI hálózati protokollok route-olásához, a Phase IV hálózati protokoll pedig a Phase IV routing protokoll szerint route-olódik, ami nagyon hasonló az IS-IS-hez. A DecNet fölött futó 4. rétegbeli protokollok egyrészt az OSI TP0, TP2 és TP4 protokolljai, másrészt a Phase IV-bôl örökölt NSP (Network Services Protocol), ami nagyjából a TP4-nek felel meg, összeköttetés-orientált, forgalomszabályozott szolgáltatást nyújtva. A TP4-hez hasonlóan ez is képes a fragmentációra, reagál a hálózati réteg által jelzett torlódásokra és támogatja a sürgôs adatcsomagok feladását.
Az AppleTalk-ot a Machintos számítógépekkel együtt fejlesztette ki az Apple az 1980-as évek elején, hogy újszerû felhasználói felületébe könnyen integrálható hálózatot szállíthasson. Elsô verziója a Phase 1 helyi munkacsoportok számára készült, de az 5 év alatt leszállított 1.5 millió Machintos arra ösztönözte a céget, hogy bôvítse korlátokban igencsak bôvelkedô protokollját. Ennek eredménye a Phase 2, amely nagyobb hálózatokban is jól mûködik. Az AppleTalk számos 2. réteg fölött fut, ezeket rendre az EtherTalk (Ethernet), FDDITalk, TokenTalk (Token Ring), stb. nevekkel illeti az Apple irodalma. A LocalTalk egy Apple fejlesztés, nagyjából egy soros interface (a fizikai interface az RS-442), busz topológiával, melyen 230.4 kbit/s sebességgel mozoghatnak adatok és 300 méteres szegmensen 32 állomást támogat.
Az AppleTalk címek egy 16 bites hálózati címbôl és egy 8 bites állomásszámból állnak, az állomások üzembehelyezésükkor számot választanak maguknak és leellenôrzik, nem használja-e más az adott címet. Ha igen, másikat választanak. Az AppleTalk alapvetôen két routing protokollt használ, az egyik a RTMP (Routing Table Maintenance Protocol), mely a RIP-hez hasonló, a másik az AURP (AppleTalk Update based Routnig Protocol), amely több AppleTalk hálózatot képes WAN kapcsolatokon keresztül összekapcsolni, tulajdonképp ez az AppleTalk EGP-je.
A Xerox Network Systems (XNS) az 1970-es évek végén jelent meg a Xerox fejlesztéseként. Számos más protokoll épül rá elsôsorban az IPX, mely szinte teljesen megfelel az XNS hálózati protokolljának, az IDP-nek (Internet Datagram Protocol). A RIP eredetileg szintén az XNS része, ez az elnevezés itt jelent meg elôször. A 4. rétegbeli SPP (Sequenced Packet Protocol) funkciójában megegyezik a TCP és az SPX szolgáltatásaival. A PC világ megjelenésével az XNS-bôl származtatott protokollok sokkal népszerûbbek lettek, mint az XNS maga.
A Banyan VINES (Virtual Integrated Network Services), a Banyan cég hálózati megoldása; ez is az XNS-bôl származik. Kliens-szerver modellre épül, ahol a munkaállomások használják fel a szerverek szolgáltatásait (nyomtatás, file-server, stb.) Hálózati protokollja, a VINES Internetwork Protocol (VIP), 48 bites címeket használ, ebbôl 32 bit a hálózati cím, mely igazából egy serverhez kötôdik és 16 bit pedig az állomás száma. A VIP az AppleTalk-hoz hasonló dinamikus címkiosztást használ, de itt a serverek jelenléte megkönnyíti a folyamatot. Routing protokollja szintén egy módosított RIP, ezúttal RTP (Routing Table Protocol) néven. Itt is létezik az ARP és van egy az ICMP-hez hasonló protokoll, az ICP (Internet Control Protocol), mely a hibák jelzésén kívül link-ek költségének terjesztésére is szolgál.
A OSI hálózati protokollok hûen tükrözik az OSI-t, mint szervezetet. Valóban nyílt és moduláris szabványok elôállítása a cél, ezek el is készülnek, de cserébe a bürokráciával fizetnek. Példának okáért egy réteg által nyújtott szolgáltatásokat szigorúan elkülönítve kezelik az ezen szolgáltatások megvalósítására felhasznált protokolloktól, ami rétegenként két specifikációt eredményez. Dupla papír, bár sokkal tisztább, mintha e két dolgot összekevernénk. Sajátos terminológiát használnak, a széles körben elterjedt angol node vagy host (állomás) kifejezések helyett csakis az end-system (végberendezés), router helyett az intermedtiate system (közbeesô állomás), csomag, keret, üzenet helyett pedig a hálózati-, adatkapcsolati- vagy alkalmazói szintû protokoll adategység elnevezések használatosak. A routing (route-olás) helyett pedig konzekvensen routeing-et írnak. Az OSI szabványok nem számítanak könnyed esti olvasmánynak.
Az OSI hálózati protokollok mind kapcsolatorientált, mind datagram szolgáltatásokat biztosítanak. Az elôbbit a CMNP (Connection Mode Network Protocol), az utóbbit CLNP (Connectionless Network Protocol) segítségével valósítják meg. A CMNP megegyezik az X.25 3. rétegbeli protokolljával, a CLNP pedig nagyon hasonlít az IP-re.
Az OSI címek nem egy állomást, hanem egy a transzport és a hálózati réteg közötti pontot (Network Service Access Point, NSAP) azonosítanak, ahol a hálózati szolgáltatás elérhetô. A pongyolán csupán NSAP címeknek hívott formátum hierarchikus. Az 1 byte hosszú AFI (Address Format Identifier) határozza meg a cím további formátumát. Az IDI (Initial Domain Identifier) hossza és jelentése az AFI-tôl függ. A DSP (Domain Specific Part) számjegyekbôl vagy byte-okból áll (a CLNP esetén byte-okból) és magát az állomást azonosítja. A route-olás szempontjai miatt a címet a CLNP esetében pontosabban is felosztották. A Routing domain határozza meg a szervezetet, melyet belül területekre oszthatunk, az állomásokat a területen belül a system-id azonosítja. Az utolsó 8 bit határozza meg, hogy az állomáson belül melyik transzport entitást címeztük meg, gyakorlati szemszögbôl nézve az IP protokoll azonosítójának felel meg.