Hubbry Logo
Connectionless-mode Network ServiceConnectionless-mode Network ServiceMain
Open search
Connectionless-mode Network Service
Community hub
Connectionless-mode Network Service
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Connectionless-mode Network Service
Connectionless-mode Network Service
Connectionless-mode Network Service
View on Wikipedia
from Wikipedia
OSI model
by layer
7.  Application layer
6.  Presentation layer
5.  Session layer
4.  Transport layer
3.  Network layer
2.  Data link layer
1.  Physical layer

Connectionless-mode Network Service (CLNS) or simply Connectionless Network Service is an OSI network layer datagram service that does not require a circuit to be established before data is transmitted, and routes messages to their destinations independently of any other messages.[2][3] As such it is a "best-effort" rather than a "reliable" delivery service. CLNS is not an Internet service, but provides capabilities in an OSI network environment similar to those provided by the Internet protocol suite. The service is specified in ISO/IEC 8348,[4] the OSI Network Service Definition (which also defines the connection-oriented service, CONS.)

Connectionless-mode Network Protocol

[edit]

Connectionless-mode Network Protocol (CLNP) is an OSI protocol deployment. CLNS is the service provided by the Connectionless-mode Network Protocol (CLNP). From August 1990 to April 1995 the NSFNET backbone supported CLNP in addition to TCP/IP.[5] However, CLNP usage remained low compared to TCP/IP.

Transport Protocol Class 4 (TP4) in conjunction with CLNS

[edit]

CLNS is used by ISO Transport Protocol Class 4 (TP4), one of the five transport layer protocols in the OSI suite. TP4 offers error recovery, performs segmentation and reassembly, and supplies multiplexing and demultiplexing of data streams over a single virtual circuit. TP4 sequences PDUs and retransmits them or re-initiates the connection if an excessive number are unacknowledged. TP4 provides reliable transport service and functions with either connection-oriented or connectionless network service. TP4 is the most commonly used of all the OSI transport protocols and is similar to the Transmission Control Protocol (TCP) in the Internet protocol suite.

Protocols providing CLNS

[edit]

Several protocols provide the CLNS service:[3]

  • Connectionless-mode Network Protocol (CLNP), as specified in ITU-T Recommendation X.233.[6]
  • End System-to-Intermediate System (ES-IS), a routing exchange protocol for use in conjunction with the protocol for providing the CLNS (ISO 9542).
  • Intermediate System-to-Intermediate System (IS-IS), an intradomain routing exchange protocol used in both the OSI and Internet environments (ISO/IEC 10589 and RFC 1142).
  • Interdomain Routing Protocol (IDRP),[7] the OSI equivalent of BGP.
  • Signalling Connection Control Part (SCCP), as specified in ITU-T Recommendation Q.711[8] is a Signaling System 7 protocol.

See also

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Connectionless-mode Network Service

View on Grokipedia
from Grokipedia
Connectionless-mode Network Service (CLNS) is a datagram-oriented communication service provided by the , allowing the independent transfer of units between open systems without the need to establish, maintain, or release a connection. This service, also known as the connectionless-mode service, operates on a best-effort basis, where each unit is routed separately and delivery is not guaranteed, making it suitable for applications requiring efficiency and low overhead over diverse subnetworks. Defined in the OSI Reference Model's Layer 3, CLNS enables end-to-end communication across heterogeneous networks by encapsulating user into Network Service Data Units (NSDUs), with a maximum size of 64,512 octets. The core mechanism of CLNS revolves around a single service primitive, N-UNITDATA, which supports both request and indication operations for sending and receiving . The N-UNITDATA.request primitive, invoked by the or higher, includes parameters such as calling NSAP address (source), called NSAP address (destination), (QoS) specifying aspects like throughput and transit delay, and the user itself. Correspondingly, the N-UNITDATA.indication primitive delivers the to the receiving entity with the same parameters, ensuring that addressing and service quality indications are preserved across the network. Unlike connection-oriented services, CLNS does not provide sequencing, flow control, or error recovery, though optional QoS parameters can request expedited delivery or low transit delay where supported by the underlying protocol. CLNS is formally specified in ITU-T Recommendation X.213 (equivalent to ISO/IEC 8348), which outlines its abstract interface, while the implementing protocol, Connectionless Network Protocol (CLNP), is detailed in ISO/IEC 8473-1. This protocol uses Data (DT) Protocol Data Units (PDUs) for information transfer and optional Error (ER) PDUs for reporting issues like invalid addresses or unsupported options, facilitating via the Subnetwork Independent Convergence Protocol (SNICP). Although not widely adopted in modern TCP/IP networks, CLNS influenced routing protocols like and remains relevant in legacy OSI environments and certain specialized systems requiring OSI compatibility.

Definition and Characteristics

Core Definition

Connectionless-mode Network Service (CLNS) is a datagram-oriented service provided at the network layer (OSI layer 3) of the Open Systems Interconnection (OSI) , enabling the independent transmission of data units from a source Network Service Access Point (NSAP) to one or more destination NSAPs without establishing, maintaining, or tearing down a connection. This service treats each data unit, known as a Network Service Data Unit (NSDU), as a self-contained entity, with no inherent requirement for sequencing, flow control, or error recovery across multiple transmissions. The CLNS employs two primary service primitives to facilitate datagram exchange between network entities. The N-UNITDATA-REQUEST primitive allows an invoking network service user to request the transmission of an NSDU, specifying parameters such as source and destination addresses, quality of service, and the data itself. Correspondingly, the N-UNITDATA-INDICATION primitive notifies the receiving network service user of an incoming NSDU, delivering the associated parameters including the source address and any expedited data indicators. These primitives support unconfirmed, one-way communication without acknowledgments or retries. Unlike transport-layer services that provide end-to-end reliability across the full communication path, CLNS operates strictly at the network layer to achieve from source to destination NSAP, offering no guarantees of arrival, order preservation, or duplication prevention. This focus ensures efficient, lightweight in diverse network topologies while delegating higher-level assurances to overlying layers if needed.

Key Operational Features

The Connectionless-mode (CLNS) operates on a stateless basis, delivering s independently without establishing or maintaining any connection context between transmissions. Each Network Service Data Unit (NSDU) is routed autonomously from the source Network Service Access Point (NSAP) to the destination NSAP, with no sequence numbering or flow control mechanisms enforced at the network layer to ensure ordering or regulate transmission rates. This design enables efficient, low-overhead packet handling, as multiple invocations of the service bear no logical relationship to one another. The implementing protocol for CLNS, such as CLNP, may provide optional per-PDU header checksums for basic header integrity verification, but the service itself offers no provisions for retransmission, end-to-end acknowledgments, or guaranteed delivery. The service does not enforce packet ordering or recovery from losses, placing responsibility for such functions, if required, on higher-layer protocols. This limited error handling contributes to the service's simplicity and speed but relies on underlying parameters to mitigate potential issues like discard. Addressing in CLNS utilizes NSAPs to uniquely identify source and destination points, supporting both individual and group addressing schemes for flexible to single endpoints or groups. NSAPs consist of structured fields that facilitate global interoperability, with the service primitives such as N-UNIT-DATA request and indication handling the one-way transfer of user data between these access points. The implementing protocol for CLNS, such as CLNP, supports fragmentation at source and intermediate nodes and reassembly at the destination for oversized NSDUs when the size exceeds the maximum allowable for transmission over a subnetwork, though this capability is not universally guaranteed across all implementations or paths. Incomplete fragments may be discarded without notification, underscoring the service's best-effort nature.

Historical Development and Standards

Origins in the OSI Model

The development of Connectionless-mode Network Service (CLNS) emerged in the late 1970s and early 1980s within the International Organization for Standardization's (ISO) efforts to establish the Open Systems Interconnection (OSI) reference model, aiming to create a vendor-neutral framework for network communication that offered a connectionless alternative to the predominant connection-oriented designs of the era. This initiative responded to the growing need for interoperable networking amid proprietary systems from various vendors, with ISO's Technical Committee 97 (later JTC1) initiating work on OSI in 1977 to standardize layers including network services. CLNS was positioned at the network layer (Layer 3) to enable datagram-based transmission without prior connection setup, providing a simple, unreliable service suitable for diverse topologies. CLNS drew significant influence from early packet-switched networks like , which demonstrated the viability of connectionless datagram transport for efficient, across heterogeneous systems. 's experience, particularly its use of s in protocols like the 1970s Network Voice Protocol and subsequent IMP designs, informed the U.S. delegation's advocacy for CLNS within ISO, contrasting with European preferences for connection-oriented services rooted in telephony traditions. This advocacy culminated in 1983 when the U.S. threatened to withdraw from the OSI effort unless connectionless crossover was permitted, leading to a compromise that allowed an addendum for CLNS. This positioned CLNS as a foundational service for unreliable, independent , emphasizing over reliability guarantees at the network layer. A key milestone occurred with the publication of the OSI Basic Reference Model in as ISO 7498, which initially focused on connection-mode , with CLNS incorporated through subsequent addenda following the 1983 international compromises. This inclusion, though initially contentious, marked CLNS's formal recognition as an essential OSI component for flexible provision, with full integration in the revision (ISO/IEC 7498-1). Subsequent ISO documents, such as ISO 8348/Add.1 (1987), further detailed its specifications.

Relevant ISO Standards

The Connectionless-mode Network Service (CLNS) is fundamentally defined by ISO 8348:1987/Add.1:1987, an addendum to the base standard ISO/IEC 8348:1987 titled "Information processing systems — Data communications — definition," which establishes the basic framework for connection-mode s at the OSI layer 3, while the addendum details service primitives, parameters, and conformance requirements for connectionless transmission. This standard was amended in 1993 through ISO/IEC 8348:1993, which refined the service definition to incorporate enhancements in addressing and access mechanisms while maintaining the core connectionless primitives such as N-UNITDATA.request and N-UNITDATA.indication for delivery without prior connection setup. Complementing this, ISO 8473:1988 provides the protocol specification for realizing the CLNS, emphasizing service aspects such as the mapping of service primitives to protocol data units (PDUs) and the handling of options for source routing and error reporting, without delving into implementation specifics. Further developments include ISO 8348:1987/Add 2:1988, an addendum on network layer addressing that introduces the structure for Network Service Access Point (NSAP) addresses, enabling IP-like hierarchical formats for global and local identification in connectionless environments. These elements were consolidated in the 1996 revision, ISO/IEC 8348:1996, which withdrew prior versions and integrated the addenda on connectionless transmission and addressing, along with updates to support subnetwork access and multicast capabilities for broader OSI interoperability. All these standards have since been withdrawn, reflecting the evolution toward IP-based networking, but they remain foundational for understanding CLNS in OSI contexts.

Underlying Network Protocols

Connectionless Network Protocol (CLNP)

The Connectionless Network Protocol (CLNP), defined in ISO/IEC 8473, serves as the primary network-layer protocol for implementing the Connectionless-mode Network Service (CLNS) within the . It enables the transfer of data units between network entities without establishing a connection, supporting delivery across diverse network topologies. CLNP realizes key CLNS service primitives, such as the UNITDATA request and indication, by encapsulating user data into protocol data units (PDUs) for transmission. CLNP PDUs consist of a fixed header, variable address fields, optional segmentation and options parts, and a data field. The fixed part, spanning the first 9 octets, includes essential control information: the Network Layer Protocol Identifier (octet 1, set to 1000 0001 for ISO 8473), Length Indicator (octet 2, specifying total header length in octets up to 254), Version/Protocol Identifier Extension (octet 3, set to 0000 0001 for version 1), PDU Lifetime (octet 4, a binary value representing seconds in 0.5-second units to prevent indefinite looping), a Flags octet (octet 5, with bits for Segmentation Permitted, More Segments, and Error Report), Type Code (octet 5 bits 5-1, e.g., 11100 for Data PDUs or 00001 for Error PDUs), Segment Length (octets 6-7, total PDU length in octets), and Checksum (octets 8-9, optionally computed over the header for integrity verification). The address part follows, containing length indicators and the source and destination Network Service Access Point (NSAP) addresses in binary format. Segmentation, if permitted by the SP flag, adds a 6-octet part with Data Unit Identifier (for reassembly), Segment Offset (position in the original PDU), and Total Length (of the initial PDU). The options part employs a Type-Length-Value (TLV) encoding for extensible parameters, such as padding (to align data), security, source routing, and quality of service, where each option begins with a parameter code (1 octet), length (1 octet), and value (variable). Routing in CLNP relies on NSAP addresses, which are variable-length identifiers (up to 20 octets) structured hierarchically with an Area Identifier and System Identifier for scalable addressing, as specified in ISO/IEC 8348/Add.2. These addresses facilitate longest-prefix matching in tables, enabling hierarchical through protocols like (IS-IS, ISO/IEC 10589). Additionally, CLNP supports via a TLV option (parameter code 1100 0101), allowing the source entity to specify an explicit path of intermediate NSAP addresses, which intermediate systems follow strictly while updating the option to reflect progress. This mechanism provides flexibility for policy-based or constrained but is optional and typically used sparingly to avoid issues. Error and diagnostic functions in CLNP enhance by providing feedback on transmission issues. The Error Report (ER) PDU, triggered when a data PDU is discarded (e.g., due to lifetime expiration, invalid segmentation, or protocol errors) and if the ER is set, carries the original PDU's header, a reason-for-discard field (TLV 1100 0001, with codes like 0000 0001 for protocol procedure errors), and optional diagnostic to the source address. This allows source entities to diagnose and mitigate issues such as congestion or misconfiguration. While CLNP lacks a dedicated Diagnostic Report (DR) packet, diagnostic capabilities are integrated into ER PDUs and options like route recording (TLV 1100 1011), which logs traversed NSAPs for path analysis in . For interoperability with (IP) networks, CLNP supports dual-stack environments through address mapping schemes that embed 32-bit IPv4 addresses into NSAP formats. RFC 1069 outlines a method using a 20-octet NSAP with Address Family Identifier (AFI) 47 and embedding the IP address in the Domain-Specific Part (DSP), enabling gateways to route between CLNP and IP domains while preserving end-to-end delivery. This approach facilitated early experiments in multiprotocol internetworks, allowing OSI and TCP/IP coexistence without full protocol replacement.

Implementation in Other Protocols

The (IP), particularly in its IPv4 and IPv6 variants, serves as a functional equivalent to Connectionless-mode Network Service (CLNS) by providing a connectionless delivery mechanism at the network layer, where each packet is routed independently without prior setup of a . This mirrors CLNS's core principle of best-effort, unreliable delivery, with IP s analogous to CLNP protocol data units (PDUs). At the , the User Datagram Protocol (UDP) extends IP to offer a simple, connectionless service similar to how transport protocols interact with CLNS in OSI environments. To enable between IP and CLNS-based networks, standards define mappings between addressing schemes and protocol operations. RFC 986 outlines guidelines for embedding IP addresses within the Network Service Access Point (NSAP) format used by CLNS, allowing IP packets to traverse ISO networks by treating IP addresses as a subset of the NSAP space through a structured prefix and suffix mapping. This approach facilitates dual-stack operation where routers can forward both IP and CLNP traffic, with IP's 32-bit addresses (for IPv4) padded or aligned to fit the variable-length NSAP structure up to 20 octets. For address translation specifically, RFC 1707 proposes a common architecture () that integrates NSAP addressing into IPng (the precursor to ), using algorithmic mappings to translate between NSAP and realms without requiring full encapsulation, though it emphasizes prefix-based compatibility for routing efficiency. Beyond open standards, proprietary protocols have implemented CLNS-like functionality in vendor-specific networks. DECnet Phase V, introduced by , adopts the ISO Connectionless-mode Network Service as its foundational layer, utilizing ISO 8473 (CLNP) for datagram transfer while integrating proprietary extensions for and . This implementation provides end-to-end datagram delivery over diverse media, with Phase V routers exchanging reachability information via ES-IS and protocols adapted from OSI. Similarly, AppleTalk's Datagram Delivery Protocol (DDP) offers a partial analog to CLNS in local area networks, delivering connectionless packets socket-to-socket without reliability guarantees, relying on underlying data-link protocols for transmission. DDP supports both short and long headers for addressing, enabling across AppleTalk internetworks via the Maintenance Protocol (RTMP). In non-OSI contexts, these implementations face limitations due to the absence of native NSAP addressing, often necessitating encapsulation techniques such as tunneling CLNP over IP (e.g., via GRE) or address mapping proxies to bridge domains. For instance, DECnet Phase V requires NSAP-derived addresses for CLNS compatibility, but interoperability with IP demands additional translation layers, potentially introducing overhead in mixed environments. AppleTalk's DDP, while efficient in homogeneous networks, lacks the hierarchical NSAP structure, limiting direct equivalence and requiring protocol converters for broader integration.

Transport Layer Interactions

Transport Protocol Class 4 (TP4) with CLNS

Transport Protocol Class 4 (TP4), defined in ISO/IEC 8073, is a connection-oriented transport protocol that operates over the Connectionless-mode Network Service (CLNS) to provide end-to-end reliable data transfer across unreliable datagram networks. This integration, specified in the addendum ISO 8073/Add.2, enables TP4 to utilize CLNS as the underlying datagram substrate for network delivery while adding transport-layer features such as multiplexing via Transport Service Access Points (TSAPs) and optional checksums for error detection. TP4's design assumes a low-quality network service (Type C), compensating for CLNS's lack of inherent reliability through protocol mechanisms that ensure ordered delivery and error handling. In TP4 over CLNS, protocol data units (PDUs) known as Transport Protocol Data Units (TPDUs) facilitate connection establishment, data transfer, and teardown. Key TPDUs include the Connection Request (CR) and Connection Confirm (CC) for setup, Data Transfer (DT) for user data conveyance with sequence numbering, Acknowledge (AK) for confirming receipt, and Disconnection Request (DR) for termination, along with Error (ER) TPDUs for reporting issues. The service primitives supporting these operations are connection-mode specific, such as T-CONNECT for establishment, T-DATA for normal data transfer (including expedited data via T-EXPEDITED-DATA), and T-DISCONNECT for release; these primitives map to N-UNITDATA requests and indications at the network layer interface. TP4 supports optional segmentation and reassembly of large Transport Service Data Units (TSDUs) into multiple DT TPDUs, using sequence numbers and offsets to reconstruct data at the receiver, with limits typically aligned to network MTU constraints like 576 bytes. Reliability in TP4 over CLNS is enhanced through built-in mechanisms rather than relying solely on applications, including verification in TPDUs to detect , retransmission of unacknowledged DT TPDUs via timers and queues, flow control using a , and explicit acknowledgments to handle loss, duplication, or misordering. Error detection is further supported by protocol validation checks and counters for issues like invalid TPDUs, with no special action beyond discard for failures in this mode. These features provide resilience against network failures, distinguishing TP4 from lower-reliability classes. TP4 with CLNS has been applied in and legacy systems requiring robust over heterogeneous networks, such as in U.S. Department of Defense environments for protocol gateways between OSI and TCP/IP stacks. It supports NATO-related communications in standards like those for systems, enabling datagram-based transport with added reliability for tactical applications.

Other Transport Protocol Classes

The ISO/IEC 8073 standard defines five classes of connection-mode transport protocols designed to provide reliable data transfer between open systems, with selectable features to match varying network service qualities. These classes—TP0 through TP4—primarily operate over the connection-oriented network service (CONS), but only Class 4 fully supports operation over the connectionless-mode network service (CLNS) by implementing end-to-end error detection and recovery without relying on network-level connections. Class 0 (TP0), known as the simple class, offers the most basic connection-mode functionality, including connection establishment, data transfer with segmentation, and protocol reporting, but lacks recovery or flow control mechanisms. While its minimal overhead and absence of recovery features give it a connectionless-like in terms of simplicity and low reliability assumptions, TP0 is explicitly designed for use over and does not support direct operation over CLNS; any adaptation would require non-standard mappings to emulate a connection-oriented substrate. Classes 1 through 3 (TP1, TP2, TP3) build on TP0 by adding connection-oriented enhancements tailored to environments, where the network service provides a reliable connection for and handling. TP1 (basic error recovery class) includes mechanisms for recovering from network disconnects or resets and supports expedited data transfer, but relies on primitives like N-CONNECT for these functions, limiting it to connection-oriented networks with no standard CLNS support. TP2 ( class) enables multiple transport connections over a single network connection with optional explicit flow control, again requiring for resource sharing. TP3 combines TP1's error recovery with TP2's multiplexing and explicit flow control, providing balanced reliability and efficiency, but like the others, it is confined to due to its dependence on network connection management. These classes offer only limited CLNS interaction through error-prone fallback in experimental or vendor-specific implementations, where reliability is sacrificed, but such uses deviate from the standard's intent. In hybrid network environments combining and CLNS domains, connection-oriented classes like TP0–TP3 can be encapsulated over CLNS by employing intermediate protocols or gateways that simulate CONS behavior, such as mapping transport connections to sequences with added reliability layers; however, this approach increases complexity and is not natively defined in ISO 8073, often favoring TP4 for seamless CLNS integration.

Comparisons and Applications

Versus Connection-Oriented Services

Connectionless-mode Network Service (CLNS) and Connection-oriented Network Service (CONS) represent the two primary modes of operation defined for the OSI network layer in ISO/IEC 8348, enabling flexible protocol stack configurations to meet diverse application requirements. CLNS provides a datagram-oriented service where each data unit is transmitted independently, without establishing a logical connection, as specified in the addendum to ISO/IEC 8348 (ISO/IEC 8348/Add.1). In contrast, CONS relies on the establishment of a virtual circuit through explicit call setup and release phases, maintaining connection state throughout the communication session. This fundamental distinction arises from CLNS's use of the N-UNITDATA primitive for self-contained data transfers, eliminating the need for synchronization or circuit allocation, whereas CONS employs N-CONNECT primitives to negotiate parameters and reserve resources prior to data exchange. The absence of virtual circuits in CLNS avoids the setup overhead and state maintenance associated with , which can introduce delays in dynamic or large-scale networks. Implemented protocols reflect this: ISO/IEC 8473 (CLNP) handles datagrams without session tracking, while ISO/IEC 8208 (for X.25-based ) enforces call establishment to ensure path consistency. As a result, CLNS incurs minimal per-packet processing, making it efficient for environments with heterogeneous subnetworks, but it lacks inherent mechanisms for error correction or ordering, shifting reliability responsibilities to higher layers. In terms of performance, CLNS offers lower latency and reduced overhead for bursty or short-lived patterns, as there is no initial or teardown, enabling immediate transmission of data units up to 64,512 octets. However, without built-in acknowledgments or retransmission, CLNS carries a higher risk of or reordering in unreliable underlying networks, potentially requiring application-level recovery. CONS mitigates these issues through its connection-oriented design, providing sequenced and error-checked delivery at the cost of higher and susceptibility to congestion during setup. CLNS proves suitable for real-time applications or scenarios, where rapid, independent packet dispatch prioritizes timeliness over guaranteed delivery, such as in broadcast messaging across diverse networks. Conversely, excels in use cases demanding reliable, sequential streams, like file transfers or transaction-oriented communications, where the overhead of connection management ensures . The OSI framework's duality in ISO/IEC 8348 allows transport protocols and applications to select between these services based on specific quality-of-service needs, promoting in multi-vendor environments.

Practical Uses and Modern Relevance

Connectionless-mode Network Service (CLNS) found historical deployment as an alternative to the connection-oriented X.25 networks, offering datagram-based communication for more efficient, scalable in wide-area environments. In particular, the Intermediate System to Intermediate System () routing protocol, standardized in ISO 10589 and republished as RFC 1142 in 1990, enabled CLNS-based internetworks by facilitating of connectionless datagrams across domains. During the , European research and wide-area networks emphasized , including CLNS, to support in emerging pan-European infrastructures, as evidenced by initiatives like those documented in RFC 1210. In modern contexts, CLNS maintains residual use in specialized defense systems, where it ensures for networks through end-system provided connectionless services, as outlined in the U.S. Defense Message System . Emulation persists via software implementations, such as loadable kernel modules for the Connectionless Network Protocol (CLNP) in version 2.6, allowing testing and integration in contemporary environments. Additionally, CLNS integrates with (MPLS) for virtual private networks (VPNs), where BGP carries CLNS reachability information to support Layer 3 VPN services over NSAP addressing. CLNS served as a conceptual precursor to UDP/IP datagram services, providing similar connectionless capabilities in OSI environments and inspiring proposals like (TCP and UDP with Bigger Addresses), which envisioned running UDP and TCP directly over CLNS as a potential IPv4 successor. Tools for CLNS testing, integrated within modules, facilitate evaluation of its handling akin to IP tools. Despite these parallels to connection-oriented services like for unreliable traffic, CLNS's emphasis on aligned more closely with UDP's lightweight model. The decline of CLNS stemmed from TCP/IP's greater simplicity, earlier deployment, and broader vendor support, rendering less practical for widespread adoption by the late 1990s.

References

  1. https://www.itu.int/rec/T-REC-X.213/en
  2. https://www.iso.org/standard/35872.html
  3. https://datatracker.ietf.org/doc/html/rfc994
  4. https://cdn.standards.iteh.ai/samples/27728/7f5f28b914494e6b930645c0d49336aa/ISO-IEC-8348-1996.pdf
  5. https://www.ecma-international.org/wp-content/uploads/s020269e.pdf
  6. http://ccr.sigcomm.org/archive/1995/oct95/ccr-9510-day.pdf
  7. http://www.bitsavers.org/pdf/datapro/communications_standards/2783_ISO_OSI.pdf
  8. https://cdn.standards.iteh.ai/samples/14253/a175344aa41f44208f4751e9a340c0bf/ISO-7498-1984-Add-1-1987.pdf
  9. https://www.iso.org/standard/15488.html
  10. https://www.iso.org/standard/20159.html
  11. https://www.iso.org/standard/15677.html
  12. https://www.iso.org/standard/15490.html
  13. https://www.iso.org/standard/27728.html
  14. https://www.rfc-editor.org/rfc/rfc994.txt
  15. https://datatracker.ietf.org/doc/html/rfc986
  16. https://apps.juniper.net/feature-explorer/feature/3675?fn=Connectionless%20Network%20Service%20%28CLNS%29
  17. https://datatracker.ietf.org/doc/html/rfc1707
  18. https://bitsavers.org/pdf/dec/decnet/EK-DNAPV-GD_DECnet_Phase_V_General_Description_Sep87.pdf
  19. https://www.cisco.com/c/en/us/td/docs/ios/decnet/configuration/guide/15_0s/dec_15_0s_book/overview_decnet.pdf
  20. https://developer.apple.com/library/archive/documentation/mac/pdf/Networking/DDP.pdf
  21. https://developer.apple.com/library/archive/documentation/mac/pdf/Networking/Introduction_to_AppleTalk.pdf
  22. https://www.cisco.com/c/en/us/td/docs/ios/decnet/configuration/guide/12-2SY/dec_12_2sy_book/configuring_decnet.html
  23. https://datatracker.ietf.org/doc/html/rfc1742
  24. https://cdn.standards.iteh.ai/samples/19979/c56005defba340c392563ee9ebf74fe5/ISO-IEC-8073-1992.pdf
  25. https://apps.dtic.mil/sti/tr/pdf/ADA206582.pdf
  26. https://www.rfc-editor.org/rfc/rfc1007.html
  27. https://www.iso.org/standard/18433.html
  28. https://www.iso.org/standard/20269.html
  29. http://www.employees.org/univercd/Feb-1998/CiscoCD/cc/td/doc/cisintwk/ito_doc/55165.htm
  30. https://www.packetizer.com/osi/understanding_osi/chapter4.html
  31. https://www.rfc-editor.org/rfc/rfc1142.txt
  32. https://datatracker.ietf.org/doc/rfc1210/
  33. https://apps.dtic.mil/sti/tr/pdf/ADA256701.pdf
  34. https://arxiv.org/pdf/1204.4301
  35. https://www.juniper.net/documentation/us/en/software/junos/bgp/topics/topic-map/clns.html
  36. https://blog.ipspace.net/2015/05/reinventing-clns-with-l3-only-forwarding/
  37. https://blog.ipspace.net/2008/04/what-is-clns/
Add your contribution
Related Hubs
Contribute something
User Avatar
No comments yet.