User:Julia.ursi/sandbox
The PJON protocol v3.0 in local mode supports connectivity for up to 254 devices, in shared mode supports connectivity for up to 4.294.967.295 buses (groups of devices) and up to 1.090.921.692.930 devices. The packet format is dynamic therefore meta-data can be optionally included using the header as a bitmap of selected features supporting interoperability between systems configured differently and providing with high efficiency including only the protocol's features used and the overhead (5-22 bytes) effectively required. Thanks to its modularity, dynamic packet format, low memory footprint and low overhead PJON can be used as an alternative to 1-Wire, i2c or CAN to connect a local network of micro-controllers with limited resources but can also be applied in place of IP to interconnect more complex networks.
Overview
[edit]- Packet transmission is regulated by a 1 byte header
- Devices communicate through packets with a maximum length of 255 or 65535 bytes
- Devices are identified by a unique 1 byte device id
- Devices can obtain an id if available (see Dynamic addressing specification v1.0)
- Buses are identified with a 4 bytes bus id
- Many buses can coexist on the same medium
- Synchronous and or asynchronous acknowledgement can be requested (see Acknowledge specification v1.0)
- Network services are identified with a 2 bytes service identifier
Layers
[edit]The PJON protocol is structured by two layers: network layer and data link layer.
Network layer
[edit]- Local and shared network addressing
- Broadcast or addressed packet transmission
- Routing and switching
- Congestion control
- Error detection
- Packet identification
- Service identification
- Asynchronous acknowledgement
Data link layer
[edit]- Medium access control
- Frame transmission
- Synchronous acknowledgement
Error detection
[edit]PJON supports both CRC8 and CRC32 to ensure safety on a wide range of use cases and packet lengths.
CRC8 polynomial
[edit]0x97 = (x + 1)(x^7 + x^6 + x^5 + x^2 + 1)^2
CRC8 C2, implicit +1 notation, source Baicheva98, is used because it has the largest possible length (119 bit) at which HD=4 can be achieved with 8-bit CRC. Other protocols specify the use of polynomials with much lower performance like CRC-8 0xEA or DOWCRC 0x8C used by 1-Wire.
CRC32 polynomial
[edit]0x82608edb = x^32 + x^26 + x^23 + x^22 + x^16 + x^12 + x^11 + x^10 + x^8 + x^7 + x^5 + x^4 + x^2 + x + 1
CRC32 IEEE 802.3 bit-reversed polynomial implicit +1 notation, or 0xedb88320, selected for its high performance on a wide range of lengths, while also being widely evaluated and accepted as a good polynomial.
Protocol examples
[edit]- ARCnet
- ATM
- Cisco Discovery Protocol (CDP)
- Controller Area Network (CAN)
- Econet
- Ethernet
- Ethernet Automatic Protection Switching (EAPS)
- Fiber Distributed Data Interface (FDDI)
- Frame Relay
- High-Level Data Link Control (HDLC)
- IEEE 802.2 (provides LLC functions to IEEE 802 MAC layers)
- IEEE 802.11 wireless LAN
- I²C
- LattisNet
- Link Access Procedures, D channel (LAPD)
- Link Layer Discovery Protocol (LLDP)
- LocalTalk
- MIL-STD-1553
- Multiprotocol Label Switching (MPLS)
- Nortel Discovery Protocol (NDP)
- Point-to-Point Protocol (PPP)
- Profibus
- SpaceWire
- Serial Line Internet Protocol (SLIP) (obsolete)
- Split multi-link trunking (SMLT)
- IEEE 802.1aq - Shortest Path Bridging
- Spanning Tree Protocol
- StarLan
- Token ring
- Unidirectional Link Detection (UDLD)
- UNI/O
- 1-Wire
- and most forms of serial communication.
Relation to the TCP/IP model
[edit]In the Internet Protocol Suite (TCP/IP), OSI's data link layer functionality is contained within its lowest layer, the link layer. The TCP/IP link layer has the operating scope of the link a host is connected to, and only concerns itself with hardware issues to the point of obtaining hardware (MAC) addresses for locating hosts on the link and transmitting data frames onto the link. The link layer functionality was described in RFC 1122 and is defined differently than the Data Link Layer of OSI, and encompasses all methods that affect the local link.
The TCP/IP model is not a top-down comprehensive design reference for networks. It was formulated for the purpose of illustrating the logical groups and scopes of functions needed in the design of the suite of internetworking protocols of TCP/IP, as needed for the operation of the Internet. In general, direct or strict comparisons of the OSI and TCP/IP models should be avoided, because the layering in TCP/IP is not a principal design criterion and in general considered to be "harmful" (RFC 3439). In particular, TCP/IP does not dictate a strict hierarchical sequence of encapsulation requirements, as is attributed to OSI protocols.
See also
[edit]- ALOHAnet#ALOHA protocol
- ODI
- NDIS
- SANA-II – Standard Amiga Networking Architecture, version 2
References
[edit]
- S. Tanenbaum, Andrew (2005). Computer Networks (4th ed.). 482,F.I.E., Patparganj, Delhi 110 092: Dorling Kindersley(India)Pvt. Ltd.,licenses of Pearson Education in South Asia. ISBN 81-7758-165-1.
{{cite book}}: CS1 maint: location (link) - Odom, Wendel (2013). CCENT/CCNA ICND1 100-101, CCENT Official cert guide. Paul Boger, cisco press. ISBN 1-58714-385-2.
External links
[edit]